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]" 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/c9ecd316-6029-40cc-8677-1d9c9676791fn%40mozilla.org.
