Re: [Gen-art] Gen-art last call review of draft-ietf-tls-multiple-cert-status-extension-04

[Elwyn Davies <[e-mail]>]

On Sat, 2013-03-23 at 14:12 +0100, Yngve N. Pettersen wrote:
> Hi,
> 
> On Sat, 23 Mar 2013 13:48:30 +0100, Elwyn Davies <[e-mail]>  
> wrote:
> 
> >> > Nits/editorial comments:
> > <<snip>>
> >> > s2.2, para 4 on page 5:
> >> >>     In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560
> >> >> <http://tools.ietf.org/html/rfc2560>] is
> >> >>     unclear about its encoding; for clarification,.....
> >> > This probably needs to be flagged up in the IANA considerations so  
> >> that
> >> > an additional reference is added to the registry.
> >> > ALSO I subsequently noted that this same caveat is already in RFC  
> >> 6066.
> >> > Consider referring to the caveat there rather than duplicating it.
> >>
> >> This language is, as you mention, a copy of the RFC 6066 note about this
> >> problem.
> >>
> >> I think it is better to duplicate it, since it is so small. A longer and
> >> more complex section would probably have been referenced, but adding  
> >> such
> >> references for small informational text would IMO make the document less
> >> readable.
> >
> > Fair enough - and I realize this isn't an IANA matter.  However, if this
> > is an issue for RFC 2560, shouldn't somebody file an erratum?  I
> > couldn't see anything about this in the current set of errata.
> 
> It is actually corrected in RFC2560bis  
> <http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/> (sec.  
> 4.4.1), currently in PKIX WG Last Call.
Ah.. That's fine... I don't follow pkix! 
> 
> At present my document is not linked to that document (since that would  
> create a dependency that could block publication), although that might  
> happen if they are actually published around the same time (as Sean is  
> thinking of). Even if it is linked, I think this information should be  
> left in the document, to be on the safe side.
That's also fine.  It doesn't need the hassle but obviously updating the
ref later would help if it doesn't delay things
> 
> As background, to my knowledge no mass market client actually send this  
> OCSP extension, particularly in the stapling request; I am also not aware  
> that any general OCSP responder support it, although I have heard mentions  
> that high security (military) responders do. (Opera did send it in the  
> early OCSP implementations when querying OCSP responders directly). Except  
> for special usage scenarios (like the military one) using this extension  
> and expecting it to be used in the response will lead to extra load on  
> both the server and the responder, as well as extra overhead, removing  
> much of the benefit of the stapling system.
> 
Such is life!
Thanks for the explanation.
/Elwyn