[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue
From:       Nikos Mavrogiannopoulos <nmav () gnutls ! org>
Date:       2012-07-11 17:36:50
Message-ID: 4FFDB9B2.2000404 () gnutls ! org
[Download RAW message or body]

On 07/11/2012 06:08 PM, Hannes Tschofenig wrote:


> > > I would be great to get your feedback on an open issue that concerns the \
> > > semantic of the exchange. I believe there are three use cases we would like to \
> > > support with this work. Below, I provide high level message exchanges to \
> > > explain those:  I) Server uses Raw Public Keys (client authentication happens \
> > > at some other layer)
> > If you don't need a client certificate or public key, you don't send a
> > certificate request.
> You mean: If the server does not want any client authentication then it does not \
> send a certificate request.  If that's what you mean then I agree with you. 
> But in this scenario the server provides the raw public key. 


This is what I mean. I don't understand understand how providing the raw
public key changes this fact. Did you explicitly specified in the
draft-ietf-tls-oob-pubkey that no certificate request is expected? If
not I would expect the TLS semantics to remain.

> > > II) Client and Server use Raw Public Keys
> > > (the smart object use case - CORE working group)
> > Your draft already covers that case.
> That's what I thought but Paul had a different understanding. 
> It is not quite clear what the semantic of the cert_type="RawPublicKey" in the \
> client hello message is. 


Then the semantics should cleared up. What is the different
understanding? As I understand this draft, if the extension is present,
then _both_ server and client certificates are encoded in "raw" format.

> > 2.

> > You create a new extension that modifies the format of the certificate
> > request to include an explicit certificate format.
> Of course the existing certificate format cannot (and should not) be changed. 
> One could put an additional marker into the cert payload that makes it easy for the \
> client and the server to differentiate the content of the payload.  


And would also be easier to mount attacks in the protocol. If you change
the format of the certificates it should be clear in the handshake what
certificate format is expected.

regards,
Nikos


[prev in list] [next in list] [prev in thread] [next in thread]