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

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2012 10:58:25 -0700

On Apr 25, 2012, at 5:35 PM, Joe Salowey wrote:

> This is an announcement of working group last call for draft-ietf-tls-oob-pubkey-03.txt.  Please complete reviews and send comments to the TLS list by Friday May 18, 2012.  

I support this document moving forwards, but it requires some significant changes first.

First, the document needs to say "Updates: 6091" because it very much updates 6091.

More importantly, the client auth text added in the last round was:

3.5.  Client authentication

   Client authentication by the TLS server is supported only through
   authentication of the received client SubjectPublicKeyInfo via an
   out-of-band method

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.

It is insufficient because it does not say how the client should respond if RawPublicKey certificates have been selected but the client does not have a raw client certificate.

I believe that an equivalent of the "empty_cert" used in RFC 6091 is needed to be defined here and then used in wording such as:

 Therefore, this section should probably instead say:

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.

I hope this helps.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2012 11:01:02 -0700

On Apr 26, 2012, at 10:57 AM, Paul Wouters wrote:

> On Thu, 26 Apr 2012, Simon Josefsson wrote:
> 
>> Major concerns:
>> 
>> 1) Section 3.1 and 3.2 more or less duplicate section 3.1 and 3.2 of RFC
>> 6091.  Wouldn't it be better to describe the RawPublicKey
>> CertificateType alone, rather than duplicating the entire
>> CertificateType extension?
> 
> I think you are right. This was originally done because it started as
> a new TLS extension, and then also covered what has now been moved to
> cached-objects.

However, there is a good reason to leave the text as-is: this draft is meant to be on standards track and RFC 6091 is an Informational RFC. In order to make this document standards track, it probably needs to define the format again.

Alternately, the WG could simultaneously try to get RFC 6091 made standards track and eliminate the duplication. I don't know if anyone cares enough about OpenPGP certificates to do so; I certainly don't, given that the OpenPGP WG never bothered to do specify enrollment procedures for them.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 00:00:45 +0200 (MEST)

> This is both wrong and insufficient.

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.

If you want to allow an assymetric authentication scheme
(i.e. Server->client OOB in combination with client->server X.509),
then it will be additionally necessary either to seperately negotiate
the type of client "certificate" and require to redefine both,
the CertificateRequest handshake message and the client's
Certificate Handshake message to distinguish which client
certificate type(s) the server is offering and which
client "certificate" type the client has chosen to use.

... at which point it is no longer possible to make this an
extension to rfc6091.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 May 2012 15:06:58 -0700

> client and server, so this will not fit into the extensibility provided

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?

> If you want to allow an assymetric authentication scheme...

I do not.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 01:34:09 +0200 (MEST)

Paul Hoffman wrote:
> Martin Rex wrote:
> 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):

>>> 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.

  [...]

>>>  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

---

From: Martin Rex <[email-masked]>
Date: Sat, 5 May 2012 01:49:21 +0200 (MEST)

following up to myself...

> OpenPGPCertDescriptorType:

Actually, the whole section defining the exact contents of the
Certificate structure (->rfc6091 section 3.3) and its dependency/interaction
with the TLS key exchange method is missing in tls-oob-pubkey-03.

While it is certainly possible to create a simpler Certificate
structure than rfc6091 section 3.3 (omitting the additional descriptor type)
and selection, reusing that from 6091 would facilitate merging this extension
and the PGP extension into a single document.

-Martin