Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-tls-oob-pubkey-11

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?

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.

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/