[cabf_validation] Profiles discussion (was: Re: Minutes of the Validation Subcommittee - March 25, 2021)

[Ryan Sleevi]

Sorry I wasn't able to make the call. Splitting out a bit from the minutes
to have some discussion on the list.

On Thu, Mar 25, 2021 at 11:55 AM Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> Corey said that a few interesting changes that weren’t discussed are
> included. One is the near-universal requirement for the use of UTF8String.
> Corey said that there is still a lot of use of PrintableString in various
> fields. This is in 7.1.4.2 on page 80 of the PDF Ryan emailed out. Corey
> said that he is not aware of discussion of this change in the past.
>
> Tim said that he proposed this change before and received a lot of
> push-back.
>

> Corey said this particularly impacts the commonName field.
>

> Tim said that we had agreed to avoid introducing big changes in the first
> version of this effort. RFC 5280 clearly permits PrintableString.
>

Good spotting! This was an accidental oversight/bad transcription on my
part as a result of shuffling through different approaches thatI mentioned
on the past call.

This should have been PrintableString or UTF8String, which is the
long-standing 2459/3280/5280 requirement -
https://tools.ietf.org/html/rfc5280#section-4.1.2.4 .

Hopefully those _two_ options should be uncontroversial, given their 25
year history.


> Corey said that there is also a new profile for OCSP delegated responder
> certificates in section 7.1.2.7 and asked if anyone had thoughts about
> this. He said that prohibiting the certificatePoliices extension may be a
> concern. Are any browsers expecting policy chaining for OCSP responder
> certificates?
>

> Tim said that CAs who use certificatePolicies to link the CPS to the cert
> to meet Mozilla requirements may have problems with this.
>

Tim: Could you expand on this? Did I overlook a conflicting browser
requirement?

Mozilla's policy only requires "CAs must provide a way to clearly determine
which CP and CPS applies to each of its root and intermediate
certificates.", which isn't even a statement about cPSUri in the
certificates (which is already forbidden for some cases by our existing
requirements). So I'm not sure what you meant here, but happy to fix it up
if that's the case.


> Corey said that client software that looks at policy chaining might be
> affected.
>

Note: Client software won't have issues here, because this would follow the
RFC 5280 rules (by not explicitly asserting a policy). Policy chaining
issues would only exist in this situation if explicitly trying to verify a
specific policy for the OCSP responder, which none of the popular
verification APIs (e.g. OpenSSL/LibreSSL/BoringSSL, NSS, Java, &
Win/Mac/Android/iOS OS APIs) let you even remotely get close to supplying :)

This is also a logical consequence of the ongoing work to align on CA/B
Forum OIDs for things subject to the BRs. As we saw from the browser
alignment ballot, where it was already a requirement in root stores,
subscriber certificates have been required to include/assert a CA/B Forum
OID for some time. This allows verifying APIs to restrict the policy OIDs
for, say, TLS, to explicitly CA/B Forum OIDs (or, conversely, measure
self-asserted compliance)

CA-specific policy OIDs don't really make any sense, as we already saw from
EV, because they don't provide extra assurance to relying parties that are
only measuring/expecting compliance with the CA/B Forum OIDs. At best, they
end up encouraging the combination of multiple separate trust frameworks,
whether those that want _more_ than the CABF or that want something
_different_ than the CABF. Since that is the only remaining technical use
case, it doesn't make sense, as we've been discussing since the SHA-1
deprecation that such mixed-framework/mixed-agility approaches are
inherently bad ideas.

For an OCSP responder, the policy OID isn't presently something OCSP
verification APIs expect (or even expose). If we did want to use one, we'd
need to precisely articulate why. "This OCSP Responder complies with the
BRs" doesn't make sense, because it's obvious that if it's a responder for
a **subject** cert that complies with the BRs, it's expected to comply with
the BRs, so there's no ambiguity.

I'm all for being relaxed here if we've got an identified technical use
case, but I'm not sure we do. Have I overlooked something?


> Tim said there are similar concerns about scope with time stamping
> certificates, and the most clear solution is to use certificatePolicies to
> assert this.
>

Tim: Could you elaborate on this? Distinguishing timestamping certificates
is done by EKU, not by certificatePolicies.

For example, if you're doing a Timestamping CA today, from an existing BR
root, you already can't use certificatePolicies' cpsUri because of 7.1.2.2
(a) of the existing BRs. Those fields are only permitted for non-Affiliate
certificates (the explicit MAY is conditional).

You can, however, separate by EKU, and if you only use the timestamping
EKU, then the Timestamping CA meets the definition of a
Technically-Constrained Non-TLS Sub-CA. This is a result of the browser
alignment ballot, we now treat no-TLS-or-anyEKU as a sufficiently
acceptable technical constraint - per 7.1.5 of existing BRs.

If you were highlighting TSA-direct-from-root, yeah, that's why I sent the
mail to the main servercert-wg@ (
https://archive.cabforum.org/pipermail/servercert-wg/2021-March/002578.html
) to try to suss that out and if folks still had that use case with their
current/modern hierarchies in 2021.

One thing I realized that I had on my TODO list written down here, but
forgot to transcribe to the list for yesterday's update, was figuring out
"non-TLS end-entity" certificates. This is intended as a legacy transition
path for CAs that have existing intermediates that didn't comply with root
program requirements, but existed before the browser alignment ballot, have
multiple EKUs, and the CA has not migrated off/revoked yet. Concretely,
say, an intermediate that issues both TLS server certs and email protection
certs, despite this no longer being allowed by the BRs and long disallowed
by root programs.

While this is no longer allowed, for CAs with those existing sub-CAs who
haven't stopped yet, we probably need a profile to cover "not TLS". The
requirements here would be much more relaxed, and be simply around EKU
(being present, not containing TLS) and the signature algorithm(s) (so no
SHA-1). That _should_ cover the TSA case, if it wasn't already addressed,
as well as any not-TLS cases.

However, even with that approach, I'd prefer to have explicit profiles
precisely specifying what roots are signing, even if we offer more
flexibility to legacy intermediates. So if folks are still doing TSAs
directly from roots, I think we should definitely add a TSA profile, and
happy for any CA who wants to point to recent examples of such issuance to
work out the profile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210325/c4c2aedf/attachment.html>