On Aug 10, 2013, at 10:55 PM, Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com<mailto:hallam(_at_)gmail(_dot_)com>> wrote:
On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir
<ynir(_at_)checkpoint(_dot_)com<mailto:ynir(_at_)checkpoint(_dot_)com>> wrote:
On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan
<hadriel(_dot_)kaplan(_at_)oracle(_dot_)com<mailto:hadriel(_dot_)kaplan(_at_)oracle(_dot_)com>>
wrote:
But, if the IESG feels an encoding mechanism doesn't need any targeted
use-case to be published as a PS, then please ignore my email for purposes of
consensus. I'm not strongly for/against - just answering Barry's original
question, from the peanut gallery as I said in my original email. And as I
said in my original email: "[the draft] doesn't appear to contain technical
errors nor fail to meet its self-stated design objectives."
I don't know about the IESG, but I don't think an encoding mechanism or for
that matter any format needs to have a targeted use case. WebSec is currently
debating ([1] whether to put the key pinning data in an HTTP header or in a
resource. If we choose the latter, there will be the question of encoding, and
we will probably consider things like XML, JSON, ASN.1, and CBOR, or roll our
own new one-time format. If someone in the group wants to do the one-off
format, we will ask why not use XML, JSON, or CBOR (nobody's going to ask about
ASN.1, because those that care enough to suggest it also know to call it BER),
and of course you'll need a good reason not to use a documented format, whether
it's "standard" or not.
Those will be the obvious choices regardless of whether CBOR is Informational,
Experimental, PS, or still a draft-bormann. Nobody's proposing technical
changes, so we might as well stick an RFC number on it. IMO the only time you
stick the "INFORMATIONAL" label on a protocol or an encoding, is when you are
just documenting a protocol or an encoding that exists outside the IETF, and
the IETF is not given change control. See draft-ietf-websec-x-frame-options for
an example. Experimental is for things where we don't know if they work in
general or if they scale. IOW, we're not sure they're appropriate for their
stated goal. That is not the case with CBOR.
Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning
(intended to be PS) with a downref. But just because downrefs exist does not
mean we should aim for them. PS is the right choice IMO.
If key pinning was to use CBOR rather than JSON or ASN.1, I think you are going
to be laughed at.
Since pins are to ASN.1 encoded certificates, I think you are obliged to choose
ASN.1 if you want the browser people to implement.
I think the browser people also have a JSON parser lying around somewhere. But
I agree that CBOR would increase the cost of implementation, and that's a good
argument against choosing CBOR. It's also a good argument against choosing any
new encoding anybody might propose.
But lets consider the case that you did decide on CBOR. The Working Group would
then be obliged to look at the specification and persuade key stakeholders to
implement the code. And that might result in changes of the 'remove this half
of the specification before we will accept it' variety or the 'we won't
implement unless the encoding is ASN.1'.
At the very least it means that the 'design goals' would get a work out.
But why would CBOR be on the table and not BJSON or JSON-B or any of the other
potential choices?
I don't see why any of them would be off the table.
Yoav