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

[Denis Pinkas <[e-mail]>]

Simon,

You said:

"revocationReason must be certificateHold, since, in principle, the 
certificate may be issued at a later point in time".

I don't believe this is appropriate. If you have certificateHold then 
the OCSP client may make other calls later on
to check if the suspension state has finished or not.

The less controversial revocationReason is "unspecified".Let us go for 
"unspecified".

Denis

>
>      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.
>