Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Stefan Santesson <[e-mail]>]

Martin,

What you say here makes sense to me.

I do in particular support the 1 jan 1970 time as it is the time zero
point for may Date formats.

/Stefan

On 10/22/12 11:53 PM, "Martin Rex" <[e-mail]> wrote:

>Simon Tardell wrote:
>>
>> I suggest that we use your current text plus that, if "revoked" is used
>> to say "never issued/not in database", the revocationReason should be
>> certificateHold and that revocationTime should be set to midnight Jan 1
>> 1950 (or some other time before the rise of PKI).
>
>I support the "revoked, ReasonCode=CertificateHold" for OCSP responders
>that can not find proof/indication that the cert in question was properly
>issued.
>
>The CertificateHold reason code is vitally important, because otherwise
>the CA would have to keep track of OCSP responses given out from the
>CA's OCSP responder that declared a serial as "permanently revoked"
>in order to ensure that the CA will never issue a cert with that serial
>in the future.  Looks like an unnecessary and easily avoidable burden to
>me.
>
>
>I don't like the particular date Jan 1, 1950, for safety, a date >= 1970
>ought to be chosen (so that it does not get negative when converted
>to time_t, which has potential to confuse some code).
>
>And since the timestamp is a GeneralizedTime, the date ought to be
>given in exactly that format, e.g.  "700101010101Z"
>
>
>What also should be noted is that the optional OCSP
>SingleResponseExtension
>"CrlID" must not be used when this "not issued" certificate was not
>conveyed through a CRL--and there currently is no means to convey
>proof-of-cert-existence through CRLs unless they're revoked, and in the
>latter case there would be no "not issued" OCSP response to convey.
>
>
>> 
>> On the other hand, I think we should consider Denis' comment:
>> 
>> *Saying that the certificate has not been issued is not fully
>>appropriate.*
>
>
>I believe it is very inappropriate for the spec to make any assumptions
>about why exactly the OCSP responder believes that a cert (serial) has not
>ever been issued.  The reason can be manyfold.  Besides an accidental or
>fraudulent deletion (attack), it may be something as simple as a
>database software bug.
>
>What we might want to say is that failures to access the database
>of issued certs ought to result in an unknown rather than revoked
>OCSP response.
>
>The records of issuance, that the OCSP responder has access to,
>need not contain the whole certificate.  The information may be
>limited to serial numbers of issued certificates, and it SHOULD
>include a hash of the cert (at least SHA-1, preferably SHA-256 as well).
>In particular, the OCSP responder may not have access to the
>validity of issued certs or any other certificate characteristics or
>certificate attributes.
>
>
>-Martin