[Servercert-wg] Proposal to Incorporate Mozilla's CRL Revocation Reason Code Requirements into the BRs
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Sep 14 05:27:07 UTC 2022
Ben, these changes look good.
Is there anything we can do for:
> /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 (CRLReason #4,
> superseded [or CRLReason #9, privilegeWithdrawn])./
I believe we should stick with "privilegeWithdrawn" for this case
regardless if the certificate has been replaced or not. It's best to
have one option rather than two.
For the "superseded" cases:
> /1. The Certificate no longer complies with the requirements of
> [Section 6.1.5](#615-key-sizes) and [Section
> 6.1.6](#616-public-key-parameters-generation-and-quality-checking)
> (CRLReason #4, superseded);/
> /7. The CA is made aware that the Certificate was not issued in
> accordance with these Requirements or the CA's Certificate Policy or
> Certification Practice Statement (CRLReason #4, superseded);/
> /10. Revocation is required by the CA's Certificate Policy and/or
> Certification Practice Statement (CRLReason #4, superseded); or/
what exactly is the rationale for this CRLReason? Is it that these
certificates will *necessarily *be replaced by compliant ones, that
"supersede" (i.e. replace) the old ones? What if the CA decides not to
replace certificates under these revocation cases?
Once we clarify these few areas, I'd be happy to endorse this ballot.
Thanks,
Dimitris.
On 14/9/2022 6:37 π.μ., Ben Wilson wrote:
> Here is the most current comparison:
>
> https://github.com/cabforum/servercert/compare/bbca71465ed8a8a76383086039f52c750009286a..1699612e5157423f607d67cc8ab9dc3a1d52b318
>
> 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
>
> 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
>>
>> 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
>>>
>>
>
> _______________________________________________
> 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/20220914/99766585/attachment-0001.html>
More information about the Servercert-wg
mailing list