Subject: [pkix] Should a CRL be required for an OCSP service provider to assert status.

From: daniel bryan <[email-masked]>
Date: Wed, 08 Jun 2016 20:21:47 +0000

So i ran into an interesting situation today that sparked a conversation.
Suppose we have a development CA that has issued 2 certificates.  The first
is a SSL webserver cert, and the second is the OCSP Signing certificate
allowing our OCSP service to assert status. The CA has NOT created or
published a CRL. The software we are researching allows a lot of
flexibility in how the ocsp database is created. One of the configuration
options is to compute the database based on a list of serial numbers that
we know the CA says has/will issue. So for example I know this CA has
issued the server cert (serial 0x12345) so I choose to compute 0x12345 as
good. I also choose to make the OCSP response this update value = to the
response creation time, as well as the validity to be a static 10 days from
the response creation. The vendor tool fails to create a database because a
CRL is not present. During my discussion with the vendor, they said,
although they could technically create a database without the CRL in this
case, they don't feel that they have the authority to do so.  But, on the
contrary, they also allow the OCSP service owner to perform "instant
revocation" which marks a serial as revoked regardless if the CA owner
revokes the serial, or publishes a CRL.  My initial thought is an OCSP
service should be able to assert any status as long as the CA has delegated
authority to the service via the OCSP Signing certificate.

Ok, with that whole semi organized info dump about what I know here are the
official questions.

*Q1: Should an OCSP service provider be able to assert a status of revoked
when the serial is not revoked on the CA.*

*Q2: Should an OCSP service provider be able to assert a status of good for
a truly valid issued certificate when no CRL has been created by the CA*
 I would like to know if their our any standards out there that provide
guidance on this subject.

---

From: Peter Rybár <[email-masked]>
Date: Thu, 9 Jun 2016 15:29:08 +0200

Dear Daniel,

You must provide also the correct time value in the thisUpdate OCSP field.

When the validations are expected in the online system, e.g. the system based on SSL/TLS, then the system uses directly or imaginary the value of acceptable calculated risk. http://www.dictionary.com/browse/calculated-risk

The calculated risk, in this case, is the interval between the time value (the present time in the online system) and the time value in thisUpdate field.

-  Q1: Should an OCSP service provider be able to assert a status of revoked when the serial is not revoked on the CA.

This case is already define in ISO/ITU-T X.509 as an authorization. 

See Clause 7.10  http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509 

„This revocation and a notification of the revocation may be done directly by the same authority that issued the certificate, or indirectly by another authority duly authorized by the authority that issued the certificate.“

The trusted authorization is usually declared at a upper level.

E.g. in a globally accessible European Union trusted list. 

See http://ep.nbusr.sk/kca/tsl/tlX509XMLSchemaDocumentation.pdf 

- Q2: Should an OCSP service provider be able to assert a status of good for a truly valid issued certificate when no CRL has been created by the CA

This case is also already covered e.g. by European legislation where the CA store the certificates in the CA database and  the CA database contains also the certificate status.

OCSP response is directly created according to information from this database.

For more information see the document in the attachment.

The eIDAS Regulation (EU) No 910/2014 http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32014R0910 

Article 24(2) point (k): in case of qualified trust service providers issuing qualified certificates, establish and keep updated a certificate database. 

Article 24(3): If a qualified trust service provider issuing qualified certificates decides to revoke a certificate, it shall register such revocation in its certificate database and publish the revocation status of the certificate in a timely manner, and in any event within 24 hours after the receipt of the request. The revocation shall become effective immediately upon its publication.

Article 24(4): With regard to paragraph 3, qualified trust service providers issuing qualified certificates shall provide to any relying party information on the validity or revocation status of qualified certificates issued by them. This information shall be made available at least on a per certificate basis at any time and beyond the validity period of the certificate in an automated manner that is reliable, free of charge and efficient.

The OCSP response is already able to cover the requirements like "beyond the validity period of the certificate" with the one of the two already used OCSP response extensions in the real systems: 

•             CertHash OCSP single extension, see http://www.common-pki.org/uploads/media/Common-PKI_v2.0.pdf

•             ArchiveCutoff OCSP extension, see RFC 6960 https://tools.ietf.org/html/rfc6960#section-4.4.4

