[Servercert-wg] Meeting minutes of November 10th

[Inigo Barreira]

Attendance: 

Aaron Poulsen (Amazon Trust Services), Adam Jones (Microsoft), Adrian
Mueller (SwissSign), Andrea Holland (SecureTrust/VikingCloud), Atsushi Inaba
(GlobalSign), Ben Wilson (Mozilla), Brittany Randall (GoDaddy), Bruce Morton
(Entrust), Chris Clements (Google Chrome), Chris Kemmerer (SSL.com), Clint
Wilson (Mozilla), Daryn Wright (GoDaddy), Dimitris Zacharopoulous (HARICA),
Dustin Hollenback (Microsoft), Enrico Entschew (D-Trust), Janet Hines
(SecureTrust/VikingCloud), Joanna Fox (TrustCor), Jos Purvis (Fastly), Ingio
Barreira (Sectigo), Lynn Jeun (Visa), Mads Henriksveen (Buypass), Marco
Schambach (IdenTrust), Martijn Katerbarg (Sectigo), Nargis Mannan
(SecureTrust/VikingCloud), Paul van Brouwershaven (Entrust), Pedro Fuentes
(OISTE), Peter Miskovic (Disig), Rebecca Kelley (Apple), Ryan Dickson
(Google Chrome), Tadahiko Ito (SECOM), Trevoli Ponds-White (Amazon Trust
Services), Tyler Myers (GoDaddy), Vijay Kumar (eMudhra), Wayne Thayer
(Fastly), Wendy Brown (FPKI)

Inigo read the antitrust statement

Previous minutes

*	October 13 - approved 
*	October F2F - in progress

Validation Subcommittee - Wayne T.

*	Final Changes to Certificate Profiles ballot

*	Merged PR that forbids OUs in CA certificates
*	Merged PR that has minor fixes, adding some ordering and encoding
requirements for subject domain component attributes, removing overly
specific cross cert requirements, fixing serial number encodings, clarifying
main constraint extensions, and removing the domain name or IP address
validation requirement. There was discussion around the last item because
the definition of domain name is overly broad and there is concern that any
word in the subject of its certificate to be validated as a domain name.

*	New type of DNS record - alternate service record (SVCB record).
There was discussion on type and how certs can be domain validated against
these records. We will create a work items to investigate use and method
type.
*	Continue review of the terms applicant and applicant representative.
Worked on Section 6.1.13 which includes a clause that says CAs May Not
generate private key pairs for subscriber certificates. Discussion on
whether the BRs allow CAs to generate private keys for when the CA is also
the subscriber for instance with test website certificates. Potential to add
a phrase at the beginning of the BRs that would clarify that a CA could hold
multiple roles if they were also requesting a certificate for their own use.

Ballot Status - Inigo B.

*	Completed IPR

*	SC58 require distributionPoint in sharded CRLs - IPR completed on
November 7th

*	Passed

*	SC56 Cleanup ballot - IPR ends on November 30th

*	Under consideration

*	SCXX Debian Weak Keys Ballot - Chris K.: seeking one more endorser
*	SCXX SLO/Response for CRL & OCSP Responses - Clint W.: still on
hold, waiting for discussion brought up by Ryan Dickson on removing OCSP to
conclude 
*	SCXX Incorporation of Mozilla Revocation Reason Codes - Ben W.: Will
send out a draft ballot for review prior to the dicussion period

Any Other

*	Ryan D. - Two items on github for discussion: making OCSP optional
and incentivizing short lived certificates and automation. 

*	Wayne T.- what is the impact of removing OCSP on OCSP stappling?
*	Ryan D. - The intent of the proposal, is if CAs want to provide it
to their clients because they feel it is an important security quality of
TLS then it is still encouraged and recommended. Given some of the other
issues related to privacy concerns and the numbers of bugs related to
operating a highly available resilient service we want to leave it up to the
CA if they want to make it available for their clients. 
*	Wayne T.- My concern is CAs have a lot of incentive not to operate
OCSP because it is an involved service. If a website operate wants to
benefit from OCSP stappling which give the benefits of revocation,
performance, and privacy, won't have the opportunity because their CA won't
provide it. 
*	Trev - If a client wanted it they could go to a CA that supported
it.
*	Dimitris Z. - These are the baseline requirements so if someone
wanted to go above and beyond to offer additional services, they are able
to.
*	Ryan D. - Similar scenario to EV, where some CAs support and some
don't. So those customers who want EV will use the CAs that support it.

*	Dimitris Z. - Do we need to separate the ServerCert WG meeting and
the Forum meeting? The Forum meeting has more people, it might be better to
just swap the meetings times and those who want to stay on for the
ServerCert can remain on the call.

*	Trev - The reason we had ServerCert first was more people would join
that meeting. Now that we have more working groups it makes sense to revisit
the meeting order.
*	Inigo B.- Do we want to have a separate call for each?
*	Martijn K. - We could switch to the next call earlier that would
address the automation for attendance gathering.
*	Trev - We wouldn't want to have a variable start time for the
ServerCert working group.
*	Inigo - If it was a set 30 minutes we would potentially wait 10
minutes for the next meeting.
*	Dimitris Z.- I think most people wouldn't want to wait and those
attending the ServerCert will likely be attending the Forum call. Consensus
is to switch the meeting order. I will also bring this up on the Forum call.

Next meeting on November 24th is cancelled. Meeting will resume on December
8th.

Adjourn 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221124/41de8359/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6853 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20221124/41de8359/attachment-0001.p7s>