[cabf_validation] 2022-06-16 Draft Minutes

[Corey Bonnell]

Hello,

Andrea forwarded the minutes she took for our previous call (thanks
Andrea!). Please review and we'll approve either tomorrow or the meeting
after (depending on how many have a chance to review).

 

Thanks,

Corey

 

-------------

 

Validation Subcommittee - Minutes of Thursday, June 16, 2022

Attendance:  Aaron Poulsen (Amazon Trust Services), Amanda Mendieta (Apple),
Andrea Holland (SecureTrust), Aneta Wojtczak (Microsoft), Ben Wilson
(Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnell
(DigCert), Dustin Hollenback (Microsoft), Emily Stark (Google Chrome),
Hubert Chao (Google Chrome), Inigo Barreria (Sectigo), Jamie Mackey (GSA
FPKIMA), Joanna Fox (TrustCor), Joe Ramm (OATI), Johnny Reading (GoDaddy),
Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Paul van Brouwershaven
(Entrust), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera), Tyler Myers
(GoDaddy),

Antitrust Statement: Read by Corey Bonnell

Previous Minutes: Minutes have not gone out yet.

Profiles Ballot

Corey - Today we will be continuing the presentation where we left off from
the face to face. We went through an overview of the some of the must not
level requirement changes on the certificate profiles ballot. Resuming today
with the should not and not recommended changes and the impact there. 

Presentation link:
http://lists.cabforum.org/pipermail/validation/attachments/20220608/ea4bb526
/attachment-0001.pdf

Should (Not) level changes - Subject

*	streetAddress and postalCode is now a not recommend.

*	Corey - There will be certificates impacted although CAs have been
phasing this out already. Should not and not recommend are identical as far
as RFC 2119 standpoint.

*	Any attribute not explicitly listed in the ordering table should not
be included

*	Corey- Unintended side effect of current language is it does not
include any of the attributes that are required for EV certificates.
*	Aneta - We can explicitly add EV required attributes.
*	Andrea - Or we can reference the EV guidelines instead.
*	Corey - We might need to add ordering of EV attributes since EV
guidelines does not explicitly list an order, but there is a wide variation
across CAs on the ordering of the attributes so if we mandate an order, we
will need an effective date.

Should (not) level changes - KeyUsage

*	RSA: digitalSignature and keyEncipherment together is now a should
not

*	Corey - This is a widespread practice and there will be a wide
impact to certificates. There is some good language in the ballot explaining
the rationale behind this decision. TLS 1.3 only requires a digital
signature bit be asserted, where some of the older protocols require the key
encipherment be asserted.

Should (not) level changes - certPolicies

*	The first policy OID should be a reserved CABF policy OID

*	Corey - This has benefits when doing policy chaining which is only
relevant to EV UI display

Should (not) level changes - Authority Key Identifier

*	Should be included in Root Certificates

*	Corey - It is very common for CAs to not include this which is
likely the result of RFC 5280 guidance.
*	Ben - What was the rationale for this considering it is against the
RFC.
*	Corey - The rationale behind this is to assist user agents that do
not follow the RFC to help them more efficiently perform path building.
Although it is not explicitly necessary for the user agents.

Should (not) level changes - Name Constraints

*	Should not contain permittedSubtrees or excludedSubtress that are
not of type dirName, iPAddress, or dNSName

*	Corey - Somewhat conflicts with the current Mozilla root policy,
ICA's if they are to be considered technically constraints they need to have
either EKU constraints or name constraints for all four of dirName,
iPAddress, dNSName, and the other name type for server names. Although this
might not result in any concrete issues since this is should not level
change.

Should (not) level changes - Other Extensions

*	Should not contain extensions that are not explicitly listed in the
Extensions table

