Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

From: "Peter Rybar" <[email-masked]>
Date: Mon, 14 Jan 2013 16:20:58 +0100

Stefan,

 > A good protocol should provide a reasonable response to every possible request.

I agree with such general sentence but rfc2560bis-08 is not able to fix discussed situations. 

Good view was dome by Piyush Jain [[email-masked]] in

[pkix] Addressing issues in 4.2.2.2 of rfc2560bis-08

Let me propose another solution.

We are trying to fix the situation, where the CA key was used for signing certificate but CA is not able to provide evidence about it for OCSP service.

1. It could be after disaster recovery procedure where the record was lost because it was not archived.

2. Or when the CA key was compromised and was used for signing a fake certificate.

I do not think that proposed solution “to provide revoked status with a reason code certificateHold and extensions id-pkix-ocsp-extended-revoke” by OCSP to RP is helpful, because:

1. CA will not be informed about the potential inconsistency in the CA database or about potential critical attack (DigiNotar); and 

2. OCSP service will not be able to decide if it is a potential CA compromise or only bad OCSP client is creating fake request because only according to analyzing the certificate content true result can be produces. Because according to rfc2560bis-08 the certificate is only on the client side.

3. Solution is expensive and not useful because the signing of such revocation response will only consume system key resources for creating unclear response. 

At first, I propose to define a new type of the OCSP Responder error message:

OCSPResponseStatus ::= ENUMERATED { …

   probablyCADatabaseOrCAKeyCompromise (7)

}

Or when solution is important to be understood by legacy clients then what is defined for probablyCADatabaseOrCAKeyCompromise will be applicable also for malformedRequest OCSP Responder error message: 

In RFC must be defined rules for RP OCSP client applications where client will be able to repeat the OCSP request but together with the certificate for which OCSP Responder error message is probablyCADatabaseOrCAKeyCompromise or malformedRequest.

This certificate will be included in singleRequestExtensions where the extension will be identified with OBJECT IDENTIFIER

id-pkix-ocsp-CertOfProbablyCADatabaseOrCAKeyCompromise.

OCSP responder will analyze received certificate and in situations where CA key was used the certificate will be provided to the CA for analysis and making decisions.

The OCSP analysis will be the bases for the second OCSP response status like:

 1. Signed good, revoked if the certificate was missed only according to recovery procedure;

 2. Unsigned with OCSP Responder error message malformedRequest when the CertID (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to the form for which OCSP responder is able to provide the status. 

  For example incorrect hash length in issuerNameHash or issuerKeyHash; 

  Incorrect serial number like when CA is using sequential number and in request is present the serial number which is out of the maximum range or is used unsigned/signed integer as a hash value stored in certificate serial number… e.g. MD5 causes permanently problems with negative serial numbers where some CA and client try to change the negative integer of certificate serial number internally and are using such positive integer in OCSP request what causes problems.

3. Unsigned with OCSP Responder error message unauthorized when OCSP responder is not authorized for providing status for requested issuerNameHash, issuerKeyHash;

4. Unsigned with OCSP Responder error message tryLater when certificate was signed with CA key and CA must define decision what to do with it.

…

I hope this proposal can be helpful as a starting point.

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, January 11, 2013 4:05 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

From: Peter Rybar <[email-masked]>
Date: Friday, January 11, 2013 3:38 PM
To: Stefan Santesson <[email-masked]>, 'Piyush Jain' <[email-masked]>, 'pkix' <[email-masked]>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Stefan,
As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or all other types of responses except for revoked!!!

How does a serial number become malformed just because it doesn't exists. Its just an integer.

Its syntactically a well formed integer.

According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of revoked with reason code certificateHold defined as equivocal result when is not correctly implemented. 
It means according to rfc2560bis all serial numbers are initially revoked with reason code certificateHold… Is it useful?

Yes.

(The revoked with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!)
 
For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value good or revoked in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions.

Then that can be achieved by defining a new single response extension that does not interfere with what is being done in 2560bis.

When hash of the certificate as a positive statement MUST be used, the situations with OCSP responses for RP are clear and unique because:
1) good or revoked is only about know and issued certificates,

Great, so how then do you respond to a request for a serial number that has never been issued?

2) any other situations are moved into one group which is unclear and not analyzed – no evidence, no responsibility.

But the responder still need to respond.

It is a radical simplification!

Of what?

Instead of trying to solve presently not practical and theoretical situations from the responsibility/liability point of view (like preparing us for situations: what we will offer for intergalactic green man, are vegetarian? ;) we can define steps which can be implemented by CAs and OCSP systems like usage of positive statement cert hash.

Asking for status of a never issued serial number is not impossible. It is not even hard.

A good protocol should provide a reasonable response to every possible request.

E.g. define new or reuse already defined in private OID space.
PositiveStatement ::= SEQUENCE {
   hashAlgorithm    AlgorithmIdentifier,
   certHash         OCTET STRING, -- Hash of Subjects certificate
}
 
And according it we cam move.

I have nothing against such extension being defined.

But it still does not remove the need for the current discussed mechanism.

The current discussed mechanism address how to respond to legacy clients to requests for non-issued serial numbers.

Your extension does not help, because it is not understood by legacy clients.

So its not either or.

/Stefan

Peter Rybar

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, January 10, 2013 2:19 PM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Peter, i think the reason for this has been thoroughly debated.

It is correct that a cert serial number that was on hold, may be released.

The requested cert serial number may actually be used in a future representing a real certificate.

So this is intentional and the whole purpose behind using the on hold reason.

/Stefan

From: Peter Rybar <[email-masked]>
Date: Thursday, January 10, 2013 12:13 PM
To: 'Piyush Jain' <[email-masked]>, Stefan Santesson <[email-masked]>, 'pkix' <[email-masked]>
Subject: Re: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

Stefan,

For me is unclear how this extension of revoked with reason code certificateHold is useful.

It define that now is possible to revoke what does not exist and it open never ending cycle of trying to fixing or correcting the first incorrect status that "fake" cert serial number is revoked but cert serial number is not revoked because "fake" cert does not exist.

I agree that extension of revoked can be helpful like:

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

When the certificate serial number is not in the OCSP database/CRL then according to rfc2560bis there are defined following possible responses:

1. signed -  good (e.g. certificate serial number is not listed in CRL)

2. signed -  unknown (e.g. certificate serial number is not listed in CRL)

3. unsigned – unauthorized as an error message

4. signed -  revoked where according to rfc2560bis are defined values for:

Extensions: id-pkix-ocsp-extended-revoke

Revocation Reasons: certificateHold

Revocation Time: 1.1.1970 00:00:00 UTC

What is missing? The rfc2560bis must also specify values for:

This Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

Next Update:  ?? ?? ??     10.1.2013 9:51:15 UTC

X.509 defines the reason code certificateHold as 1) it may remain on the CRL; 2) it may be replaced by a (final) revocation; 3) it may be explicitly released;

and 

4) as a consequence of rfc2560bis the status of certificate serial number indicated as revoked with reason code certificateHold can be replaced with real status of a new real certificate which was issued with the same certificate serial number as was asked in the incorrect OCSP request created by insufficiently implemented applications where the signature of the certificate was not checked with CA public key.

It is based on the following definitions:

According to rfc2560bis the certificate status value is:
http://tools.ietf.org/wg/pkix/draft-ietf-pkix-rfc2560bis/ 
 
   -  good … is not revoked, (does not necessarily mean that the certificate was ever issued)…
   -  revoked … has been revoked (This state MAY also be returned if the responder knows that the requested certificate has never been issued during the history of the associated CA using any current or previous issuing key.)
   -  unknown …

   When a responder responds revoked to a status request for a non-
   issued certificate, the responder MUST also;
 
    - include the extended revoked definition response extension
      (section 4.8), indicating that the OCSP responder supports the
      extended definition of revoked state to also cover non-issued
      certificates,
    - provide the revocation reason certificateHold (6), and;
    - specify the revocation date January 1, 1970. 

According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code extension:

http://www.itu.int/rec/T-REC-X.509

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3). 

Once a hold has been issued, it may be handled in one of three ways: 

a) it may remain on the CRL with no further action, causing users to reject transactions issued during the hold period; or, 

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold, and the optional instruction code extension field shall not appear; or, 

c) it may be explicitly released and the entry removed from the CRL.

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

> -----Original Message-----

> From: Stefan Santesson [mailto:[email-masked]]

> Sent: Tuesday, January 08, 2013 8:40 PM

