<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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 <b>id-ad-caIssuers
</b>access method (see also the admonition in RFC 5280 that I have
already quoted before).<br>
</p>
<p>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.<br>
</p>
<p>Adriano</p>
<p><br>
</p>
<p></p>
<div class="moz-cite-prefix">Il 01/05/2024 14:27, Corey Bonnell via
Servercert-wg ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f341f86f9-9a0f06f3-4e70-4611-bd91-84164a01045f-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;}@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Clint,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> </span>My
understanding is that the intent was indeed to restrict these
to HTTP specifically.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That matches my understanding as well.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Corey<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Servercert-wg <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg-bounces@cabforum.org"><servercert-wg-bounces@cabforum.org></a>
<b>On Behalf Of </b>Clint Wilson via Servercert-wg<br>
<b>Sent:</b> Tuesday, April 30, 2024 5:53 PM<br>
<b>To:</b> Dimitris Zacharopoulos (HARICA)
<a class="moz-txt-link-rfc2396E" href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a>; ServerCert CA/BF
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] [External Sender]
Question regarding the id-ad-caIssuers accessMethod URI<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To your original questions:<o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Do Members agree with that
interpretation? <o:p></o:p></p>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><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 ? <o:p></o:p></p>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, at least for certificates issued
after SC-62 went into effect (maybe also for those prior,
I just haven’t looked).<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%2371277-subscriber-certificate-authority-information-access___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmU5MDk6YTA4YWI1ZDhkNjMyOTFhMDVhMGVjMzNlMWU3MmZmMTY0ZTU4NWVjZjEyMDc0MWUwMTIxNTA3MzBiMWE2ZWMwNjpoOkY"
title="Protected by Avanan: 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%23712112-crl-distribution-points___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjRlMTk6YWY0YmIzMWY4YmUzMTQ2YjIyYjZiNzI3ZDZkNjYzNDUyNTdiMmRkOWI0NmUxNzg4NmJlYmU3OWNhZTFjYjBjNzpoOkY"
title="Protected by Avanan: 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> . <o:p></o:p></p>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Clint<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Apr 25, 2024, at 5:41<span
style="font-family:"Arial",sans-serif"> </span>AM,
Dimitris Zacharopoulos (HARICA) 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:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/html/rfc2817___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmVmNWI6NDU4YWZiNWJmYTVhNmY4NDk2YTQ3NzNlYzZjNDNkOTc1YmQ3ZDBhYzkzZTdjMjVjMTk2NDliNTYzYWY3YjMyNzpoOkY"
title="Protected by Avanan: 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.<o:p></o:p></p>
<div>
<p class="MsoNormal">On 25/4/2024 3:29 μ.μ., Ryan
Dickson via Servercert-wg wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) at least one
historical GitHub <a
href="https://url.avanan.click/v2/___https:/github.com/sleevi/cabforum-docs/pull/36___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjYwM2I6MzRjNjY5NGMzYTQ0MDVmMDczNjU3OTEwZjY3NzllMTRiNzJjZGIzNTdjYTE0ZWY4YWZiMTkyMTZiNGQ2ZWRiMjpoOkY"
title="Protected by Avanan: https://github.com/sleevi/cabforum-docs/pull/36"
moz-do-not-send="true">discussion</a> (referenced
in ballot <a
href="https://url.avanan.click/v2/___https:/cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjIxZDc6ZTIyNTE1ZWRkN2QzOGI4NmRjZmQ2ZDM2YmY3YWZkYzJiMjg1ODc2NzExNDM3ZDg5MTk0M2NjZmE3ZDAwOGYwMzpoOkY"
title="Protected by Avanan: https://cabforum.org/2023/03/17/ballot-sc62v2-certificate-profiles-update/"
moz-do-not-send="true">preamble</a>):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<ul
style="margin-top:0in;box-sizing:border-box"
type="disc">
<li class="MsoNormal"
style="color:#1F2328;margin-top:3.0pt;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo3;box-sizing:border-box"><i><span
style="font-family:"Segoe UI",sans-serif">"authorityInformationAccess:
This is a new requirement.</span></i><span
style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li>
</ul>
<ul type="disc">
<ul type="circle">
<li class="MsoNormal"
style="color:#1F2328;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo3;box-sizing:border-box"><i><span
style="font-family:"Segoe UI",sans-serif">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.</span></i><span
style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li>
<li class="MsoNormal"
style="color:#1F2328;margin-top:3.0pt;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo3;box-sizing:border-box"><i><span
style="font-family:"Segoe UI",sans-serif">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.</span></i><span
style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li>
<li class="MsoNormal"
style="color:#1F2328;margin-top:3.0pt;mso-margin-bottom-alt:auto;mso-list:l2 level2 lfo3;box-sizing:border-box"><i><span
style="font-family:"Segoe UI",sans-serif">This prohibits the
use of other access methods, as they
are not used in the Web PKI."</span></i><span
style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></li>
</ul>
</ul>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">and 2) Corey's Validation
Subcommittee presentation at <a
href="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"
title="Protected by Avanan: 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://url.avanan.click/v2/___https:/lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526/attachment-0001.pdf___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjY1Yjk6ZDU2NWZjZmJiMDcwZTY0MmI5ZjRiMDJkN2NhOGIxNmVkOWZkYTVmMGExNjYwMjUxM2IyMDhlMTE1MTVhYzY4ZDpoOkY"
title="Protected by Avanan: 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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">D-Trust volunteered to
propose an update to the BRs to address the
issue in <a
href="https://url.avanan.click/v2/___https:/bugzilla.mozilla.org/show_bug.cgi?id=1884714%23c1___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjIxOTI6YTZlMTBlMzdmMTgzODI3ZGJiMTg4YWZiYTAyYmYwZDJhMTkwNjA3MGQ2MDEzZjcxNmFlNDEwZDM1OWUzMGJjYzpoOkY"
title="Protected by Avanan: https://bugzilla.mozilla.org/show_bug.cgi?id=1884714#c1"
moz-do-not-send="true">this</a> Bugzilla
Bug (Actions Table).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ryan<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 25, 2024 at
3:44<span
style="font-family:"Arial",sans-serif"> </span>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:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p><span
style="font-family:"Calibri",sans-serif">Hi,</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">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:</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>CAs SHOULD NOT include URIs that specify https, ldaps, or similar<o:p></o:p></pre>
<pre>schemes in extensions. CAs that include an https URI in one of these<o:p></o:p></pre>
<pre>extensions MUST ensure that the server's certificate can be validated<o:p></o:p></pre>
<pre>without using the information that is pointed to by the URI. Relying<o:p></o:p></pre>
<pre>parties that choose to validate the server's certificate when<o:p></o:p></pre>
<pre>obtaining information pointed to by an https URI in the<o:p></o:p></pre>
<pre>cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess<o:p></o:p></pre>
<pre>extensions MUST be prepared for the possibility that this will result<o:p></o:p></pre>
<pre>in unbounded recursion.<o:p></o:p></pre>
</blockquote>
<p><span
style="font-family:"Calibri",sans-serif">That said, whether it
amounts to a violation of the BRs it's a
different matter. Generally speaking,
since the requirement for the <b>id-ad-caIssuers</b>
accessMethod is expressed in the same way
as for the <b>id-ad-ocsp</b> accessMethod
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.</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">It should also be
noted that PKILINT contains a validator
for checking that the URI in the <b>id-ad-caIssuers</b>
accessMethod starts with "http://".</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">Adriano</span><o:p></o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">Il 25/04/2024 08:10,
Dimitris Zacharopoulos (HARICA) via
Servercert-wg ha scritto:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div align="center">
<table class="MsoNormalTable"
style="width:30.0%" width="30%"
cellpadding="0" border="1">
<tbody>
<tr>
<td
style="background:yellow;padding:1.2pt 1.2pt 1.2pt 1.2pt" valign="top">
<p class="MsoNormal"><span
style="color:red">NOTICE:</span><span
style="color:black"> Pay
attention - external email -
Sender is </span><span
style="color:black"><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></span><span
style="color:black"> </span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"
style="text-align:center" align="center"><o:p> </o:p></p>
<p class="MsoNormal"><br>
<br>
Dear Members, <br>
<br>
I have a quick question regarding the
id-ad-caIssuers accessMethod URI. <br>
<br>
<a
href="https://url.avanan.click/v2/___https:/www.rfc-editor.org/rfc/rfc5280.html%23section-4.2.2.1___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjJhNGI6MWFjOGRjMDRlYmE5NWU3Njk3MDI3MWFmOTQzNDAwYTdlYzkzMmYxMmQ0MDcwNTRmNzVmMTM3NjUzMTgzYWQ0OTpoOkY"
title="Protected by Avanan: 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>
<br>
<o:p></o:p></p>
<blockquote
style="margin-left:0in;margin-top:3.0pt;margin-right:0in;margin-bottom:3.0pt">
<p class="MsoNormal"
style="background:#F8F8F8"><span
style="font-size:11.5pt;font-family:"Arial",sans-serif;color:#1D1C1D">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.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%2371277-subscriber-certificate-authority-information-access___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjAxZGM6M2QzM2FkODM3NDBhOThkNDA1YzZmMDY2MTEwMGQyZGIxNGJmZTQyM2Q4ODhiNWE0OTcxMGI5MmEyNWJjY2Q0OTpoOkY"
title="Protected by Avanan: 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/blob/main/docs/BR.md%23712112-crl-distribution-points___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjdkNWU6NjU0MDRmYWVjOGE3MTdhZDU5YjY1YmYyMzJhYmVhZWJhYjdiNzAzY2E4YWI2OTk2NWViMTdlYmViMzBmMTIzOTpoOkY"
title="Protected by Avanan: 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>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Servercert-wg mailing list<o:p></o:p></pre>
<pre><a
href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><o:p></o:p></pre>
<pre><a
href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OjA4NjA6M2I1Yjc1OGQ5YjM1YWJkODA0ZTRjMzQ3ZTBlZmQ2MmJlOWQzOTA5NmQ1MjI4ZTY3NzM1MGIxMzc5ZDQzMDQ2MjpoOkY"
title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></pre>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<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://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmJhM2I6MDYyNzZhY2RjZWQ0ZjBjZTNmMjU3ZDgwMjVjNWZlMmU4MWYzMTM0MWI4NmIxMzBiNGE2ZWU5YWM3OGUwN2FhNjpoOkY"
title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Servercert-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:Servercert-wg@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><o:p></o:p></pre>
<pre><a
href="https://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmFjNDM6ZWEwNWYyMzc3M2NmOTZmNGRhNGUwNDhjNTg1YjE3NDFhMmQzMjY5Y2RhMzkwNTBlY2E1YjU4ZmQyZTkxZDYyOTpoOkY"
title="Protected by Avanan: https://lists.cabforum.org/mailman/listinfo/servercert-wg"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<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://url.avanan.click/v2/___https:/lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmE4NmM6MDcxNTQxOGMyZWJkMjA1YTMyNmQyNjRjNDVmYjBhYTdlNTk5ZTVhNDNmNDk0MDAzOTdjZDE3YTNiNjc0NjYyZTp0OkY"
moz-do-not-send="true">https://url.avanan.click/v2/___https://lists.cabforum.org/mailman/listinfo/servercert-wg___.YXAzOmRpZ2ljZXJ0OmE6bzphODFkMzMxMGYzOTRmZTQxZTk4MzM4MjY1MjJhNmQ3NDo2OmE4NmM6MDcxNTQxOGMyZWJkMjA1YTMyNmQyNjRjNDVmYjBhYTdlNTk5ZTVhNDNmNDk0MDAzOTdjZDE3YTNiNjc0NjYyZTp0OkY</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</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" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
</body>
</html>