[cabf_validation] 2021-11-04 Meeting Minutes

[Corey Bonnell]

Attendees:

Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Clint Wilson,
Corey Bonnell, Dimitris Zacharopoulos, Doug Beattie, Enrico Entschew, Iñigo
Barreira, Janet Hines, Joanna Fox, Johnny Reading, Kati Davids, Martjin
Katerbarg, Niko Carpenter, Rebecca Kelley, Ryan Dickson, Stephen Davidson,
Steven Deitte, Thomas Zermeno, Tim Hollebeek, Trevoli Ponds-White, Tyler
Myers, Wayne Thayer

 

 

Tim read the anti-trust statement.

 

Agenda for today is discussing the CRL validity period ballot proposal and
certificate profiles.

 

Wayne mentioned that he wanted to discuss CNAME delegation to the CA. Tim
mentioned that there has been background discussion on this topic and we can
discuss today.

 

CRL validity period ballot:

Tim: Spent some time reviewing to find potential bugs and found one that was
flagged on the list.

Corey: I have concerns with side effects of making a global change to fix a
local problem. For example, Random Values. A CA today may allow for Random
Values to be valid for 30 days and X seconds, which would now be
non-compliant.

Trev: Perhaps we can future-date clarity changes to avoid things like that.

Tim: I agree. Since this issue isn't urgent, we can put a future date.

Trev: Yes, I think that's a good practice. Since the intent is to clarify
minor things, we should put a future effective date so we can focus on more
urgent concerns.

Wayne: I'm supportive of taking more time to allow people to assess impact
of the ballot. Should we move the effective date to June 1st or July 1st.

Corey: My understanding is that we are modifying the conventions in section
1. We should put an effective date in section 1 as well.

Wayne: Originally, I had the change scoped to CRLs and later added the text
in section 1. We can remove the change in section 1.

Tim: I like it being document-wide. We can make the document-wide change
effective on June 1st. There will be ambiguity until June 1st for the
sections outside CRL, but that ambiguity exists today.

Corey: Right, we're not making the situation any worse by adding an
effective date to the document-wide convention change. If anything, we're
making it better by setting the right course.

Wayne: So we'll make the change to the CRL section and add the effective
date to conventions.

 

Tim: As an aside, I'm looking to creating a cleanup ballot since we haven't
done one in a while. I'm looking to do a ballot that's a cleanup and not
introduce more controversial clarifications and changes. Let me know if
there's anything that anyone wants to have addressed.

Clint: There are some GitHub issues that are marked as cleanup items.

Tim: Yes, there's a wide variety. I'm looking to get those fixed.

 

Certificate Profiles:

Tim: I'm going to go through my F2F presentation and we can discuss each
point here to gain consensus on next steps.

Dimitris: Is the goal to revisit all the high level issues, determine how we
will proceed, and then update the ballot?

Tim: Yes.

Trev: It would be good to share your presentation here to refresh everyone's
memory and also inform those who weren't at the F2F. Also, questions might
have come up since the F2F.

 

- Cross Certificates must have EKUs

Corey: Current practice is to omit EKUs for cross certificates, so it is
definitely a change.

Tim: But a good one?

Corey: As long as there are no client interoperability issues with it, this
should be no problem.

Wayne: My only concern is that this is a change in requirements. Should it
be a separate ballot?

Trev: I agree with Wayne.

Tim: The original intent of the profiles work was not to introduce large
changes to existing practice and this is such a change.

Wayne: I'm sure this may affect some CAs and it's potentially easy to miss
in a larger ballot.

 

- First policy OID must be CABF reserved OID

Tim: This is something that I originally was not a fan of but I understand
the inertia of changing certificate-processing software. However, this
provides useful guidance so I'm in favor of including it.

Dimitris: I'm in favor of it, but it falls into the same category as the
previous topic. It'll be considered a mis-issuance if a reserved OID isn't
in the first position.

Doug: If a browser doesn't want to trust a certificate because the OIDs
aren't in a particular order that's one thing but treating it as a
mis-issuance is heavy-handed.

Clint: We should make this a SHOULD. It gives guidance but also avoids
mis-issuance.

