Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

[[e-mail] (Martin Rex)]

Piyush Jain wrote:
> > 
> > revocationDate of a CRL does not give you either of the two interesting
> > times: (a) when a certificate was revoked and (b) since when a certificate
> > is  supposed to be invalid.
> 
> My interpretation was that revocationDate tells you a) but not b).  For b)
> you need invalidity date extension. Your assertion is that revocationDate
> does not tell you the revocation time. I think it is incorrect.  Here is the
> excerpt from 5280 section 5.1.2.6
>   "Certificates revoked by the CA are uniquely identified by the certificate
> serial number.  The date on which the revocation occurred is specified.  The
> time for revocationDate MUST  be expressed as described in section 5.1.2.4."

rfc5280 is inaccurate in that it assumes that "revocationDate" means
revocationDate, andignores the X.509 definition.

But the date when either the cert holder reported/requested or the CA
decided or acknowledged that the cert is to be revoked is somewhat
irrelevant for the code that is processing these data structures.
The only point in times interesting to them is (a) when was it first
posted/published or (b) at which time invalidity should be assumed
to have started.



> 
>> 
>> OCSP was designed to report on status _other_ than revocation, but didn't
>> define any codepoints to convey "reject this cert"  other than those defined
>> for CRLs.  
> 
> OCSP explicitly states that good status implies that certificate was never
> revoked and does not necessarily imply that cert was issued or valid.
> And that response extension may be used to convey additional information
> regarding the status such as positive statements about issuance and
> validity.

Correct.  OCSP says that a simple-minded OCSP responder, like one feeding
on CRLs, may respond "good" for certs / serials that may have never been
issued.  

What it neither says, and certainly not suggest is that an OCSP responder
who is well aware that a certificate was never issued, should also
respond "good".

It actually fairly basic common sense that the description of positive
confirmations of cert issuance is complemented about negative
confirmations (=revoked status, due to a lack of alternative
negative confirmations) about not-issued certs.


>
> The code points were not defined but the provision for including
> those additional statuses is clearly stated - by defining response
> extension, not by overloading the meaning of revoked. 

The text under good only describes positive confirmations.
Negative confirmations would not make any sense under status "good".


> 
>>And from that list, in order to interoperate with the installed base
>> "certificateHold, reject" appears to be the most sensible choice.
>
> I fail to understand how this helps interoperability. And what "install
> base" are you talking about - public CA deployments, enterprise OCSP
> deployments or something else.

The installed base of RPs, to which a responsible OCSP responder wants
to deliver the message "you ought to reject this cert", plus counting
in that this status can not be conveyed through CRLs (to which some RPs
will fallback if OCSP returns an error) or that some implementations
will soft-fail when OCSP returns an error.


> 
>> There is no such thing as a strict sequence of OCSP responses, so the
>> conventions that apply to the relation of revocationDate to thisUpdate for
>> a serial listed on a CRL do not apply to OCSP.  FWIW, they also apply only
>> to the very first CRL that this serial appears on, so in general, this
>> is a pretty irrelevant characteristic for code that processes
>> CRLs and OCSP responses.
> 
> All the more reason to add sections in OCSP to clarify the meaning of
> revcationTime and revocationReason in OCSP. Currently there is no text for
> these fields in OCSP and people fallback to 5280 to figure out what it means
> and how it should be set.


What the revocationDate means to an RP is extremely context dependent,
so if anything could be clarified, then that it can not be clarified
due to how its defined in X.509.

Recall ITU-T Rec. X.509 (08/2005), page 35


  d) A CRL contains, for each revoked certificate, the date when the
     authority posted the revocation. Further information may be known
     as to when an actual or suspected key compromise occurred, and this
     information may be valuable to a certificate user. The revocation
     date is insufficient to solve some disputes because, assuming the
     worst, all signatures issued during the validity period of the
     certificate have to be considered invalid. However, it may be
     important for a user that a signed document be recognized as valid
     even though the key used to sign the message was compromised after
     the signature was produced. To assist in solving this problem,
     a CRL entry can include a second date which indicates when it was
     known or suspected that the private key was compromised.

"The revocation date is insufficient to solve some disputes ..."
"To assist in solving ..."

bottom line is that X.509 says, revocationDate can mean anything to
anybody, and you might need a layer and a court to analyze what it means
with respect to a particular's CA certificate practice statement.

It is up to the RP to decide what it means in terms of risk management
and whether to ignore any given revocationDate and invalidityDate
timestamps.


-Martin