[Servercert-wg] [External Sender] Re: Question regarding the id-ad-caIssuers accessMethod URI
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu May 2 07:06:44 UTC 2024
Regardless of the original intent to limit or not the allowed scheme s
to "http" (i.e. excluding "https") in the BRs, we should keep in mind
the practical implications of using https in the *id-ad-caIssuers
*access method (see also the admonition in RFC 5280 that I have already
quoted before).
When a client accesses the caIssuers URI (which I don't think it's very
frequent, but I am not sure), it does so in order to obtain the
intermediate CA it lacks to complete the cert chain up to a trusted
root, in order to verify a leaf certificate (or a lower-level
intermediate CA); but if that URI is an "https" one (and not simply
"http"), it is possible that the client will end up in a vicious circle,
eventually hanging or failing.
Adriano
Il 01/05/2024 14:27, Corey Bonnell via Servercert-wg ha scritto:
>
> Hi Clint,
>
> > My understanding is that the intent was indeed to restrict these to
> HTTP specifically.
>
> That matches my understanding as well.
>
> > 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.
>
> The S/MIME BRs use the term “scheme” to explicitly specify when only
> plaintext HTTP (and not HTTPS) URIs are allowed. If the consensus is
> that a change in the TLS BRs is warranted, then I think using this
> term would better clarify the requirements regarding the mandated use
> of plaintext HTTP.
>
> Thanks,
>
> Corey
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
> Of *Clint Wilson via Servercert-wg
> *Sent:* Tuesday, April 30, 2024 5:53 PM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; ServerCert
> CA/BF <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [External Sender] Question regarding
> the id-ad-caIssuers accessMethod URI
>
> 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%2371277-subscriber-certificate-authority-information-access___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmU5MDk6YTA4YWI1ZDhkNjMyOTFhMDVhMGVjMzNlMWU3MmZmMTY0ZTU4NWVjZjEyMDc0MWUwMTIxNTA3MzBiMWE2ZWMwNjpoOkY> (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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%23712112-crl-distribution-points___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjRlMTk6YWY0YmIzMWY4YmUzMTQ2YjIyYjZiNzI3ZDZkNjYzNDUyNTdiMmRkOWI0NmUxNzg4NmJlYmU3OWNhZTFjYjBjNzpoOkY> .
>
>
> 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://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/html/rfc2817___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmVmNWI6NDU4YWZiNWJmYTVhNmY4NDk2YTQ3NzNlYzZjNDNkOTc1YmQ3ZDBhYzkzZTdjMjVjMTk2NDliNTYzYWY3YjMyNzpoOkY>
> 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://url.avanan.click/v2/___https:/github.com/sleevi/cabforum-docs/pull/36___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjYwM2I6MzRjNjY5NGMzYTQ0MDVmMDczNjU3OTEwZjY3NzllMTRiNzJjZGIzNTdjYTE0ZWY4YWZiMTkyMTZiNGQ2ZWRiMjpoOkY> (referenced
> in ballot preamble
> <https://url.avanan.click/v2/___https:/cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjIxZDc6ZTIyNTE1ZWRkN2QzOGI4NmRjZmQ2ZDM2YmY3YWZkYzJiMjg1ODc2NzExNDM3ZDg5MTk0M2NjZmE3ZDAwOGYwMzpoOkY>):
>
> * /"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://url.avanan.click/v2/___https:/cabforum.org/2022/06/06/minutes-of-the-f2f-56-meeting-in-warsaw-poland-6-8-june-2022/___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmJjMWQ6MTM2ZjYxZGJiMWY2ZWY1NjJiMmI4Y2JkZjI5YmRjOTM2Nzc3MTVkN2I5MjgwNTlmNjQ0MDY2NjI2MzNlNThhOTpoOkY> (slide
> 14
> <https://url.avanan.click/v2/___https:/lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjY1Yjk6ZDU2NWZjZmJiMDcwZTY0MmI5ZjRiMDJkN2NhOGIxNmVkOWZkYTVmMGExNjYwMjUxM2IyMDhlMTE1MTVhYzY4ZDpoOkY>,
> /"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://url.avanan.click/v2/___https:/bugzilla.mozilla.org/show_bug.cgi?id=1884714%23c1___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjIxOTI6YTZlMTBlMzdmMTgzODI3ZGJiMTg4YWZiYTAyYmYwZDJhMTkwNjA3MGQ2MDEzZjcxNmFlNDEwZDM1OWUzMGJjYzpoOkY>
> 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://url.avanan.click/v2/___https:/www.rfc-editor.org/rfc/rfc5280.html%23section-4.2.2.1___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjJhNGI6MWFjOGRjMDRlYmE5NWU3Njk3MDI3MWFmOTQzNDAwYTdlYzkzMmYxMmQ0MDcwNTRmNzVmMTM3NjUzMTgzYWQ0OTpoOkY>
> 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%2371277-subscriber-certificate-authority-information-access___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjAxZGM6M2QzM2FkODM3NDBhOThkNDA1YzZmMDY2MTEwMGQyZGIxNGJmZTQyM2Q4ODhiNWE0OTcxMGI5MmEyNWJjY2Q0OTpoOkY>
> (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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%23712112-crl-distribution-points___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjdkNWU6NjU0MDRmYWVjOGE3MTdhZDU5YjY1YmYyMzJhYmVhZWJhYjdiNzAzY2E4YWI2OTk2NWViMTdlYmViMzBmMTIzOTpoOkY>
> .
>
>
> Thank you,
> Dimitris.
>
>
>
>
> _______________________________________________
>
> Servercert-wg mailing list
>
> Servercert-wg at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjA4NjA6M2I1Yjc1OGQ5YjM1YWJkODA0ZTRjMzQ3ZTBlZmQ2MmJlOWQzOTA5NmQ1MjI4ZTY3NzM1MGIxMzc5ZDQzMDQ2MjpoOkY>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmJhM2I6MDYyNzZhY2RjZWQ0ZjBjZTNmMjU3ZDgwMjVjNWZlMmU4MWYzMTM0MWI4NmIxMzBiNGE2ZWU5YWM3OGUwN2FhNjpoOkY>
>
>
>
> _______________________________________________
>
> Servercert-wg mailing list
>
> Servercert-wg at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmFjNDM6ZWEwNWYyMzc3M2NmOTZmNGRhNGUwNDhjNTg1YjE3NDFhMmQzMjY5Y2RhMzkwNTBlY2E1YjU4ZmQyZTkxZDYyOTpoOkY>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmE4NmM6MDcxNTQxOGMyZWJkMjA1YTMyNmQyNjRjNDVmYjBhYTdlNTk5ZTVhNDNmNDk0MDAzOTdjZDE3YTNiNjc0NjYyZTp0OkY
> <https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmE4NmM6MDcxNTQxOGMyZWJkMjA1YTMyNmQyNjRjNDVmYjBhYTdlNTk5ZTVhNDNmNDk0MDAzOTdjZDE3YTNiNjc0NjYyZTp0OkY>
>
>
> _______________________________________________
> 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/20240502/6b5f5eea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240502/6b5f5eea/attachment-0001.p7s>
More information about the Servercert-wg
mailing list