[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”
Aaron Gable
aaron at letsencrypt.org
Thu May 11 17:37:30 UTC 2023
Thanks, Ryan, I believe that does address this concern!
On Thu, May 11, 2023 at 9:06 AM Ryan Dickson <ryandickson at google.com> wrote:
> Hi Aaron,
>
> I think this concern might already be addressed in this
> <https://github.com/ryancdickson/staging/commit/2ab659ca36ab0f72318c5b9bec1121cd389f1035>
> commit (where I was responding to a comment from Wayne), which is part of
> an updated branch
> <https://github.com/ryancdickson/staging/tree/make-ocsp-optional-updates>
> that I plan on merging <https://github.com/ryancdickson/staging/pull/3>
> into the initial effort
> <https://github.com/ryancdickson/staging/tree/make-ocsp-optional> to kick
> off a second round of discussion (either tomorrow or early next week).
>
> To further help prevent confusion, I collapsed
> <https://github.com/ryancdickson/staging/commit/7012dafedd523d975d10a218f10998ef36f2c69c>
> the separate crlDistributionPoints rows in the updated 7.1.2.7.6 into one,
> with a note
> <https://github.com/ryancdickson/staging/commit/0cb0ce3175e8863873b74f64d685b6495bafdc7e>
> indicating that the extension's presence is dependent upon the contents of
> Section 7.1.2.11.2 ("CRL Distribution Points").
>
> In summary, the latest draft of the ballot text (not yet introduced for
> discussion):
>
> - 1.2.2 ("Relevant Dates"): Indicates that effective 3/15/2024, CAs
> must generate and publish CRLs (as described in the updated 4.9.7).
> [unchanged from original draft]
> - 7.1.2.7.6 ("Subscriber Certificate Extensions"): Indicates CRLDP
> must not be marked critical and points to 7.1.2.11.2 ("CRL Distribution
> Points) for additional context. [changed from original draft]
> - 7.1.2.11.2 ("CRL Distribution Points"): Indicates that the
> crlDistributionPoints extension MUST be present in Subordinate CA
> Certificates and Subscriber Certificates that 1) are not Short-Lived
> Subscriber Certificates or 2) do not include an Authority Information
> Access extension with an id-ad-ocsp accessMethod. [changed from original
> draft]
>
>
> If you disagree, please let me know!
>
> Thanks,
> Ryan
>
> On Tue, May 9, 2023 at 8:09 PM Aaron Gable <aaron at letsencrypt.org> wrote:
>
>> Hi Ryan,
>>
>> In reviewing this ballot, I've noticed another aspect of it that I
>> believe is unintended.
>>
>> The ballot amends Section 1.2.2 Relevant Dates to say that "CAs MUST
>> generate and publish CRLs" effective 2024-03-15.
>>
>> However, it also amends 7.1.2.7.6 Subscriber Certificate Extensions to
>> say that the crlDistributionPoints extension MUST be included in all
>> non-Short-Lived Subscriber Certificates. This section was introduced in
>> ballot SC-062, and (as noted in Section 7.1 Certificate Profile) has an
>> effective date of 2023-09-15.
>>
>> Therefore this ballot would actually require CAs to include CRLDP URLs
>> (and therefore to generate and publish CRLs) as soon as September of this
>> year, which I do not believe is this ballot's intent.
>>
>> Thanks,
>> Aaron
>>
>> On Thu, Apr 27, 2023 at 6:30 AM Ryan Dickson via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> 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 to include:
>>>
>>> -
>>>
>>> Establishing a detailed CRL profile, consistent with the certificate
>>> profiles introduced in Version 2.0.0 of the Baseline Requirements.
>>> -
>>>
>>> CAs MUST generate and publish either:
>>> -
>>>
>>> a full and complete CRL; OR
>>> -
>>>
>>> partitioned CRLs (sometimes called “sharded” CRLs), that when
>>> aggregated, represent the equivalent of a full and complete CRL.
>>> -
>>>
>>> CAs MUST include the corresponding HTTP URI for either the full and
>>> complete or partitioned/sharded CRL in the CRL Distribution Point
>>> extension of subscriber certificates.
>>> -
>>>
>>> CRLs MUST be updated and reissued once daily.
>>>
>>>
>>> Finally, the proposal revisits the concept of a “short-lived”
>>> certificate, introduced in Ballot 153
>>> <https://cabforum.org/2015/11/11/ballot-153-short-lived-certificates/>. As
>>> described in this ballot, short-lived certificates (sometimes called
>>> “short-term certificates” in ETSI specifications
>>> <https://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.04.04_60/en_31941201v010404p.pdf>)
>>> 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
>>> here
>>> <https://docs.google.com/document/d/180T6cDSWPy54Rb5d6R4zN7MuLEMShaZ4IRLQgdPqE98/edit>
>>> .
>>>
>>>
>>>
>>> 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/a0360b61e73476959220dc328e3b68d0224fa0b3..6ff4a7b332f46a8a54cc36e16d1299373d31efe9
>>>
>>>
>>>
>>> — Motion Ends —
>>>
>>>
>>> This ballot proposes a Final Maintenance Guideline. The procedure for
>>> approval of this ballot is as follows:
>>>
>>>
>>> Discussion (14+ days)
>>>
>>> -
>>>
>>> Start time: 2023-04-27 13:30:00 UTC
>>> -
>>>
>>> End time: Not before 2023-05-11 13:30:00 UTC
>>>
>>>
>>> Vote for approval (7 days)
>>>
>>>
>>> -
>>>
>>> Start time: TBD
>>> -
>>>
>>> End time: TBD
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230511/ec1b9fd2/attachment-0001.html>
More information about the Servercert-wg
mailing list