RE: [TLS] TLS 1.2 hash agility

[<Pasi.Eronen at nokia.com>]

The "_sign" part in "rsa_sign" also means that the cert has to 
contain a RSA public key that can be used for signing. So
if we defined a new type, it would be called "rsa_sign_v1_2" 
or something...

At this point of the protocol, we already know what protocol 
version was negotiated, so changing the semantics is possible 
without ruining backwards compatibility.

Besides, it wouldn't be enough to define a new "rsa_" type; 
this issue applies to all client certificate types, so 
we'd have to obsolete all of them ("MUST NOT send any of these
if TLS 1.2 is negotiated") and assign new numbers. This would 
also require revising RFC 4492, which I'd rather avoid...

Best regards,
Pasi

> -----Original Message-----
> From: ext Russ Housley [mailto:housley at vigilsec.com] 
> Sent: 27 September, 2007 19:26
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: tls at ietf.org
> Subject: RE: [TLS] TLS 1.2 hash agility
> 
> For backward compatibility, wouldn't it be cleaner to add a new 
> rsa_xxx type to indicate the different semantics.  The new type would 
> not be supported by non-TLS v1.2 implementations, nut the handling of 
> rsa_sign wouid be the same in all cases.
> 
> Russ
> 
> 
>   At 05:41 AM 9/27/2007, Pasi.Eronen at nokia.com wrote:
> >mike-list at pobox.com wrote:
> >
> > > The only thing I could come up with is that putting the list of
> > > signature algorithms in the CertificateRequest is a change to the
> > > format of that message, so it requires version-specific 
> processing,
> > > whereas if you use the server extension, the format of Certificate
> > > Request is the same as previous TLS versions.
> >
> >CertificateRequest will require version-specific processing anyway,
> >because its semantics will change. For example, in TLS 1.0/1.1
> >ClientCertificateType "rsa_sign" meant a certificate containing
> >an RSA key, and signed with RSA. In TLS 1.2, it will probably
> >mean just a cert containing an RSA key; the signature algorithm
> >part will be specified separately.
> >
> >(Another difference is that in TLS 1.0/1.1, clients that didn't
> >have certificates often just ignored CertificateRequest;
> >current draft of TLS 1.2 mandates sending an empty Certificate
> >message instead.)
> >
> >Best regards,
> >Pasi
> >
> >_______________________________________________
> >TLS mailing list
> >TLS at lists.ietf.org
> >https://www1.ietf.org/mailman/listinfo/tls
> 
> 

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls