<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 17, 2021 at 11:27 AM Ryan Sleevi via Validation <<a href="mailto:validation@cabforum.org">validation@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 dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 17, 2021 at 11:21 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">dzacharo@harica.gr</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>
    <br>
    I recall the policy OID chaining between issuing CAs and leaf
    certificates having been discussed in the past, and the result of
    that discussion was that chaining is not enforced by Browsers and
    has no applicability for the publicly-trusted TLS Certificates. If
    such a chaining requirement was enforceable by Browsers, it could
    also be used to scope certain Issuing CAs but we didn't want to use
    that method.<br></div></blockquote><div><br></div><div>No, this is completely incorrect and inconsistent with RFC 5280.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    Is there a requirement for the custom CABF OIDs to be present in the
    issuing CA Certificates if they do not have "anyPolicy" ?</div></blockquote><div><br></div><div>Yes, this is required by RFC 5280.</div></div></div></blockquote><div><br></div><div>To expand on this, since I think your question reveals it may not be obvious: This is exactly what I'm trying to clarify with the profiles work, to explore these logical consequences of the existing requirements consistent with RFC 5280.</div><div><br></div><div>We require that the CABF OID MUST be present on Subscriber certs. RFC 5280 therefore requires that the same OID MUST be present on intermediate certificates (or the anyPolicy), or else the certificate was not properly issued according to that policy. The BRs currently list "MAY" for the Reserved CABF OIDs for Sub-CAs and MAY for anyPolicy (for affiliated CAs) and MAY for CA-specific OID, but also require that the CA MUST have at least one policy OID present. Consequently, this means that an affiliated sub-CA MUST use (anyPolicy - as the ONLY OID - OR one or more CABF reserved OIDs), while a non-affiliated sub CA MUST use (one or more reserved CABF OIDs). They MAY include additional OIDs, including CA-specific OIDs.</div><div><br></div><div>That's the first issue with the language that I raised.</div><div><br></div><div>The second issue is with that distinction of Affiliated/non-Affiliated, and whether "issued to" is a statement of "at issuance time", or whether the act of transferring a key/cert mean that the (existing) key/cert is _now_ "issued to" a different entity. Put differently, "issued to" can be both a statement about when it was issued, but can also be a statement about when the measurement is taken (e.g. "this certificate (that was issued) is issued to user X" is a statement about when it's measured)</div></div></div>