The CertHash - OCSP single extension is mandatory in some EU member states.

OCSP - CertHash is the hash value of the certificate whose status is returned by the OCSP response (Common PKI extensions CertHash (positive statement), Clause 3.1.2, Common PKI Specification V2.0). If this extension is found in the OCSP response, then the certificate status is known for OCSP and the hash value ensures the integrity by currently secure hash algorithm.

ITU-T/ISO standard for X.509 certificates and RFC 6960 define the rules for CRL and OCSP response. 

RFC 6960:

"

   thisUpdate -   The most recent time at which the status being indicated is known by the responder  to have been correct. 

   nextUpdate - The time at or before which newer information will be available about the status of the certificate.

   producedAt - The time at which the OCSP responder signed this response.

   revocationTime - The time at which the certificate was revoked or placed on hold. 

If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.

"

Best regards,

Peter

From: pkix [mailto:[email-masked]] On Behalf Of daniel bryan
Sent: Wednesday, June 8, 2016 10:22 PM
To: [email-masked]
Subject: [pkix] Should a CRL be required for an OCSP service provider to assert status.

So i ran into an interesting situation today that sparked a conversation. Suppose we have a development CA that has issued 2 certificates.  The first is a SSL webserver cert, and the second is the OCSP Signing certificate allowing our OCSP service to assert status. The CA has NOT created or published a CRL. The software we are researching allows a lot of flexibility in how the ocsp database is created. One of the configuration options is to compute the database based on a list of serial numbers that we know the CA says has/will issue. So for example I know this CA has issued the server cert (serial 0x12345) so I choose to compute 0x12345 as good. I also choose to make the OCSP response this update value = to the response creation time, as well as the validity to be a static 10 days from the response creation. The vendor tool fails to create a database because a CRL is not present. During my discussion with the vendor, they said, although they could technically create a database without the CRL in this case, they don't feel that they have the authority to do so.  But, on the contrary, they also allow the OCSP service owner to perform "instant revocation" which marks a serial as revoked regardless if the CA owner revokes the serial, or publishes a CRL.  My initial thought is an OCSP service should be able to assert any status as long as the CA has delegated authority to the service via the OCSP Signing certificate.

Ok, with that whole semi organized info dump about what I know here are the official questions.

Q1: Should an OCSP service provider be able to assert a status of revoked when the serial is not revoked on the CA.

Q2: Should an OCSP service provider be able to assert a status of good for a truly valid issued certificate when no CRL has been created by the CA

 I would like to know if their our any standards out there that provide guidance on this subject.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Jun 2016 11:33:47 -0400

Peter,

I think it's appropriate to cite X.509 text in response to Daniel's 
questions.
However, EU legislation is not the same as ITU or IETF standards, and 
one should
note that distinction, where appropriate. For example, I recall that 
PKIX did not
endorse the notion of OCSP providing an indication of a cert as valid, 
vs. not revoked,
when folks have posed that question in the past.

Steve

---

From: daniel bryan <[email-masked]>
Date: Thu, 09 Jun 2016 18:30:43 +0000

Thanks for such a detailed response. I believe i understand what your
saying, but I want to resay it just to make sure.

Point 1: The first point you say is that "This update" should be based on
the most recent time at which the status is known to be correct to the
responder. Suppose the following case. The CA makes the status known via a
CRL. It publishes a CRL june 9th at 12am UTC.  The next CRL will be
published 12 hours later (June 9th 12pm). The OCSP service is asked for the
status of this certificate june 9th at 6am.  It sounds like your saying the
proper response for the OCSP service to return in the this update field is
the time on the CRL (june 9th @12am) because we don't "know" if any
revocation took place between 12am and 6am, and we wont find out for 6 more
hours. We would still use jun 9th@6am for the "produced at" time, but not
"this update"  Am i understanding this point right?

Regarding Question 1: should the ocsp service be able to say revoked if the
CA hasnot/will not revoke the cert. It sounds like your saying yes. As long
as the CA has authorized the service to respond on it's behalf, it's ok if
the status of the CA database, is different from the ocsp service.

