On 20/01/16 14:35, Richard Barnes wrote:
Changing the subject line as this is branching a bit...
<snip>
IIRC, the original motivation for this text was to make it possible to
suppress OCSP requests directly from TLS clients (that don't support OCSP
Stapling). In particular, there was a concern that some OCSP responders
might not be able to cope with the OCSP traffic generated by certs used by
sites with extremely high numbers of users.
At the time, Firefox didn't support OCSP Stapling, and it was much less
common for CAs to use CDNs for their OCSP responders. (Indeed, some CAs
didn't even support OCSP back then).
This sentence has always bothered me, though, because in order to make
sense, you would have to have the CA verify that the OCSP response is
stapled, and there's not any requirement to do that. ISTM that omitting
the OCSP URL only really makes sense if there's a TLS Feature extension
requiring stapling (i.e., must-staple).
Now that Must-Staple exists, then yes, definitely.
"""
The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted, provided
that the Certificate contains a TLS Feature extension including the value
status_request(5). This extension requires that the Subscriber “staples”
the OCSP response for the Certificate in its TLS handshakes [RFC4366]."
"""
If this is non-controversial, maybe this is something to add to Bowen's
ballot that's being discussed on another thread?
+1
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
