Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

["Piyush Jain" <[e-mail]>]

Not arguing that it should be required. I'm with you on keeping it optional.

It is your statement about backward compatibility to justify it that is
incorrect.
Backward compatibility "with deployments of RFC2560" is not affected in
either case. Legacy clients will continue to work whether you make it
required or optional.

You probably meant "maintain compliance with RFC 2560 and RFC 5019."

-Piyush

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Friday, March 29, 2013 9:37 AM
> To: Piyush Jain; 'Black, David'; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> On 3/29/13 5:17 PM, "Piyush Jain" <[e-mail]> wrote:
> 
> >' "revoked" status is still optional in this context in order to
> >maintain backwards compatibility with deployments of RFC 2560.'
> >
> >I fail to understand this statement about backward compatibility.
> >How does "revoked" being "optional/required breaks backward
> compatibility?
> >The only reason cited in the WG discussions to use revoked for
> >"not-issued"
> >was that any other approach would break backward compatibility with
> >legacy clients. And now the draft says that revoked is optional because
> >making it required won't be backward compatible.
> 
> Yes. Making it required would prohibit other valid ways to respond to this
> situation that is allowed by RFC 2560 and RFC 5019.
> Such as responding "good" or responding with "unauthorized" error.
> 
> >
> >And it gives the impression that best course of action for 2560bis
> >responders is to start issuing revoked for "not-issued", which is far
> >from the originally stated goal to provide a way for CAs to be able to
> >return revoked for such serial numbers.
> 
> The latter is what optional means.
> 
> /Stefan
>