[Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed May 1 06:40:04 UTC 2024
Thanks Clint,
It would help doing some research in CENSYS to see if this is a real
problem or not. I will try to get some additional resources internally
to help me with this. In any case, this discussion might inspire some of
the linting software developers to write a lint expecting only *http://*
URLs in that field.
Best regards,
Dimitris.
On 1/5/2024 12:52 π.μ., Clint Wilson wrote:
> Hi Dimitris,
>
> My understanding is that the intent was indeed to restrict these to
> HTTP specifically. That is, the phrase “the only URLS present MUST be
> HTTP URLs” is intended to preclude the use of HTTPS, and not just to
> indicate that any scheme which relies on the Hypertext Transfer
> Protocol can be used.
>
> Presumably when 5280 was drafted, the authors were aware of the
> updates 2817 made to 2616, but chose not to reference those updates.
> Even if not, I concur with Ryan and my recollection is also that the
> discussion during SC-62’s formation did include this topic with the
> consensus (at that time) being that some fields would be restricted to
> using only HTTP URIs.
>
> To your original questions:
>>>
>>>> Do Members agree with that interpretation?
>>>
>
> Yes
>
>>>>
>>>> If this is the correct interpretation, would it be considered a
>>>> violation of the BRs if a CA or end-entity certificate contains
>>>> https:// URL in the id-ad-caIssuers accessMethod ?
>>>
>
> Yes, at least for certificates issued after SC-62 went into effect
> (maybe also for those prior, I just haven’t looked).
>
>>>>
>>>> I'm afraid that this might not be as clear in the BRs as it
>>>> should be, so if people agree with the above, we should
>>>> probably update section 7.1.2.7.7
>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access> (and
>>>> possibly other parts) to explicitly state that the allowed
>>>> scheme is "http" and not "https", just like we do for the CRLDP
>>>> in section 7.1.2.11.2
>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points> .
>>>
>>>
>
> I’m not convinced a clarification is worthwhile here. To be clear, I’m
> not opposed, I’m just not sure it’s something CAs are actively getting
> or likely to get wrong — if some are, then I would instead support
> such a clarification.
>
> Cheers!
> -Clint
>
>> On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos (HARICA) via
>> Servercert-wg <servercert-wg at cabforum.org> wrote:
>>
>> Hi Ryan,
>>
>> The question is not between HTTP vs FTP vs LDAP but specifically for
>> "HTTP URL" that could have two schemes "http" and "https".
>>
>> RFC 2616 (June 1999) included only "http" and was updated in May 2000
>> by RFC 2817 <https://datatracker.ietf.org/doc/html/rfc2817> to
>> include TLS Within HTTP/1.1 ("https").
>>
>> I hope this clarifies the issue.
>>
>>
>> Dimitris.
>>
>> On 25/4/2024 3:29 μ.μ., Ryan Dickson via Servercert-wg wrote:
>>> It's my understanding that the intent of the updates made in SC-62
>>> were to prohibit any non-HTTP URI. This was discussed in:
>>>
>>> 1) at least one historical GitHub discussion
>>> <https://github.com/sleevi/cabforum-docs/pull/36> (referenced in
>>> ballot preamble
>>> <https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/>):
>>>
>>> * /"authorityInformationAccess: This is a new requirement./
>>> o /BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL
>>> of the Issuing CA's certificate and MAY contain the HTTP URL
>>> of the Issuing CA's OCSP responder./
>>> o /Some questions were raised about whether this means other
>>> URLs, other schemes, or multiple URLs can be included.
>>> Similar to crlDistributionPoints, the ordering of URLs
>>> implies processing semantics on clients, and only particular
>>> URL schemes are supported. Namely, if one of the two
>>> supported access methods are present (CA issuer or OCSP),
>>> *then the only URLs present MUST be HTTP URLs*, and MUST be
>>> listed in order of priority./
>>> o /This prohibits the use of other access methods, as they are
>>> not used in the Web PKI."/
>>>
>>> /
>>> /
>>> and 2) Corey's Validation Subcommittee presentation at F2F 56
>>> <https://cabforum.org/2022/06/06/minutes-of-the-f2f-56-meeting-in-warsaw-poland-6-8-june-2022/> (slide
>>> 14
>>> <https://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf>,
>>> /"Non-HTTP (i.e., LDAP and FTP) OCSP and CA Issuers URIs are
>>> prohibited").//
>>> /
>>> /
>>> /
>>> D-Trust volunteered to propose an update to the BRs to address the
>>> issue in this
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1884714#c1> Bugzilla
>>> Bug (Actions Table).
>>>
>>> Thanks,
>>> Ryan
>>>
>>> On Thu, Apr 25, 2024 at 3:44 AM Adriano Santoni via Servercert-wg
>>> <servercert-wg at cabforum.org> wrote:
>>>
>>> Hi,
>>>
>>> IMO, including an HTTPS URI in the *id-ad-caIssuers*
>>> accessMethod is at least a bad practice and very unwise (if done
>>> on purpose), as it may give rise to unbounded loops, as it is
>>> clearly explained in RFC5280:
>>>
>>>
>>>> CAs SHOULD NOT include URIs that specify https, ldaps, or similar
>>>> schemes in extensions. CAs that include an https URI in one of these
>>>> extensions MUST ensure that the server's certificate can be validated
>>>> without using the information that is pointed to by the URI. Relying
>>>> parties that choose to validate the server's certificate when
>>>> obtaining information pointed to by an https URI in the
>>>> cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
>>>> extensions MUST be prepared for the possibility that this will result
>>>> in unbounded recursion.
>>>
>>> That said, whether it amounts to a violation of the BRs it's a
>>> different matter. Generally speaking, since the requirement for
>>> the *id-ad-caIssuers* accessMethod is expressed in the same way
>>> as for the *id-ad-ocsp* accessMethod and for *distributionPoint*
>>> (see 7.1.2.11.2), therefore if using an "https" URI is indeed a
>>> violation it should be so for all three cases.
>>>
>>> It should also be noted that PKILINT contains a validator for
>>> checking that the URI in the *id-ad-caIssuers* accessMethod
>>> starts with "http://".
>>>
>>> Adriano
>>>
>>>
>>> Il 25/04/2024 08:10, Dimitris Zacharopoulos (HARICA) via
>>> Servercert-wg ha scritto:
>>>> NOTICE: Pay attention - external email - Sender is
>>>> 0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000 at amazonses.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Dear Members,
>>>>
>>>> I have a quick question regarding the id-ad-caIssuers
>>>> accessMethod URI.
>>>>
>>>> Section 4.2.2.1 of RFC 5280
>>>> <https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.2.1>
>>>> states that:
>>>>
>>>>> When theid-ad-caIssuersaccessMethod is used, at least one
>>>>> instance SHOULD specify an accessLocation that is an HTTP
>>>>> [RFC2616] or LDAP [RFC4516] URI.
>>>>
>>>> RFC 2616 does not support https. That was introduced in a
>>>> superseded version.
>>>>
>>>> Since RFC 5280 points to RFC 2616, based on past discussions
>>>> about strictly adhering to RFC 5280 despite the existence of
>>>> superseded versions, I believe that the proper interpretation
>>>> of this requirement is that the "http" scheme is allowed and
>>>> "https" is not.
>>>>
>>>> Do Members agree with that interpretation?
>>>>
>>>> If this is the correct interpretation, would it be considered a
>>>> violation of the BRs if a CA or end-entity certificate contains
>>>> https:// URL in the id-ad-caIssuers accessMethod ?
>>>>
>>>> I'm afraid that this might not be as clear in the BRs as it
>>>> should be, so if people agree with the above, we should
>>>> probably update section 7.1.2.7.7
>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access>
>>>> (and possibly other parts) to explicitly state that the allowed
>>>> scheme is "http" and not "https", just like we do for the CRLDP
>>>> in section 7.1.2.11.2
>>>> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points>
>>>> .
>>>>
>>>>
>>>> Thank you,
>>>> Dimitris.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Servercert-wg mailing list
>>>> Servercert-wg at cabforum.org
>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240501/1e63e3c0/attachment-0001.html>
More information about the Servercert-wg
mailing list