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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Sep 12 08:55:38 UTC 2022


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
>
> 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) (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://github.com/BenWilson-Mozilla/servercert/commit/52a480803beff1f96d61c4b6d76570ac7adff4d5
>>
>>                     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
>>
>>
>>
>>                 _______________________________________________
>>
>>                 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/20220912/5fdca419/attachment-0001.html>


More information about the Servercert-wg mailing list