<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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>
    <p><font face="Calibri">
        <blockquote type="cite">
          <pre class="newpage">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>
        </blockquote>
      </font></p>
    <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 class="moz-cite-prefix">Il 25/04/2024 08:10, Dimitris
      Zacharopoulos (HARICA) via Servercert-wg ha scritto:<br>
    </div>
    <blockquote type="cite"
cite="mid:0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000@email.amazonses.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <title></title>
      <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 class="moz-txt-link-abbreviated" href="mailto:0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000@amazonses.com">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>
      <code data-stringify-type="code" class="c-mrkdwn__code"
style="box-sizing: inherit; --saf-0: rgba(var(--sk_foreground_low,29,28,29),.13); border: 1px solid var(--saf-0); background-color: rgba(var(--sk_foreground_min,29,28,29),.04); color: rgb(var(--dt_color-plt-flamingo-70)); font-variant-ligatures: none; white-space: pre-wrap; overflow-wrap: break-word; word-break: normal; tab-size: 4; border-radius: 3px; padding: 2px 3px 1px; font-size: 12px; line-height: 1.50001; font-family: Monaco, Menlo, Consolas, "Courier New", monospace !important;">id-ad-caIssuers</code>
      <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" class="c-mrkdwn__quote"
        data-stringify-type="quote"
style="box-sizing: inherit; margin: 4px 0px; padding: 0px 0px 0px 16px; position: relative; counter-reset: list-0 0 list-1 0 list-2 0 list-3 0 list-4 0 list-5 0 list-6 0 list-7 0 list-8 0 list-9 0; 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; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(248, 248, 248); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
        When the<span> </span><code data-stringify-type="code"
        class="c-mrkdwn__code"
style="box-sizing: inherit; --saf-0: rgba(var(--sk_foreground_low,29,28,29),.13); border: 1px solid var(--saf-0); background-color: rgba(var(--sk_foreground_min,29,28,29),.04); color: rgb(var(--dt_color-plt-flamingo-70)); font-variant-ligatures: none; white-space: pre-wrap; overflow-wrap: break-word; word-break: normal; tab-size: 4; border-radius: 3px; padding: 2px 3px 1px; font-size: 12px; line-height: 1.50001; font-family: Monaco, Menlo, Consolas, "Courier New", monospace !important;">id-ad-caIssuers</code><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 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>