Trev: Should it be its own ballot? 

Tim: That's a good idea. I'd like to avoid a ballot explosion, so maybe one
ballot to introduce the format changes and another for requirements changes?

Wayne: I think this one is fine if it's a SHOULD.

Trev: Are we making it a SHOULD so that we eventually make it a MUST?

Corey: I'm wondering if there are plans on the Certificate Consumer side to
implement proper policy-chaining that would cause this to become a MUST
sooner.

Doug: I think for now we can make this a SHOULD.

Tim: At first, I hated this client behavior. But I think that stemmed from
it being undocumented. If it's documented, perhaps long term we can make it
a MUST.

Trev: Perhaps we can make this a MUST next year?

Tim: I think that's reasonable.

 

- Changes to Name Constraints

Corey: There's a couple of things here. To prohibit issuance of trusted
certificates with dNSNames, you add a single dNSName entry under
excludedSubtrees. However, for rfc822Name and sRVName, it's more complex.
You need to add an entry to permittedSubtrees to prohibit issuance. Also
problematic is that the current profiles draft specifies sRVName constraints
in a way that violates ASN.1 syntax, so we need to revisit this.

Dimitris: Why do we need any provisions for sRVName? We currently don't
handle sRVNames in the BRs.

Corey: This stemmed from current Mozilla policy, which requires constraints
on sRVName to be considered technically constrained. However, I know of no
way to express them correctly given the specification. When the clause in
Mozilla Policy was added, there was an expectation that sRVNames would be
permitted by the BRs but that never happened.

Dimitris: So an empty string for sRVNames doesn't work?

Corey: Yes, because the ASN.1 syntax for sRVName has a constraint that at
least 1 character must be present.

Dimitris: I don't have an objection to update the BRs to account for
sRVNames, but it should be a separate ballot.

Corey: Perhaps the best approach may be to not tackle sRVNames at all in the
first iteration of the profiles draft and instead revisit sRVNames more
completely at a later point.

Tim: I think that makes sense especially since we don't have a good solution
here.

Wayne: I agree.

 

- Cross Certificates

Tim: This definition brings great clarity, but may change things for some
CAs.

Dimitris: My understanding is that a Cross Certificate was always a
Subordinate CA certificate.

Tim: I think if you look in the wild you'll find Cross Certificates that
aren't 100% compliant Subordinate CA certificates.

Doug: Since you need to include the subject DN for the Root certificate in
the Cross Certificate, it might not comply with the requirements for
Subordinate CA naming.

Wayne: I think considering Cross Certs to be Sub CA certs is already widely
believed to be a requirement amongst Root Programs, so I'm struggling to see
this as a normative change.

 

- AKI/SKI

Corey: I'm still not sure what the rationale is for the first bullet point
(making inclusion of AKI in self-signed Root certificates a SHOULD). I did
some digging after the F2F and the only relevant thing I found was a Chrome
commit comment for some test certificate generation script. Ryan mentioned a
slowdown if there was a collision of key identifiers but beyond that I
didn't find anything.

Ryan: From my understanding, this was a hint to the certificate path-builder
that it encountered a root certificate and didn't need to process others. I
can bring more information for the next meeting.

Corey: That would be helpful, as my thinking was that the absence of the AKI
would be the signal that you encountered a Root certificate.

Trev: Since this is an optimization that Google wants, it should be its own
ballot. It's not a clarification as it deals with a new software
implementation so it should have a future effective date.

Corey: That makes sense.

Ryan: This would be a SHOULD-level requirement, so there is no additional
enforcement mechanism on the CA operator, so I see this as relatively safe
for this community. I understand the alternative perspective, which is what
is the requirement change a year from now. I'll dig up more on this.

Tim: DigiCert has a policy that we comply with SHOULDs unless we know of a
reason not to, so we consider them to be softly normative.

Corey: That's the correct approach. When violating a SHOULD, you should
understand the rationale for the SHOULD-level requirement so you can make an
informed decision.

Trev: That's why I think there's value in having this be a separate ballot.
It can explain the value of following the SHOULD and the ramifications of
not.

 

- Bans of various kinds