Regarding question 2: should the ocsp service be able to assert good.. It
sounds like your saying, it's ok for it to assert good, as long as it was
learned from an authorized source, for example, if the CA allows the ocsp
service to view the database of issued certs. But it is NOT ok for the OCSP
service to just say good, when it has no idea if the cert was issued or
valid.  This is also semi related to pre-computed databases.  Alot of OCSP
service software allows you to "assume" certs are good as long as they are
not on a CRL. for example, if the CA issued certs 0x1to 0x500 and only
revoked serial 0x100. the software allows you to assume good based on the
CRL. you might say that you want to assume 500 up, and 500 down as good. so
0x1 to 0x600 would be good (with the exception of the revoked 0x100) But in
reality, serials 501 - 600 have never been issued.  I can see the certhash
extension being of use here also. Overall, it sounds like your saying, it
is absolutely against standard to assume a cert is good, unless you have
been explicitly told by the CA that its been issued and is not revoked. Am
i understanding this right?

On Thu, Jun 9, 2016 at 9:29 AM Peter Rybár <[email-masked]> wrote:

> Dear Daniel,
>
>
>
> You must provide also the correct time value in the *thisUpdate* OCSP
> field.
>
>
>
> When the validations are expected in the online system, e.g. the system
> based on SSL/TLS, then the system uses directly or imaginary the value of
> acceptable calculated risk.
> http://www.dictionary.com/browse/calculated-risk
>
> The calculated risk, in this case, is the interval between the time value
> (the present time in the online system) and the time value in *thisUpdate*
> field.
>
>
>
> *-  Q1: Should an OCSP service provider be able to assert a status of
> revoked when the serial is not revoked on the CA.*
>
>
>
> This case is already define in ISO/ITU-T X.509 as an *authorization*.
>
> See Clause 7.10
> http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509
>
> „This revocation and a notification of the revocation may be done directly *by
> the same authority that issued the certificate*, or indirectly *by
> another authority duly authorized* by the authority that issued the
> certificate.“
>
>
>
> *- Q2: Should an OCSP service provider be able to assert a status of good
> for a truly valid issued certificate when no CRL has been created by the CA*
>
> This case is also already covered e.g. by European legislation where the
> CA store the certificates in the CA database and  the CA database contains
> also the certificate status.
>
> The eIDAS Regulation (EU) No 910/2014
> http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32014R0910
>
>
>
> Article 24(2) point (k): in case of qualified trust service providers
> issuing qualified certificates, establish and keep updated a *certificate
> database*.
>
>
>
> Article 24(3): If a qualified trust service provider issuing qualified
> certificates decides to revoke a certificate, it *shall register* such
> *revocation* in *its certificate database* and publish the revocation
> status of the certificate in a timely manner, and in any event *within 24
> hours* after the receipt of the request. The revocation shall become
> effective immediately upon its publication.
>
>
>
> Article 24(4): With regard to paragraph 3, qualified trust service
> providers issuing qualified certificates shall provide to any relying party
> information on the *validity* or *revocation* status of qualified
> certificates issued by them. This information shall be made available at
> least *on a per certificate basis at any time and beyond the validity
> period* of the certificate in an automated manner that is reliable, free
> of charge and efficient.
>
>
>
> The OCSP response is already able to cover the requirements like "beyond
> the validity period of the certificate" with the one of the two already
> used OCSP response extensions in the real systems:
>
> •             *CertHash* OCSP single extension, see
> http://www.common-pki.org/uploads/media/Common-PKI_v2.0.pdf
>
> •             *ArchiveCutoff* OCSP extension, see RFC 6960
> https://tools.ietf.org/html/rfc6960#section-4.4.4
>
>
>
> The *CertHash* - OCSP single extension is mandatory in some EU member
> states.
>
>
>
> OCSP - *CertHash* is the hash value of the certificate whose status is
> returned by the OCSP response (Common PKI extensions *CertHash* (positive
> statement), Clause 3.1.2, Common PKI Specification V2.0). If this extension
> is found in the OCSP response, then the certificate status is known for
> OCSP and the hash value ensures the integrity by currently secure hash
> algorithm.
>
>
>
>    *thisUpdate* -   The most recent time at which the status being
> indicated is known by the responder  to have been correct.
>
>    *nextUpdate* - The time at or before which newer information will be
> available about the status of the certificate.
>
>    *producedAt* - The time at which the OCSP responder signed this
> response.
>
>    *revocationTime* - The time at which the certificate was revoked or
> placed on hold.
>
>
>
> If *nextUpdate* is not set, the responder is indicating that newer
> revocation information is available all the time.
>
> "
>
>
>
> Best regards,
>
> Peter
>
>
>
>
>
> *From:* pkix [mailto:[email-masked]] *On Behalf Of *daniel bryan
> *Sent:* Wednesday, June 8, 2016 10:22 PM
> *To:* [email-masked]
> *Subject:* [pkix] Should a CRL be required for an OCSP service provider
> to assert status.
>
>
>
> *Q2: Should an OCSP service provider be able to assert a status of good
> for a truly valid issued certificate when no CRL has been created by the CA*
>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 9 Jun 2016 16:35:29 -0400

