Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Yoav Nir <ynir@xxxxxxxxxxxxxx>]

On Aug 10, 2013, at 10:55 PM, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote:

On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir <ynir@xxxxxxxxxxxxxx> wrote:

On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> 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