Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul
> Wouters
> Sent: Tuesday, April 10, 2012 9:09 AM
> To: Paul Hoffman
> Cc: tls@ietf.org
> Subject: Re: [TLS] Client certificate authentication and
draft-ietf-tls-oob-
> pubkey
> 
> On Tue, 10 Apr 2012, Paul Hoffman wrote:
> 
> >> When the TLS client contacts the server, it has some idea of who it
> >> is contacting for the out of band authentication of the received raw
> >> public key. The server has no such idea when it is contact out of the
> >> wild, and if it just receives a SPKI without any identifier, then it
> >> cannot really know what to do.
> >
> > Sure it can. The same way that the client would have an internal list of
DNS-
> to-SPKI associations, the server could have an internal list of ID-to-SPKI
> associations.
> 
> True. It wouldn't be the best system, but you are right.
> 
> >> This is why I suggested the TLS extension equivalent for SNI for the
> >> client.
> >
> > Where is this suggested?
> 
> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already
> removed there after discussion with EKR in Quebec City.
> 

If this is really what you want to do, then I would suggest that the
document be expanded so that there exists the possibility to include an
identifier and/or a public key in the certificate form defined by the oob
document.

Jim

> 
> > True, but the current draft needs to say how it implements the RFC 6091
> semantics. Leaving it silent will lead to misunderstanding.
> >
> >> But as there is no way currently for the TLS client to convey its own
> >> cert_type is different than then cert_type it requested of the
> >> server, I guess we should stick with using the same cert_type symantics
as
> in 6091.
> >
> > Why, yes, you should. :-)
> >
> >> That would mean that without a new TLS extension, that TLS servers
> >> sending a certificate_request in response to receiveing a
> cert_type="RawPublicKey"
> >> is likely to end in a failed TLS connection, because the server
> >> cannot authenticate the client based on the received certificate of
type
> RawPublicKey.
> >
> > As above, I don't see why that is the case. A server can get client
names
> and SPKIs out of band just as a client can.
> 
> Yes, it can, but not "as a client can", because the client knows which
identity
> it is going to contact, while the server does not know which identity it
is
> contacted by.
> 
> > Please add clarifying text regardless, and then we can discuss if we
agree
> with it.
> 
> Will do.
> 
> Paul
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls