Hi Peter,
My understanding is that although HTTP GET requests are expected to be 
idempotent (i.e., the state of the world should not change as a side effect of 
the GET request), there is no expectation that content itself of the specified 
resource must be static. RFC 5019 leverages GET requests to improve 
cacheability [1]. Given the performance benefits of implementing RFC 5019, this 
is likely why the BRs mandate that CAs must support HTTP GET for their 
responders.

Thanks,
Corey

[1] https://datatracker.ietf.org/doc/html/rfc5019#section-5

-----Original Message-----
From: [email protected] <[email protected]> On 
Behalf Of Peter Gutmann
Sent: Friday, October 8, 2021 5:11 AM
To: [email protected]; Corey Bonnell <[email protected]>
Subject: Re: OCSP responder behavior for HTTP GET requests

'Corey Bonnell' via [email protected] writes:

>Section 4.9.10 of the BRs [1] specifies that “OCSP responders operated 
>by the CA SHALL support the HTTP GET method

Regardless of the URL-encoding issues, isn't this wrong in any case since GET 
is idempotent but OCSP isn't?  So the solution isn't to try and patch up the 
use of the wrong HTTP mechanism but to require the use of non-idempotent POST 
to match the non-idempotent OCSP, and then the URL-encoding issue resolves 
itself.

Peter.

--
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB625181E9F6A7D472CF3390ECEEB29%40SY4PR01MB6251.ausprd01.prod.outlook.com.

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB21869E664E7B681455A597A992B59%40DM6PR14MB2186.namprd14.prod.outlook.com.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to