> To: Peter Rybar; 'Piyush Jain'; 'pkix'

> Subject: Re: [pkix] Question about extended Revoked Extension defined in

> section 4.4.8 of ocsp draft 8

> Importance: High

> Peter;

> On 1/8/13 5:18 PM, "Peter Rybar" <[email-masked]> wrote:

> >Stefan,

> >The terminology is not clear for someone who will see:

> >The revocation is of "non-issued certificate".

> >Because by reading the text it is expected that the certificate was

> >issued, but fraudulently.

> What part of the text supports that?

[Piyush] None explicitly, but many would infer it that way. The certificate

space that is covered by your interpretation of "non-issued" includes

certificates which are not signed using the CA key and those that are signed

fraudulently. RPs won't make queries for certificate for which they cannot

verify the signature. So the only genuine requests for "non-issued

certificates" coming to a responder would be those for fraudulently issued

certificates unless you are saying that this specification will allow for

RPs to skip signature checking.

> >The revocation with a new extension is only about fraudulently issued

> >certificate. It means this new extension and revocation is not used

> >when the certificate is not issued and only fake random certificate

> >serial number was created in OCSP request.

> What?

> How in this physical universe would the OCSP responder tell the

> difference???

> Crystal ball?

> >While it is intended only for fraudulently issued certificate where

> >fraudulently issued certificate can potentially reuse any already used

> >certificate-serial-number the extension must contain e.g. a positive

> >confirmation of existence in the form of hash value of fraudulently

> >issued certificate.

> No that is a task for another possible effort.

> It's not part of this update.

[Piyush] Can you clarify what is the goal for this update? I think it is one

of the following

- Allow for extending definition of revoked so other specifications can

extend the protocol

- Address handling of fraudulently issued certificate.

- Address handling of any certificate not issued by the CA.

But based on different threads on this topic I get confused about what it

is. Having the goal clear would help us keep the review of draft focused. 

> But this update paves the way for such extension. Which I'm not against.

> It's just not part of this update effort.

> >Only according to the hash value of fraudulently issued certificate

> >relaying party and OCSP responder is able to identify fraudulently

> >issued certificate because CA was compromised and serial numbers of

> >certificates are not any longer unique for compromised CA.

> >Conclusion:

> >Positive statement extension as a hash value of the certificate whose

> >status OCSP response is providing can be used in this case:

> >  when the certificate is revoked,

> >  when the certificate is good and also

> >  when the certificate is fraudulently issued.

> >For that reason it can be more helpful to define in RFC one positive

> >statement extension as a hash value of the certificate whose status the

> >OCSP response is providing and define in RFC that it will support

> >situations when status is:

> >   -- good

> >   -- revoked

> >And for randomly created certificate serial numbers without records in

> >OCSP database will be use:

> >   -- unknown

> No, we have been through this and determined WG consensus.

> Unknown is not the choice, since it may not have the desired effect (to

> indicate that a certificate with this serial number should not be

trusted).

> It's important that this works with legacy clients. They will be around

for a

> while.

[Piyush] That's an interesting usage of the word "legacy". I don't think

that any of the previous versions of OCSP recommended interpreting "unknown"

or UNAUTHORIZED(unsigned) responses to imply that certificate can be

trusted. The right word would be to "incorrectly implemented clients".

> /Stefan

> >_______________________________________________

> >pkix mailing list

> >[email-masked]

> >https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________ pkix mailing list [email-masked] https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________ pkix mailing list [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Jan 2013 05:15:19 +0100 (CET)

Peter Rybar wrote:
> We are trying to fix the situation, where the CA key was used for
> signing certificate but CA is not able to provide evidence about
> it for OCSP service.

Actually, this is _NOT_ what were trying to accomplish.

The OCSP update is about discontinuing to return "good" when the
OCSP responder has access to the CA's cert issue records and can not
find any proof-of-existence that the cert serial in the OCSP request
refers to a properly issued certificate.

At the abstract level, we do _not_ care how this happened,

This change will also standardize the behaviour used by DigiNotar to
mitigate the problem of misissued certs for which they did not have
any records of issuance because these had been purposely destroyed.

> 
> I do not think that proposed solution ?to provide revoked status
> with a reason code certificateHold and extensions
> id-pkix-ocsp-extended-revoke? by OCSP to RP is helpful, because:
> 
> 1. CA will not be informed about the potential inconsistency in the
> CA database or about potential critical attack (DigiNotar); and 

a) That is an entirely seperate issue.

b) It is up to CAs to decide what to do about OCSP requests for "not issued"
   cert serials that are received by OCSP responders to which CAs have
   granted access to the cert issue records.

c) As you can see in X.509  08/2005 (the one referenced by PKIX/rfc5280)
   section 8.5.2.1 "Hold instruction code extension", it has always been
   the intention that any instructions about actions that a CA expects
   RPs to perform (beyond "do not trust this cert NOW") ought to be
   conveyed through extensions with clearly defined semantics, rather
   than wild guessing on the part of the RP.

d) the installed base of rfc2560 is quite unlikely to notice, and unlikely
   to react to any extensions that we might include in the OCSP response,
   therefore is conside (1) as a bogus requirement.

> 
> 2. OCSP service will not be able to decide if it is a potential
> CA compromise or only bad OCSP client is creating fake request
> because only according to analyzing the certificate content true
> result can be produces. Because according to rfc2560bis-08 the
> certificate is only on the client side.

The update under discussion does not try to change anything about this
from rfc2560.  The installed base of rfc2560 clients is huge, and
you probably will have to live with such clients (and the resulting
impossibility of the OCSP responder to determine the OCSP clients
motivation for inquring the status of potentially fake serials
for many years to come).

What all protocol updates have in common, is, that it will not change
what the installed base is sending out and will not change how the
installed interprets what it receives.

What is possible, however, when one of the communication peer is
updated, that interop is improved, and the desirable behaviour
will happen more often than before the update.

> 
> 3. Solution is expensive and not useful because the signing of such
> revocation response will only consume system key resources for
> creating unclear response. 

a) The solution is extremely useful, because it can be used to stop
   RPs accepting certs when the cert serial can not be found on the
   cert issue record log.  Further improvements, such as conveying
   the cert hash of all certs, for which cert issue records exists,
   can be independently added to OCSP.

b) The solution is not expensive at all.  Nobody is required to
   implement it.  In order to make a trustworthy assertion about
   the certificate status that a responsible client will find
   acceptable during certificate revocation checking, a valid
   digital signature on the OCSP response is a requirement.

   If you are worried about being unable to pre-sign an OCSP response
   for not-issued certs, that problem was newly created by the dirty
   hack to randomize the cert serial after the X.509 design weakness was
   discovered that the specific design of X.509 cert issuance would
   enable a mere hash collision attack to achieve what would normally
   require a second preimage attack.

   Since the attack needs the wiggle room of the subjectPublicKey
   info bits, I'm wondering whether it would not be much more appropriate
   for the CA to clean up the subject name from the certificate request
   and inserted a randomized RDName component into the subject name,
   instead of messing up the certificate serial number space.

   (Will there ever be NSEC3 records for the .com zone?)

c) The response is *VERY* clear (i.e. has well-defined semantics)

Quoting from section 8.5.2.2 of X.509 08/2005:

  A certificate may be placed on hold by issuing a CRL entry with a
  reason code of certificateHold. The certificate hold notice may
  include an optional hold instruction code to convey additional
  information to certificate users (see 8.5.2.3).
  Once a hold has been issued, it may be handled in one of three ways:
 
    a) it may remain on the CRL with no further action, causing users
       to reject transactions issued during the hold period

