I did a quick check, but was only able to find one recently issued leaf certificate that contained an https CA Issuers URI. There seems to be about 26 CA certificates that do as well, but all were issued before 2019 except for 2. Of the 1 leaf and 2 CA certificates that are more recent, they’re all from CAs that have very limited root inclusion in the ecosystem and do not participate in the CA/BF afaict.
Not sure how relevant all that is, but just to share what I’d found. I’m sure others could do a more thorough job, but I don’t see clear signs that this is a widespread issue at least (phew! :) Cheers, -Clint > On Apr 30, 2024, at 11:40 PM, Dimitris Zacharopoulos (HARICA) > <dzach...@harica.gr> wrote: > > 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@cabforum.org> >>> <mailto:servercert-wg@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. >>>> 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. >>>> 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. >>>> 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@cabforum.org <mailto:servercert-wg@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-000...@amazonses.com >>>>>> >>>>>> <mailto:0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000...@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 the id-ad-caIssuers accessMethod 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@cabforum.org <mailto:Servercert-wg@cabforum.org> >>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>>>> _______________________________________________ >>>>> Servercert-wg mailing list >>>>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>>> >>>> >>>> _______________________________________________ >>>> Servercert-wg mailing list >>>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >>> >>> _______________________________________________ >>> Servercert-wg mailing list >>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
