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

[Hannes Tschofenig <[e-mail]>]

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:

> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls