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

[Paul Wouters <[e-mail]>]

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.


> 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