*	Corey - Examples of notable ones in use that are not included: MSFT
Template Name (etc.), QCStatements, TLSFeature (OCSP Must-Staple).
*	Paul - What is the reasoning behind not including QCStatements or
OCSP Must-Staple.
*	Corey - Would need to review the discussions from late last summer,
but idea that anything that is not fully described in the profiles ballot
should not be included.
*	Inigo - The QCStatements have not been discussed between the
browsers and the EU commission since they are still discussing several
aspects around QWACs.  There is an ETSI standard profile for QWACs which
includes QCStatements. This creates a contradiction since a CA has to follow
the corresponding CABF standards to be certified but in order to issue QWACs
you have to follow the ETSI standards. Especially if the should not becomes
a shall not in the future. The EU commission and browsers are still
discussing validating the certificates with the EUTL which also requires you
to follow the ETSI standards. 
*	Corey - It could be construed as contradictory. The information in
this presentation is based on the current draft ballot, so we can revisit
some of these decisions in light of new information.
*	Emily - has this evolved from shall not to a should not or has this
always been a should not?
*	Corey - I would have to revisit this language, but it was never a
shall not or must not. This may have fluctuated between you may include
other extension levels.
*	Ben - For Mozilla on the Must-Staple, I am not sure what the
rational is maybe server administrators would want to put in their
certificates, but it seems okay to have a should not because they can add it
if they need it.
*	Dustin - What is the impact for certificates? Should we investigate?
This one might be more impactful, so it would be good to known.
*	Corey - I was unable to grab the impact information due to time, but
you can find out the specific extension OIDs and you can do a search on
censys with unknown extension id or for QCStatements. I believe delegated
credentials have specific certificate extensions in them and if they are not
explicitly enumerated the net result is a should not violation if included.
It would be good to get an impact analysis on this change.
*	Clint - The intent was to expand the list to explicitly listed
extensions in v2. So, until we have a well-defined referenced document or
set of validation requirements it makes sense for them to be a should not.
The idea is to have something that relying parties can rely on to
demonstrate what CA's are doing. CAs can work on getting these less defined
extensions better defined with standards or reference document to be
included on the explicit list. The extension could be added in this ballot,
if it is ready, or v2 or a standalone ballot, if necessary. 
*	Dustin - If someone has an extension that they want added could it
be added now. If it is a really impactful extension that might justify
adding it to the may now as long as there is a reference, but the onus is on
the impacted CAs.
*	Corey - It is difficult to find all the use cases. Having the CAs
that are potentially impacted do the digging and research makes sense.
*	Martijn - I did a rough look up (it is rough because I didn't check
for duplicate precerts or leaf certificates nor check against if the root
was trusted) QCStatements has 16k active certificates and TLSFeature has 1.3
million active certificates.

V2 - Who defines OID

*	Corey - A lot of RFCs will have their own OID and there might be
similar arrangements on a private level or other formalized standards
documents. It would be valuable to know when use of an OID has been granted
so CAs are not adding OIDs that the OID arch owner might not approve of.

V2 - Certificate Policies

*	V1 allows cPSUri in all non-Root certificate types. The proposal to
disallow all qualifiers for Sub CA certificates with anyPolicy

*	Corey - This is essentially codifying an RFC 5280 should not level
requirement, if the anyPolicy OID is expressed then no qualifiers should be
included in the certPolicies extension.

*	V1 allows for Certificate policies extension in OCSP responders
until the sunset date

*	Corey - There was good discussion on this item last week. Ryan
Dickson is going to follow-up on the way policy constraints are handled in
chrome.

V2- Naming

*	V1 makes OrganizationName in IV certificates a not recommended. V2
proposal is to make it a must not.
*	Defining naming requirements for OCSP delegated responder
certificates.

*	Corey- There was some discussion on github on whether or not names
can be reused across generations for ocsp delegated responders and this
would be valuable to clarify on v2

*	Defining requirements for dnQualifier attribute to enable sunset of
CN. 

*	Corey - This was proposed years ago by Peter Bowan would allow for
deprecation of common name in certs but still allow for non empty subject
dn. There were some concerns at the time that if you didn't include the
common name the subject dn would be empty and would cause interoperability
issues with some clients. The idea is to instert a dn qualifier attribute so
the Subject dn is no longer empty.

V2- Other items

*	Define requirements for other extensions. 
*	Prohibit all non-TLS issuance

*	Corey - This is for a root that is audited by TLS BRs essentially
moving to single use hierarchy. If there are additional items that we want
to tackle, we can add them as well.

Other Comments

*	Ben - Question on the Subject dn are we going to change our course
on that item.
*	Corey - My personal opinion this is a large normative change for
something that was previously allowed. There is an international research
community that uses these certificates. Their use case should be
accommodated at least in the short-term. Their PKI operations would be
drastically disrupted.
*	Clint - We should be able to add language to define how they are
validated against 3224 that covers the concern. The concern is there are
values that are potentially misleading since we don't know how they are
validated.
*	Ben - I see your point but I don't know how they go about validating
it.
*	Clint - Is that something that CAs can provide some insight the
subject dn how are they being validated. So we can understand how disruptive
it would be. Mostly Sectigo and DigiCert that have impacted customers. Can
we get that information from you?
*	Corey - That is something that we can dig into to come up with more
specific validation requirements. The main concern is that the ballot
language prohibits the inclusion of the same attribute type multiple times
that would need to be accommodated.
*	Clint - That can be accommodated as long as we have some base
requirements for how those values are validated. It would be helpful to see
what the current processes are so we can put in validation requirements,
maybe they are being validated by 3224 already. If it is truly disruptive to
put in validation requirements, we will have to think of a different path
because we don't want to disrupt an impactful community unnecessarily. We do
want to have some baseline requirements of how those certificates are being
validated.
*	Corey - That is a good approach, the idea that we defined the
validation requirements in the BRs after we have an evaluation of current
practice. Then we would have an explicit carve out to allow for multiple
domain component attributes to appear in a single dn.
*	Dustin - Thank you Corey for making the case impact reports.
*	Corey - I hope that in the future we can do similar analysis like
this to concretely view the impact of potential changes. 

 

 

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