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

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

Hi David,

Your interpretation of the text is right on target.
How, based on the past discussions in this WG, that is not the intent.

The sole reason cited for overloading the meaning of revoked status with
non-issued was that it allows new servers to interoperate with legacy
clients. The WG agreed that there are many better alternatives but they all
break compatibility with older clients. In fact, a more secure and complete
proposal by Denis was not adopted because of the same reason.

I believe that Stefan is trying to convey that requiring servers to return
revoked in this context will make them non-compliant with 2560 and 5019 as
opposed to breaking interoperability with legacy clients.

Cheers
-Piyush

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Friday, March 29, 2013 11:18 AM
> To: Piyush Jain; 'Stefan Santesson'; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; Black, David
> Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> 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
> > >
> >
> >