> OCSPResponseStatus ::= ENUMERATED { ?

The  symbolic name suggested above for a new ReasonCode is a terribly bad
idea, indicating a lack of understanding of protocol design.
If anything, a sensible name for the desired function would be:

     noIssueRecordFound(7)

and if *your* implementation of an OCSP responder would want to convey
any more specific reason what may have caused this situation, you could
include an explicit extension, similar to how X.509 08/2005 suggests
this for conveying additional info or requesting specific RP actions
in 8.5.2.3 Hold instruction code extension.

But the problem with a newly defined ReasonCode is that we do not
really know how the installed base will process this, and whether it
may treat such a new revocation code as a final/permanent status
and cache it _much_ longer than what is appropriate for a temporary
status such as certificateHold.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 15 Jan 2013 05:28:58 +0100

Peter,

In general.
For several reasons I'm not supportive of your proposals.

The basic problem is that you don't listen to the problem statement being
repeated here time after time after time.
We are NOT trying to solve CA compromise. We are giving the protocol the
capability to reasonably respond to requests for serial numbers that don't
match any issued cert.

That may or may not be caused by CA compromise.

If you want to craft a perfect solution for handling CA compromise, fine.
But that is not part of this update effort.
/Stefan

From:  Peter Rybar <[email-masked]>
Date:  Monday, January 14, 2013 4:20 PM
To:  Stefan Santesson <[email-masked]>, 'Piyush Jain'
<[email-masked]>, 'pkix' <[email-masked]>
Subject:  [pkix] Solution with singleRequestExtensions
CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

> We are trying to fix the situation, where the CA key was used for signing
> certificate but CA is not able to provide evidence about it for OCSP service.
> I do not think that proposed solution ³to provide revoked status with a reason
> code certificateHold and extensions id-pkix-ocsp-extended-revoke² by OCSP to
> RP is helpful, because:
> 1. CA will not be informed about the potential inconsistency in the CA
> database or about potential critical attack (DigiNotar); and
> 2. OCSP service will not be able to decide if it is a potential CA compromise
> or only bad OCSP client is creating fake request because only according to
> analyzing the certificate content true result can be produces. Because
> according to rfc2560bis-08 the certificate is only on the client side.
> 3. Solution is expensive and not useful because the signing of such revocation
> response will only consume system key resources for creating unclear response.
>  
> OCSPResponseStatus ::= ENUMERATED { Š
> Or when solution is important to be understood by legacy clients then what is
> defined for probablyCADatabaseOrCAKeyCompromise will be applicable also for
> malformedRequest OCSP Responder error message:
> In RFC must be defined rules for RP OCSP client applications where client will
> be able to repeat the OCSP request but together with the certificate for which
> OCSP Responder error message is probablyCADatabaseOrCAKeyCompromise or
> malformedRequest.
>  
> This certificate will be included in singleRequestExtensions where the
> extension will be identified with OBJECT IDENTIFIER
> OCSP responder will analyze received certificate and in situations where CA
> key was used the certificate will be provided to the CA for analysis and
> making decisions.
>  
>  2. Unsigned with OCSP Responder error message malformedRequest when the
> CertID (issuerNameHash, issuerKeyHash, serialNumber) is not corresponding to
> the form for which OCSP responder is able to provide the status.
>   Incorrect serial number like when CA is using sequential number and in
> request is present the serial number which is out of the maximum range or is
> used unsigned/signed integer as a hash value stored in certificate serial
> numberŠ e.g. MD5 causes permanently problems with negative serial numbers
> where some CA and client try to change the negative integer of certificate
> serial number internally and are using such positive integer in OCSP request
> what causes problems.
> 3. Unsigned with OCSP Responder error message unauthorized when OCSP responder
> is not authorized for providing status for requested issuerNameHash,
> issuerKeyHash;
> 4. Unsigned with OCSP Responder error message tryLater when certificate was
> signed with CA key and CA must define decision what to do with it.
> Š
>  
> To: Stefan Santesson <[email-masked]>, 'Piyush Jain'
> <[email-masked]>, 'pkix' <[email-masked]>
>> As you can see in my previous mail, when OCSP request contains incorrect
>> (malformed) serial number, because the certificate does not exist, the OCSP
>> Responder may return an error message malformedRequest or all other types of
>> responses except for revoked!!!
>  
> 
>> According to rfc2560bis is situation worse because the status revoked which
>> was about the real certificate status (in CRL or in previous OCSP RFC) is now
>> with extension of revoked with reason code certificateHold defined as
>> equivocal result when is not correctly implemented.
>> It means according to rfc2560bis all serial numbers are initially revoked
>> with reason code certificateHoldŠ Is it useful?
>  
> 
> Yes.
> 
>  
>> 
>> (The revoked with reason code certificateHold is based on CA database and in
>> some next steps database can also include the hash values of certificates for
>> positive statement!)
>>  
>> For that reason some systems and legislations where non-repudiation services
>> are required (e.g. QES) dictate that status value good or revoked in OCSP
>> response MUST contain a positive statement a hash value of certificate in
>> singleExtensions.
>>  
>  
> 
> Then that can be achieved by defining a new single response extension that
> does not interfere with what is being done in 2560bis.
> 
>  
>> 
>> When hash of the certificate as a positive statement MUST be used, the
>> situations with OCSP responses for RP are clear and unique because:
>> 2) any other situations are moved into one group which is unclear and not
>> analyzed  no evidence, no responsibility.
>  
> 
>> Instead of trying to solve presently not practical and theoretical situations
>> from the responsibility/liability point of view (like preparing us for
>> situations: what we will offer for intergalactic green man, are vegetarian?
>> ;) we can define steps which can be implemented by CAs and OCSP systems like
>> usage of positive statement cert hash.
>>  
>  
> 
>> To: 'Piyush Jain' <[email-masked]>, Stefan Santesson
>> <[email-masked]>, 'pkix' <[email-masked]>
>>> It define that now is possible to revoke what does not exist and it open
>>> never ending cycle of trying to fixing or correcting the first incorrect
>>> status that "fake" cert serial number is revoked but cert serial number is
>>> not revoked because "fake" cert does not exist.
>>>  
>>> When the certificate serial number is not in the OCSP database/CRL then
>>> according to rfc2560bis there are defined following possible responses:
>>> 3. unsigned  unauthorized as an error message
>>> X.509 defines the reason code certificateHold as 1) it may remain on the
>>> CRL; 2) it may be replaced by a (final) revocation; 3) it may be explicitly
>>> released;
>>> and 
>>> 4) as a consequence of rfc2560bis the status of certificate serial number
>>> indicated as revoked with reason code certificateHold can be replaced with
>>> real status of a new real certificate which was issued with the same
>>> certificate serial number as was asked in the incorrect OCSP request created
>>> by insufficiently implemented applications where the signature of the
>>> certificate was not checked with CA public key.
>>>  
>>>    -  good Š is not revoked, (does not necessarily mean that the certificate
>>> was ever issued)Š
>>>    -  revoked Š has been revoked (This state MAY also be returned if the
>>> responder knows that the requested certificate has never been issued during
>>> the history of the associated CA using any current or previous issuing key.)
>>>    -  unknown Š
>>>  
>>> A certificate may be placed on hold by issuing a CRL entry with a reason
>>> code of certificateHold. The certificate hold notice may include an optional
>>> hold instruction code to convey additional information to certificate users
>>> (see 8.5.2.3). 
>>> a) it may remain on the CRL with no further action, causing users to reject
>>> transactions issued during the hold period; or,
>>> b) it may be replaced by a (final) revocation for the same certificate, in
>>> which case the reason shall be one of the standard reasons for revocation,
>>> the revocation date shall be the date the certificate was placed on hold,
>>> and the optional instruction code extension field shall not appear; or,
>>> _______________________________________________ pkix mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>> _______________________________________________ pkix mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 15 Jan 2013 15:51:52 +0100

Stefan,

Probably you have missed my argument that CRLReason of certificateHold is defined only in ITU-T X.509 and logical semantics specified for CRL and delta CRL when certificateHold is used is problematic for the usage in OCSP where request/response can be created several times in unspecified time/date.

The usage of certificateHold as you have proposed is confusing and for that reason I was proposing another solution where is addressed the problem of issued certificate by CA without evidence in CA. 
Because the sentence "revoked response for non-issued certificates" is vague when it is only about wrong serial number and the certificate does not exists at application creating OCSP request.
It is absurd situations and OCSP responder must react with an error message on such absurd request because that is not situation abut the certificate status, that is wrong request which is only about the integer number.
OCSP is Online Certificate Status Protocol.
It is not partial status about one or two component of the CertID! ( serialNumber or issuerNameHash or issuerKeyHash )
 
When OCSP has access to the CA database, what is the case defined in rfc2560bis for "revoked response for non-issued certificates", then the error message is right response, 
because such certificate does not exist and 
because the certificate does not exist also the status does not exist about the certificate which does not exist.

The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). This state MAY also be
   returned if the responder knows that the requested certificate has
   never been issued during the history of the associated CA using any
   current or previous issuing key.

Another argument why revocation with reason code certificateHold is problematic: 

ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008) 

8.5.2.2 Reason code extension

b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on hold , and the optional instruction code extension field shall not appear; or,,

According to “the revocation date shall be the date the certificate was placed on hold” and according to usage of OCSP:

