Re: [TLS] Certificate URL extension in draft-ietf-tls-rfc4366-bis-02

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On 
> Behalf Of Mike
> Sent: Thursday, July 24, 2008 10:11 AM
> To: tls at ietf.org
> Cc: draft-ietf-tls-rfc4366-bis at tools.ietf.org
> Subject: Re: [TLS] Certificate URL extension in 
> draft-ietf-tls-rfc4366-bis-02
> 
> > The issue is whether to make the hash mandatory in the client 
> > certificate URL extension.  Without the hash it presents some 
> > vulnerabilities in that the certificate can be replaced.  With the 
> > hash it will cause difficulty for clients that are issued a new 
> > certificate that is populated in the repository before they have a 
> > chance to retrieve it.  It seems that on the list there was 
> some very 
> > rough consensus to make the hash mandatory.
> > 
> > In order to resolve this issue I propose that we make the hash 
> > mandatory for this extension.  If this causes an 
> operational problem 
> > in some environments then a new extension can be defined 
> that has an 
> > optional or no hash.
> 
> It doesn't sit well with me that you have URLAndOptionalHash, 
> and then say that the hash is not optional.  Plus it's been 
> optional for more than two years, so changing it now is not 
> backward compatible.
> 
> Another observation is that if a client determines the 
> certificate hash by fetching the certificate and calculating 
> the hash of what it receives, you have not solved the 
> substitution problem -- in fact that makes it worse since the 
> server will be more confident in the certificate than if no 
> hash was sent -- the client needs to be configured with the 
> hash.  (This means that this extension does not lessen 
> configurability requirements; it only allows a client to save 
> a little bit on memory.)
> 
> In addition, it seems you don't want to be stuck with SHA-1 
> anyway, so perhaps it would be best to deprecate the current 
> CertificateURL and create a new extension with hash agility added:
> 
>      struct {
>          opaque        url<1..2^16-1>;
>          HashAlgorithm algorithm;
>          opaque        hash<1..2^8-1>;
>      } URLAndHash;
> 
[Joe] Issue 46 (http://trac.tools.ietf.org/wg/tls/trac/ticket/46)
suggests a mechanism for hash agility that provides some degree of
backward compatibility. 

> Mike
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls