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

[Nelson B Bolyard <nelson at bolyard.com>]

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.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls