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

[Ben Wilson]

Looks good to me. I'll work on it.
Thanks,
Ben

On Thu, Sep 8, 2022 at 1:21 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> 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://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 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/20220908/b266666c/attachment.html>