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

[Martin Rex <[e-mail]>]

Paul Hoffman wrote:
> 
> Martin Rex wrote:
> > 
> > I believe it is acceptable and more correct than your proposed
> > alternative.
> > 
> > RFC6091 does _not_ permit different certificates types for
> > client and server, so this will not fit into the extensibility provided
> > by rfc6091.
> 
> Ummmm, I never said that it did.
> My proposed alternative wording was to deal with exactly the case of
> both sides using raw keys. Why did you think different?

Ooops, I'm sorry.

Your proposed replacement text is actually much less problematic
than the description heading it (and which I had better quoted):

>>>
>>> This is both wrong and insufficient.
>>>
>>> It is wrong in that the server might also authenticate the client
>>> through a future TLSA-type protocol that handles user certificates,
>>> and might also authenticate the client through LDAP. The entire
>>> sentence can be removed.

  [...]

>>>  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
  "empty_cert" that contains a RawPublicKey value

I believe wie 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;



Btw. -oob Section 3.3 should be modified similar to rfc6091 section 3.4:

current:

   3.3. Certificate Request

   The semantics of this message remain the same as in the TLS
   specification.

new:

   3.3. Certificate Request

   The semantics of this message remain the same as in the TLS
   specification.  However, if this message is sent, and the negotiated
   certificate type is RawPublicKey, then the "certificate_authorities"
   list MUST be empty.


-Martin