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

[Simon Tardell <[e-mail]>]

On Mon, Oct 22, 2012 at 4:52 PM, Denis Pinkas <[e-mail]> wrote:

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

Which is entirely appropriate.  If you make a standard OCSP query the
certificate is identified with the hash of the issuer name and key and the
serial number. There is nothing that prevents a CA from later issuing a
certificate with the just-queried key. It would be unlikely, given best
practices for generating serial numbers, but still.

On the other hand, one could imagine a scenario where there is a time lag
between the issuance of the certificate and the insertion of the
certificate into the responder database (e.g. where the token hasn't been
"activated" or "acknowledged" yet and the issuer wants to prevent the token
from being used before such "activation"). If the relying party would get a
definite revocation reason code it would not (necessarily) try again once
the token has been "activated" and the certificate is valid for use and
used to generate a second signature (since it knows a definite reason code
doesn't change).

This scenario isn't as contrived as it may seem.

/Simon

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