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

["Black, David" <[e-mail]>]

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:[e-mail]]
> Sent: Friday, March 29, 2013 1:13 PM
> To: 'Stefan Santesson'; Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; gen-
> [e-mail]
> Cc: [e-mail]
> 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:[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
> >
> 
>