Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-tls-oob-pubkey-11
Yes
(Sean Turner)
No Objection
(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 10 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2013-11-17 for -10)
Unknown
Just a few editorial comments on this fine document, all purely at the nit level. Accept or reject as you see fit, and no need to respond unless you want to. -- Section 1 -- OLD Alternative methods are available that allow a TLS clients/servers to obtain the TLS servers/client public key: NEW Alternative methods are available that allow a TLS client/server to obtain the TLS server/client public key: END Probably also best to change the first bullet to "The TLS client" also, so all is consistent (the other bullets start that way). Some other minor grammar/usage editing, if I may: OLD This document introduces the use of raw public keys in TLS/DTLS. Raw public key thereby means that only a sub-set of the information found in typical certificates is utilized, namely the SubjectPublicKeyInfo structure of a PKIX certificates that carries the parameters necessary to describe the public key. Other parameters also found in a PKIX certificate are omitted. A consequence of omitting various certificate related structures is that the resulting raw public key is fairly small (compared to the original certificate) and does not require codepaths for the ASN.1 parser, for certificate path validation and other PKIX related processing tasks. NEW This document introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificates that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys does not require paths for an ASN.1 parser, for certificate path validation, and for other PKIX related processing tasks. END The "This document is structured as follows" paragraph oddly omits an explanation of Section 6. If you find the paragraph useful, you should probably add "Section 6 describes security considerations with this approach," or some such. -- Section 6 -- Is the indentation of the third paragraph intentional and significant, and, if so, what does it mean?
Richard Barnes Former IESG member
Yes
Yes
(2013-11-19 for -10)
Unknown
Section 1: "does not require codepaths for the ASN.1 parser" That's not really true, since you're still using SubjectPublicKeyInfo, right? Likewise, if you are ultimately going to authenticate the key (as discussed in the Security Considerations), you're going to validate something like a trust chain, e.g., via PKIX or DNSSEC. So I'm not sure you actually get the code size savings you claim. Section 3: "... is represented in a DER encoded ASN.1 format ..." It would be better to say that the subjectPublicKeyInfo value in the Certificate payload MUST contain the DER encoding of the SubjectPublicKeyInfo structure. Just in case someone decides to put BER, XER, etc. in there. Figure 4: Both "select()" statements are missing opening "{" characters.
Sean Turner Former IESG member
Yes
Yes
(for -10)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2013-11-18 for -10)
Unknown
Good to see this getting done. Thanks. - The write-up sez experts to be added by AD. Just noting that in case there's some urgency and a ball-drop, I'm fine if that's done when there's a request to handle. - Section 1, 1st para: I could quibble and say that self-signed certs are just as traditional in TLS. Not as common, but just as traditional. Shouldn't they get some kind of mention? - Figure 1: is 2^24-1 still a good max length? Just checking in case there's a reason now to prefer smaller over same-as-others. - Section 3: definition of SPKI - did you take a look at DANE to see if there's any text there to copy or reference? I'm sure you did, but just in case that's not been done with the final DANE RFC, in which case it'd be worth a quick check now. - Figure 3/algs: Did you think about the curve 25519 equivalent for signatures (ed25519 is it?) - should that use the ECDSA OID or be a new certificate type? Just curious. - 5.1: Be nice if the example made clear that this can work with DH for forward secrecy as well. (As part of a general tendency to want more DH and PFS.) - section 6: "the identity and public key" phrase is a little ickky - wouldn't it be better to talk about identifiers and not identity at least when discussing binding to the public keys? - section 6: what happens if a spec wants to use this but also wants to punt to yet another spec as to how to bind keys/identifiers? (Such as arguably CoAP.) Are you asking that we drag CoAP back to the core wg? I guess not. Maybe that MUST needs some more consideration? I'd suggest s/MUST/need/
Adrian Farrel Former IESG member
No Objection
No Objection
(for -10)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -10)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -10)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -10)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -10)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -10)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(for -10)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -10)
Unknown