[cabf_validation] 2022-04-07 Meeting Minutes

Fri Apr 15 16:02:53 UTC 2022

2022-04-07 validation-sc minutes

Attendees:

Andrea Holland

Ben Wilson

Bruce Morton

Clint Wilson

Corey Bonnell

Daryn Wright

Dustin Hollenbeck

Enrico Entschew

Joanna Fox

Joe Ramm

Paul van Brouwershaven

Rebecca Kelley

Ryan Dickson

Ryan Sleevi

Stephen Davidson

Trevoli Ponds-White

Wayne Thayer

Minute-taker: Corey

Corey read the antitrust statement.

Primary topic of discussion were the changes proposed to the certificate
profiles ballot to reflect recent discussions:
https://github.com/sleevi/cabforum-docs/pull/39

Including AKI in Root Certificates

Ryan S: I think the takeaway for the previous call was that we should make
this a SHOULD and provide supplementary text explaining the rationale.

Corey: My recollection was that we would specify a "MAY" and document in the
supplementary text various quirks of client implementations. This normative
change would not be made in this ballot, as was agreed back in November. We
can specify this as a normative requirement in a future ballot.

Ryan S: I don't think I agree that this is a normative change. RFC 2119 is
specific in how to interpret a "SHOULD"; it's something that you should have
a good reason not to do but you can. The intent of the inclusion of a
SHOULD-level requirement is to lead CAs to the "happy path" where there is
maximum interoperability with clients. Is there strong objection to making
this a SHOULD and we should make this a MAY or else CAs will vote "no", or
how else can we address these concerns?

Corey: I suppose my concern isn't with gauging whether or not the ballot
will pass, but rather ensuring that we agree on approach. I do see changing
a "MAY" to a "SHOULD" as a normative change, as they are meaningfully
different RFC 2119 terms. The agreement previously reached was that we would
minimize normative changes in the initial ballot to ensure that the ballot
is easy to understand for CAs. Down the road, we can add further
improvements. For example, in a few months we can have a ballot that moves
this to a SHOULD or MUST. Or for the prohibition on including
certificatePolicies in the OCSP responder profile: there is no requirement
today that prohibit its inclusion but it is something we can mandate in a
future ballot. The intent is not to pass this profiles ballot and not
improve upon it for several years, but instead to get this initial version
integrated into the BRs and then we can iterate on improvements in future
ballots. Pushing off normative requirements changes would also reduce
complexity by not having to have extensive discussion on effective dates.

Ryan S: Do you think the change from MAY to SHOULD should have an effective
date?

Corey: I think it would be preferable to push off normative requirements
changes unless we know of a compelling reason to include it.

Ryan S: I suppose this is where the disconnect may be. My recollection was
that for the initial profiles ballot, we would document existing
requirements and add guidance so that CAs know of the "happy path". Some of
the changes presented in this PR appear to be "change for change's sake",
which is perhaps one of the sources of disconnect.

Prohibiting certificatePolicies in OCSP responder certs

Ryan S: The original proposal was to implement a ban roughly 6 months after
the effective date. OCSP responders are not issued daily, so it seems like
ample notice to mandate this effective date. Again, my understanding wasn't
this ballot couldn't contain requirements changes, but rather that it can,
provided the changes are clear, well justified, and have ample lead times.

Clint: I agree with Ryan. Given the large amount of time dedicated to this
ballot, I would prefer shorter lead times for these changes barring specific
feedback on why these changes are not feasible. I share some of Corey's
concern that if we push too fast then it will slow down future work, but I
also don't see any strong justification for delaying these changes.
Especially for things such as the change from a MAY to a SHOULD for AKI in
root certificates; it's a no-op operationally for CAs.

Corey: There definitely are competing concerns. If we can add things that
don't have an impact now, we can. But we should be wary of introducing
things that may have an impact. For the MAY to SHOULD change, I do think
there may be an impact as auditors may require evidence for the rationale of
violating the SHOULD. But if there's consensus it's a no-op, then we can
change it.

Bruce: I agree with Corey that it is a normative change.

Ryan S: I want to clarify: is the concern that with a SHOULD there is a
requirement than analysis must be performed and auditors may expect evidence
of such analysis, or is it that auditors may interpret a SHOULD as a MUST?

Corey: If your auditor does treat a SHOULD as a MUST without documentation
for the analysis, then a CA may receive an audit observation if they are
unable to produce such documentation.

Ryan S: The explanation that we would provide in the supplementary
documentation would be that evidence.

Corey: Yes, but that may be up to auditor interpretation. Again, we can keep
the SHOULD, but based on previous discussions we were going to relax to a
MAY. I don't see this particular item as important, but I think the
differences in opinion on this issue highlight some high-level differences
across the entire ballot.

Ryan S: Agreed. To fully understand: is the extent of concerns surrounding
the change from a MAY to a SHOULD be around auditor interpretation, or are
there additional concerns?

