Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt

[=JeffH <[e-mail]>]

I have a comment on -tls-oob-pubkey-03 itself, and then a followup to the 
client certificate comments...

###

3.1. Client Hello
	.
	.
    The [RFC6091] defined CertificateTypeExtension is extended as
    follows:


    enum { client, server } ClientOrServerExtension;

    enum { X.509(0), OpenPGP(1),
       RawPublicKey([TBD]),
       (255) } CertificateType;

    struct {
       select(ClientOrServerExtension)
           case client:
             CertificateType certificate_types<1..2^8-1>;
           case server:
             CertificateType certificate_type;
       }
    } CertificateTypeExtension;
	.
	.

What the difference is between the above and RFC6091 is not immediately 
apparent (it's only the addition of RawPublicKey([TBD]) to the CertificateType 
enum). This difference should be noted explicitly in the prose and perhaps 
-tls-oob-pubkey should only show the CertificateType enum definition, unless 
ClientOrServerExtension and CertificateTypeExtension are better delineated as 
unchanged and presented for exposition only (or if some form of merge with 
RFC6091 is done as mentioned by Martin Rex).

###

Martin Rex replied:
 >
 >>> Paul Hoffman suggested including this modified version of S 3.5 from
 >>> RFC6091
 >>>
 >>>>  3.5.  Client Certificate
 >>>>
 >>>>  This message is only sent in response to the certificate request
 >>>>  message.  The client certificate message is sent using the same
 >>>>  formatting as the server certificate message, and it is also required
 >>>>  to present a certificate that matches the negotiated certificate
 >>>>  type.  If RawPublicKey certificates have been selected and no certificate
 >>>>  is available from the client, then a certificate structure of type
 >>>>  "empty_cert" that contains an RawPublicKey value MUST be sent.
 >>>>  The server SHOULD respond with a "handshake_failure" fatal alert if
 >>>>  client authentication is required.
 >
 >
 > What is confusing in your description is [this phrase:]
 >
 >   "empty_cert" that contains a RawPublicKey value
 >
 > I believe [we] need another codepoint in the rfc6091 enumerator
 > OpenPGPCertDescriptorType:
 >
 >       enum {
 >            empty_cert(1),
 >            subkey_cert(2),
 >            subkey_cert_fingerprint(3),
 > +          x509_spki(4),
 >            (255)
 >       } OpenPGPCertDescriptorType;
 >
 > because "empty_cert" is not meant to be extensible in rfc6091:
 >
 >      uint24 OpenPGPEmptyCert = 0;
 >
 >       struct {
 >            OpenPGPCertDescriptorType descriptorType;
 >            select (descriptorType) {
 >                 case empty_cert: OpenPGPEmptyCert;
 >                 case subkey_cert: OpenPGPSubKeyCert;
 >                 case subkey_cert_fingerprint:
 >                     OpenPGPSubKeyCertFingerprint;
 >            }
 >       } Certificate;


Actually, in looking at S 3.3 of RFC6091, it appears that other than the first 
paragraph, that section (in RFC6091) is specific to the OpenPGP certificate type.

Shouldn't -tls-oob-pubkey more properly define it's own equivalent structures 
rather than attempt to re-use the apparently OpenPGP-specific ones there in S 
3.3 of RFC6091 (if PaulH's suggestion is adopted)?

fwiw, I agree with PaulH's comments (and with Simon Josefsson's also).

###



HTH,

=JeffH