Hi Rufus, Section 3.3 of RFC 3986 [1] defines the following ABNF production rule for a path character (“pchar”):
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
The production rule for “sub-delims” is defined in section 2.2 as follows:
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Given this grammar, standards-compliant clients do not need to percent-encode
the “+” and “=” characters, so OCSP responders must accept these characters
as-is. However, “/” is noticeably absent from the pchar production rule (which
makes sense, as it’s used as the path segment delimiter), so it must be
percent-encoded.
Thanks,
Corey
[1] https://datatracker.ietf.org/doc/html/rfc3986#section-3.3
From: [email protected] <[email protected]> On
Behalf Of Rufus Buschart
Sent: Monday, January 3, 2022 10:22 AM
To: [email protected]
Cc: Rufus Buschart <[email protected]>
Subject: Re: OCSP responder behavior for HTTP GET requests
We had discussions about the '+'-character in the string created by Digicert to
assess whether an OCSP responder is behaving according to the RFCs / BRs or
not. The earliest reference about URL encoding we found is RFC1738, chapter 2.2
which states:
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
Also, there is plenty of discussion on StackOverflow about this issue, and it
seems, that the + sign as part of the URL needs to be decoded into a + sign and
not into a ‘white space’ as long as it is not part of a form POST submission
request body or in the ?query part of the URL
(https://stackoverflow.com/a/2700981/1426535
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F2700981%2F1426535&data=04%7C01%7Cmartin.furuhed%40nexusgroup.com%7C3122eb4b49c349dca69b08d9b0291649%7C89f9cd6ffab54f61a85eb1b24768f7f6%7C0%7C0%7C637734512790851142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C71RNqc3bsx44PwbvYAzulRRJIoZGF3mRrTRMitIfFs%3D&reserved=0>
).
But there is a reference in RFC6960 to RFC3986, the update to RFC1738. And RFC
3986 section 2.2 states the following for reserved characters:
URI producing applications should percent-encode data octets that
correspond to characters in the reserved set unless these characters
are specifically allowed by the URI scheme to represent data in that
component.
With this section applied to the OCSP GET request context, the requesting OCSP
client is the 'URI producing application' and should perform percent-encoding
of all characters in the reserved set. This would mean, that the '+'-character
in the test string is invalid and should be URL encoded.
How does the Mozilla Community feel about this?
/Rufus
Rufus Buschart schrieb am Mittwoch, 13. Oktober 2021 um 16:00:53 UTC+2:
Do we believe that an affected CA should open a bug report? The situation is an
edge case: as long as the OCSP responder didn't receive a requested for such a
specific URL, it didn't fail and the CA is compliant to the BRs but as soon as
it received such a request once, the CA is not compliant anymore. How do you
feel?
/Rufus
[email protected] schrieb am Mittwoch, 13. Oktober 2021 um 02:58:16
UTC+2:
Corey Bonnell writes:
>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.
Ah, right, and since 5019 removes the replay-protection nonces it would make
the whole thing cacheable while non-5019 OCSP with nonces wouldn't be. The
reason I brought it up is that SCEP has run into problems with GET, see the
note at https://datatracker.ietf.org/doc/html/rfc8894.html#section-4.1, which
are typically very hard to diagnose because of the conditions under which they
occur.
Peter.
--
You received this message because you are subscribed to the Google Groups
"[email protected] <mailto:[email protected]> "
group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]
<mailto:[email protected]> .
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c9ecd316-6029-40cc-8677-1d9c9676791fn%40mozilla.org
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c9ecd316-6029-40cc-8677-1d9c9676791fn%40mozilla.org?utm_medium=email&utm_source=footer>
.
--
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/DM6PR14MB2186FD4A83392BABC91116E692499%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