The firs OCSP request will be in time t0 when certificate SerNum1 is not issued.

You propose OCSP response revoked where:

Then certificate will be issued in time t1 and revoked in time t2 in CRL.

OCSP request will be created in time t3 and according to definition “the revocation date shall be the date the certificate was placed on hold” the revocation time will be … what a problem is because two interpretations exist.

Is OCSP based on CRL or not… 

When is not based on CRL as is stated in rfc2560bis for revoked then the revocation time must be 1.1.1970 00:00:00 UTC

I hope it is ridiculous :)

For that reason I propose to use in this situation OCSP responder error message malformedRequest.

For example for clause 7.4 Repudiation of a digital signing (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic when certificateHold is used because transactions created in each time when the certificate was in certificateHold must not be accepted.

Also for that reason the certificateHold is forbidden in some systems or legislations.

It creates additional complexity where each CRL must be analyzed to have the complete time line in which date/time and how long the certificate was in the certificateHold state because the certificate can be in certificateHold state several times.

Martin Rex propose to use OCSP responder error message noIssueRecordFound (7) instead of

    probablyCADatabaseOrCAKeyCompromise (7) }

I agree, it is better and new OCSP RFC will define what will be done by the OCSP client when OCSP responder error message malformedRequest is received.

OCSP client application will create a new OCSP request for the certificate where this certificate will be included in the singleRequestExtensions the extension identified by OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound .

According to it OCSP responder or CA will be able to solve the problems with probably CA Database inconsistency or CA Key compromise and also the problem how the OCSP must be able to response on certificate serial number that don't match any issued cert.

Because following response, when CA key was used, can be the real status of the certificate or OCSP responder error message tryLater because the analysis was started.

When CA key was not used for signing the certificate in request the OCSP responder will return error message unauthorized because OCSP is not authorized.

Peter Rybar

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2013 5:29 AM
To: Peter Rybar; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

Peter,

In general.

The basic problem is that you don't listen to the problem statement being repeated here time after time after time.

We are NOT trying to solve CA compromise. We are giving the protocol the capability to reasonably respond to requests for serial numbers that don't match any issued cert.

If you want to craft a perfect solution for handling CA compromise, fine. But that is not part of this update effort.

/Stefan

From: Peter Rybar <[email-masked]>
Date: Monday, January 14, 2013 4:20 PM
To: Stefan Santesson <[email-masked]>, 'Piyush Jain' <[email-masked]>, 'pkix' <[email-masked]>
Subject: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

Stefan,

Good view was done by Piyush Jain [[email-masked]] in

}

The RFC must define rules for RP OCSP client applications where the client will be able to repeat the OCSP request but together with the certificate for which OCSP responder error message is probablyCADatabaseOrCAKeyCompromise or malformedRequest.

…

Peter Rybar

  _____  

 

Stefan,

Yes.

 

 

Of what?

 

 

So its not either or.

/Stefan

Peter Rybar

  _____  

/Stefan

Stefan,

 

and 

 

 

 

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in section 4.4.8 of ocsp draft 8

of the following

extend the protocol

trusted).

for a

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Jan 2013 16:42:14 +0100

Peter,

I agree with you one point, but I disagree with you on two others:

The agreement : CertificateHold should not be used to address the 
problem we want to solve

The disagreements :
    a) the error message malformedRequest is not the right approach, 
since the request is well-formed.
    b) the error message unauthorized is not the right approach, since 
the request is unauthorized.

Please read the message I sent to Stefan at 2:58 p.m. today for a 
proposal to address the problem.

Denis

