Re: [TLS] draft-ietf-tls-multiple-cert-status-extension-04

["Yngve N. Pettersen" <[e-mail]>]

On Fri, 29 Mar 2013 13:37:22 +0100, Sean Turner <[e-mail]> wrote:

> On 3/28/13 12:51 PM, Yngve N. Pettersen wrote:
>>
>> Hello Hannes
>>
>> Thanks for the review.
>>
>> 1) Updating RFC 6066
>>
>> It might be that it can be said to update 6066, but I have leaned
>> towards that it is not updating 6066, since, while most of the new
>> structures are derived from the 6066 definitions, they are really only
>> defined for the new extension.
>>
>> If RFC 6066 had only defined the OCSP stapling system, I would have been
>> inclined to say my draft obsoleted it, but that is not workable since
>> there are other extensions defined in it.
>>
>> It could be that the update of the CertificateStatus message count as
>> such an update, even if it is only defined for the new extension.
>>
>> Do the Chairs or AD have any opinions on this?
>>
>>
>>> Would you expect that someone uses RFC 6066 or would they instead use
>>> draft-ietf-tls-multiple-cert-status-extension-04
>>> with respect to the OCSP procedure?
>>
>> In a transition phase I would expect clients to send both the 6066
>> CertificateStatus request extension, and the new one defined by my
>> draft. Long term I would expect a change to only using the new  
>> extension.
>
> If this is a new standalone extension, then it doesn't update RFC 6066.  
>   In the past "updates" has sometimes been used as a "see also" tag, but  
> that's now gently being stomped out.

OK

>> Servers supporting both should IMO return the new extension.
>
> If you say this in the draft then I'd be leaning towards an update. That  
> is if you changing behavior about an extension that's in 6066 it's an  
> update.

I am not planning such language. I'll leave it up to implementors to make  
such decisions, but I also hope they will see the benefit of using the  
newer extension when it is presented.


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/