ietf
[Top] [All Lists]

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

2013-08-10 15:01:36
On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir <ynir(_at_)checkpoint(_dot_)com> 
wrote:


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


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?


-- 
Website: http://hallambaker.com/
<Prev in Thread] Current Thread [Next in Thread>