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

Tim Hollebeek tim.hollebeek at digicert.com
Mon Jan 9 15:42:04 UTC 2023


I like March 15, September 15, and July 15 because they align with our growing consensus to use the 15th day of odd months for deadlines, reducing the number of possible deadlines from 366 to 6, a >60x reduction in complexity for those of us trying to track and manage these things.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ben Wilson via Servercert-wg
Sent: Friday, January 6, 2023 6:08 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Cc: 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

I am preparing the ballot, but I think that the effective dates should be included in your GitHub version. (Currently at https://github.com/cabforum/servercert/compare/0a07e046326101ef3b57572daebd3cf45ff4840f<https://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/compare/0a07e046326101ef3b57572daebd3cf45ff4840f&g=ZWJmMjY3Njc2YjRiNjg0Yw==&h=OWFjMmE2ZWM0Nzg4NzIzMjc2ZGYxMjkzMTEyNDI1ODgxZWY3YmI4MjQ4NDUzMmZjMWM4NTQ1ZjA1M2ZiZGRlOA==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>.)  CAs in Mozilla's program should have already been including reason codes in CRLs.  Elsewhere, others have suggested March 15 and September 15 as potential effective dates for other ballots, but I'd be willing to say July 1st or July 15th. What are everyone's thoughts?

Ben


On Thu, Jan 5, 2023 at 10:44 AM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>> wrote:
Language updated in https://github.com/cabforum/servercert/pull/405/commits/0a07e046326101ef3b57572daebd3cf45ff4840f<https://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/pull/405/commits/0a07e046326101ef3b57572daebd3cf45ff4840f&g=NTk0NmQ2YjZlYWI3NzVjNA==&h=ZmUxMmU5NWQzYzg3ZDBjZThkNmNkYzFjYWU2NDRmZTllYzkxY2Q3NmEzNDUzNTRhYmVkYTIwMTQ0MmU0MmJhMw==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>.

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<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/pull/405/files%23r1061778056&g=ZGU3MzkyM2ZlZjY3YmRkYw==&h=Y2I2MWI5ZTA3ZGZiMWQyNThjMTQ1MmU0OGNhY2NlNjk5OTMzNTFhOWI4NGU1MTdlNjRkMjA1ZDY4ZWRiZWU5ZQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=> 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<mailto:dzacharo at harica.gr>> wrote:
I created https://github.com/cabforum/servercert/pull/405/files<https://avanan.url-protection.com/v1/url?o=https%3A//github.com/cabforum/servercert/pull/405/files&g=NDcyZWU2N2E5OWZjOGJjYg==&h=YTc0NTlkMzM5MjhiMzhlMWJjODUxM2UzOWQxMjFhNjJlNjBkOTY1MGRmYWE2M2Y1ZjI4YTEwNGVkODJjNDM0MQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=> 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<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md%23611-end-entity-tls-certificate-crlrevocation-reasons&g=MTQ3ODlkM2UyMmJmNzIzMA==&h=ODM4N2M2YjI2NmUwODk2Nzg0NDdmM2E3ZTRlYWIyYTA0NGMyMzg0MTY4YzFlZTJhZjQxZjRhNzQ5YTBlM2ZlOQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=> 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<mailto: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<https://avanan.url-protection.com/v1/url?o=http%3A//4.9.1.1/2&g=YzQ3MWExY2I3Y2NmOGU3OA==&h=MzE0NDZlY2ViYWM5M2QwZmM4OTc3MWMxNmYxMmIwZDBjNGQyNDc5ODIzYWQ0ZmNmMWJhMWI2ZTdlNTRkN2MyYw==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=> 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<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

Here is the most current comparison:

https://github.com/cabforum/servercert/compare/bbca71465ed8a8a76383086039f52c750009286a..1699612e5157423f607d67cc8ab9dc3a1d52b318<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fcabforum%252Fservercert%252Fcompare%252Fbbca71465ed8a8a76383086039f52c750009286a..1699612e5157423f607d67cc8ab9dc3a1d52b318%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3D6U2qShXXY%252FWlUn2vWCqq0YB8yQAQxEiQXejzc6pCawE%253D%26amp%3Breserved%3D0&g=NWJiZDRlZTQzNjUyYjcxNw==&h=YzczZWZkYjFhMmNlMzVmNGY0ZDU2NTM2Yjc2OTEyMTk5Y2Q1MGNiY2FjZGIzMTY1MjlkZDM5OTdkYjQ2ZTY4NQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

Ben

On Mon, Sep 12, 2022 at 11:00 AM Ben Wilson <bwilson at mozilla.com<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fgithub.com%252FBenWilson-Mozilla%252Fservercert%252Fcommit%252F94a07d08855cf489a2bdddff7d8a9490969d5d06%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3Dh0d4CsixQeyG7GMzM2nqO3ScDRRM1EomVg%252BuwI3lBIc%253D%26amp%3Breserved%3D0&g=NGQ2YmM2MjMwZjc3OWU3Yg==&h=MTZjMTVhMzc2OGI0Nzg0ODhiODQ0OWE2NjUwZjJkZmU4NDBhYmUxOGY2MzFmMzRiMDQ0MTRkYWI3Y2EyMTU0Mg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

Ben

On Mon, Sep 12, 2022 at 9:51 AM Ben Wilson via Servercert-wg <servercert-wg at cabforum.org<mailto: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<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fgithub.com%252FBenWilson-Mozilla%252Fservercert%252Fcommit%252Fb185a28fcc20d5853747e4506103823e3dc7c282%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DopmFVkFFcOqc3DWpy%252BwP%252B79ihMxBOPnZE34AGDSKjWY%253D%26amp%3Breserved%3D0&g=MDc0NDIzN2Y1NjBkZDFjZg==&h=ZDk4NjE4NDY4ODJlYmVkNjBhZDQyMzc1NDc5NGE0YTQ4ZTI2YjBhODRmMTgwMDkyYWQ1YmZiZGI0NzNmMDFkYw==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

Ben

On Thu, Sep 8, 2022 at 12:05 PM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fwiki.debian.org%252FSSLkeys%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3D%252FV7HivQUf9v8s2xTxi1rVgVbg7XfH9TtU4RjlKL0T6c%253D%26amp%3Breserved%3D0&g=ZDI0ZTViMDdlYmYwM2ZiYQ==&h=NTgzMGI0ZjFiNzAxMWIzMGM0NDMxNDJlY2FkYmYxNmU2Y2QxMmI1ZTVjZDZjOGFlMjA0NmVjZjgzOTUzYWZjMg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>) (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<mailto: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<mailto: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://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fcabforum%252Fservercert%252Fissues%252F377%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DD4KPoI9FuCxKdr9yp378P8kEzjJq9wX%252FUEj%252F0SDufv4%253D%26amp%3Breserved%3D0&g=ODAyZjlhMDQ3Y2VkNTU3ZA==&h=YjAyMmVhMjQ1ZjI0MWQyNzg2MjYyZmFjZDY1ZTBhZTI1NjJkODFmZWFmYzEyY2MwNDRhY2UyMjllY2U5MTM4NQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

https://github.com/BenWilson-Mozilla/servercert/commit/52a480803beff1f96d61c4b6d76570ac7adff4d5<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Fgithub.com%252FBenWilson-Mozilla%252Fservercert%252Fcommit%252F52a480803beff1f96d61c4b6d76570ac7adff4d5%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DLOfjUsptzgpQxI1k6K8oUgU0aj2LDncd48ZzuXe86Hs%253D%26amp%3Breserved%3D0&g=NTdjYTFjNzRiMDhkMDQzZQ==&h=ZGQ0ZjkwMjFiOTMwMTk0NmEyZDU5ZjdiMTk4OGFjZjk2YjExMDAyN2U1MTdjYmVmZDEyNWFhNzI1YmYwMGI0Zg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

I'm looking for comments, suggestions, and two endorsers.

Thanks,

Ben
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.cabforum.org%252Fmailman%252Flistinfo%252Fservercert-wg%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3Diis%252B0QIl3jXlnwoZxV15jIUE%252FGB%252FtJyHdECcBBoSrcQ%253D%26amp%3Breserved%3D0&g=OGMwMTQxMDM5OWNmNzg3Ng==&h=YzM3YjllYjcwMzk5YTNmMDJlOTM1ZmMwNzVjNzg1OTZmYmZmNzUzY2Y2MGRjNDhiYzAxNTc1YzZmNmQ4Mzk4Mg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>


_______________________________________________

Servercert-wg mailing list

Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.cabforum.org%252Fmailman%252Flistinfo%252Fservercert-wg%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3Diis%252B0QIl3jXlnwoZxV15jIUE%252FGB%252FtJyHdECcBBoSrcQ%253D%26amp%3Breserved%3D0&g=ZmFjZDg5ZTgyNWNiZjBhNw==&h=Yjg1Y2RlZjExMGFjNTJiZDYwYjJiNDhjODI2NjNjZTcxYjM4ZGFiMGE5MmZjYWYzNGEyOWZmNGE4NWE1YjQ5Yg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.cabforum.org%252Fmailman%252Flistinfo%252Fservercert-wg%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3Diis%252B0QIl3jXlnwoZxV15jIUE%252FGB%252FtJyHdECcBBoSrcQ%253D%26amp%3Breserved%3D0&g=NDRmODliZmZkMjhiZTUyMg==&h=ZWE2OGFmYjFmZTlkNzZmYjI2ZWYyYjhlNDQ1NWYyYTdlMzY5M2YyMmVhNWEyOWUzZjk3Yjg3YjI1ZWU0ZDIyOA==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>



_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.cabforum.org%252Fmailman%252Flistinfo%252Fservercert-wg%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688809839%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3Diis%252B0QIl3jXlnwoZxV15jIUE%252FGB%252FtJyHdECcBBoSrcQ%253D%26amp%3Breserved%3D0&g=ZjcwZDMwMTA5NTM2ZDc0NQ==&h=ZmY5OTAxYTczNWExNjFiNjBjOTg0MzVhZGM5NWE1NjE2Y2IyNWQwYTRkZmMwNDkwMDFhMTRkMjY5ZTAwZjllZA==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//eur01.safelinks.protection.outlook.com/%3Furl%3Dhttps%253A%252F%252Flists.cabforum.org%252Fmailman%252Flistinfo%252Fservercert-wg%26amp%3Bdata%3D05%257C01%257Croman.fischer%2540swisssign.com%257Ce95c13967f6d4cffa0db08dac376a9d2%257C21322582607f404c82d950ddb1eca5c9%257C1%257C0%257C638037211688965625%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26amp%3Bsdata%3DrOfjT8%252B0oEL1XaQtLBTQ5EQOkSK3lJR0AbU1lVyZF68%253D%26amp%3Breserved%3D0&g=OGU2NjgzYTVkOTc0NGFiZA==&h=YzU1OGIxN2MzNjQxZmU0YTQ5ZmM1YzM4ZTBmYzc4NWU5MDg0M2RmZWFkNWQxYTExOTQ5OGFjMDQzZGM5MjVjYg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=MzVlZGJiMjRmZDAwNzFlMw==&h=ZjI2OGVjZTRlMjZkYThjZTRhMDk4M2JiMTI4YjMzMmQwODRmMDg4OWRjZTBkM2Q2MGVmZGQxZTgzNzE2NzdkZg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>


_______________________________________________

Servercert-wg mailing list

Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=MTRhN2I3OTA2ZGU2M2Q4Yw==&h=NjJmYTRjMzgzMWYwOGI2YzRlYjU1YTI2ZDhjM2I0ZDMxOGZkNTYxZjgxOTRjN2IzNTg3ZTdkOGM2ZTBiYTU3NQ==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/servercert-wg<https://avanan.url-protection.com/v1/url?o=https%3A//lists.cabforum.org/mailman/listinfo/servercert-wg&g=OWYyNDAwYjRkOGIwYTk3Ng==&h=Zjk4NTlkN2Q5MGMxNDk5NTI0Y2Q0YTE4NTcxZjQ3Yzg5YTU0YTI5MDA0NDgxZDk4ODVkZGE2ODA5ZGY2NGJjZg==&p=YXAzOmRpZ2ljZXJ0OmE6bzplMzA1NzFmNGVjYTM2N2I1ODcyYTM2M2ZjODdiOGM0ZTp2MTpoOkY=>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230109/fe4e1085/attachment-0001.html>


More information about the Servercert-wg mailing list