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

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Stefan Santesson
> Sent: Wednesday, October 31, 2012 11:47 AM
> To: [e-mail]
> Subject: [pkix] Proposed resolution to non-issued certificates - 2560bis
> 
> I didn't put up an end date for the straw-poll, but the trend seems clear.
> 
> The results so far (if I counted right)
> 
> Supporting #1: 22
> Supporting #2: 0
> Supporting #3 using "unknown": 6
> Supporting #3 using "unauthorised: 2
> 
> 6 persons supporting #1 has expressed various levels of support/demand for
> an explicit declaration that the OCSP responder supports the enhanced
> definition of "revoked" to include "no issued".
> 
> 1 person responded off-line supporting #1.
> 
> 
> If the trend reflects the opinion of the WG. This is my proposed
> resolution:
> 
> 
> 1) Extend the "revoked" response to also be allowed for non-issued
> certificates. Clearly stating that this is optional if and only if the
OCSP
> responder knows that the requested serial number has never been issued.
[Piyush] This requires changing the current text for 'good'. Pasted for your
reference

The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

> 2) Specify that a "revoked" status for a non-issued certificate serial
number
> MUST have revocationTime set to Jan 1, 1970 and MUST set the
> revocationReason to certificateHold (6).
[Piyush] There were some objections on using certificateHold as
revocationReason for this purpose. CA compromise would be more appropriate
because the only scenario where this is beneficial is when the CA is
compromised.

> 2) Define a new optional non-critical extension declaring that OCSP
> responder returns "revoked" for non-issued certificates according to the
> updated standard. This extension MUST be present in all responses where
> the "revoked" response is returned as a result of a status request for a
non-
> issued certificate.
[Piyush] Are you proposing that the specification of this extension would be
part of OCSP or it would be published as a separate specification? 
I think that it should not be part of main OCSP specification, given that it
is useful only in the exceptional scenario where CA gets compromised.
> 
> 
> Rationale:
> The certificateHold reason feels important for one particular reason. If a
CA is
> issuing certificates with sequential serial numbers, then it could be
possible
> to obtain a revoked response for a certificate serial number that is not
yet
> issued, but soon will be issued. That the certificate serial number is
currently
> not issued, does not mean that it never will, thus the certificateHold
reason
> seems more appropriate.
> 
[Piyush] Given that a fraudulent certificate has been issued with a serial
number, the CA would eventually revoke the certificate with this serial
number and would not issue any newer certificate with the same serial.
I think the confusion arises from the fact that we've been using
'not-issued' and 'fraudulently-issued' interchangeably. All this time I'd
been thinking that we are discussing the latter. If that is indeed the case,
caCompromise seems more appropriate.

> The date 1 Jan, 1970 is appropriate since it is common in programming
> languages to express time as milliseconds since jan 1, 1970. Selecting
this
> time avoids time expression as a negative integer.
> 
> This date translates to (java):
> Date revocationTime = new Date(0);  //Jan 1st, 1970
> 
> The extension would be a simple OID with no data structure and MUST not
> be set to critical.
> 
> 
> Question:
> Would it make sense to require an OCSP responder that adopts the
> expanded use of "revoked" to always include the new extension?
> It would add the benefit that someone receiving "good" can know that the
> OCSP responder has checked that the certificate in fact has been issued by
> the CA.
> In such case it may be reasonable to add an optional data structure which
> MAY contain a hash of the cert.
> Such hash would make the positive confirmation even stronger, adding proof
> of existence of the certificate.
[Piyush] I hope that you realize that big enterprise PKI deployments use
OCSP and CRLs interchangeably. And with this proposal OCSP becomes more
authoritative than CRL. 
So I guess the next step would be to change the basic path validation
algorithm to drop the use of CRLs in favor of OCSP and also drop the
signature verification (off course if the RP knows that his OCSP responder
issues stronger positive confirmations).
> 
> But perhaps this will bee too much to agree on :)
> 
[Piyush] How about a thinner profile of SCVP that could address everything
you are trying to achieve in OCSP.

> /Stefan
> 
> 
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix