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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Paul Wouters [mailto:[e-mail]]
> Sent: Wednesday, April 11, 2012 11:10 AM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: RE: [TLS] Client certificate authentication and
draft-ietf-tls-oob-
> pubkey
> 
> On Wed, 11 Apr 2012, Jim Schaad wrote:
> 
> >> 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.
> 
> Personall, I strongly prefer not adding more fields to the bare key
certificate
> type, as those people who want to cover client authentication can use full
> PKIX certs already, and TLS client authentication in the wild seems to be
> extremely rare. The only two cases I knew are CAcert and Fedora (and for
> the latter it does not even add security, as I need to identify with
another
> factor anyway (yubikey))
> 
> Is there an actual use case where bare keys would be preferable over full
> PKIX, that also include client auth not based on burned in keys covered by
> server side SPKI lookups?

Please put me onto the very confused list.

In your response to Paul yesterday, you stated that you wanted a TLS
extension which did SNI for the client, this is what I was suggesting you
put into your structure.

I was under the impression that you were arguing that looking up the SPKI at
the server was not going to work and that therefore something else was
needed.

Now you seem to be stating that certificates should be what is used for
client authentication.

None of this is clear from the current document.  And only the case of
looking up SPKI would seem to be even possible from the current document.
If you state that the certificate structure that is going to be used is the
OOB certificate structure then it is going to be the one used by both the
client and the server.  If you sometimes change this it will make for a very
confused server.  This means that whatever types of information you need to
identify the client to the server for authentication needs to be in this
structure definition. 

If you look at what was done in RFC 6091 - they 

1) were very explicit about what the client certificate was and
2) defined a special case for sending an empty PGP certificate slot when the
client did not have one available.

Jim


> 
> Paul