Chunghwa Telecom votes “Yes” on Ballot SC-063.
Thanks! Li-Chun Chen Chunghwa Telecom Co., Ltd. From: Servercert-wg [mailto:[email protected]] On Behalf Of Ryan Dickson via Servercert-wg Sent: Friday, July 7, 2023 1:00 AM To: ServerCert CA/BF <[email protected] <mailto:[email protected]> > Subject: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation” 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: o a full and complete, or o 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… o within twenty-four (24) hours after recording a Certificate as revoked; and o 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum. org%2F2015%2F11%2F11%2Fballot-153-short-lived-certificates%2F&data=05%7C01%7 Crealsky%40cht.com.tw%7C83c927adfee54ddee0b508db827555ed%7C54eb9440cf0345fe8 35e61bd4ce515c8%7C0%7C0%7C638247218110057925%7CUnknown%7CTWFpbGZsb3d8eyJWIjo iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& sdata=Lakozfrayhc3HJvDY9W9MEQ3MtVGrFXIuTRlHOpWaR8%3D&reserved=0> . As described in this ballot, short-lived certificates (sometimes called “short-term certificates” in ETSI <https://apc01.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%7Crealsky%40cht.com.tw%7C83c927adfee54ddee0b508d b827555ed%7C54eb9440cf0345fe835e61bd4ce515c8%7C0%7C0%7C638247218110057925%7C Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vK69SQsnKCrVnNijja99kYUVCg5%2BYbjH0qkaHbk roQY%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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog le.com%2Fdocument%2Fd%2F180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98%2Fedit& data=05%7C01%7Crealsky%40cht.com.tw%7C83c927adfee54ddee0b508db827555ed%7C54e b9440cf0345fe835e61bd4ce515c8%7C0%7C0%7C638247218110057925%7CUnknown%7CTWFpb GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C 3000%7C%7C%7C&sdata=Zxu6GXect2r2IXftp8eYSaHBbbR3YmyttHWDzxynRhw%3D&reserved= 0> here. Proposal Revision History: · The set of updates resulting from the first round of discussion are presented <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fryancdickson%2Fstaging%2Fpull%2F3%2Ffiles&data=05%7C01%7Crealsky%40cht.c om.tw%7C83c927adfee54ddee0b508db827555ed%7C54eb9440cf0345fe835e61bd4ce515c8% 7C0%7C0%7C638247218110057925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wh2TZF5kK9 I05U78DtYllxYQd1LuSRIJHs3YxfHdWYY%3D&reserved=0> here. · The set of updates resulting from the second round of discussion are presented here <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fryancdickson%2Fstaging%2Fpull%2F5%2Ffiles&data=05%7C01%7Crealsky%40cht.c om.tw%7C83c927adfee54ddee0b508db827555ed%7C54eb9440cf0345fe835e61bd4ce515c8% 7C0%7C0%7C638247218110057925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=28hKp%2BGA iyLf5vdPejqWIqX02XKFucQUXyBneOp4v6E%3D&reserved=0> . · The set of updates resulting from the third round of discussion are presented here <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co m%2Fryancdickson%2Fstaging%2Fpull%2F7%2Ffiles&data=05%7C01%7Crealsky%40cht.c om.tw%7C83c927adfee54ddee0b508db827555ed%7C54eb9440cf0345fe835e61bd4ce515c8% 7C0%7C0%7C638247218110057925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ImXJ5qQk5R Ki3eQ7m7fui7jTgh%2BAsWPgGSCIsB5mGRA%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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
