[Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation”

Inigo Barreira Inigo.Barreira at sectigo.com
Fri Jul 7 14:56:25 UTC 2023


Sectigo votes YES

 

De: Servercert-wg <servercert-wg-bounces at cabforum.org> En nombre de Ryan
Dickson via Servercert-wg
Enviado el: jueves, 6 de julio de 2023 17:59
Para: ServerCert CA/BF <servercert-wg at cabforum.org>
Asunto: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: "Make OCSP
Optional, Require CRLs, and Incentivize Automation"

 

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

 

Purpose of Ballot SC-063

This Ballot proposes updates to the Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates related to making Online
Certificate Status Protocol (OCSP) services optional for CAs. This proposal
does not prohibit or otherwise restrict CAs who choose to continue
supporting OCSP from doing so. If CAs continue supporting OCSP, the same
requirements apply as they exist today.

 

Additionally, this proposal introduces changes related to CRL requirements
including:

*	CRLs must conform with the proposed profile.
*	CAs must generate and publish either:

*	a full and complete, or 
*	a set of partitioned CRLs (sometimes called "sharded" CRLs), that
when aggregated, represent the equivalent of a full and complete CRL.

*	CAs issuing Subscriber Certificates must update and publish a new
CRL.

*	within twenty-four (24) hours after recording a Certificate as
revoked; and 
*	Otherwise: 

*	at least every seven (7) days if all Certificates include an
Authority Information Access extension with an id-ad-ocsp accessMethod ("AIA
OCSP pointer"), or
*	at least every four (4) days in all other cases.

 

Finally, the proposal revisits the concept of a "short-lived" certificate,
introduced in Ballot 153
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.
org%2F2015%2F11%2F11%2Fballot-153-short-lived-certificates%2F&data=05%7C01%7
Cinigo.barreira%40sectigo.com%7C5ae96381d59d4811df6208db7e39f892%7C0e9c48946
caa465d96604b6968b49fb7%7C0%7C0%7C638242561837954416%7CUnknown%7CTWFpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
C%7C%7C&sdata=J3OXFy66BiVwjgcDO7H52cjBYh3LGn1NW4vUSwGGN8k%3D&reserved=0> .
As described in this ballot, short-lived certificates (sometimes called
"short-term certificates" in ETSI
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.
org%2Fdeliver%2Fetsi_en%2F319400_319499%2F31941201%2F01.04.04_60%2Fen_319412
01v010404p.pdf&data=05%7C01%7Cinigo.barreira%40sectigo.com%7C5ae96381d59d481
1df6208db7e39f892%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C6382425618379
54416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EgNuZPKaBlIlAvejN%2BLopzT6TOdSL2W
Z%2B4FKUrKSidU%3D&reserved=0> specifications) are:

*	optional. CAs will not be required to issue short-lived
certificates. For TLS certificates that do not meet the definition of a
short-lived certificate introduced in this proposed update, the current
maximum validity period of 398 days remains applicable. 

*	constrained to an initial maximum validity period of ten (10) days.
The proposal stipulates that short-lived certificates issued on or after 15
March 2026 must not have a Validity Period greater than seven (7) days.

*	not required to contain a CRLDP or OCSP pointer and are not required
to be revoked. The primary mechanism of certificate invalidation for these
short-lived certificates would be through certificate expiry. CAs may
optionally revoke short-lived certificates. The initial maximum certificate
validity is aligned with the existing maximum values for CRL "nextUpdate"
and OCSP response validity allowed by the BRs today. 

 

Additional background, justification, and considerations are outlined
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog
le.com%2Fdocument%2Fd%2F180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98%2Fedit&
data=05%7C01%7Cinigo.barreira%40sectigo.com%7C5ae96381d59d4811df6208db7e39f8
92%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638242561837954416%7CUnknown
%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
n0%3D%7C3000%7C%7C%7C&sdata=TnVdl5UeP%2B3gEkv1Wa6gyPwjJ%2F99YudIBgNJrA9bet0%
3D&reserved=0> here.

 

Proposal Revision History:

*	The set of updates resulting from the first round of discussion are
presented
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fryancdickson%2Fstaging%2Fpull%2F3%2Ffiles&data=05%7C01%7Cinigo.barreira%
40sectigo.com%7C5ae96381d59d4811df6208db7e39f892%7C0e9c48946caa465d96604b696
8b49fb7%7C0%7C0%7C638242561838110640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ct
MOWzUdNZA58MAXd3%2ByOTIwOpxacG%2FsIF46CFINt%2Bw%3D&reserved=0>  here.
*	The set of updates resulting from the second round of discussion are
presented here
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fryancdickson%2Fstaging%2Fpull%2F5%2Ffiles&data=05%7C01%7Cinigo.barreira%
40sectigo.com%7C5ae96381d59d4811df6208db7e39f892%7C0e9c48946caa465d96604b696
8b49fb7%7C0%7C0%7C638242561838110640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cr
rW6ovoxg1wE6ezMwUBSQS8alqB0yOCNyevYcVOWmI%3D&reserved=0> .
*	The set of updates resulting from the third round of discussion are
presented here
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2Fryancdickson%2Fstaging%2Fpull%2F7%2Ffiles&data=05%7C01%7Cinigo.barreira%
40sectigo.com%7C5ae96381d59d4811df6208db7e39f892%7C0e9c48946caa465d96604b696
8b49fb7%7C0%7C0%7C638242561838110640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w4
kGxD5npyb0oHLhnetUC66uMmlkZtQnEaAKoDdwpiw%3D&reserved=0> . 

 

The following motion has been proposed by Ryan Dickson and Chris Clements of
Google (Chrome Root Program) and endorsed by Kiran Tummala of Microsoft and
Tim Callan of Sectigo.

 

- Motion Begins -

 

This ballot modifies the "Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates" ("Baseline Requirements"),
based on Version 2.0.0.

 

MODIFY the Baseline Requirements as specified in the following Redline: 

https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b6
8d0224fa0b3..b8a0453e59ff342779d5083f2f1f8b8b5930a66a 

 

- Motion Ends -

 

This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows:

 

Discussion (13+ days)

*  Start time: 2023-06-22 20:30:00 UTC

*  End time: 2023-07-06 15:59:59 UTC

 

Vote for approval (7 days)

*  Start time: 2023-07-06 16:00:00 UTC

*  End time: 2023-07-13 16:00:00 UTC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230707/62d39644/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/20230707/62d39644/attachment-0001.p7s>


More information about the Servercert-wg mailing list