On 06/09/2016 02:30 PM, daniel bryan wrote:

Regarding question 2: should the ocsp service be able to
assert good.. It sounds like your saying, it's ok for it to
assert good, as long as it was learned from an authorized
source, for example, if the CA allows the ocsp service to view
the database of issued certs. But it is NOT ok for the OCSP
service to just say good, when it has no idea if the cert was
issued or valid.  This is also semi related to pre-computed
databases.  Alot of OCSP service software allows you to
"assume" certs are good as long as they are not on a CRL. for
example, if the CA issued certs 0x1to 0x500 and only revoked
serial 0x100. the software allows you to assume good based on
the CRL. you might say that you want to assume 500 up, and 500
down as good. so 0x1 to 0x600 would be good (with the
exception of the revoked 0x100) But in reality, serials 501 -
600 have never been issued.  I can see the certhash extension
being of use here also. Overall, it sounds like your saying,
it is absolutely against standard to assume a cert is good,
unless you have been explicitly told by the CA that its been
issued and is not revoked. Am i understanding this right?

Actually, this is incorrect. RFC 6960
says:

The "good" state indicates a
positive response to the status inquiry.  At a minimum, this
positive response indicates that no certificate with the
requested certificate serial number currently within its
validity interval is revoked.  This state does not necessarily
mean that the certificate was ever issued or that the
time at which the response was produced is within the
certificate's validity interval. Response extensions may be used
to convey additional information on assertions made by the
responder regarding the status of the certificate, such as a
positive statement about issuance, validity, etc.

The "revoked" state indicates that the certificate has been
revoked, either temporarily (the revocation reason is
certificateHold) or permanently.  This state MAY also be
returned if the associated CA has no record of ever having
issued a certificate with the certificate serial number in the
request, using any current or previous issuing key (referred to
as a "non-issued" certificate in this document).

Some OCSP responders act as you describe. They have knowledge about
which certificates have been issued and respond "revoked" for a
certificate that has not been issued. However, this is not required
by the standard, as "good" does not necessarily mean that the
certificate was issued, just that it has not been revoked.

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 Jun 2016 17:40:52 +0200 (CEST)

Stephen Kent wrote:
> one should note that distinction, where appropriate.

In this case, EU legislation just uses the existing extensibility
of the OCSP protocol in a straightforward and sensible fashion,
so that is just fine.

>
> For example, I recall that PKIX did not endorse the notion of OCSP
> providing an indication of a cert as valid, vs. not revoked,

Now that is a funny interpretation of the facts.  ;-)

When the OCSP spec was last revised, that very notion was actually
standardized.  Yes, there was a significant amount of dissenters,
but they ended up in the rough for conveying the notion as part of 
the OCSP protocol, albeit without the (obvious&existing) means
(CertHash extension) that ended up in the EU legislation.

See the diffs for Section-2.2 Response of the OCSP revision:

https://tools.ietf.org/rfcdiff?url1=rfc2560&url2=rfc6960

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jun 2016 17:06:17 -0400

Martin,

The June 2013 OCSP revised text expanded the discussion of what "good" 
means, noting that it is an indication that no cert issued with the 
serial number in question, and within its validity interval, was 
revoked. It also retained the statement that "good" is not an indication 
that a cert is valid. I don't see any indication in the revised text of 
Section 2.2 to support your assertion that the revisions represent a 
retreat from the earlier PKIX position on OSCP as other than a 
revocation status protocol.

