Subject: [TLS] Followup on RFC 6091 and oob-pubkeys

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Dec 2012 11:41:45 -0800

There has been a bunch of discussion on the mailing list and at the
IETF meeting in Paris about whether we should reuse the RFC 6091
structures and code points (extending them for raw public keys)
or define new structures and code points to handle raw public keys.

To recap the state of affairs:

- TLS w/o RFC 6091 provides for X.509 certificates
- RFC 6091 provides support for OpenPGP as well as a generic
  structure to negotiate other certificate types by defining new code
  points.
- The intent of the OOB draft is to provide support for raw public keys.

The current draft uses new structures. At the meeting it was discussed
whether we could reuse the 6091 code points and the discussion centered
around whether 6091 allowed asymmetric certificate usage. I.e., was it
possible to have the client use a certificate of type A and the server to
use a certificate of type B. (I'm speaking loosely here and including
raw keys within certificates for this purpose). So, for instance, the
server might have a cert but the client merely a raw key. The minutes
(http://www.ietf.org/proceedings/85/minutes/minutes-85-tls) reflect
that there was a somewhat confusing consensus that this was needed
and so if RFC 6091 precluded that we should define new structures/
code points. I volunteered to research this and report back.

After reviewing RFC 6091, I believe that it requires that the client and
server use the same credentials (assuming client authentication at
all). Here's the relevant passage:

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 OpenPGP certificates have been selected and no certificate
   is available from the client, then a certificate structure of type
   "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent.
   The server SHOULD respond with a "handshake_failure" fatal alert if
   client authentication is required.

Based on the above, I believe that the WG consensus implies that we
define new structures with the more general semantics.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 02 Dec 2012 08:59:07 +0100

> define new structures with the more general semantics.

Well since the new use-cases justify that I have no objection. What my
main point is about, is to keep a single certificate type extension in
TLS by defining values to be used for openpgp keys as well, and
deprecate both the previous extension and registry. The openpgp type
could simply be marked as reserved in this draft. This way there will be
no need for two different certificate type extensions for the
applications that need to support both openpgp and raw keys.

If the issue is exhaustion of certificate types, then it should be
increased in size.

regards,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 2 Dec 2012 12:17:06 +0200

Hi Erk, 

thanks for looking at this issue. 

Your observation confirms my impression and in http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06 we define such a new structure (called certificate_type) with a generic semantic. 
I don't care too much about the name of the new extension but I believe it does the job. Can we stick with this design? 

A question that was raised on the list concerned the support of OpenPGP. Currently, the draft only defines the raw public key formats and, of course, allows the ability to add further values to the registry. Is this enough or should the document also populate the values for OpenPGP?

Ciao
Hannes

On Dec 1, 2012, at 9:41 PM, Eric Rescorla wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 02 Dec 2012 11:32:21 -0500

> define new structures with the more general semantics.

If these general semantics are desirable (i believe they are, given the
discussion), it sounds to me like a new draft would obsolete RFC 6091,
since it would provide all the features of 6091 plus the capability to
indicate separate cert types for each peer.

It doesn't make sense for the IETF to have two registries for
certificate types in TLS; I think we should re-use the certificate type
registry from RFC 6091 for this proposal.

Regards,

	--dkg

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 Dec 2012 01:28:00 +0000

> applications that need to support both openpgp and raw keys.

[Joe]  It seems the openpgp specification need to be updated to use the extension.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 Dec 2012 01:33:17 +0000

> indicate separate cert types for each peer.
[Joe] The new draft would define a new extension,  it wouldn't obsolete RFC 60691 because it will not discuss openpgp. 

> registry from RFC 6091 for this proposal.
[Joe] If it was desirable for openpgp to make use of the new semantics of the new extension then another document would be needed to update or obsolete RFC 6091.