[cabf_validation] Draft Minutes of Validation Call 5-May-2022

[Ben Wilson]

*Validation Subcommittee – Minutes of Thursday, May 5, 2022*

*Attendance*:  Ben Wilson, Corey Bonnell, Rebecca Kelley, Hubert Chao,
Joanna Fox, Tyler Myers, Aneta Wojtczak, Wayne Thayer, Janet Hines, Georgy
Sebastian, Dustin Hollenback, Michael Slaughter, Clint Wilson, Doug
Beattie, Enrico Entschew, Joe Ramm, Tobias Josefowitz, Andrea Holland,
Stephen Davidson, Martijn Katerbarg

*Antitrust Statement:* Read by Corey Bonnell

*Previous Minutes:* Draft minutes circulated by Aneta on 5/4/2022.  Dustin
asked whether minutes should be detailed (transcribed) or provided with
less detail. Discussion followed that it depended on who was preparing the
minutes and that no protocol has been previously adopted. One reason for
creating detailed minutes is that the IPR Policy deals with “Contributions”
of a member, and detailed minutes help track those. Going forward, we can
use Webex to support transcription, if that’s available. Approval of the
minutes was postponed.

*Profiles Ballot*

Activity has taken place on Github.  Last meeting we discussed the
commentary document, which we could discuss again if we have time, or we
could discuss the commits and associated commentary.  We also need to
discuss pushing this to a final ballot. Ryan S. said he had several edge
cases that he preferred to discuss rather than items that have already been
pushed in Github.

*1 – *The permitted certificate policies for a non-TLS sub CA is currently
ambiguous.  Does a BR OID for non-TLS CAs make sense? The group agreed that
probably not.  A CABF OID doesn’t make sense.

*2 –* In existing BR 7.1.5, name constraints, we reference the notion of
technically constraining CAs with EKU.  The first part says, “For a
Subordinate CA Certificate to be considered Technically Constrained, the
certificate MUST include an Extended Key Usage (EKU) extension specifying
all extended key usages that the Subordinate CA Certificate is authorized
to issue certificates for.”  However, there are CAs that use a
precertificate-signing CA certificate with a special EKU OID specified in
RFC 6962 (1.3.6.1.4.1.11129.2.4.4), similar to how an OCSP responder has a
special EKU OID for OCSP signing.  Is that type of CA inside or outside the
scope of the BRs? If we determine that a precertificate-signing CA is
technically constrained, it will weaken requirements on key protection,
audits, etc.  It might also introduce ambiguity and support an argument by
some that the misissuance of a precertificate isn’t a misissuance under RFC
5280 or the Baseline Requirements. (Even though multiple root programs will
still treat this as a misissuance.)

The current profiles work has revealed this ambiguity and potential gap in
the BRs. We need to close this potential loophole. Ben asked whether the
precertificate-signing CA certificate would have the serverAuth EKU in
addition to the special EKU.  Ryan said that it isn’t prohibited by RFC
6962.  Looking at proposed section 7.1.2.4.2 (see
https://github.com/sleevi/cabforum-docs/pull/36), there is a line that says
“NOT RECOMMENDED” for any other EKUs.  Should that be a “MUST NOT”?
Additionally,
the title of section 7.1.2.4 could remove the words “Technically
Constrained”.  Both of those proposals seemed to have support from the
group.  Otherwise, if the precertificate-signing CA were to be considered
“technically constrained”, that might exempt that precertificate-signing CA
from audits.  Whereas, if we say, “If a CA certificate conforms to this
profile, it is NOT considered Technically Constrained,” then it would be
within the scope of the audit. Also, WebTrust and ETSI could update their
audit criteria to include precertificate-signing CAs in audits to ensure
that they only issue precertificates.

Corey said that if we want to encompass the signing material, we should
evaluate the security benefits of bringing the precertificate-signing CA in
scope. Ryan responded that there a key security policy implication is
misissuance because a precertificate is considered by browsers to be the
binding intent to issue a real certificate. There don’t appear to be
downsides to keeping these CAs in scope.

Ryan  –  With the profiles, every certificate should be able to be
overlayed on these profiles and must meet the corresponding requirements
for that type of certificate.

Corey – If the intent is to capture the non-TLS profiles, I think one
further challenge of trying to specify the non-TLS profiles is that the
validation requirements are different for other types of certificates, e.g.
S/MIME, etc.

Ryan reviewed the base profile of “Technically Constrained Non-TLS
Subordinate CA (7.1.2.3)” in https://github.com/sleevi/cabforum-docs/pull/36
and focused on “serialNumber” (i.e. must be 64 bits of output from a
CSPRNG), “validity” (i.e. may be backdated up to 1 day), etc.  The issue
being how those should be handled in light of other certificate types, like
S/MIME.

Under the “Extensions” section of the profile commentary, Ryan focused on
the crlDistributionPoints subsection and noted that it is a property of the
issuer, not of the subject, and so it makes complete sense that it be
included in the profile for Technically Constrained Non-TLS Subordinate
CAs. Similarly, the EKU specification (“BRs 7.1.2.2 (g) already contains
rules for non-TLS subordinate CAs, such as prohibiting id-kp-serverAuth”)
is necessary in the profile to define that it is a non-TLS CA.  Well-formedness
for name constraints is a necessary part of the profile.

So there are places that impose requirements on non-TLS CAs, above and
beyond RFC 5280 or the existing BRs (although some of them may be implied
by the current BRs), which we can discuss further.

*3 –* See section 7.1.2.5.1 (commentary in
https://github.com/sleevi/cabforum-docs/pull/36 ) and BR section 7.1.2.2.g.
– we have requirements on EKUs – “For Subordinate CA Certificates that will
be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280]
MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The
values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280],
id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be
present. Other values SHOULD NOT be present.”  But for end entity TLS
server certificates, the BRs currently allow the emailProtection EKU to be
present – so there is some incongruity.  Bottom line - in profiles, under
name constraints, can we just delete the RFC 822 name constraint
requirement in the certificate profile because it doesn’t make sense?

