[cabf_validation] More Certificate Policy Weirdness

[Ryan Sleevi]

On Wed, Mar 17, 2021 at 11:27 AM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

>
>
> On Wed, Mar 17, 2021 at 11:21 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>>
>> 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.
>>
>
> No, this is completely incorrect and inconsistent with RFC 5280.
>
>
>> Is there a requirement for the custom CABF OIDs to be present in the
>> issuing CA Certificates if they do not have "anyPolicy" ?
>>
>
> Yes, this is required by RFC 5280.
>

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.

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.

That's the first issue with the language that I raised.

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210317/a58e84de/attachment-0001.html>