[cabf_validation] Draft Teleconference Minutes - 2021-07-01

[Doug Beattie]

Validation Minutes 2021-07-01

Tim read the Antitrust Statement.

## Attendees
Andrea Holland

Aneta Wojtczak

Corey Bonnell

Enrico Entschew

Janet Hines

Johnny reading

Kati Davids

Niko Carpenter

Paul van Brouwershaven

Ryan Sleevi

Shelley Brewer

Tim Hollebeek

Tobias Josefowitz

Trevoli Ponds-White

Wayne Thayer



Antitrust statement read.

Agenda

*	No Agenda

Discussion topics follow:

 

No progress on certificate profiles since the F2F

 

Ballot 202

*	Ryan, Dimitris and Corey are working language
*	Adjusted definition of domain name (domain label ==> Domain Label, defined term)
*	IDNA  versions discussion: Ryan and Corey agree
*	Ready to start discussion period next week.
*	There are some changes, please review the changes and send comments to discussion list.
*	See: https://github.com/cabforum/servercert/pull/285

General Profile discussion

Back and forward dating and how this interplays with CT

*	Ryan working on this. Need deep review of this part of the profiles update.

*	Not after is “simple” which is X after notBefore
*	notBefore is more complicated

*	Intermediates may need to be backdated to support replacements
*	Add language based on past discussions of validations and hopefully reflects how we’re doing this today, or if we need to specify effective dates.
*	First step is to get clear language in this ballot

Does the current set of profiles support all use cases?

*	For example, are there special Infra structure certs with smart card login that we need profiles for, or are all certificate use cases clearly specified?  Please send questions to the list if there are other profiles needed

Aneta had 4 questions on profiles: 

*	The CP policies are in a specified order.  Is there a specified order for AIA fields?

*	AIA: Does it need to be in specify order?  
*	Ryan: The ordering does not matter.  

*	The order of different access methods doesn’t matter
*	The ordering for the same access method does matter
*	If you have multiple CaIssuers (Access method), the order should be the order of the CAs preference (RFC 5280).  We’d want the HTTP version first.
*	If you had 10 CaIssuers followed by 10 OCSP, that’s fine, or any mix and match,

*	Ryan to take action to provide clarity on this.

*	SKI is currently specified as “Should not” be present:

*	5280 says this  (allows but indicates based on purpose), and since TLS should not need it, but eventually it may turn to MUST not.  Are there reasons to keep it?
*	If there are use cases, then include, but as a TLS certificate it should not be needed
*	Aneta asks if there are security risks with including it?  Ryan, No.  
*	The Google Meta goal is that every extension in the profile must have a specific TLS purpose.  Including SKI won’t be a security issue, but it adds 160+ bits (24 bytes) and that may matter for some http3 QUIC.  If there is a reason we need it, then keep it, else let’s remove it.  It will remain Should not for V1, but will consider MUST not for V2 unless specific TLS use cases can be defined.
*	Ryan: V2 is where we can start removing unneeded extensions.

*	Can we put multiple URLs for CRL?

*	Ryan: A goal is to move to singular URLs.  Today many CAs include multiple CLRs and mix http and LDAP.
*	It would be good to address this because it does have processing impacts and effects. For CLRLs, you need to download all CRLs listed, so it has performance implications.
*	Ryan to check language.  Find balance between not changing too much.
*	Tim: Some countries need their own, so there are legitimate cases where multiple are needed.  In V2 we can narrow down, like LDAP links, there is not a reason for that.
*	For now, multiple URLs will be allowed so language will be updated to permit this.
*	CRL distribution point is a sequence of X with multiple URLs within general names.

*	So, 2 places where sequences can be multiple:

*	Multiple CRL distribution points, or multiple URIs within generalName

*	Idea is multiple CDPs each with one generalName
*	Double check CT to see how it’s happening today.

*	Goal is to have one CRL

 

