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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 21 Aug 2008 15:21:06 -0700

If no-one is using this extension without the hash what is the harm in
making it mandatory in the specification?  

It seems also that hash agility can be added in a backward compatible
way as described in

http://wiki.tools.ietf.org/wg/tls/trac/ticket/46

We could define a new extension, but it seems that there are other
enhancements we want to make to it.  It seems that it would make sense
to pursue this as a separate work item (if there are folks interested in
working on it).  

Cheers,

Joe 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Thursday, July 24, 2008 4:52 PM
> To: Nelson B Bolyard
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] Certificate URL extension in 
> draft-ietf-tls-rfc4366-bis-02
> 
> At Thu, 24 Jul 2008 16:04:11 -0700,
> Nelson B Bolyard wrote:
> > 
> > Mike wrote, quoting Joseph Salowey,
> > 
> > >> 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.
> > 
> > Right.  If a new extension must be defined, the onus to do 
> so should 
> > be on those who wish to change the existing extension.  If 
> some folks 
> > want a new extension in which the hash is not optional, and/or the 
> > hash algorithm is flexible (as Mike suggests), then those 
> folks should 
> > define the new extension with those properties.
> > 
> > The people who want to keep the existing extension, as it has been 
> > defined for years, should not need to define a new 
> extension just to 
> > preserve the existing one's semantics.
> 
> So, is there anyone actually using the extension without 
> digests? If so, now is the time to speak up. If not, then the 
> "we want to keep it as-is"
> tends to lose some of its force.
> 
> -Ekr
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls