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

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

> I guess it would be okay if you and David make the determination that this
> issue is not worth debating anymore but I would surely have appreciated
> hearing the opinions of a few others.

I'm not sure how much of a say I have in that determination - Sean (as AD)
is absolutely free to acknowledge my input and ignore it ;-).

> The deviation from that consensus is that in such cases, the current draft
> prohibits clients to interpret the certificate as non-issued, and requires
> them to interpret it as issued and revoked by the CA. And this is necessary
> to circumvent the responder trust issue for CA delegated responders if they
> return extended revoked indicating non-issuance.
> Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html.

I do not see that prohibition in the new text in -16.  In the cited email
message, I do see a disagreement between you and Stefan about what implementations
are likely to do, but I don't see any text in the draft that dictates that
implementations must or must not make that interpretation.

Speaking for myself, I would have no problem w/client code that inferred that
any "revoked" response with revocation reason certificateHold (6) and
revocationTime January 1, 1970 most likely indicates a non-issued certificate.
OTOH, such a client *cannot* rely on always receiving that form of response
for a known non-issued certificate for the reasons discussed in the new text
(e.g., responder not updated to use that response, responder uses only pre
produced responses).

Again speaking for myself, I think the current text in -16 is ok, in that I
don't see the prohibition that Piyush is concerned about there.  OTOH, I'd also
be ok with a couple of sentences added to say that (new) clients could use
that response format to infer that the certificate is a known non-issued
certificate, but that clients cannot rely on getting that form of response
for all known non-issued certificate (i.e., may get an "unknown" response).

Thanks,
--David

> -----Original Message-----
> From: Piyush Jain [mailto:[e-mail]]
> Sent: Tuesday, April 09, 2013 2:03 AM
> To: 'Sean Turner'
> Cc: [e-mail]; [e-mail]; [e-mail];
> 'Stefan Santesson'; Black, David; [e-mail]; [e-mail]; gen-
> [e-mail]; 'Henry B. Hotz'
> Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> > I went back and looked at the WG poll about this issue that you and lot of
> > other people participated in (https://www.ietf.org/mail-
> > archive/web/pkix/current/msg31906.html).  The WG's rough consensus was
> > to allow "revoked" to be used for non-issued certificates with the caveat
> > thrown in by Paul Hoffman that the meaning of "revoked" be clear about
> > what it now means.  I've not seen anything that would make me want to
> > throw this draft back to the WG to revisit that consensus.
> >
> 
> I believe that the straw poll consensus was that revoked will be overloaded
> to convey non-issued status to the clients.
> The deviation from that consensus is that in such cases, the current draft
> prohibits clients to interpret the certificate as non-issued, and requires
> them to interpret it as issued and revoked by the CA. And this is necessary
> to circumvent the responder trust issue for CA delegated responders if they
> return extended revoked indicating non-issuance.
> Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html.
> 
> This is an important distinction because from client's point of view
> non-issued response for a CA signed certificate is much more severe than a
> revoked response and is indicative of a CA/RA compromise.
> The reason I'm raising this at LC is because there were a few WG members who
> acknowledged this issue and there was no consensus (other than Stefan's
> response in the post linked above) on how this should be handled.
> 
> I guess it would be okay if you and David make the determination that this
> issue is not worth debating anymore but I would surely have appreciated
> hearing the opinions of a few others.
> 
> Best
> Piyush
> 
> 
>