<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thanks Clint,<br>
<br>
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 <b>http://</b> URLs in that field.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 1/5/2024 12:52 π.μ., Clint Wilson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6DC40971-C3EA-468C-A9D5-DF6B539857B7@apple.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Hi Dimitris,</div>
<div><br>
</div>
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.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>To your original questions:</div>
<div>
<blockquote type="cite">
<blockquote type="cite"
cite="mid:0100018f153b72fc-053f7204-7d34-4284-89db-bba51e655881-000000@email.amazonses.com">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">
<blockquote type="cite">Do Members agree with that
interpretation? <br>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div><br>
</div>
<div>Yes</div>
<br>
<blockquote type="cite">
<blockquote type="cite"
cite="mid:0100018f153b72fc-053f7204-7d34-4284-89db-bba51e655881-000000@email.amazonses.com">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">
<blockquote type="cite"><br>
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 ? <br>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div><br>
</div>
<div>Yes, at least for certificates issued after SC-62 went into
effect (maybe also for those prior, I just haven’t looked).</div>
<br>
<blockquote type="cite">
<blockquote type="cite"
cite="mid:0100018f153b72fc-053f7204-7d34-4284-89db-bba51e655881-000000@email.amazonses.com">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">
<blockquote type="cite"><br>
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 <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access"
moz-do-not-send="true">section 7.1.2.7.7</a> (and
possibly other parts) to explicitly state that the
allowed scheme is "http" and not "https", just like we
do for the CRLDP in <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points"
moz-do-not-send="true">section 7.1.2.11.2</a> . </blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers!</div>
<div>-Clint</div>
<div><br>
<blockquote type="cite">
<div>On Apr 25, 2024, at 5:41 AM, Dimitris Zacharopoulos
(HARICA) via Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div> Hi Ryan,<br>
<br>
The question is not between HTTP vs FTP vs LDAP but
specifically for "HTTP URL" that could have two schemes
"http" and "https".<br>
<br>
RFC 2616 (June 1999) included only "http" and was
updated in May 2000 by <a
href="https://datatracker.ietf.org/doc/html/rfc2817"
moz-do-not-send="true">RFC 2817</a> to include TLS
Within HTTP/1.1 ("https").<br>
<br>
I hope this clarifies the issue.<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 25/4/2024 3:29 μ.μ.,
Ryan Dickson via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f153b72fc-053f7204-7d34-4284-89db-bba51e655881-000000@email.amazonses.com">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div dir="ltr">
<div>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:<br>
</div>
<div>
<div><br>
</div>
<div>1) at least one historical GitHub <a
href="https://github.com/sleevi/cabforum-docs/pull/36"
moz-do-not-send="true">discussion</a> (referenced
in ballot <a
href="https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/"
moz-do-not-send="true">preamble</a>):</div>
<div><br>
</div>
<div>
<ul dir="auto"
style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji"">
<li
style="margin-left:0px;box-sizing:border-box;margin-top:0.25em"><i>"authorityInformationAccess:
This is a new requirement.</i></li>
<ul dir="auto"
style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:0px">
<li
style="margin-left:0px;box-sizing:border-box"><i>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.</i></li>
<li
style="margin-left:0px;box-sizing:border-box;margin-top:0.25em"><i>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), <b>then the only URLs
present MUST be HTTP URLs</b>, and
MUST be listed in order of priority.</i></li>
<li
style="margin-left:0px;box-sizing:border-box;margin-top:0.25em"><i>This
prohibits the use of other access
methods, as they are not used in the Web
PKI."</i></li>
</ul>
</ul>
<div><font
face="-apple-system, system-ui, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"
color="#1f2328"><i><br>
</i></font></div>
</div>
<div>and 2) Corey's Validation Subcommittee
presentation at <a
href="https://cabforum.org/2022/06/06/minutes-of-the-f2f-56-meeting-in-warsaw-poland-6-8-june-2022/"
moz-do-not-send="true">F2F 56</a> (slide <a
href="https://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf"
moz-do-not-send="true">14</a>, <i>"Non-HTTP
(i.e., LDAP and FTP) OCSP and CA Issuers URIs
are prohibited").</i><font
face="-apple-system, system-ui, Segoe UI, Noto Sans, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji"
color="#1f2328"><i><br>
</i></font></div>
<div><i><br>
</i></div>
<div>D-Trust volunteered to propose an update to
the BRs to address the issue in <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1884714#c1"
moz-do-not-send="true">this</a> Bugzilla Bug
(Actions Table).</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Ryan</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 25,
2024 at 3:44 AM Adriano Santoni via Servercert-wg
<<a href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><font face="Calibri">Hi,</font></p>
<p><font face="Calibri">IMO, including an HTTPS
URI in the <b>id-ad-caIssuers</b>
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:</font></p>
<div><font face="Calibri"> </font><br
class="webkit-block-placeholder">
</div>
<blockquote type="cite"><font face="Calibri">
<pre>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.</pre>
</font></blockquote>
<font face="Calibri"> </font>
<p><font face="Calibri">That said, whether it
amounts to a violation of the BRs it's a
different matter. Generally speaking, since
the requirement for </font><font
face="Calibri">the <b>id-ad-caIssuers</b>
accessMethod </font><font face="Calibri">is
expressed in the same way as for the </font><font
face="Calibri"><b>id-ad-ocsp</b>
accessMethod </font><font face="Calibri">and
for <b>distributionPoint</b> (see
7.1.2.11.2), therefore if using an "https"
URI is indeed a violation it should be so
for all three cases.</font></p>
<p><font face="Calibri">It should also be noted
that PKILINT contains a validator for
checking that the URI in the </font><font
face="Calibri"><b>id-ad-caIssuers</b>
accessMethod starts with "http://".<br>
</font></p>
<p><font face="Calibri">Adriano</font></p>
<p><font face="Calibri"><br>
</font></p>
<div>Il 25/04/2024 08:10, Dimitris Zacharopoulos
(HARICA) via Servercert-wg ha scritto:<br>
</div>
<blockquote type="cite">
<div align="center">
<table width="30%" cellspacing="2"
cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top" bgcolor="#ffff00"> <span
style="color:red">NOTICE:</span>
Pay attention - external email -
Sender is <a
href="mailto:0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000@amazonses.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000@amazonses.com</a>
</td>
</tr>
</tbody>
</table>
<br>
</div>
<br>
<br>
Dear Members, <br>
<br>
I have a quick question regarding the <span></span>
id-ad-caIssuers <span> </span> accessMethod
URI. <br>
<br>
<a
href="https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.2.1"
moz-do-not-send="true">Section 4.2.2.1 of
RFC 5280</a> states that: <br>
<br>
<blockquote type="cite"
style="box-sizing:inherit;margin:4px 0px;padding:0px 0px 0px 16px;color:rgb(29,28,29);font-family:Slack-Lato,Slack-Fractions,appleLogo,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:common-ligatures;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;word-spacing:0px;white-space:normal;background-color:rgb(248,248,248);text-decoration-style:initial;text-decoration-color:initial">
When the<span> </span>id-ad-caIssuers<span> </span>accessMethod
is used, at least one instance SHOULD
specify an accessLocation that is an HTTP
[RFC2616] or LDAP [RFC4516] URI.</blockquote>
<br>
RFC 2616 does not support https. That was
introduced in a superseded version. <br>
<br>
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. <br>
<br>
Do Members agree with that interpretation? <br>
<br>
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 ? <br>
<br>
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 <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access"
moz-do-not-send="true"> section 7.1.2.7.7</a>
(and possibly other parts) to explicitly state
that the allowed scheme is "http" and not
"https", just like we do for the CRLDP in <a
href="https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points"
moz-do-not-send="true"> section 7.1.2.11.2</a>
. <br>
<br>
<br>
Thank you, <br>
Dimitris. <br>
<br>
<br>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Servercert-wg mailing list
<a href="mailto:Servercert-wg@cabforum.org" moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext"
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>