> Stefan,
>
> Probably you have missed my argument that CRLReason of certificateHold 
> is defined only in ITU-T X.509 and logical semantics specified for CRL 
> and delta CRL when certificateHold is used is problematic for the 
> usage in OCSP where request/response can be created several times in 
> unspecified time/date.
>
> Because the sentence"revoked response for non-issued certificates" is vaguewhen it is only about wrong serial number and the certificate does not exists at application creating OCSP request.
> It is absurd situations and OCSP responder*must react*  with*an error message*  on such absurd request because that is not situation abut the certificate status, that is wrong request which is only about the integer number.
> When OCSP has access to the CA database, what is the case defined in rfc2560bis for"revoked response for non-issued certificates", then the error message is right response,
>     returned if the responder knows that the requested certificate*has*
> *    never been issued during the history of the associated CA using any*
> *    current or previous issuing key*.
>
> Another argument why revocation with reason code certificateHoldis 
> problematic:
>
> b) it may be replaced by a (final) revocation for the same 
> certificate, in which case the reason shall be one of the standard 
> reasons for revocation, *the revocation date shall be the date the 
> certificate was placed on hold *, and the optional instruction code 
> extension field shall not appear; or,,
>
> According to "*the revocation date shall be the date the certificate 
> was placed on hold*" and according to usage of OCSP:
>
> You propose OCSP response *revoked*where:
>
> OCSP request will be created in time t3 and according to definition 
> "*the revocation date shall be the date the certificate was placed on 
> hold*" the revocation time will be ... what a problem is because two 
> interpretations exist.
>
> Is OCSP based on CRL or not...
>
> When is not based on CRL as is stated in rfc2560bis for revoked then 
> the revocation time must be 1.1.1970 00:00:00 UTC
>
> For that reason I propose to use in this situation OCSP responder 
> error message *malformedRequest*.
>
> For example for clause 7.4 Repudiation of a digital signing (ISO/IEC 
> 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic 
> when certificateHoldis used because transactions created in each time 
> when the certificate was in certificateHold must not be accepted.
>
> It creates additional complexity where each CRL must be analyzed to 
> have the complete time line in which date/time and how long the 
> certificate was in the certificateHold state because the certificate 
> can be in certificateHold state several times.
>
> I agree, it is better and new OCSP RFC will define what will be done 
> by the OCSP client when OCSP responder error message 
> *malformedRequest* is received.
>
> OCSP client application will create a new OCSP request for the 
> certificate where this certificate will be included in the 
> singleRequestExtensions the extension identified by OBJECT IDENTIFIER 
> id-pkix-ocsp-*CertOf**NoIssueRecordFound*.
>
> According to it OCSP responder or CA will be able to solve the 
> problems with probably CA Database inconsistency or CA Key compromise 
> and also the problem how the OCSP must be able to response on 
> certificate serial number that don't match any issued cert.
>
> Because following response, when CA key was used, can be the real 
> status of the certificate or OCSP responder error messagetryLater 
> because the analysis was started.
>
> When CA key was not used for signing the certificate in request the 
> OCSP responder will return error message *unauthorized*because OCSP is 
> not authorized.
>
> Peter Rybar
>
> ------------------------------------------------------------------------
>
> *From:*Stefan Santesson [mailto:[email-masked]]
> *Sent:* Tuesday, January 15, 2013 5:29 AM
> *To:* Peter Rybar; 'Piyush Jain'; 'pkix'
> *Subject:* Re: [pkix] Solution with singleRequestExtensions 
> The basic problem is that you don't listen to the problem statement 
> being repeated here time after time after time.
>
> We are NOT trying to solve CA compromise. We are giving the protocol 
> the capability to reasonably respond to requests for serial numbers 
> that don't match any issued cert.
>
> If you want to craft a perfect solution for handling CA compromise, 
> fine. But that is not part of this update effort.
>
> /Stefan
>
> *From: *Peter Rybar<[email-masked] <mailto:[email-masked]>>
> *Date: *Monday, January 14, 2013 4:20 PM
> *To: *Stefan Santesson <[email-masked] 
> <mailto:[email-masked]>>, 'Piyush Jain' <[email-masked] 
> <mailto:[email-masked]>>, 'pkix' <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *[pkix] Solution with singleRequestExtensions 
>     Good view was done by Piyush Jain [[email-masked]
>     <mailto:[email-masked]>] in
>
>     I do not think that proposed solution "to provide *revoked* status
>     with a reason code *certificateHold* and extensions
>     id-pkix-ocsp-*extended-revoke*" by OCSP to RP is helpful, because:
>
>     1. CA will not be informed about the potential inconsistency in
>     the CA database or about potential critical attack (DigiNotar); and
>
>     2. OCSP service will not be able to decide if it is a potential CA
>     compromise or only bad OCSP client is creating fake request
>     3. Solution is expensive and not useful because the signing of
>     such revocation response will only consume system key resources
>     for creating unclear response.
>
>     OCSPResponseStatus ::= ENUMERATED { ...
>
>     *probablyCADatabaseOrCAKeyCompromise (7)*
>
>     }
>
>     Or when solution is important to be understood by legacy
>     clientsthen what is defined for
>     *probablyCADatabaseOrCAKeyCompromise* will be applicable also for
>     *malformedRequest* OCSP Responder error message*: *
>
>     The RFC must define rules for RP OCSP client applications where
>     the client will be able to repeat the OCSP request but together
>     *with the certificate* for which OCSP responder error message is
>     *probablyCADatabaseOrCAKeyCompromise* or *malformedRequest*.
>
>     This certificate will be included in singleRequestExtensions where
>     the extension will be identified with OBJECT IDENTIFIER
>
>     id-pkix-ocsp-*CertOfProbablyCADatabaseOrCAKeyCompromise*.
>
>     OCSP responder will analyze received certificate and in situations
>     where CA key was used the certificate will be provided to the CA
>     for analysis and making decisions.
>
>      2. Unsigned with OCSP Responder error message malformedRequest
>     when the CertID (issuerNameHash, issuerKeyHash, serialNumber) is
>     not corresponding to the form for which OCSP responder is able to
>     provide the status.
>
>       Incorrect serial number like when CA is using sequential number
>     and in request is present the serial number which is out of the
>     maximum range or is used unsigned/*signed integer as a* hash value
>     stored in certificate serial number... e.g. MD5 causes permanently
>     problems with negative serial numbers where some CA and client try
>     to change the negative integer of certificate serial number
>     internally and are using such positive integer in OCSP request
>     what causes problems.
>
>     3. Unsigned with OCSP Responder error message unauthorized when
>     OCSP responder is not authorized for providing status for
>     requested issuerNameHash, issuerKeyHash;
>
>     4. Unsigned with OCSP Responder error messagetryLater when
>     certificate was signed with CA key and CA must define decision
>     what to do with it.
>
>     ...
>
>     ------------------------------------------------------------------------
>
>     *From:*Stefan Santesson [mailto:[email-masked]]
>     *Sent:* Friday, January 11, 2013 4:05 PM
>     *To:* Peter Rybar; 'Piyush Jain'; 'pkix'
>     *Subject:* Re: [pkix] Question about extended Revoked Extension
>     defined in section 4.4.8 of ocsp draft 8
>
>     *From: *Peter Rybar<[email-masked] <mailto:[email-masked]>>
>     *Date: *Friday, January 11, 2013 3:38 PM
>     *To: *Stefan Santesson <[email-masked]
>     <mailto:[email-masked]>>, 'Piyush Jain' <[email-masked]
>     <mailto:[email-masked]>>, 'pkix' <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [pkix] Question about extended Revoked Extension
>     defined in section 4.4.8 of ocsp draft 8
>
>         Stefan,
>
>         As you can see in my previous mail, when OCSP request contains incorrect (malformed) serial number, because the certificate does not exist, the OCSP Responder may return an error message malformedRequest or*all*  other types of responses*except for revoked*!!!
>
>         According to rfc2560bis is situation worse because the status revoked which was about the real certificate status (in CRL or in previous OCSP RFC) is now with extension of*revoked*  with reason code certificateHold defined as equivocal result when is not correctly implemented.
>
>         It means according to rfc2560bis all serial numbers are initially*revoked*  with reason code certificateHold... Is it useful?
>
>     Yes.
>
>         (The*revoked*  with reason code certificateHold is based on CA database and in some next steps database can also include the hash values of certificates for positive statement!)
>
>           
>
>         For that reason some systems and legislations where non-repudiation services are required (e.g. QES) dictate that status value*good*or*  revoked*  in OCSP response MUST contain a positive statement a hash value of certificate in singleExtensions.
>
>           
>
>     Then that can be achieved by defining a new single response
>     extension that does not interfere with what is being done in 2560bis.
>
>         1)*good*  or*revoked*  is only about know and issued certificates,
>
>         2)*any*  other situations are moved into one group which is unclear and not analyzed -- no evidence, no responsibility.
>
>     The current discussed mechanism address how to respond to legacy
>     clients to requests for non-issued serial numbers.
>
>         ------------------------------------------------------------------------
>
>         *From:*Stefan Santesson [mailto:[email-masked]]
>         *Sent:* Thursday, January 10, 2013 2:19 PM
>         *To:* Peter Rybar; 'Piyush Jain'; 'pkix'
>         *Subject:* Re: [pkix] Question about extended Revoked
>         Extension defined in section 4.4.8 of ocsp draft 8
>
>         *From: *Peter Rybar<[email-masked] <mailto:[email-masked]>>
>         *Date: *Thursday, January 10, 2013 12:13 PM
>         *To: *'Piyush Jain' <[email-masked]
>         <mailto:[email-masked]>>, Stefan Santesson
>         <[email-masked] <mailto:[email-masked]>>, 'pkix'
>         <[email-masked] <mailto:[email-masked]>>
>         *Subject: *Re: [pkix] Question about extended Revoked
>         Extension defined in section 4.4.8 of ocsp draft 8
>
>             Stefan,
>
>             For me is unclear how this extension of *revoked* with
>             reason code certificateHold is useful.
>
>             It define that now is possible to revoke what does not
>             exist and it open never ending cycle of trying to fixing
>             or correcting the first incorrect status that "fake" cert
>             serial number is revoked but cert serial number is not
>             revoked because "fake" cert does not exist.
>
>             I agree that extension of *revoked* can be helpful like:
>
>             When the certificate serial number is not in the OCSP
>             database/CRL then according to rfc2560bis there are
>             defined following possible responses:
>
>             1. signed - *good (e.g. *certificate serial number is not
>             listed in CRL*)*
>
>             2. signed - *unknown (e.g. *certificate serial number is
>             not listed in CRL*)*
>
>             3. unsigned -- unauthorized as an error message
>
>             4. signed - *revoked* where according to rfc2560bis are
>             defined values for:
>
>             X.509 defines the reason code certificateHold as 1) it may
>             remain on the CRL; 2) it may be replaced by a (final)
>             revocation; 3) it may be explicitly released;
>
>             and
>
>             4) as a consequence of rfc2560bis the status of
>             certificate serial number indicated as revoked with reason
>             code certificateHold can be replaced with real status of a
>             new real certificate which was issued with the same
>             certificate serial number as was asked in the incorrect
>             OCSP request created by insufficiently implemented
>             applications where the signature of the certificate was
>             not checked with CA public key.
>
>                 -  good ... is not revoked, (does*  not*  necessarily mean that the certificate was*  ever issued*)...
>
>                 -  revoked ... has been revoked (This state MAY also be returned if the responder knows that the requested certificate*has never been issued*  during the history of the associated CA using any current or previous issuing key.)
>
>                 -  unknown ...
>
>             A certificate may be placed on hold by issuing a CRL entry
>             with a reason code of certificateHold. The certificate
>             hold notice may include an optional hold instruction code
>             to convey additional information to certificate users (see
>             8.5.2.3).
>
>             a) it may remain on the CRL with no further action,
>             causing users to reject transactions issued during the
>             hold period; or,
>
>             b) it may be replaced by a (final) revocation for the same
>             certificate, in which case the reason shall be one of the
>             standard reasons for revocation, the revocation date shall
>             be the date the certificate was placed on hold, and the
>             optional instruction code extension field shall not
>             appear; or,
>
>             Subject: RE: [pkix] Question about extended Revoked
>             Extension defined in section 4.4.8 of ocsp draft 8
>
>             > To:Peter Rybar; 'Piyush Jain'; 'pkix'
>
>             > On 1/8/13 5:18 PM, "Peter Rybar" <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             >
>
>             > >Stefan,
>
>             > >[email-masked] <mailto:[email-masked]>
>
>             _______________________________________________ pkix
>             mailing list [email-masked] <mailto:[email-masked]>
>         _______________________________________________ pkix mailing
>         list [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 15 Jan 2013 08:28:53 -0800

Denis,

You said 

The disagreements : 
   a) the error message malformedRequest is not the right approach, since
the request is well-formed.
   b) the error message unauthorized is not the right approach, since the
request is unauthorized.

Based on your reasoning above, I would like to add

c) The status revoked is not the right approach, since the certificate is
not revoked.

I support Peter's point that creating a signed revoked (or even signed
unknown) for non-existent certificates is unnecessary waste. Given that the
primary reason for OCSP is to address operational issues associated with
CRLs, providing signed responses for non-existent certificates is unlikely
to gain adoption, especially among large CAs who have deployed huge
pre-signed OCSP infrastructure. Please note that returning a signed response
for non-certificates makes pre-signing computationally infeasible.

For reference, the 2 CAs who have the biggest share of SSL server market
currently respond with unsigned UNAUTHORIZED and TRY_LATER for serial
numbers that are not associated with a certificate. And a third one who
provides managed PKI hosting uses a third party responder which returns
TRY_LATER for non-existent certificates.

I support your proposal for using notIssuedOrIrregularlyIssued(7) instead of
certificateHold(6), if returning revoked for non-certificates is assumed to
be axiomatic by this WG, which IMO should not be the case.

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Denis Pinkas
Sent: Tuesday, January 15, 2013 7:42 AM
To: Peter Rybar
Cc: [email-masked]
Subject: Re: [pkix] Solution with singleRequestExtensions
CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

Peter,

The agreement : CertificateHold should not be used to address the problem we
want to solve

The disagreements : 
   a) the error message malformedRequest is not the right approach, since
the request is well-formed.
   b) the error message unauthorized is not the right approach, since the
request is unauthorized.

Please read the message I sent to Stefan at 2:58 p.m. today for a proposal
to address the problem.

Denis

Stefan,

Probably you have missed my argument that CRLReason of certificateHold is
defined only in ITU-T X.509 and logical semantics specified for CRL and
delta CRL when certificateHold is used is problematic for the usage in OCSP
where request/response can be created several times in unspecified
time/date.

The usage of certificateHold as you have proposed is confusing and for that
reason I was proposing another solution where is addressed the problem of
issued certificate by CA without evidence in CA. 
Because the sentence "revoked response for non-issued certificates" is vague
when it is only about wrong serial number and the certificate does not
exists at application creating OCSP request.
It is absurd situations and OCSP responder must react with an error message
on such absurd request because that is not situation abut the certificate
status, that is wrong request which is only about the integer number.
OCSP is Online Certificate Status Protocol.
It is not partial status about one or two component of the CertID! (
serialNumber or issuerNameHash or issuerKeyHash )
 
When OCSP has access to the CA database, what is the case defined in
rfc2560bis for "revoked response for non-issued certificates", then the
error message is right response, 
because such certificate does not exist and 
because the certificate does not exist also the status does not exist about
the certificate which does not exist.

Another argument why revocation with reason code certificateHold is
problematic: 

b) it may be replaced by a (final) revocation for the same certificate, in
which case the reason shall be one of the standard reasons for revocation,
the revocation date shall be the date the certificate was placed on hold ,
and the optional instruction code extension field shall not appear; or,,

According to "the revocation date shall be the date the certificate was
placed on hold" and according to usage of OCSP:

The firs OCSP request will be in time t0 when certificate SerNum1 is not
issued.

OCSP request will be created in time t3 and according to definition "the
revocation date shall be the date the certificate was placed on hold" the
revocation time will be . what a problem is because two interpretations
exist.

Is OCSP based on CRL or not. 

When is not based on CRL as is stated in rfc2560bis for revoked then the
revocation time must be 1.1.1970 00:00:00 UTC

For that reason I propose to use in this situation OCSP responder error
message malformedRequest.

For example for clause 7.4 Repudiation of a digital signing (ISO/IEC
9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely problematic when
certificateHold is used because transactions created in each time when the
certificate was in certificateHold must not be accepted.

Also for that reason the certificateHold is forbidden in some systems or
legislations.

It creates additional complexity where each CRL must be analyzed to have the
complete time line in which date/time and how long the certificate was in
the certificateHold state because the certificate can be in certificateHold
state several times.

Martin Rex propose to use OCSP responder error message noIssueRecordFound
(7) instead of

I agree, it is better and new OCSP RFC will define what will be done by the
OCSP client when OCSP responder error message malformedRequest is received.

OCSP client application will create a new OCSP request for the certificate
where this certificate will be included in the singleRequestExtensions the
extension identified by OBJECT IDENTIFIER
id-pkix-ocsp-CertOfNoIssueRecordFound .

According to it OCSP responder or CA will be able to solve the problems with
probably CA Database inconsistency or CA Key compromise and also the problem
how the OCSP must be able to response on certificate serial number that
don't match any issued cert.

Because following response, when CA key was used, can be the real status of
the certificate or OCSP responder error message tryLater because the
analysis was started.

When CA key was not used for signing the certificate in request the OCSP
responder will return error message unauthorized because OCSP is not
authorized.

Peter Rybar

  _____  

Subject: Re: [pkix] Solution with singleRequestExtensions

Peter,

In general.

/Stefan

Stefan,

 > A good protocol should provide a reasonable response to every possible
request.

I agree with such general sentence but rfc2560bis-08 is not able to fix
discussed situations. 

We are trying to fix the situation, where the CA key was used for signing
certificate but CA is not able to provide evidence about it for OCSP
service.

1. It could be after disaster recovery procedure where the record was lost
because it was not archived.

2. Or when the CA key was compromised and was used for signing a fake
certificate.

I do not think that proposed solution "to provide revoked status with a
reason code certificateHold and extensions id-pkix-ocsp-extended-revoke" by
OCSP to RP is helpful, because:

2. OCSP service will not be able to decide if it is a potential CA
compromise or only bad OCSP client is creating fake request because only
according to analyzing the certificate content true result can be produces.
Because according to rfc2560bis-08 the certificate is only on the client
side.

3. Solution is expensive and not useful because the signing of such
revocation response will only consume system key resources for creating
unclear response. 

At first, I propose to define a new type of the OCSP Responder error
message:

OCSPResponseStatus ::= ENUMERATED { .

}

Or when solution is important to be understood by legacy clients then what
is defined for probablyCADatabaseOrCAKeyCompromise will be applicable also
for malformedRequest OCSP Responder error message: 

The RFC must define rules for RP OCSP client applications where the client
will be able to repeat the OCSP request but together with the certificate
for which OCSP responder error message is
probablyCADatabaseOrCAKeyCompromise or malformedRequest.

The OCSP analysis will be the bases for the second OCSP response status
like:

 1. Signed good, revoked if the certificate was missed only according to
recovery procedure;

number. e.g. MD5 causes permanently problems with negative serial numbers

3. Unsigned with OCSP Responder error message unauthorized when OCSP
responder is not authorized for providing status for requested
issuerNameHash, issuerKeyHash;

.

Peter Rybar

  _____  

 

Stefan,

How does a serial number become malformed just because it doesn't exists.
Its just an integer.

According to rfc2560bis is situation worse because the status revoked which
was about the real certificate status (in CRL or in previous OCSP RFC) is
now with extension of revoked with reason code certificateHold defined as
equivocal result when is not correctly implemented. 
It means according to rfc2560bis all serial numbers are initially revoked
with reason code certificateHold. Is it useful?

Yes.

(The revoked with reason code certificateHold is based on CA database and in
some next steps database can also include the hash values of certificates
for positive statement!)

 

Great, so how then do you respond to a request for a serial number that has
never been issued?

2) any other situations are moved into one group which is unclear and not
analyzed - no evidence, no responsibility.

 

Of what?

Instead of trying to solve presently not practical and theoretical
situations from the responsibility/liability point of view (like preparing
us for situations: what we will offer for intergalactic green man, are
vegetarian? ;) we can define steps which can be implemented by CAs and OCSP
systems like usage of positive statement cert hash.

Asking for status of a never issued serial number is not impossible. It is
not even hard.

A good protocol should provide a reasonable response to every possible
request.

The current discussed mechanism address how to respond to legacy clients to
requests for non-issued serial numbers.

Your extension does not help, because it is not understood by legacy
clients.

So its not either or.

/Stefan

Peter Rybar

  _____  

The requested cert serial number may actually be used in a future
representing a real certificate.

So this is intentional and the whole purpose behind using the on hold
reason.

/Stefan

Stefan,

For me is unclear how this extension of revoked with reason code
certificateHold is useful.

 

3. unsigned - unauthorized as an error message

and 

 
   -  good . is not revoked, (does not necessarily mean that the certificate
was ever issued).
   -  revoked . has been revoked (This state MAY also be returned if the
responder knows that the requested certificate has never been issued during
the history of the associated CA using any current or previous issuing key.)
   -  unknown .

 

According to ITU-T Rec. X.509 (11/2008), clause 8.5.2.2 Reason code
extension:

 

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 6:17 PM
To: 'Stefan Santesson'; 'Peter Rybar'; 'pkix'
Subject: RE: [pkix] Question about extended Revoked Extension defined in

of the following

extend the protocol

trusted).

for a

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Jan 2013 18:48:45 +0100 (CET)

Peter Rybar wrote:
> is defined only in ITU-T X.509

Huh?  You should get yourself a new copy of rfc5280

  http://tools.ietf.org/html/rfc5280

if your's is missing certificateHold(6) CRLReason in the reasonCode
extension.

>
> and logical semantics specified for CRL and delta CRL when
> certificateHold is used is problematic for the usage
> in OCSP

That is non-sensical.  This update does not create CRLs or delta CRLs,
so the semantics of CRLs and deltaCRLs is irrelevant (for this update).

Even then, any existing OCSP responder that feeds on URL will have to
sensibly deal with this reason code when processing CRLs and delta CRLs,
even without this update, so there is nothing about this complexity
that you could blame onto the propsed update.

>
> where request/response can be created several times in
> unspecified time/date.

The semantics of the certificateHold ReasonCode for the "not-issued"
situation is clear and well-defined.

But what you appear to totally ignore is the problem of permanent
revocation status.  An RP may cache any OCSP response with a permanent
revocation status FOREVER, entirely ignoring the nextUpdate field,
because that is exactly what a permant revocation status implies.
Therefore we MUST ABSOLUTELY avoid to convey a revoked status
that an RP might consider a permanent revocation status!

> 
> The usage of certificateHold as you have proposed is confusing

Nope, the X.509 semantics of certificateHold that, which we want to use,
is crystal clear in 8.5.2.2 (a):

   the hold status may remain with no further action, causing users
   to reject transactions issued during the hold period

(the words "on the CRL" removed, since this is about the semantics of
 revocationReason within the OCSP SingleResponse, not the semantics
 of ReasonCode within a CrlEntryExtension).

>
> and for that reason I was proposing another solution where is
> addressed the problem of issued certificate by CA without evidence in CA. 
> Because the sentence "revoked response for non-issued certificates"
> is vague when it is only about wrong serial number and the certificate
> does not exists at application creating OCSP request.

As I've previously described,

the certificate that the RP is holding is entirely irrelevant to
the rfc2560 OCSP protocol -- which is why typical rfc2560 OCSP clients
seem to never include the (optional) certificate in OCSP requests.

>
> It is absurd situations and OCSP responder must react with an error
> message on such absurd request because that is not situation about
> the certificate status, that is wrong request which is only about
> the integer number.

rfc2560, and how it is used by the installed base, is provably
about Certificate Serial Status, not about Certificate status.
Some RPs may boldly infer Certificate status from Certificate Serial
Status, but that is an inference from the OCSP response, not a function
of the OCSP protocol the way it is used by common OCSP clients.

There is no such thing as an absurd situation for the OCSP responder
when looking up a cert serial from the CA cert issue records.  Either
an issue record will be found (likely returning a certificate hash
along with the status that the serial was found), or no issue record
will be found.

These are two well-defined, easily distinguishable lookup results
that can be trivially converted into determinstic OCSP responder behaviour
with clear and obvious semantics.

>
> It is not partial status about one or two component of the CertID!
> ( serialNumber or issuerNameHash or issuerKeyHash )

I'm sorry, this statement non-sensical.

issuerNameHash and isserKeyHash refer to the CA cert, and as you
can see from the ASN.1 definition, they are non-optional -- these
two values MUST always be compared, and if they don't match, the
result MUST be an "unknown" OCSP response.

The serialNumber is the parameter that refers to the certificate.
And in order to determine the certificate status this value MUST
be matched, whether sourcing from a CRL, delta CRL, proxied OCSP request
or CA cert issue records.

So there can not be such thing as a partial status or a partial match.

>  
> When OCSP has access to the CA database, what is the case defined
> in rfc2560bis for "revoked response for non-issued certificates",
> then the error message is right response, 

This is also a non-sensical statement.  An error message has the semantics
"this information source is unable to provide cert status information",
which would non only a pretty stupid response for any authoritative
OCSP to return when that OCSP responder known pretty damn well that
this cert serial does not exist on the CA cert issue records, and
when two extremely common types of behaviours of RPs in the installed
base for an "unknown" response from an authoritative OCSP responder
are  (1) fail soft and accept the cert or (2) fallback to CRL checking,
where the revocation check is bound to return status "good", because
it is impossible to detect the "not-issued" with CRLs.

Bottom line, while returning "good" is permitted by rfc2560 in absence
of the capability to detect "not issued", and will result in the same
behaviour as the OCSP client soft failing or falling back to CRL checking,
returning unknwon would be a pretty dumb response for an authoritative
OCSP responder which *KNOWS* the status of the requested cert serial.

> b) it may be replaced by a (final) revocation for the same certificate,
> in which case the reason shall be one of the standard reasons for
> revocation, the revocation date shall be the date the certificate was
> placed on hold, and the optional instruction code extension field
> shall not appear; or,,

You seem to be totally confused (or exhibit problems in understanding X.509)

We're using 8.5.2.2 (a) EXCLUSIVELY for the rfc2560 update.

8.5.2.2 (b) obviously does not apply to a cert serial that has
"not issued" status.
"not issued" is a temporary status until (if ever) a real cert with that
serial gets issued.  Once a real cert with that serial has been issued,
OCSP requests for this cert serial will return the status of this real
cert from the CA issue records, and no longer report "not issued".

> 
> According to ?the revocation date shall be the date the certificate
> was placed on hold? and according to usage of OCSP:

Since there _exists_ no certiticte when certificateHold conveys the
"not issued" status, this rule can obviously not apply, because there
is no information source from which any "placedOnHoldTime" could
be copied into the OCSP response.

Consequently, the value to place in revocationTime for "not issued"
is defined in 2560bis -- that should be intuitively apparent.

> OCSP request will be created in time t3 and according to definition?
> the revocation date shall be the date the certificate was placed on hold?
> the revocation time will be? what a problem is because two
> interpretations exist.

Really, why do you ask at all??

For a certificate that _exists_, and that is put onHold by the CA,
the CA will know pretty damn well when it asserted that onHold,
and it will very very very probably publish exactly that date on
a CRL or delta CRL along with the onHold status.

Whether and when the OCSP responder conveyed "notIssued" in an OCSP response
using the onHold ReasonCode is invisible and irrelevant to the certificate
status information maintained by the CA, so there can not possibly arise
any confusion.  When the CA publishes a certificate revocation status
for a certificate that it has issued, the information conveyed through
CRLs and the information conveyed through OCSP ought to remain consistent.

What the rfc2560bis update changes is only the incorrectly asserted "good"
status for cert serials that do not appear on the CA cert issue record.

> 
> Is OCSP based on CRL or not? 

It will be a local decision of the OCSP responder whether it feeds
on CRLs, on CRLs + deltaCRLs, on CRLs + deltaCRLs + CA cert issue records
or on CA cert issue+status records alone, or on any other combination
of certificate status information sources it sees fit.

This is called "implementation freedom", something that will be
obvious to anyone with implementation experience.

> error message malformedRequest.

That doesn't compute for the reason that have be regurgitated
several times on this list.

> 
> For example for clause 7.4 Repudiation of a digital signing
> (ISO/IEC 9594-8:2008 (E) ITU-T Rec. X.509 (11/2008)) is extremely
> problematic when certificateHold is used because transactions
> created in each time when the certificate was in certificateHold
> must not be accepted.

Transactions created with a keypair where the cert serial is unknown
to the CA that is alleged to have issued that cert is EVEN MORE problematic,
do you realize that?  Because it is not unlikely that not only the
CA doesn't know about this cert, but also that the subject asserted
by that cert does not know about that cert (that is regular the intent
of fraudulent certs), and it will be in the very best interest of
the RP, in the very best interest of the CA and in the very best
interest of a subject asserted by a fraudulently issued cert
if the transaction is not accepted.

THIS IS EXACTLY WHAT THIS UPDATE IS ABOUT!

Gosh, I feel like I'm talking to Eliza.

Continuing to return "good" status for a potentially fraudulent cert,
which the CA does not have on its record log for whatever reason,
would be squarely against the interest of RP, CA and asserted subject,
so continuing to do so would be gross negligent.

> Also for that reason the certificateHold is forbidden in some systems

While it is true that a lot of politician/legislators are pretty
clueless about technology,  But I see it happen just as often
that technical guys are clueless about understanding legislation.

Legislation normally legislates duties of legal entities
(e.g. Party A must do A and must not do B).
and not try to legislate bits (such as: it is prohibited for bit 7
of PDU A field B to have a value of 1.  On violation of this rule,
bit 7 will face a prison term of up to 5 years for gross negligent
values of 1 and a /dev/null penalty for wilful values of 1).

Unless a specific legislation is completely and thoroughly goofed
(which happens rarely), positively confirming the use a cert (serial)
for use in a transaction for which a CA is fully aware that it has
no proof of issuance (and therefore does not even know whose identity
that cert asserts), will be a much more severe act of gross negligence
and potentially make that CA an accomplice in fraud, than resorting
to a safety measure by asserting certificateHold in the OCSP response.

I don't know how legislation works in other countries, but in
Germany, in order to become liable, there either needs to be
gross negligence or intent to cause harm.  In the above situation,
the emergency reaction to return certificateHold in the OCSP response
is evidently neither of gross negligence nor harm, so there is not
going to be a problem.

Aren't there QES specs that require the use of an explicit
proof-of-existence certificate hash conveyed in an OCSP extension
of an OCSP "good" response, specifically to accomodate the well-known
shortcoming of base OCSP not being able to convey "not issued"?

> 
> It creates additional complexity where each CRL must be analyzed to have
> the complete time line in which date/time and how long the certificate
> was in the certificateHold state because the certificate can be in
> certificateHold state several times.

I don't have the slightest clue what you mean, but it has certainly
nothing to do whatsoever with conveying certificateHold for "not issued"
certs.

When your OCSP responder computes its responses from CRLs, then there
is ABSOLUTELY NO CHANGE in behaviour with respect to certs that are
listed on CRLs in copying the CRLEntry contents into the OCSP response.
So there is exactly ZERO additional complexity for processing CRLs.

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 16 Jan 2013 09:33:30 +0100

Martin, Stefan,

If the main case is to provide the final status for the OCSP client, where the client will not subsequently try to use a CRL, then you must also expect that the initial rules were checked and are valid.

The initial rules:
1. X.509 is based on PKI and all objects are protected by PKI and the first step is to check the signature of the object. 
2. When the signature of the object is valid, only after that check the fields of the object must be used as an input in other conditions which can be checked.

In the OCSP case where CertID {issuerKeyHash, issuerNameHash, serialNumber} is created and used:

1. The OCSP client will use a public key of the CA to check the signature of the certificate whose status need to be checked. 
2. When the signature is valid, the client creates "issuerKeyHash".
3. The OCSP client will check the issuer name field of the certificate whose status need to be checked.
4. When issuer names are identical, the client creates "issuerNameHash".
5. The OCSP client will use a serial number from the certificate whose status need to be checked and will be created CertID {issuerKeyHash, issuerNameHash, serialNumber} and OCSP REQUES.

As you can see, the present protocol is clear that random cert serial number must not be used. There is only the case when CA key is used as correct CA key or as compromised CA key.

For that reason the status REVOKED must be used only for issued (signed) certificates in the OCSP and also in CRL.

Including non-issued certificates in OCSP responses means ignoring PKI and mixing some another part of protocols like some trustworthy out-of-band procedure with procedure based on PKI.

Peter Rybar

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2013 6:49 PM
To: Peter Rybar
Cc: 'Stefan Santesson'; 'Piyush Jain'; 'pkix'
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

-Martin

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 16 Jan 2013 10:00:25 +0100

Peter,

 From a protocol point of view, an OCSP responder may not rely on any 
check made by an OCSP client.
So an OCSP responder MUST be ready to receive requests that contain any 
value (good or bad), including :
  - a random serial number,
  - a malformed ASN.1 request,
  - etc ....

Martin gave you yesterday an extensive response that is fully correct.
Your arguments are leading nowhere.

Please do not waste our time.

Denis

---

From: "Peter Rybar" <[email-masked]>
Date: Wed, 16 Jan 2013 17:59:07 +0100

Denis,

I agree that Martin's and Stefan's description and also the last Martin's mail contains clear information what they intend by it to fix.

But when you look at it from the practical side the usage of revoked status for the "not-issued" / "not used serial number by CA" is only encapsulation of *UNKNOWN* result into the *REVOKED* result.

So, I agree with you Denis, but from another side that such solution where the status revoked is used as a carrier of UNKNOWN status leading nowhere and its implementation only waste implementer's time.

Can you create practical examples of statuses and how it is expected that clients and CAs will use it?

The mistake is in the precondition that responder *KNOWS* the status.
Because authoritative OCSP responder with access to the CA database has not e.g. information about the certificate issued by CA, e.g. record in database was deleted or was not created.

Proposed OCSP response:
By Martin and Stefan
  Signed status Revoked, 
     Revocation Reasons: certificateHold, 
     Extensions: id-pkix-ocsp-extended-revoke
     Revocation Time: 1.1.1970 00:00:00 UTC

Consequence: 
It is not permanent status and can be changed but special rules must be used.
1. Correct certificate, but without record in OCSP database will be permanently revoked by rfc2560bis applications because in rfc2560bis is not defined mechanism how it can be reported and corrected on CA/OCSP side.
When in this time it will be requested to be revoked e.g. as a keyCompromise where user will provide all registration documentation to the CA... the HOLD status will be changed to the real status but must be used special logical rules for the time of revocation and not rules defined for certificateHold in X.509/RFC. 
(Client and RP applications were correctly using certificate for long time with CRL checking as valid and only once when rfc2560bis OCSP responder was used some unclear situation happened so client recommend to RP to use only CRL :o) :-) ;)
2. Incorrect serial number of non existing certificate. It is unknown case where it can be useful - probably as attacks e.g. consuming system time for signing responses.  

Proposed OCSP response:
By Denis
  Signed status Revoked, 
     Revocation Reasons: notIssuedOrIrregularlyIssued, 
     Revocation Time: 1.1.1970 00:00:00 UTC

Consequence:
It is a permanent status according to actual definition where only certificateHold can be changed.
It is unclear what it will causes in applications in which is not implemented proposed bit in revocation reason. Probably Stefan was pointing on it to avoid such situations.

My proposal (updated by comments of Martin and Denis) of OCSP response:
For QES the positive statement certHash of the certificate must be used for a good and revoked status.
When the positive statement certHash of the certificate is not included in the responder database, then the OCSP Responder must return an error message noIssueRecordFound.

Client applications if recognize the error message noIssueRecordFound can create another OCSP request where will be included requested certificate in  
singleRequestExtensions extensin identified by OID id-pkix-ocsp-CertOfNoIssueRecordFound.
According to it OCSP responder or CA will be able to solve the problems with probably CA Database inconsistency or CA Key compromise.

The following OCSP response can be signed with positive statement certHash tryLater while CA makes a decision or OCSP Responder can return an error message malformedRequest when CertID does not correspond to certificate in id-pkix-ocsp-CertOfNoIssueRecordFound or signed response unknown (what is the same as revoked with reason certificateHold, extensions id-pkix-ocsp-extended-revoke because client have no hint, provided by OCSP, what to do with it).

The extension included in singleRequestExtensions and identified by OBJECT IDENTIFIER id-pkix-ocsp-CertOfNoIssueRecordFound contains certificate for which the status in OCSP request is requested.

OCSPResponseStatus ::= ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6),   --Request unauthorized
       noIssueRecordFound (7) -- probably CA Database inconsistency 
                              -- or CA Key compromise
   }

Peter Rybar

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2013 10:00 AM
To: Peter Rybar
Cc: [email-masked]
Subject: Re: [pkix] Solution with singleRequestExtensions CertOfProbablyCADatabaseOrCAKeyCompromise for legacy clients

Peter,

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Jan 2013 06:42:18 +0100

> currently respond with unsigned UNAUTHORIZED and TRY_LATER for serial numbers
> that are not associated with a certificate. And a third one who provides
> managed PKI hosting uses a third party responder which returns TRY_LATER for
> non-existent certificates.

This is important.

The update proposal does not change this.
The curent draft proposal just allows the revoked response. It does not
mandate it.

The current draft allows communities, such as the CAB forum to craft a
strategy for their responders that suits the needs of their infrastructure
and threats.
It gives them one more tool in their toolbox.

So in this particular case, I would leave it up to the CAB Forum to decide
what SSL cert responders should do to operate in the Web PKI environment.

/Stefan