[Servercert-wg] Proposal to Incorporate Mozilla's CRL Revocation Reason Code Requirements into the BRs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Jan 5 17:44:09 UTC 2023
Language updated in
https://github.com/cabforum/servercert/pull/405/commits/0a07e046326101ef3b57572daebd3cf45ff4840f.
I don't see any other unresolved comments. Ben, please do one last
review in case I missed something.
Thanks,
Dimitris.
On 5/1/2023 7:24 μ.μ., Ben Wilson wrote:
> 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
>>>> <http://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>
>>>>> <mailto: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>
>>>>> <mailto:bwilson at mozilla.com>;
>>>>> CA/B Forum
>>>>> Server
>>>>> Certificate WG
>>>>> Public
>>>>> Discussion
>>>>> List
>>>>> <servercert-wg at cabforum.org>
>>>>> <mailto: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 list
>>>>> Servercert-wg at cabforum.org
>>>>> https://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/2247b4ff/attachment-0001.html>
More information about the Servercert-wg
mailing list