[cabf_validation] Draft Minutes from Today's call of 2020-06-18

[Robin Alden]

Validation Subcommittee meeting.  Thursday 18th June, 2020

Agenda:
* Certificate profiles.

>From previous meetings:
Fix the tracablility so we know where everything came from.
Dimitris volunteered to do it and Tim Volunteered to check it.

* recent discussions on Validation list between Ryan and Doug on subject attributes, and Wayne on rfc8737.

rfc8737:
(Wayne:)
Sent an email to the list last night.  We've been waiting for a long time, ..  Multiple root programs believe method 10 is insecure.  Root programs have told CAs they can't use method 10.
A new method was created using TLS ALPN.  Servers need to understand that a validation is being requested.  The RFC has now been published (awaiting IANA review).
We can now incorporate that language into the BRs (method 19).

1) Can we go ahead
2) Is there a reason to allow a sunset method for method 10.
3) People are using ALPN as a kind of method 10.  Will this bite them?
4) Are there layers we should put on top of the RFC like ....
e.g. the token duration..

Tim: 2018-08-27 is when it exited the working group.
Ryan: We have the RFC, just awaiting IANA review.
Tim: Not recommending waiting, in fact the opposite as RFCs can get stuck in this state.
Ryan: Shouldn't get stuck.
 if the IANA registration failed the RFC would be withdrawn, but that doesn't affect the security properties.
Corey: Do we know what IANA's concern is?
Ryan: My understanding is concerns over the language directing IANA to do something.

Wayne: It sounds like we should go ahead and make the change.
I know LE supports ALPN already, presumably under 3.2.2.4.10.
Does anyone see problems with this?

Ryan: LE (with 30 day re-use of a validation) and Buypass (with longer?) have deployed ALPN for 3.2.2.4.10.
I suggest 'this method has been retired and should not be used for > 90 days' to allow previous completed validations to age out.

Wayne: More general time is 2yrs.
Ryan: Yes, but very few users of method 10, so suggest 90 days.

Ryan: Nervous to say old validations were completed under the new validation method.
If you were already compliant, you'll be able to use the new instead of the old after the transition date.

Tim: So if you had an ALPN method compliant non-compliant with the RFC (but otherwise secure) doing method 10 today, you might have work to do to become RFC compliant.

Ryan: Hopefully that comes out in the discussion.

Wayne: I will update the ballot to say something about re-use of prior validations.

Tim: There are two SHOULD's in the security considerations section of the RFC.  There's a reference to the ACME threat model that's worth thinking about.

Ryan: Those are saying you should not use this method as a consumer.

Tim: let's discuss it on the list.

* Are there any points to add to the discussion on list between Doug and Ryan on Subject DNs.

Ryan: In trying to draft the ballot, there are some systemic problems.
CAs can issue intermediates and roots with these attributes for a period of time.
Sunset after which you can use (these) attributes.

We will have to restart the discussion period for the MD ballot. (due to tweaks to the generator).
That will be to circulate it in about 3 weeks, hopefully that timescale works.  Do people think we need something sooner.
Doug: It works.  People have been issuing CA certs without a strict defualt deny for some time and I don't think another couple of weeks is going to make a big difference.
Would like to discuss about cross-certs.  3 fields that might not be possible in cross-certs, and want to discuss a sunset for those.

Ryan: We can see some of this in the browser alignment ballot, the discussion around how to manage name matching.  My goal : I would like us to be able to move the profiles for subordinates and cross-certificates, get them to a point they can have transitions going forwards.  So get to a point where you cant use them to issue further certificates after some time.
I realize that cross-certificates adds a wrinkle, but I in general I want to know the old intermediates will fade away.
Get to a point where we can say "All unexpired unrevoked paths must comply with these rules."
In the future, new certs must use intermediates with the new profile.

Tim: The details matter and will need some discussion, but it makes sense.

* We have a new tab for Subscriber TLS.  Do you have any comments on the work done there?

Ryan: I have had no bandwidth to look at it.

Doug: I made some suggestions about what should be in the fields and tried to add in the source selection.
3 separate sections for DN because DV/OV/IV have different requirements.  If we attempt to do it all in one the rules get really hard.
Since we have policy OIDs that define the cert, we should be able to define the profile at the profile section.

Ryan: Agree 3 sections.  The profile pertains to the policy.
It is duplicative for other attributes (e.g. basic constraints), but that makes it easier for CAs to consume and invest.

Doug: Agree.  For this week and next we'll keep the common fields in the sheet, but will switch to 3 copies.

Tim: Are you implying that a couple of us go off and work on it for the next 2 weeks.

Doug: Yes.

Doug: Is serverAuth EKU required?
Ryan: Browser Alignment ballot requires it.

There remains concerns about EKUs ..
Policy OID indicates the purpose of the certificate, beyond the validation method.
5280 has the eku on the leaf, ...
This is why I'd like it to be that if you assert the BR policy OID then the cert complies with one of the BR profiles.
In the ballot alignment ballot, I asked if we should have a distinct OID for BT compliant, and allow that OID to appear in other certs, or do we introduce a new policy for DV+BR, etc.?
Right now we have 4 policy OIDs , DV, OV, EV, IV, .
I would there to be an OID for BR complaince, and then another 1 (of the 4 so far) OIDs to indicate the purpose.

Doug: There are uses where the CA wants to issue certs under the BRs, say with clientAuth, but would not need serverAuth.  *Must* they add it?

Ryan: (from the ballot discussion) the profile for the subscriber certificate is still fairly liberal when Either id-kp-serverAuth or id-kp-clientAuth or both values must be present, and so in your case, the BR scenario, .. would we say for EV/OV/IV/DV, the eku can be either/or. And if a cert complies and only has id-kp-clientAuth, is it subject to the BRs?

Tim: Yes, that was a surprise a couple of weeks ago that id-kp-clientAuth can be sufficient?
There may be a scope mismatch.  The requirements state for serverAuth, but apply to clientAuth?

Ryan: Thats why I want to get to OID being unambiguous.
A sub-CA with id-kp-clientAuth could be out of scope..
Clients need a singular OID that they check for to work out if the certificate is in or out of scope.
If you have a client auth, and its asserting any of the CABF OIDs it would be subject to the BRs, for now, and we should find a way to distinguish that.

Doug: I agree it falls under the BRs and audits.
Not sure we need a new OID for only client auth, but discussion will sort that.

Corey: Section 1.1 says the BRs are for server certificates.

Ryan: I don't think so, because you can use it for server to server auth.
This is a case of making the scope more clear.
I would like to have a transition point based on the policy OID.  But that is a multi-year transition.
In the absence of that it would be great to have it based on EKU, but the question is would we include clientAuth EKU in that and we could choose not to, but we should make it explicit.

Tim: I don't think its necessary to have a separate OID for BR compliance, but clarify ...

Ryna; Critical you have a single OID for 5280 compliance. We can't transition off EKUs without that.
Tim: Why not, why can't I do 'one of 4'.

Ryan: Look at the 5280 initial policy validation. You'd need to do 4 separate validations.  It matters if policy mappings come into play.  E.g. the 'does this CA comply with my program' policy mapping.
So i think clientAuth is in scope for now.
I will open a guthub issue about the point, because it is a good point for discussion.

Closed at 16:52

Regards

Robin Alden
Chief Compliance Officer