Yes, the EU defined a _private_ extension (CertHash) to support the 
notion of expanding the scope of OCSP. If an OCSP server operator 
assumes that all of the OCSP clients it deals with recognize this 
private, non-critical extension, then it is obviously free to make use 
of it.

Steve

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 14 Jun 2016 18:03:06 +0200

Bonjour,

2016-06-13 23:06 GMT+02:00 Stephen Kent <[email-masked]>:

> [...]
Yes, the EU defined a *private* extension (CertHash) to support the notion
> of expanding the scope of OCSP. If an OCSP server operator assumes that all
> of the OCSP clients it deals with recognize this private, non-critical
> extension, then it is obviously free to make use of it.
>

s/EU/Germany/

Thinking EU leads to eIDAS, and this CertHash isn't part of ETSI standards
used for eIDAS.

-- 
Erwann.

---

From: Peter Bowen <[email-masked]>
Date: Tue, 14 Jun 2016 09:11:46 -0700

[...]
> The vendor tool fails to create a database because a CRL is not present.
> During my discussion with the vendor, they said, although they could
> technically create a database without the CRL in this case, they don't feel
> that they have the authority to do so.  But, on the contrary, they also
> allow the OCSP service owner to perform "instant revocation" which marks a
> serial as revoked regardless if the CA owner revokes the serial, or
> publishes a CRL.  My initial thought is an OCSP service should be able to
> assert any status as long as the CA has delegated authority to the service
> via the OCSP Signing certificate.
>
> Q1: Should an OCSP service provider be able to assert a status of revoked
> when the serial is not revoked on the CA.
>
> Q2: Should an OCSP service provider be able to assert a status of good for a
> truly valid issued certificate when no CRL has been created by the CA

There seems to be some confusion between "CRL" and "database", so I'm
not entirely clear on your question.

A Certificate Revocation List (CRL) is a specific signed data
structure defined in X.509.  There is no general requirement that CAs
publish a CRL.  Many CAs only offer revocation information via OCSP or
some other mechanism.

There is nothing in the OCSP RFCs that says _how_ a OCSP Responder
knows about the status of certificates.  That is outside of the
protocol. It is entirely possibly to use OCSP without having a CRL
published by the CA.  The OCSP responder could get information
directly from the CA via some out of band method or the OCSP responder
operator could be responsible for managing revocation for all the CA
certificates (there is a model where the CA just issues and another
party handles revocation).

As to your questions, those are both policy questions.  There is
nothing in the technical standards (either ISO/IEC|ITU-T or IETF) that
will provides a definitive answer to your questions.  Different PKIs
implementing the standards may have different answers to your
questions.

Thanks,
Peter

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jun 2016 13:10:10 -0400

Erwann,

Thanks for the clarification. Seems the scope of this private extension 
is even narrower than I thought.

Steve

> Bonjour,
>
> 2016-06-13 23:06 GMT+02:00 Stephen Kent <[email-masked] 
> <mailto:[email-masked]>>:
>
>     [...]
>
>     Yes, the EU defined a _private_ extension (CertHash) to support
>     the notion of expanding the scope of OCSP. If an OCSP server
>     operator assumes that all of the OCSP clients it deals with
>     recognize this private, non-critical extension, then it is
>     obviously free to make use of it.
>
>
> s/EU/Germany/
>
> Thinking EU leads to eIDAS, and this CertHash isn't part of ETSI 
> standards used for eIDAS.
>
> -- 
> Erwann.

---

From: [email-masked] (Martin Rex)
Date: Wed, 15 Jun 2016 13:32:29 +0200 (CEST)

> private, non-critical extension, then it is obviously free to make use 

Your description is missing the point.

The really interesting change was the change in the definition of
"revoked", where an updated OCSP responder can report "revoked"
in situations where the previous spec sort-of implied "good".

The change allows OCSP responders to narrow the situation where they
respond with "good", but it does not require it.  However, the client
can recognize the different "good" semantics in the response, that is what
is important.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Jun 2016 14:36:40 -0400

Martin,

> ...
To which text, specifically, are you referring?

Steve