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

From: Denis Pinkas <[email-masked]>
Date: Thu, 17 Jan 2013 17:40:33 +0100

Peter,

Your proposal is not acceptable:

   - Old OCSP clients will simply fail because the error message 
noIssueRecordFound does not exist in RFC 2560
     and/or (?)  because they will be unable to process the 
singleRequestExtensions noIssueRecordFound
  .
-  Old OCSP clients cannot take advantage of certHash, but this is not a 
reason of not including it :
     it would be indeed a very valuable extension for new OCSP clients

A response to one of your observations:

certificateHold is not necessarily the single temporary revocation status,
since we can change the wording in 2560bis in a backwards compatible way.

Denis

> 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,
>
>   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
>
>> 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
>>
>> Peter Rybar wrote:
>>> Probably you have missed my argument that CRLReason of certificateHold
>>> 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.
>>> OCSP is Online Certificate Status Protocol.
>> 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.
>>
>>
>>> 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
>>>
>>> Once a hold has been issued, it may be handled in one of three ways:
>>>
>>> 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.
>>
>>> The firs OCSP request will be in time t0 when certificate SerNum1 is not issued.
>>>
>>> You propose OCSP response revoked where:
>>> Extensions: id-pkix-ocsp-extended-revoke
>>> Revocation Reasons: certificateHold
>>> Revocation Time: 1.1.1970 00:00:00 UTC
>>>
>>> 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.
>> 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.
>>
>>
>>> For that reason I propose to use in this situation OCSP responder
>>> 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
>>> or legislations.
>> 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
>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>