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

[Simon Tardell <[e-mail]>]

>  If the meaning of "revoked"
> is changed it is also necessary to say what should be the values of both
> revocationTime and revocationReason:
>
[…]


> CRLReason is defined in RFC 5280 as:
>
>    CRLReason ::= ENUMERATED {
>         unspecified             (0),
>         keyCompromise           (1),
>         cACompromise            (2),
>         affiliationChanged      (3),
>         superseded              (4),
>         cessationOfOperation    (5),
>         certificateHold         (6),
>              -- value 7 is not used
>         removeFromCRL           (8),
>         privilegeWithdrawn      (9),
>         aACompromise           (10) }
>
>
For the revocationTime should we use the content of notBefore field from the
> certificate ?
>

The certificate that was not issued could have any time. It is also not
seen by the responder. The reasonable revocationTime would be "the
beginning of time". Any time which is before any reasonable issuance time
of any certificate in the PKI would do. The issuance time of the issuing CA
would do, or for that matter the battle of Hastings.


> For the revocationReason should we use unspecified or keyCompromise ?
>

revocationReason must be certificateHold, since, in principle, the
certificate may be issued at a later point in time. If a key was
compromised, it would be the CA key, not the key that the certificate.

>

> In any case, guidance should be given.
>
> Although I understand that changing the meaning of "revoked" may be seen
> as "safer"
> for old implemenations, changing the meaning of "unknown" also seems to be
> a reasonable alternative.
>
> In this case, it might be useful (and sufficient) to say that if an OCSP
> responder is authoritative
> for the target certificate, then the OCSP client SHOULD NOT use an
> alternative source
> of revocation information like CRLs.
>

Which would be putting requirements on the behavior of already existing
OCSP clients out there that we know are not true and are out of the control
of most people setting up PKIs.

Simon Tardell,
Technology Nexus.