Currently, we say, “(New) rules for rfc822Name are introduced. This is to
account for the fact that a Technically Constrained Non-TLS Sub-CA is still
within scope of the BRs, if it is issued by an in-scope Issuing CA. In
order for that non-TLS Sub-CA to also be seen as technically constrained
for its purpose (e.g. technically constrained for email), it's necessary to
be explicit that rfc822Name is permitted. The existing rules from 7.1.2.4
would apply to any rfc822Name constraint, and this attempts to derive the
functional requirements for this field, also in line with the existing
requirements of 3.2.2.4 / 3.2.2.5. Although not intended to be seen as a
‘new’ requirement, as these are reflected through the combination of
existing requirements and clauses, it may be seen as such.” This would be
deleted.

Corey – This assumes that there is EKU chaining, which there isn’t in RFC
5280, so we might be in uncharted territory here.  Ryan – but the BRs
assume that EKU chaining is relevant for audit scoping, although Apple has
a different approach, requiring that everything be audited.

Ryan – One option, for consistency with the BRs, is to assume that there is
EKU chaining, and that the RFC 822 name constraints won’t matter, or we can
lean toward RFC 5280 and conservatively keep the requirement for “defense
in depth”.

Wayne – Do you know if there are any certificates that would not be
permitted to exist if we made this change?

Ryan – We don’t know, because emailProtection is not allowed in these
TLS-issuing CAs.

The proposal on the table is to remove the RFC 822 name constraint since
their purpose is only to issue TLS certificates.  There was a question from
GlobalSign a year or so ago about clientAuth-only certificates (with RFC
822 names) issued from TLS CAs, without serverAuth – only for clientAuth,
but that is no longer an open question from GlobalSign.

*4 – *BR Section 7.1.2.2.a. currently says for policyIdentifiers – “The
following fields MAY be present if the Subordinate CA is not an Affiliate
of the entity that controls the Root CA … [then you can have a CPS URI].”  (But
if you are an affiliate, you can’t have these?)  There are a variety of
subordinate CAs in the web PKI that may or may not be affiliates and what
does this all mean?

Regarding section 7.1.6.2.1 of the proposed profile (
https://github.com/sleevi/cabforum-docs/pull/36), and for most of our
profiles, including non-TLS CA profiles (7.1.2.5.1), they refer to
Affiliated CAs – that’s a bug that needs to be fixed because we have
different requirements when they are affiliated or not affiliated.  Or to
simplify it, we could remove this distinction in BR 7.1.2.2.a entirely and
allow all CA certificates to have CPS URIs.  Alternatively, we would create
variations for every instance of CPS URI in the profiles for affiliated vs.
unaffiliated CAs because we have different requirements for EKUs and policy
IDs when you’re affiliated vs. unaffiliated.  Removing the distinction in
the profiles seemed to be the way to go, where possible, with the exception
of the anyPolicy OID, which would have the distinction.

See also EVG section 9.7 (if you’re issuing an EV, non-affiliated CA, you
have to put the CPS URI qualifier in).  When the issuing CA is controlled
by the entity, the CPS URI can be included, even though it is going to be
the same as the parent CA.

*5 – *Ryan will update the commentary in
https://github.com/sleevi/cabforum-docs/pull/36 based on today’s discussion.
This is taking a diff approach.  Currently it’s gone from v. 1.8.1 to 1.8.4.
When it is done, it will not only explain where something came from, but
also why we made a particular decision when multiple things were permitted.
We things ironed out, we could enter the discussion period next week.

*6 – *One last thing – name uniqueness for OCSP signing certificates.  It’s
not a problem when they are the same key, and we don’t currently require CA
uniqueness of names in the currently proposed profile document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220505/b7fe3084/attachment-0001.html>