[Servercert-wg] Proposal to Incorporate Mozilla's CRL Revocation Reason Code Requirements into the BRs

Ben Wilson bwilson at mozilla.com
Thu Jan 5 17:24:23 UTC 2023 

Great - thanks.

On Thu, Jan 5, 2023 at 10:06 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Hi Ben,
>
> I saw your comments with proposed language, and here are my thoughts,
> in-line:
>
> On 4/1/2023 8:50 μ.μ., Ben Wilson wrote:
>
> Hi Dimitris,
>
> I have submitted two comments that I think need to be resolved.
>
> I think the first "1" should be written as:
>
> The Subscriber requests in writing, *without giving a reason required to
> be specified by this section 4.9.1.1,* that the CA revoke the ..."
>
>
> I prefer your earlier comment
> <https://github.com/cabforum/servercert/pull/405/files#r1061778056> which
> says
>
> "1. The Subscriber requests in writing, *without giving a reason,* that
> the CA revoke the ..."
>
> I believe this language is simpler as long as this option is available to
> Subscribers that just want to revoke a certificate and don't want to
> suggest a specific reason. I assume this is still allowed.
>
>
> Number 10 in the second list should be written as:
>
> "10. Revocation is required by the CA's Certificate Policy and/or
> Certification Practice Statement *for a reason that is not otherwise
> required to be specified by this section 4.9.1.1* ..."
>
>
> +1
>
> If you are ok with the first option, I will update the PR.
>
> Thanks!
> Dimitris.
>
>
> Ben
>
> On Tue, Nov 22, 2022 at 1:12 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> I created https://github.com/cabforum/servercert/pull/405/files which
>> includes some elements from your proposal and MRSP language.
>>
>> I also did a comparison of BRs section 4.9.1.1 revocation use cases that
>> are already mentioned in MRSP section 6.1.1 (attached). There are only a
>> few revocation use cases mentioned in MRSP that are not explicitly
>> described in 4.9.1.1 so we could try adding those to 4.9.1.1 for full
>> consistency.
>>
>> This proposal:
>>
>>    - explains the expectations for each reasonCode
>>    - preserves the existing 5 revocation use cases for 24h and the 11
>>    cases for 5-day that CAs/auditors are already familiar with, and adds an
>>    explicit reasonCode per MRSP.
>>
>> This presentation format is already familiar to CAs, less ambiguous, and
>> IMO minimizes the risk of implementing incorrectly.
>>
>>
>> Thanks,
>> Dimitris.
>>
>>
>> On 17/11/2022 5:46 μ.μ., Ben Wilson wrote:
>>
>> Sounds good. Thanks, Dimitris.
>> Ben
>>
>> On Wed, Nov 16, 2022 at 11:23 PM Dimitris Zacharopoulos (HARICA) <
>> dzacharo at harica.gr> wrote:
>>
>>>
>>>
>>> On 15/11/2022 6:11 μ.μ., Ben Wilson wrote:
>>>
>>> That could simplify it, but Mozilla's CRL Reason Code rules would still
>>> supersede that section.
>>>
>>>
>>> I don't see it as "superseding" but differently "presented". Mozilla
>>> chose that particular presentation format without taking into consideration
>>> the time limits for revocation. MRSP
>>> <https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#611-end-entity-tls-certificate-crlrevocation-reasons>only
>>> mentions the reasons and expectations for using such reasons. The BRs are
>>> more explicit in the use cases and it's more important for the CA to know
>>> which cases must be revoked within 24 hours and which ones must be revoked
>>> within 5 days. It's a better "starting point" for CAs, and that's that they
>>> are used to follow.
>>>
>>> I believe we can successfully update 4.9.1.1 to aligned with MRSP
>>> section 6.1 without changing the current presentation format of revocation
>>> use cases in the BRs. If you are open to the idea, I can work with you on a
>>> more concrete proposal and see how it looks.
>>>
>>>
>>> Thanks,
>>> Dimitris.
>>>
>>>
>>> On Tue, Nov 15, 2022 at 2:22 AM Dimitris Zacharopoulos (HARICA) via
>>> Servercert-wg <servercert-wg at cabforum.org> wrote:
>>>
>>>> On 15/11/2022 1:02 π.μ., Ben Wilson via Servercert-wg wrote:
>>>>
>>>> Thanks.
>>>>
>>>> Any additional thoughts, recommendations, etc.?
>>>>
>>>>
>>>> Hi Ben,
>>>>
>>>> I assume that the use cases described within the parenthesis under
>>>> 4.9.1.1 are "examples" which means that the "i.e." should be replaced with
>>>> "e.g.".
>>>>
>>>> I am not very much in favor of the breakown of subsections for each
>>>> revocation reasonCode which repeats the language "SHOULD revoke within 24
>>>> hours and SHALL revoke within 5 days" in various cases, and gets especially
>>>> confusing when the Subscriber requests in writing, which can apply to
>>>> several reasonCodes.
>>>>
>>>> The previous attempt keeping the existing structure that CAs/Auditors
>>>> are already familiar with, seems like a better approach. That's because CAs
>>>> already have controls in place to handle "specific revocation use cases" as
>>>> they are listed in the current sections 4.9.1.1 and 4.9.1.2. All we need to
>>>> do now is map those known cases to a specific RFC5280 reasonCode.
>>>>
>>>> If additional revocation use cases have been documented in MRSP, we can
>>>> add those in 4.9.1.1/2 as needed.
>>>>
>>>> What do others think? Should we try to minimize the changes to 4.9.1.1
>>>> and 4.9.1.2 or do a complete restructuring?
>>>>
>>>>
>>>> Thanks,
>>>> Dimitris.
>>>>
>>>>
>>>>
>>>> Ben
>>>>
>>>> On Thu, Nov 10, 2022 at 11:33 PM Roman Fischer via Servercert-wg <
>>>> servercert-wg at cabforum.org> wrote:
>>>>
>>>>> Dear Ben,
>>>>>
>>>>>
>>>>>
>>>>> Thanks for your effort to make it better understandable. Even for me
>>>>> as a non-native speaker it’s now much clearer when to use which reasonCode
>>>>> (but it’s still very complex!).
>>>>>
>>>>>
>>>>>
>>>>> Could the section
>>>>>
>>>>>
>>>>>
>>>>> ** The privilegeWithdrawn reasonCode does not need to be made
>>>>> available to the Subscriber as a revocation reason option, because
>>>>> the use of this reasonCode is determined by the CA and not the Subscriber.
>>>>>
>>>>>
>>>>>
>>>>> be reformulated to use one of the RFC 2119 terms? Maybe your intention
>>>>> was “SHALL NOT be made available”?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>> Roman Fischer, SwissSign
>>>>>
>>>>>
>>>>>
>>>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>>>> Of *Ben Wilson via Servercert-wg
>>>>> *Sent:* Freitag, 11. November 2022 00:53
>>>>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>>>>> servercert-wg at cabforum.org>
>>>>> *Subject:* Re: [Servercert-wg] Proposal to Incorporate Mozilla's CRL
>>>>> Revocation Reason Code Requirements into the BRs
>>>>>
>>>>>
>>>>>
>>>>> All,
>>>>>
>>>>> Here is another iteration of a proposal to incorporate Mozilla's CRL
>>>>> reason code requirements into the Baseline Requirements.
>>>>>
>>>>> I am open to your suggestions and recommendations on how to make this
>>>>> better.
>>>>>
>>>>> I'll put another draft in GitHub again after I receive feedback.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 20, 2022 at 10:16 PM Ben Wilson via Servercert-wg <
>>>>> servercert-wg at cabforum.org> wrote:
>>>>>
>>>>> Hi Corey,
>>>>>
>>>>>
>>>>>
>>>>> See responses below.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 14, 2022 at 11:38 AM Corey Bonnell <
>>>>> Corey.Bonnell at digicert.com> wrote:
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> It appears the ballot text has potential divergences from the
>>>>> published MRSP:
>>>>>
>>>>>
>>>>>
>>>>> 1. This ballot prohibits other CRLReasons from appearing in CRLs. This
>>>>> is meaningfully different from MRSP, where the new requirements are
>>>>> applicable solely to revocations that occur on or after the effective date.
>>>>>
>>>>>
>>>>>
>>>>>  I think this can be fixed with some language changes.
>>>>>
>>>>>
>>>>>
>>>>> 2. There is no requirement to document reason codes in the Subscriber
>>>>> Agreement, whereas there is in MRSP. Is this change intentional?
>>>>>
>>>>>
>>>>>
>>>>> Not exactly an intentional elimination of the requirement, but I can
>>>>> make the ballot consistent with the MRSP with some language changes as
>>>>> well. My idea was to suggest that CAs could incorporate the necessary
>>>>> information "by reference" so that the CRL reason code explanations
>>>>> wouldn't have to appear fully in Subscriber Agreements or Terms of Use.
>>>>>
>>>>>
>>>>>
>>>>> 3. Regarding 24-hour revocation reason #5: it appears that
>>>>> privilegeWithdrawn is now allowed. According to MRSP, only superseded is
>>>>> appropriate for this case.
>>>>>
>>>>>
>>>>>
>>>>> For consistency, I'll change this to superseded only.
>>>>>
>>>>>
>>>>>
>>>>> 4. Regarding 5-day revocation reason #9: this is not a scenario listed
>>>>> in MRSP. In other words, this revocation scenario must be denoted as
>>>>> “unspecified” as the CRLReason under MRSP. Therefore, it is not possible to
>>>>> satisfy both the proposed BR text and MRSP.
>>>>>
>>>>>
>>>>>
>>>>> That's probably the approach to take - thanks.  Another possibility is
>>>>> to move this revocation reason down to 4.9.1.2 - CAs should revoke the
>>>>> intermediate CA certificate(s) rather than all end entity certificates.
>>>>>
>>>>>
>>>>>
>>>>> 5.  Regarding 5-day revocation reason #10: this appears to be like
>>>>> scenario #7, but it is different in that revocation may be required even if
>>>>> there’s no violation of the CP/CPS. I don’t think this scenario is
>>>>> enumerated in MRSP, so it is not possible to specify a reason code that
>>>>> satisfies both MRSP and this ballot for this scenario.
>>>>>
>>>>>
>>>>>
>>>>> Kathleen and I think that this reason is in the MRSP under the section
>>>>> for the superseded CRLReason -  "the CA operator has revoked the
>>>>> certificate for compliance reasons such as the certificate does not comply
>>>>> with this policy, the CA/Browser Forum's Baseline Requirements, or the CA
>>>>> operator’s CP or CPS".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> More generally, the Defined Term “Certificate” should be used
>>>>> throughout the ballot for consistency.
>>>>>
>>>>>
>>>>>
>>>>> Agreed.  Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Corey
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>>>> Of *Ben Wilson via Servercert-wg
>>>>> *Sent:* Tuesday, September 13, 2022 11:37 PM
>>>>> *To:* Ben Wilson <bwilson at mozilla.com>; CA/B Forum Server Certificate
>>>>> WG Public Discussion List <servercert-wg at cabforum.org>
>>>>> *Subject:* Re: [Servercert-wg] Proposal to Incorporate Mozilla's CRL
>>>>> Revocation Reason Code Requirements into the BRs
>>>>>
>>>>>
>>>>>
>>>>> Here is the most current comparison:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/cabforum/servercert/compare/bbca71465ed8a8a76383086039f52c750009286a..1699612e5157423f607d67cc8ab9dc3a1d52b318
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2Fbbca71465ed8a8a76383086039f52c750009286a..1699612e5157423f607d67cc8ab9dc3a1d52b318&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6U2qShXXY%2FWlUn2vWCqq0YB8yQAQxEiQXejzc6pCawE%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 12, 2022 at 11:00 AM Ben Wilson <bwilson at mozilla.com>
>>>>> wrote:
>>>>>
>>>>> Here is another edit that tries to make minimal changes to BR section
>>>>> 4.9.1.1.
>>>>>
>>>>>
>>>>> <http://goog_144053405>
>>>>>
>>>>>
>>>>> https://github.com/BenWilson-Mozilla/servercert/commit/94a07d08855cf489a2bdddff7d8a9490969d5d06
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fservercert%2Fcommit%2F94a07d08855cf489a2bdddff7d8a9490969d5d06&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h0d4CsixQeyG7GMzM2nqO3ScDRRM1EomVg%2BuwI3lBIc%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 12, 2022 at 9:51 AM Ben Wilson via Servercert-wg <
>>>>> servercert-wg at cabforum.org> wrote:
>>>>>
>>>>> Thanks, Dimitris. I'll work on that approach and get something back to
>>>>> you soon.
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 12, 2022 at 2:56 AM Dimitris Zacharopoulos (HARICA) <
>>>>> dzacharo at harica.gr> wrote:
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> After a quick reading, I noticed that the subsections are not
>>>>> symmetrical and a bit inconsistent. For example, some of them contain the
>>>>> statement "the CA SHOULD revoke a certificate within 24 hours and MUST
>>>>> revoke a Certificate within 5 days", some do not.
>>>>>
>>>>> Other examples:
>>>>>
>>>>>    - 4.9.1.1.1, is labeled "Subscriber-Requested Revocation", however
>>>>>    there are other subsections that are also "Subscriber-Requested". This
>>>>>    separation seems confusing.
>>>>>    - 4.9.1.1.4 is about unreliable validation but most of the
>>>>>    remaining subsections are titled after the RFC 5280 revocation reasons.
>>>>>
>>>>> Finally, it's not very clear when the "unspecified (0)" reason must be
>>>>> used because of section 4.9.1.1.8 (Other Circumstances) which doesn't point
>>>>> to a revocation reason.
>>>>>
>>>>> >From my perspective, I'm not sure if breaking down each subsection is
>>>>> more helpful for reading the revocation requirements than the current
>>>>> listing. I understand there is a desire to copy the MRSP language as much
>>>>> as possible but perhaps we need to consider a less "intrusive" set of
>>>>> changes to a section that CAs already have a difficult time reading and
>>>>> implementing.
>>>>>
>>>>> IMO we either need to describe the revocation scenario and point to
>>>>> the RFC 5280 revocation reason (closer to what the BRs have today), or
>>>>> start with the RFC 5280 revocation reasons and enumerate the revocation
>>>>> scenarios (closer to what MRSP has today). I find it confusing to mix the
>>>>> two approaches.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Dimitris.
>>>>>
>>>>> On 12/9/2022 6:32 π.μ., Ben Wilson wrote:
>>>>>
>>>>> For review - here is another proposal that takes BR section 4.9.1.1
>>>>> and puts the 24-hour and 5-day revocation times into subsections that match
>>>>> the CRL reason codes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/BenWilson-Mozilla/servercert/commit/b185a28fcc20d5853747e4506103823e3dc7c282
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fservercert%2Fcommit%2Fb185a28fcc20d5853747e4506103823e3dc7c282&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=opmFVkFFcOqc3DWpy%2BwP%2B79ihMxBOPnZE34AGDSKjWY%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 8, 2022 at 12:05 PM Dimitris Zacharopoulos (HARICA) <
>>>>> dzacharo at harica.gr> wrote:
>>>>>
>>>>> Good point.
>>>>>
>>>>> s/
>>>>>
>>>>> *expected/shall use/ *
>>>>>
>>>>> On 8/9/2022 8:26 μ.μ., Tim Hollebeek wrote:
>>>>>
>>>>> I would prefer standard 2119 language instead of an “expectation”.
>>>>> There are no documented rules for what it means for a CRLReason to be
>>>>> expected to be a certain value.
>>>>>
>>>>>
>>>>>
>>>>> -Tim
>>>>>
>>>>>
>>>>>
>>>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
>>>>> <servercert-wg-bounces at cabforum.org> *On Behalf Of *Dimitris
>>>>> Zacharopoulos (HARICA) via Servercert-wg
>>>>> *Sent:* Thursday, September 8, 2022 3:21 AM
>>>>> *To:* Ben Wilson <bwilson at mozilla.com> <bwilson at mozilla.com>; CA/B
>>>>> Forum Server Certificate WG Public Discussion List
>>>>> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
>>>>> *Subject:* Re: [Servercert-wg] Proposal to Incorporate Mozilla's CRL
>>>>> Revocation Reason Code Requirements into the BRs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/9/2022 8:22 μ.μ., Ben Wilson wrote:
>>>>>
>>>>> Good suggestion. I can re-work a proposal that re-writes BR sec.
>>>>> 4.9.1.1 to re-group the revocation reasons into the reason codes that
>>>>> should be used. Is that what you were thinking?
>>>>>
>>>>>
>>>>> Yes. We should also try to keep the current BRs prioritization. The
>>>>> section begins with the cases where the Certificate(s) need to be revoked
>>>>> within 24h and then moves to the 5-day revocation cases.
>>>>>
>>>>> We could walk this list down making sure that all Mozilla cases are
>>>>> listed (add the ones that are not) and add the expected revocationReason
>>>>> for each case. For example:
>>>>>
>>>>> *The CA SHALL revoke a Certificate within 24 hours if one or more of
>>>>> the following occurs:*
>>>>>
>>>>>    1. *The Subscriber requests in writing that the CA revoke the
>>>>>    Certificate (expected CRLReason:unspecified);*
>>>>>    2. *The Subscriber notifies the CA that the original certificate
>>>>>    request was not authorized and does not retroactively grant authorization
>>>>>    (expected CRLReason:**privilegeWithdrawn**);*
>>>>>    3. *The CA obtains evidence that the Subscriber's Private Key
>>>>>    corresponding to the Public Key in the Certificate suffered a Key
>>>>>    Compromise (expected CRLReason:keyCompromise);*
>>>>>    4. *The CA is made aware of a demonstrated or proven method that
>>>>>    can easily compute the Subscriber's Private Key based on the Public Key in
>>>>>    the Certificate (such as a Debian weak key, see *
>>>>>    *https://wiki.debian.org/SSLkeys*
>>>>>    <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FV7HivQUf9v8s2xTxi1rVgVbg7XfH9TtU4RjlKL0T6c%3D&reserved=0>*)
>>>>>    (expected CRLReason:keyCompromise);*
>>>>>    5. *The CA obtains evidence that the validation of domain
>>>>>    authorization or control for any Fully-Qualified Domain Name or IP address
>>>>>    in the Certificate should not be relied upon (expected CRLReason: *
>>>>>    *superseded**).*
>>>>>
>>>>> and so on.
>>>>>
>>>>> Does that work?
>>>>>
>>>>> Dimitris.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 7, 2022 at 6:01 AM Dimitris Zacharopoulos (HARICA) via
>>>>> Servercert-wg <servercert-wg at cabforum.org> wrote:
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> I believe the proposal, as written, causes confusion in regards to
>>>>> 4.9.1.1. Some of the reasons described in your proposal are already
>>>>> mentioned in 4.9.1.1. Perhaps we should work some more to "unify" the two
>>>>> sections.
>>>>>
>>>>> My proposal would be to update 4.9.1.1 and include the expected
>>>>> CRLReason after each case.
>>>>>
>>>>>
>>>>> Thoughts?
>>>>> Dimitris.
>>>>>
>>>>> On 6/9/2022 8:13 μ.μ., Ben Wilson via Servercert-wg wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> I'm looking for one more endorser.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 29, 2022 at 12:40 PM Ben Wilson via Servercert-wg <
>>>>> servercert-wg at cabforum.org> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>>
>>>>>
>>>>> I have created a proposal in Github to incorporate Mozilla's CRL
>>>>> Revocation Reason Code requirements into the Baseline Requirements.
>>>>>
>>>>>
>>>>>
>>>>> See https://github.com/cabforum/servercert/issues/377
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fissues%2F377&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D4KPoI9FuCxKdr9yp378P8kEzjJq9wX%2FUEj%2F0SDufv4%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> https://github.com/BenWilson-Mozilla/servercert/commit/52a480803beff1f96d61c4b6d76570ac7adff4d5
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBenWilson-Mozilla%2Fservercert%2Fcommit%2F52a480803beff1f96d61c4b6d76570ac7adff4d5&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LOfjUsptzgpQxI1k6K8oUgU0aj2LDncd48ZzuXe86Hs%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> I'm looking for comments, suggestions, and two endorsers.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Ben
>>>>>
>>>>> _______________________________________________
>>>>> Servercert-wg mailing list
>>>>> Servercert-wg at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iis%2B0QIl3jXlnwoZxV15jIUE%2FGB%2FtJyHdECcBBoSrcQ%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Servercert-wg mailing list
>>>>>
>>>>> Servercert-wg at cabforum.org
>>>>>
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iis%2B0QIl3jXlnwoZxV15jIUE%2FGB%2FtJyHdECcBBoSrcQ%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Servercert-wg mailing list
>>>>> Servercert-wg at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iis%2B0QIl3jXlnwoZxV15jIUE%2FGB%2FtJyHdECcBBoSrcQ%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Servercert-wg mailing list
>>>>> Servercert-wg at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688809839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iis%2B0QIl3jXlnwoZxV15jIUE%2FGB%2FtJyHdECcBBoSrcQ%3D&reserved=0>
>>>>>
>>>>> _______________________________________________
>>>>> Servercert-wg mailing list
>>>>> Servercert-wg at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Croman.fischer%40swisssign.com%7Ce95c13967f6d4cffa0db08dac376a9d2%7C21322582607f404c82d950ddb1eca5c9%7C1%7C0%7C638037211688965625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rOfjT8%2B0oEL1XaQtLBTQ5EQOkSK3lJR0AbU1lVyZF68%3D&reserved=0>
>>>>>
>>>>> _______________________________________________
>>>>> Servercert-wg mailing list
>>>>> Servercert-wg at cabforum.org
>>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>>
>>>>
>>>> _______________________________________________
>>>> Servercert-wg mailing listServercert-wg at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20230105/713cea97/attachment-0001.html>

More information about the Servercert-wg mailing list