*	Do OCSP responders need to have basic constraints? It’s marked as MUST for OCSP responder certificates but SHOULD NOT  for TLS certificates

*	Ryan said that this needs to be a MUST because there are some implementations that need it to make sure it’s not a CA certificate.
*	OCSP responder cert must not be treated as a CA cert, so Basic Constraints is a MUST.
*	Default encoding is CA default false.  Need to clarify that/double check
*	Tim: Basic constraint has no values since default is what we want, so it’s an empty extension
*	For end entity certs: 5280 (must appear in CA certs), but others are all MAY.
*	In V1, make it SHOULD NOT
*	In V2, make MUST NOT and follow RFC5280, to save up to 9 bytes
*	Tim: for OCSP responder we want to make it clear that this is not a CA certificate.
*	Ryan to check and make applicable updates.

 

Cory:

 <https://cabf.webex.com/cabf-en/url.php?frompanel=false&gourl=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.211:19

"To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates."

 

*	If we intend to deviate from the RFCs, we should be clear if we prescribe something different in the BRs.
*	Ryan: Should we specify in the profiles where we deviate from 5280?
*	Corey, for example, the BRs support wildcards and this deviates and we call that out.  Also, we have a should for AKI in self-signed root certificates (deviates).  We might want to have a short statement somewhere acknowledging that this deviates from 5820.
*	Ryan to take a pass on that also.
*	Something less than every field, but call out unique items, and play with presentation of this in the spec.  An appendix explaining non-normative decisions are to help CAs with guidance.
*	Ryan: We want to optimize certificate sizes for TLS and there there’s a tension between allowing CAs to optional include things that are useful for their users and browsers wanting to represent their users that don’t want optional fields.  Will look into this and provide some general design guidance how those principles manifest within the profiles.

Tim: We could add this to the preamble of the ballot.  Ryan was planning to include this type of thing for the specific changes in this profile ballot, but there are other things and looking at all ballots and archives is not optimal, from a historical perspective.

One of the goals is to include what we need here so we don’t need to look at 5280. In some cases, we take more strict view (name constraints criticality).

 

Tim: should probably list exhaustively all changes since there are only a “few”.  Ryan, probably lots of work and of questionable value.

 

Ryan: come around to view the BRs as the BRs and include necessary RFC5280 items vs. needing to say: comply with 5280.

Tim: keep normative section clear and concise, and appendix can be in more detail (non-normative) without causing more confusion.

Ryan to put together some drafts for review on this topic.

 

Other topics:

 

Cory: Paul raised name constraints issue. Do we need a bigger discussion for v1?  Breaks svr names.

Ryan: The BRs definition of technically constrained is limited to TLS certificate types (dnsName, IpAddress).  Root programs that support more cert types like Email and srv name constraints to say it’s permitted where appropriate and ensure they do the right thing.

*	If you have an Email CA and want to issue that from a BR TLS CA that there are clear rules around that and that is where email and srv name constraints come in.

V2 should include srv name support, and that is what Cory is asking if it’s not in current root programs.  How do you specify that a CA cannot issue certs with SRV name certs?  Ryan looking into this based on implication research.

Ryan will address and explain decision for srv name use and constraints.  This is not unique to srv name constraints.

Uri name constraints for example vs. dns name constraints: Need to be clear and consistent on these constraints.

>From Ryan:  <https://cabf.webex.com/cabf-en/url.php?frompanel=false&gourl=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fissues%2F268> https://github.com/cabforum/servercert/issues/268

 

Kati from GoDaddy:

*	Shift from “should not” to “must not”: Is this a goal overall, or just in profiles?
*	Ryan: in this part, yes, just profiles, this is where we should move to MUST  or MUST NOT.
*	We should have good reasons for what we need or do.
*	Similar discussion on default allow vs. default deny

2.1.1.9 Tim’s pet peeve: There is no clean term that “this is going away in the future”. Wishes this was a distinct verb.

 

 

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