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

[Denis Pinkas <[e-mail]>]

Ryan,

Given your argumentation, let us go for "revoked", rather than "unknown ".

However, adding a note in the draft to record why this choice was made 
might be useful.

Denis



> Though I prefer the Unknown approach today all OCSP capable browsers 
> other than Opera ignore Unknown OCSP responses.
>
> Given the arguable limited value of changing the response definitions 
> at all it seems accommodating this seems the most prudent approach.
>
> This is why the CABFORUM accepted the revoked response approach even 
> though it is not as pure.
>
> Sent from my iPhone
>
> On Oct 22, 2012, at 7:03 AM, Denis Pinkas <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> To the PKIX list:
>>
>> Â Â  Without changing the meaning of "good" and of either "revoked" or
>> Â Â  "unknown", it is not possible to address the case of what is
>> Â Â Â  presently called "non-issued certificates".
>>
>> The current text from RFC 2560 is:
>>
>> Â Â  "The "good" state indicates a positive response to the state 
>> 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 state of the certificate such as
>> Â Â  positive statement about issuance, validity, etc.
>>
>> Â Â  The "revoked" state indicates that the certificate has been revoked
>> Â Â  (either permanantly or temporarily (on hold)).
>>
>> Â Â  The "unknown" state indicates that the responder doesn't know about
>> Â Â  the certificate being requested".
>>
>>
>> Â Â  A minor change should be done to advertise that "good" may be
>> Â Â  returned when the certificate was never issued and CRLs are being
>> Â Â  used.
>>
>>
>> Replacement text for the definition of the "good" state:
>>
>> Â Â  "The "good" state indicates a positive response to the state 
>> 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 *(e.g. when CRLs are used by the OCSP responders)*
>>   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 OCSP
>> Â Â  responder regarding the state of the certificate such as *an **
>> **Â Â  indication that the OCSP responder has a direct access to the **
>> **Â Â  database of issued certificates*, validity, etc ... "
>>
>> Â Â  Then either the meaning of "rekoved" or of "unknown" needs to be
>> Â Â  changed.
>>
>> Â Â  draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and
>> Â Â  proposes to keep the meaning of "unknown" unchanged and to change
>> Â Â  the meaning of "revoked" in the following way:
>>
>> Â Â  "The "revoked" state indicates that the certificate has been revoked
>> Â Â  (either permanently or temporarily (on hold)). This state SHOULD 
>> also
>> Â Â  be returned if the responder *knows that the requested 
>> certificate has **
>> **Â Â  never been issued*. Note that the receiver of a response may 
>> have to
>> Â Â  consult out-of-band knowledge, or information in an extension 
>> defined
>> Â Â  outside of this standard, to know whether a particular responder has
>> Â Â  knowledge about whether a requested certificate has been issued or
>> Â Â  not and whether it responds "good" or "revoked" to a state request
>> Â Â  for a non-issued certificate".
>>
>> Â Â  There is a door opened for a future extension "to know whether a
>> Â Â  particular responder has knowledge about whether a requested
>> Â Â  certificate has been issued or not".
>>
>> Â Â  However, the extension proposed in 
>> draft-pinkas-2560bis-certinfo-00.txt,
>> Â Â  carries a slightly different meaning:
>>
>> Â Â Â Â Â  - an indication that the serial number of the target
>> Â Â Â Â Â Â Â  certificate is not present in the database,
>>
>> *Saying that the certificate has not been issued is not fully 
>> appropriate.*
>>
>> The text should be modified in the following way:
>>
>> Â Â  "The "revoked" state indicates that the certificate has been 
>> revoked
>>    (either permanently or temporarily (on hold)).  This state SHOULD
>> Â Â  also be returned if the responder *has an access to the database
>>    of **issued certificates and if the serial number of the target **
>> **Â Â  certificate is not present in that database. *
>>
>> Â Â *In this case, the "revoked" state indicates either that the **
>> **Â Â  certificate has never been issued or that it has been issued 
>> but **
>> **Â Â  subsequently removed (by an attack or by accident) from the
>> Â Â  database **of issued certificates.*
>>
>>    Response extensions may be used  to convey additional information
>> Â Â  on assertions made by the OCSPÂ  responder regarding the state 
>> of the
>> Â Â  certificate such as *an **indication that the OCSP responder has
>> Â Â  a direct access to the **database of issued certificates*, 
>> validity, etc ... "
>>
>> An alternative is to keep the meaning of "revoked" and to change
>> the meaning of "unknown" in the following way:
>>
>> Â Â  "The "unknown" status indicates either that the server doesn't know
>> Â Â  about the certificate being requested *or the revocation status
>> Â Â  of the certificate being requested*
>>
>>    Response extensions may be used  to convey additional information
>> Â Â  on assertions made by the OCSPÂ  responder regarding the state 
>> of the
>> Â Â  certificate such as *an **indication that the OCSP responder has
>> Â Â  a direct access to the **database of issued certificates*, 
>> validity, etc ..."
>>
>> There are pros and cons for each alternative. If the meaning of 
>> "revoked"
>> is changed it is also necessary to say what should be the values of both
>> revocationTime and revocationReason:
>>
>> Â Â  CertStatus ::= CHOICE {
>>        good        [0]     IMPLICIT NULL,
>>        revoked     [1]     IMPLICIT RevokedInfo,
>>        unknown     [2]     IMPLICIT UnknownInfo }
>>
>> Â Â  RevokedInfo ::= SEQUENCE {
>>        revocationTime             GeneralizedTime,
>>        revocationReason    [0]     EXPLICIT CRLReason
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 
>> OPTIONAL }
>>
>> Â Â  UnknownInfo ::= NULL
>>
>> CRLReason is imported from PKIX1Implicit88 { iso(1) 
>> identified-organization(3)
>> dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>> id-pkix1-implicit(19) }
>>
>> 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 ?
>>
>> For the revocationReason should we use unspecified or keyCompromise ?
>>
>> 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.
>>
>> Denis
>>
>>
>>> In line;
>>>
>>> From: Piyush Jain <[e-mail] <mailto:[e-mail]>>
>>> Date: Sunday, October 21, 2012 7:42 PM
>>> To: Stefan Santesson <[e-mail] 
>>> <mailto:[e-mail]>>, 'Peter Rybar' <[e-mail] 
>>> <mailto:[e-mail]>>, 'Carl Wallace' <[e-mail] 
>>> <mailto:[e-mail]>>, 'Simon Tardell' 
>>> <[e-mail] <mailto:[e-mail]>>
>>> Cc: 'Peter Rybar' <[e-mail] <mailto:[e-mail]>>, 
>>> <[e-mail] <mailto:[e-mail]>>
>>> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
>>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/pkix