Hi Piyush, The usual backwards compatibility concern is mixed new/legacy deployments. In this case, the specifics appear to be:
New clients with legacy servers cannot expect to see "revoked" in this case. This matters because a hypothetical client coded to depend on a "revoked" response in this case won't work correctly with legacy servers (even though it'd be rather questionable to code that dependency into a new client - never underestimate the creativity and cleverness of implementers). New servers with legacy clients risk breaking clients that can't cope with "revoked" in this case, as you noted: >>> any other approach would break backward compatibility with >>> legacy clients. Both of these are justifications for "optional", as these RFCs apply to both clients and servers. Thanks, --David > -----Original Message----- > From: Piyush Jain [mailto:[email protected]] > Sent: Friday, March 29, 2013 1:13 PM > To: 'Stefan Santesson'; Black, David; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; gen- > [email protected] > Cc: [email protected] > Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > 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:[email protected]] > > Sent: Friday, March 29, 2013 9:37 AM > > To: Piyush Jain; 'Black, David'; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected] > > Cc: [email protected]; [email protected] > > Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > > > On 3/29/13 5:17 PM, "Piyush Jain" <[email protected]> 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 > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
