Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Draft profile of OCSP Responders and Responses #2

Closed
wants to merge 5 commits into from
Closed

Draft profile of OCSP Responders and Responses #2

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
c24cf1e
Draft profile of OCSP Responders and Responses
sleevi Apr 25, 2017
03d4055
Update BR.md
sleevi Apr 26, 2017
2040d6a
Change year to 3 months/92 days, on suggestion from Doug Beattie.
sleevi Jul 10, 2017
b8bb4b4
Update text regarding pre-producing responses
sleevi Jul 10, 2017
3171d33
Update and clarify requirements related to Delegated OCSP Responder c…
sleevi Jul 10, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 32 additions & 19 deletions docs/BR.md
View file
Open in desktop
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -813,7 +813,8 @@ The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days i
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; 7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
8. The Issuing CA's or Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; 8. The Issuing CA's or Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository;
9. Revocation is required by the Issuing CA's Certificate Policy and/or Certification Practice Statement; or 9. Revocation is required by the Issuing CA's Certificate Policy and/or Certification Practice Statement; or
10. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time). 10. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time); or
11. The Subordinate CA has issued one or more Delegated OCSP Responder Certificates with a validity period greater than 31 days and the Issuing CA obtains evidence that the Delegated OCSP Responder Certificate's Private Key has been misused, suffered a Key Compromise, or no longer complies with the requirements of Section 6.1.5 and 6.1.6.