Tim: Banning LDAP URIs is also being discussed in the SMIME WG. 

Corey: For TLS, they are definitely the exception more than the rule.

Tim: Add it to the normative change list so people don't miss it?

Corey: That makes sense.

 

(certificatePolicies in OCSP responder certificates)

Corey: If you look at Censys, existing practice is that many CAs include. I
don't feel too strongly if they go away, but it's a matter of timelines.

Dimitris: If you consider the OCSP certificate to be as critical as the CA
certificate, then a Relying Party would need to take a look under which
policy the certificate was issued.

Tim: That's a good point. We had a similar issue in code signing where there
was no policy OID for timestamping to denote which timestamp authority
certificates were under CSBR scope.

Trev: Do we have a profile in the draft for OCSP responder certificates?

Tim: Yes.

Trev: Doesn't it seem odd to define a profile in the BRs but not allow the
policy to be expressed in the certificate?

Tim: Yes, and also potentially goes against adding policy OIDs to all
certificates that comply with the BRs. Perhaps we should go the opposite
direction and require certificatePolicies.

Trev: Yes, either we should have a profile and a policy or we don't care how
they are defined and not have a profile.

Corey: I like the idea of specifying the profile in the BRs since it's good
guidance for CAs. I could go either way on whether certificatePolicies is
included.

Trev: Yes, I don't have strong feelings either way but it seems
inconsistent.

 

- QCStatements as a SHOULD NOT

Tim: The current draft lists certain extensions, but for everything not
listed, it's a SHOULD NOT. Absent further clarifying text in the profiles,
this could be read as a potential ban on QCStatements in the future.

Dimitris: I believe Ryan has changed the position on this. Enrico asked
whether there is a plan to ban QCStatements at the last teleconference call
and Ryan said no. So this SHOULD NOT is inconsistent with that statement.
Perhaps we can look at all extensions that have been historically included
in certificates and make them a MAY with all others being a SHOULD NOT.

Tim: Yes, but we'll have to undergo that exercise. That could be significant
work.

Dimitris: Agreed. Perhaps we can move this to version 2.0.

 

- Serial number bounds

Tim: We should state the length of serial numbers is based on the
DER-encoded value. There was resistance to this, but I never understood why.
We should add this.

 

- Non-TLS CAs

Tim: This is thorny and we only got to the hand-wavy level.

Dimitris: The first bullet point (intermediates issued by Roots under BR
scope must include CABF OIDs) makes sense. But then we need a policy to
denote non-TLS.

Corey: There was an argument made that the subordinate CA certificate
profile in the BRs applies to non-TLS CAs today. However, if you follow that
argument, then by including a CABF OID in the non-TLS CA, you will be
granting technical capability for that "non-TLS CA" to issue TLS Subscriber
certificates that will be trusted by clients that implement policy-chaining
as opposed to EKU-chaining.

Dimitris: If we have a separate policy OID, then we won't grant technical
capability.

Corey: Yes, but that's a future approach. The argument previously made was
that the BRs require the inclusion of BR policy OIDs in non-TLS CAs today.

 

- More Open Questions

 

(Domain Names in Subject Fields requiring DCV, example given was O=SSL.com)

Tim: I believe this is not a supportable interpretation. Just because a dot
appears in a subject field doesn't mean that field value is now a domain
name that needs to be validated. Does anyone believe this is a valid
interpretation?

Trev: I do not.

Clint: I'm not saying that it's reasonable to require DCV for SSL.com, but
it would be strange if the Subscriber couldn't complete DCV. This seems more
like a legal issue than a CAB Forum issue.

 

(Backdating)

Tim: There was an attempt to prohibit backdating altogether but this is
complicated by precertificates as the final certificate validity period must
match the previously issued precertificate. Since this was brought up in
June and there have been no proposals to address, I suggest we allow for
back/forward-dating of +/- 48 hours.

 

Tim: We're out of time; we'll pick up next time with a discussion of
delegating DCV to the CA.

 

Meeting adjourned.

 

Thanks,

Corey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20211111/0569ed90/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/20211111/0569ed90/attachment-0001.p7s>