Corey: There may not be additional concerns beyond auditor interpretation,
but I'd be in favor of minimizing these sorts of changes.

Ryan D: I tend to agree with Ryan (S) and Clint; this is a no-op change. As
for pushing off changes, we should have justification for doing so. The
discussion on "auditor interpretation" doesn't help me to see the concrete
challenges that this language would create.

Trev: One of the things that we wanted to differentiate when we previously
discussed this is that we should separate requirements changes from
formatting changes. When CAs diff from one version of the BRs to another and
both formatting and requirements changes are included in the set of changes,
then it becomes more difficult to determine whether the change is the result
of a requirements change or a mere change in presentation format. For that
reason, we previously determined it would be best to introduce requirements
changes separately to ensure they don't get lost in the document churn.

Ryan D: I can appreciate this perspective, but I think we're adding
unnecessary work by separating out these items. There will be separate
ballots, each with their own voting and review periods. If we have to chase
this ballot with others immediately thereafter, it seems like we're delaying
the inevitable.

Trev: Right, but I think you can make the opposite argument that if we would
have taken out these requirements changes and put them in their own ballot,
we would have been done with all this work some time ago. I see the BRs as a
living document that we can change in the future, so I see minimizing the
number of changes as reducing the burden for each ballot individually.

Clint: We have also heard from CAs that the sheer number of ballots is a
burden, such as more IPR reviews. It certainly is a tricky balance.

Trev: Yes, which is why we previously proposed introducing the formatting
change ballot. Then shortly thereafter, we would, for example, introduce
another ballot with five requirements changes. 

Ryan S: CAs will need to closely review this ballot regardless of whether or
not there are intentional requirements changes introduced to ensure that
their practices are in alignment.

Non-TLS Sub CA profile

Ryan S: From the previous discussion, I believe the common understanding is
that we would define solely what is technically necessary for a non-TLS sub
CA. I believe the discussion in September and at the F2F is that you cannot
issue non-TLS ICAs with malformed extensions. Removing the non-TLS profile
entirely from the profile is modifying the BRs to essentially say that
issuing certificates with malformed extensions is permissible. 

Corey: My recollection of the F2F meeting was that there are certain
circumstances where you do need to issue certificates with malformed
extensions. For example, critical nameConstraints are may not be supported
by certain client implementations. It is a RFC 5280 violation to make the
nameConstraints extension non-critical. Browsers may support the critical
nameConstraints extension, but in other trust frameworks, such as S/MIME,
there may be email clients that do not. The challenge is that we still have
mixed use PKI heirarchies today, but the proposed non-TLS ICA profile may
cause issues for non-TLS use cases. So the F2F consensus was that, in the
short term, we would not normatively specify the non-TLS ICA profile.

Ryan S: We have today in the BRs section 7.1.2.4 that states all
certificates must conform with RFC 5280, but we also have the explicit
permission to violate RFC 5280's requirement for critical nameConstraints.
If we are saying that 7.1.2.4 doesn't apply to non-TLS certificates, then we
are saying that it doesn't encompass all issuance under a BR CA.

Corey: We reached a different conclusion at the F2F, where there was
agreement that the issuance of non-TLS certificates is not in scope of the
TLS BRs today. In particular, the exclusion of the serverAuth EKU means that
the issuance of that certificate is out of scope of the BRs. That's not to
say this won't change in the future, but that is the current state of the
requirements today.

Ryan S: We have in section 7.1.2.2 (g) requirements for non-TLS ICAs. Was
the view that this language is not applicable?

Corey: Yes, there was agreement that the EKU specification for non-TLS ICAs
was not appropriate for inclusion in the BRs.

Ryan S: This language is present in the TLS BRs today. It sounded from the
minutes that this language doesn't apply today.

Corey: Yes, the conclusion reached was that this language is essentially
unenforceable, as it is opining on issuance that is not in scope of the BRs.

Ryan S: One of the main motivations for this profiles work was to explicitly
specify the profile of all certificates signed by a BR CA. So the position
that certain issuances are "out of scope" seems to run counter to that goal.
Is the argument that the BRs only apply when a "certificate-shaped thing"
looks like a TLS certificate?

Corey: Yes, that was the conclusion at the F2F.

Ryan S: The logical extension of that is that the issuance any malformed
certificate might not actually be a mis-issuance, but rather a signing
operation that is simply out of scope of the BRs. 

Corey: One of the challenges is that specific Root Programs may have
expectations in this area, but the BRs today do not. Essentially, this is
another take on the long discussions of the "scope of the BRs".

Corey: We only have 1 minute left, but we can resume on the list and at the
next meeting.

Clint: This discussion has been very helpful. Perhaps we can have a special
validation meeting to more quickly hash out these issues.

Corey: I agree, Clint. We can devote the majority of the time on the next
call to these issues and if we determine that additional time beyond that is
needed, we can have a special meeting to more quickly reach conclusions.

Meeting adjourned.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220415/4f7ee37e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220415/4f7ee37e/attachment-0001.p7s>