search

cabforum / servercert

Repository for the CA/Browser Forum Server Certificate Chartered Working Group
https://cabforum.org/working-groups/scwg/
161 stars 104 forks source link

Update to description of certificateHold #506

Open dougbeattie opened 6 months ago

dougbeattie commented 6 months ago

This section of the BRs: https://github.com/cabforum/servercert/blob/a0efd83d3818fe5c3df23bf4b32483cc4e6f133c/docs/BR.md#721-version-numbers

says this about the certificateHold reason code:

Regarding this statement:
“2) a Certificate not subject to these Requirements”,
Since "these Requirements” means the BRs, how is it that the BRs can place requirements on non TLS certificates? Maybe this was an old requirement related to ICAs that issued both TLS and non-TLS certificates and the ICA was governed by the BRs, but I don't believe this is a concern anymore.

We recommend removing #2. It’s not urgent so maybe we do this in the next clean-up.

timfromdigicert commented 6 months ago

My first guess is that a CRL subject to these requirements might include certificates that themselves are not.

It’s easy to think of S/MIME examples where this would be the case, but thinking up server examples is harder since e.g. a client-only cert is no longer allowed.

-Tim

From: Doug Beattie @.> Sent: Thursday, April 25, 2024 1:26 PM To: cabforum/servercert @.> Cc: Subscribed @.***> Subject: [cabforum/servercert] Update to description of certificateHold (Issue #506)

This section of the BRs: https://github.com/cabforum/servercert/blob/a0efd83d3818fe5c3df23bf4b32483cc4e6f133c/docs/BR.md#721-version-numbers

says this about the certificateHold reason code:

Regarding this statement: “2) a Certificate not subject to these Requirements”, Since "these Requirements” means the BRs, how is it that the BRs can place requirements on non TLS certificates? Maybe this was an old requirement related to ICAs that issued both TLS and non-TLS certificates and the ICA was governed by the BRs, but I don't believe this is a concern anymore.

We recommend removing #2 https://github.com/cabforum/servercert/pull/2 . It’s not urgent so maybe we do this in the next clean-up.

— Reply to this email directly, view it on GitHub https://github.com/cabforum/servercert/issues/506 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFREHHWDZ47BZAVVYZ6U4LY7E4AZAVCNFSM6AAAAABGZJ34LKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DIMJRG4ZDMMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

clintwilson commented 6 months ago

Yeah I don't think this should be removed. It shouldn't do any harm because it's not actually opining on anything not subject to the TBRs. As I understand it, this is saying that a CA certificate which is subject to the TBRs can't use certificateHold for any certificates it issues, regardless of whether that certificate is itself subject to the TBRs. It's only a potential issue for multi-purpose Root CAs, afaict, and even then shouldn't really be something encountered with all the other requirements imposed on separating certificate purposes.

That's not to say a change here couldn't be helpful. Given the amount of time that's passed since the bifurcation date in the current language, we could just update this to say MUST NOT be included if it's well understood that this would still apply to any potential (though unlikely) non-TBR certificates issued by a TBR CA.

dougbeattie commented 6 months ago

That's fine, then a minor update the next time we're doing "spring cleaning" to say exactly that would help anyone looking at this in the future.

On Thu, Apr 25, 2024 at 1:45 PM Clint Wilson @.***> wrote:

Yeah I don't think this should be removed. It shouldn't do any harm because it's not actually opining on anything not subject to the TBRs. As I understand it, this is saying that a CA certificate which is subject to the TBRs can't use certificateHold for any certificates it issues, regardless of whether that certificate is itself subject to the TBRs. It's only a potential issue for multi-purpose Root CAs, afaict, and even then shouldn't really be something encountered with all the other requirements imposed on separating certificate purposes.

That's not to say a change here couldn't be helpful. Given the amount of time that's passed since the bifurcation date in the current language, we could just update this to say MUST NOT be included if it's well understood that this would still apply to any potential (though unlikely) non-TBR certificates issued by a TBR CA.

— Reply to this email directly, view it on GitHub https://github.com/cabforum/servercert/issues/506#issuecomment-2077826185, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFJQ67OOFVSQSRFIIB5NU3Y7E6KZAVCNFSM6AAAAABGZJ34LKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXHAZDMMJYGU . You are receiving this because you authored the thread.Message ID: @.***>

timfromdigicert commented 6 months ago

Yeah, "(1) X or (2) not X and either (A) or (B)" is not the most unambiguous way to write a requirement. I'm assuming the grouping is supposed to be: "(1) X or { (2) not X and either (A) or (B) }"

Since it's well past 2020, we can probably just clarify it to be "MUST not be included regardless of whether the referenced certificate is subject to these BRs or not".

robstradling commented 6 months ago

if it's well understood that this would still apply to any potential (though unlikely) non-TBR certificates issued by a TBR CA.

FWIW, at least one CA Owner seems to be currently using a TBR CA to issue a mixture of TBR and non-TBR leaf certificates. When reviewing a recent incident bug on Bugzilla we noticed that the CRL for https://crt.sh/?caid=5654 (CN=ACCVCA-120) was far, far larger than could be explained by the population of TBR certs known to crt.sh. We found https://www.accv.es/quienes-somos/politicas/, which seems to indicate that this Subordinate CA issues a wide variety of TBR and non-TBR certificate types.