### 4.9.2 Who can request revocation ### 4.9.2 Who can request revocation
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate. The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.
Expand Down Expand Up @@ -853,30 +854,33 @@ The CA SHALL update and reissue CRLs at least (i) once every twelve months and (
No stipulation. No stipulation.


### 4.9.9 On-line revocation/status checking availability ### 4.9.9 On-line revocation/status checking availability
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: The CA SHALL provide an OCSP responder that conforms to the profile specified by RFC5019 for all Certificates issued, including the transport profile.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is replaced with line 856, restricting it to JUST RFC 5019.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a refinement on the requirement from 866/867, whose goal is to make it efficient for Relying Parties and Servers to efficiently obtain fresh OCSP information. It is more restrictive than the current language, which permits RFC 6960 A.1 style GETs, but matches what Clients and Servers are already expecting (notably, IIS).

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other thing this profile requires is that the CA MUST include a nextUpdate field. This is effectively already part of Microsoft's program requirements, as part of https://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx#C_Revocation_Requirements

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compulsory nextUpdate is also part of the Mozilla requirements.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note that RFC5019 and RFC6960 are not consistent about the presence of nextupdae field in the OCSP response. RFC5019 says: "Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response”. However, RFC6960 says “If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.” This means that client can accept the OCSP response but they cannot cache it.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SamerW That's not a correct analysis. RFC 5019 is a profile of RFC 6960 - so of course 5019 is more restrictive than 6960 (or, alternatively, 6960 is more liberal). You're arguing that because it's possible to be more liberal, it's at conflict with 5019 - but not, the entire purpose of referencing 5019 is to indicate the MUST requirement nature of the nextUpdate, and then to further constrain the profile of 5019 in the Baseline Requirements.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a refinement on the requirement from 866/867

What does 866/867 refer to here?

It is more restrictive than the current language, which permits RFC 6960 A.1 style GETs, but matches what Clients and Servers are already expecting (notably, IIS).

By my reading, the only way in which RFC5019 GETs are more restrictive than RFC 6960 GETs is that they specify some response headers. Is that accurate?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, reading down I see that 866/867 refers to line numbers, and the comment on line 867 explains about the caching headers.


1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intended to be addressed by line 1596.

2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose
revocation status is being checked.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is intended to be addressed by line 1597.


In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as
defined by RFC6960.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is not about availability, but requirements, it's moved to line 871.



### 4.9.10 On-line revocation checking requirements ### 4.9.10 On-line revocation checking requirements
Effective 1 January 2013, the CA SHALL support an OCSP capability using the GET method for Certificates issued All OCSP responses MUST conform to the profile specified in Section 7.3
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All other aspects about what the response looks like are now moved to Section 7.3, which is consistent with RFC 3647.

in accordance with these Requirements.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we're past the effective date, this is removed. The requirement on line 856 is slightly more restrictive in this, but only in that it normatively specifies the use of HTTP caching directives, so that Relying Parties (and Servers) can efficiently obtain the information.



For the status of Subscriber Certificates: For newly issued Subscriber Certificates, OCSP responses SHOULD be published prior to the delivery of the Certificate to the Subscriber. OCSP responses MUST be published no later than 10 minutes after the Subscriber Certificate has been issued.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to try to provide an upper bound for Relying Parties, particularly servers, as to when they can expect to obtain a fresh OCSP response.

Ideally, this would be a MUST be published prior, but some bound of latency is expected. 10 minutes seemed a reasonable upper-bound for distribution to CDNs, but to allow efficient deployment of stapling, particularly mustStaple, this number would likely need to come down to something like 1 minute. This is just a starting point for discussion.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does submitting a certificate to one or more CT logs count as "delivery of the Certificate to the Subscriber"? (The Subscriber may be operating a log monitor that detects the newly submitted certificate quickly, especially if one or more of the logs has a very short STH issuance frequency).

If so, CAs that want to embed SCTs in OCSP responses would need to take special care here. Specifically, a cert's first OCSP response would need to be generated without embedded SCTs and before the cert is submitted to the CT logs. But...that would mean that the cert wouldn't be CT-compliant (to begin with), and so future CT-requiring browsers would reject it until the next OCSP response (with embedded SCTs) is provided.

I realize that a "SHOULD" is not a "MUST", but I'd like to be able to embed SCTs in a cert's first OCSP response without that action being frowned upon.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robstradling Yup, that's the thorny part which I wanted to be careful with. I wanted to describe an upper bound for that, because there's a need to reasonably accommodate both logging a certificate and publishing to a CDN. I was trying to find a different phrase here - my goal was say if something was API delivered, then the API shouldn't return success until it met these criteria (ideally). This fits with something like ACME nicely, which supports the async return case.

So my intent was to set the lower bound as "before success is indicated to the customer" (whether it be API or otherwise), with the upper bound as "within 10 minutes of issuance". Do you have any suggestions here how to clarify?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps "OCSP responses SHOULD be published prior to delivering the Certificate directly to the Subscriber"? (i.e., delivering by publishing to CT would be "indirectly" delivering).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like saying "directly" opens up rules-lawyering. Better to take the position that "delivering the Certificate to the Subscriber" should be interpreted as being made available through the interface used to request a certificate.

  • for ACME, that means GETting the certificate returns success rather than an in-progress code
  • for a web interface, a download link is provided
  • for issuance via email, the email with the certificate is sent to the requester



The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. The CA SHALL publish an updated OCSP response for Subscriber Certificates by the earlier of:
1. 8 hours prior to the nextUpdate field of the previously published OCSP response; or
2. If the OCSP response has a validity period, as defined by the difference in time between the thisUpdate and nextUpdate fields, of greater than 16 hours, then the value of the thisUpdate field plus one half of the validity period of the OCSP response.


For the status of Subordinate CA Certificates: The CA SHALL publish an updated OCSP response for Subordinate CA Certificates by the earlier of:
1. 24 hours after revoking a Subordinate CA Certificate; or
2. 3 months; or
3. 92 days.

If a Delegated OCSP Responder Certificate is used:
1. The Delegated OCSP Responder Certificate MUST be directly signed and issued by the Issuer CA of the Subscriber Certificate it provides status information for, using the same issuer name and key; and
2. The Delegated OCSP Responder Certificate MUST contain the id-pkix-ocsp-nocheck extension as defined in RFC6960; and
3. All certificates issued by the CA for the Delegated OCSP Responder's public key MUST contain an extended key usage certificate extension whose only value is id-kp-OCSPSigning, as specified in RFC6960; and
4. The Delegated OCSP Responder Certificate MUST have a validity period no greater than one year, and SHOULD have a validity period no greater than 31 days. If a Delegated OCSP Responder Certificate with a validity period greater than 31 days is issued, the Issuing CA MUST be subject to the revocation requirements of Section 4.9.1.2.


The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate. If a Delegated OCSP Responder Certificate is not used, or if the validity period of the Delegated OCSP Responder Certificate is greater than 31 days, the OCSP response MUST be pre-produced as specified in RFC5019.


If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures. If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures.


Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates. OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just cleaning up effective dates

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think more editing should be done than just removing the dates. This exception should be phased out over time.



### 4.9.11 Other forms of revocation advertisements available ### 4.9.11 Other forms of revocation advertisements available
If the Subscriber Certificate is for a high-traffic FQDN, the CA MAY rely on stapling, in accordance with [RFC4366], to distribute its OCSP responses. In this case, the CA SHALL ensure that the Subscriber "staples" the OCSP response for the Certificate in its TLS handshake. The CA SHALL enforce this requirement on the Subscriber either contractually, through the Subscriber Agreement or Terms of Use, or by technical review measures implemented by the CA. If the Subscriber Certificate is for a high-traffic FQDN, the CA MAY rely on stapling, in accordance with [RFC4366], to distribute its OCSP responses. In this case, the CA SHALL ensure that the Subscriber "staples" the OCSP response for the Certificate in its TLS handshake. The CA SHALL enforce this requirement on the Subscriber either contractually, through the Subscriber Agreement or Terms of Use, or by technical review measures implemented by the CA.
Expand Down Expand Up @@ -1357,9 +1361,7 @@ b. cRLDistributionPoints


c. authorityInformationAccess c. authorityInformationAccess


With the exception of stapling, which is noted below, this extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA's certificate (accessMethod = 1.3.6.1.5.5.7.48.2). This extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA's certificate (accessMethod = 1.3.6.1.5.5.7.48.2).
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with this section is that it applies to subordinate CAs, but the method it describes cannot be used to provide revocation status information for subordinate CAs. That's provided by RFC 6961, from Yngve Pettersen, but for which few (no?) browser members support.

Because of that, it's possible to meet this requirement using the language written, so it's removed. Support for status_request_v2 isn't high on most folks TLS1.2 agenda. In TLS1.3, the whole mechanism is changed (and implicitly includes this, although that may not be desirable). I suspect that this is probably a broader discussion for Browser Members as to whether to support this case in the future, but given that it cannot and is not supported now, it seemed OK to remove.


The HTTP URL of the Issuing CA's OCSP responder MAY be omitted, provided that the Subscriber "staples" the OCSP response for the Certificate in its TLS handshakes [RFC4366].


d. basicConstraints d. basicConstraints


Expand Down Expand Up @@ -1595,10 +1597,21 @@ The issuing CA SHALL document in its Certificate Policy or Certification Practic


## 7.3 OCSP profile ## 7.3 OCSP profile


1. All OCSP responses MUST conform with RFC6960 and be the profile specified in RFC5019.
2. Responses MUST have the same value for the producedAt and thisUpdate times.
3. Except for responses indicating a Revoked status, the difference in time between the thisUpdate and nextUpdate fields MUST be greater than or equal to 8 hours and MUST NOT be greater than or equal to 192 hours (7 days).
4. For OCSP responses directly signed by the issuing CA, the response MUST NOT include any certificates within the BasicOCSPResponse's certs field.
5. For OCSP responses signed by a Delegated OCSP Responder Certificate, the response MUST only include the Delegated OCSP Responder Certificate within the BasicOCSPResponse's certs field and MUST NOT include any additional certificates.

### 7.3.1 Version number(s) ### 7.3.1 Version number(s)


OCSP responders MUST support v1 requests, as specified in RFC6960. OCSP responders MUST produce v1 responses, as specified in RFC6960.

### 7.3.2 OCSP extensions ### 7.3.2 OCSP extensions


1. As specified in RFC5019 for pre-produced responses, responses MUST NOT include the id-pkix-ocsp-nonce extension.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed during the SHA-1 discussions, CAs supporting id-pkix-ocsp-nonce can be induced to sign material used to produce collisions. It also is actively detrimental to stapling.

If there's a use case for CAs to support this, I think we need to specify an upper-bound, and would want to revisit the profile for OCSP Responder Certificates to minimize risk. There's no good answers here.

2. Responses MAY include an OCSP extension with the OID 1.3.6.1.4.1.11129.2.4.5. If such an extension is included, it MUST conform to RFC6962.
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just the CT extension, and making it a requirement that you can't put random stuff in here.


Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there other extensions CAs are using? I'd love to explicitly forbid all other extensions for consistency, but don't know enough about the space to do this definitively.

# 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS # 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
The CA SHALL at all times: The CA SHALL at all times:


Expand Down