[Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

Thu Apr 25 12:35:52 UTC 2024

[like]  Sven Rajala reacted to your message:
________________________________
From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Ryan Dickson via Servercert-wg <servercert-wg at cabforum.org>
Sent: Thursday, April 25, 2024 12:29:21 PM
To: Adriano Santoni <adriano.santoni at staff.aruba.it>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

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 (referenced in ballot preamble): "authorityInformationAccess: 

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://urldefense.com/v3/__https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/__;!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XG8icd_E$>):

  *   "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://urldefense.com/v3/__https://cabforum.org/2022/06/06/minutes-of-the-f2f-56-meeting-in-warsaw-poland-6-8-june-2022/__;!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XCLJuGak$> (slide 14<https://urldefense.com/v3/__https://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf__;!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XK-CkUdI$>, "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://urldefense.com/v3/__https://bugzilla.mozilla.org/show_bug.cgi?id=1884714*c1__;Iw!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2X0woQAbI$> 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<mailto: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://"<https://urldefense.com/v3/__http://*22__;JQ!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XEgs7twQ$>.

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<mailto: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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5280.html*section-4.2.2.1__;Iw!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XM-qUAys$> 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 at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://urldefense.com/v3/__https://lists.cabforum.org/mailman/listinfo/servercert-wg__;!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XiZF4fNo$>

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://urldefense.com/v3/__https://lists.cabforum.org/mailman/listinfo/servercert-wg__;!!BjbSd3t9V7AnTp3tuV-82YaK!y174iVBDtZ3z5-EvidUFZS37N7NTH7eP98SfJziM58hPZLOaQQRXxgxnzQAgD9nso-0KMdxJVAN4O4UBpijDsJ2XiZF4fNo$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240425/b2a9518d/attachment-0001.html>