Great feedback. This is exactly the type of input needed to get clarity around 
operating OCSP responder services for certificates in the WebPKI ecosystem.

> I think an important part missing from this, overall, is to highlight that 
> these clauses only apply with respect to definitive responses. That is, this 
> only applies to the set of responses for which a pre-certificate exists (and 
> thus a matching certificate is presumed to exist) or for where a certificate 
> actually exists.

Agreed, these clauses need to apply to definitive responses (pre-cert || cert).

> Presuming the OCSP responder supports the requestor CertID algorithm :)

Correct.

> I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280 
> both presuppose the existence of other sources of revocation, beyond those 
> enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in the 
> air. So I don't think either the policies or text currently require this 
> "ONLY" clause, but I do think we want to nail down the situations here. As it 
> relates specifically to the (precert || cert) case, the BRs treat the 
> responder as a singular "the", so I don't think the ONLY applies... so I 
> think this whole thing washes out as "not allowed" for the case of (precert 
> || cert), and is met by "unauthorized", as well as possible transport-layer 
> options (RFC 5019 is somewhat silent, AFAICT, on this)

My interpretation incorrectly presumed only OCSP as an option. I was attempting 
to address the NOTE in RFC 6960 from Section 2.2 but I failed to account for 
CRLs:

NOTE: The "revoked" status indicates that a certificate with the
         requested serial number should be rejected, while the "unknown"
         status indicates that the status could not be determined by
         this responder, thereby allowing the client to decide whether
         it wants to try another source of status information (such as a
         CRL). 

> Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I 
> wasn't sure if the suggestion was enumerating it as a MUST ("should be used") 
> or merely acknowledging it as a valid situation for revoked.


I was acknowledging it as a valid situation for revoked and did pull from 
Section 2.7.

> If the assumption of policy is that the existence of a pre-certificate is 
> proof of equivalent issuance, then the only situation this arises is if and 
> only if the CA is running an online signing service in line with 6960, rather 
> than the pre-distribution approach of RFC 5019 that the scale of the Web PKI 
> effectively ensures is necessary, and only in the cases where a 
> pre-certificate /doesn't/ exist.

I must admit I was focused on RFC 6960 and should have been including RFC 5019 
in my interpretation.

> So to recap:
> - In RFC 5019, it's clear that one of the core goals of 5019 is to not 
> require the creation of definitive responses for the entire serial space. So 
> we're only talking (pre-cert || cert) definitive cases.
> - In RFC 6960, it's clear that one of the core goals of the extended response 
> is to leave it /optional/ (MAY) for CAs to respond Revoked, and for serial 
> numbers they have no record of having issued. So we're talking !(pre-cert || 
> cert) cases.

Well said.

- Curt

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to