On Fri, Jun 14, 2024 at 9:44 AM Wayne <[email protected]> wrote: > The CP and CPS mentioned in RFC 3647 at some point got flipped by some CAs > and are being used in the opposite interpretation than RFC 3647 states. > Originally one was the summary (CP), one was the details (CPS), and which > is which now depends on the CA. I don't think this divergence *should *matter > in reading each CA's documents in isolation, but it is interesting > historically and is an indication of how deeply CAs read the RFCs. >
I don't think I agree with the interpretation that a CP was a "summary" and a CPS was the "details" -- RFC 3647 clearly draws the line differently, saying that the CP is the *what*, while the CPS is the *how*. For example, a CP (like the BRs) might say "you MUST NOT sign using RSASSA-PKCS1-v1_5 with SHA-1", while a CPS might say "we sign only using sha256WithRSAEncryption". Again, the CP is supposed to be prescriptive, while the CPS is supposed to be descriptive. To be clear, a descriptive document can still place strictures on the CA whose behavior it describes: it's an incident for a CA to act in a way that their CPS does not describe. But I believe that a CPS should not contain RFC 2119-style MUST/SHOULD requirements; it should instead consist of "we do X" statements. This is the crux of why I believe that the "inconsistency" language doesn't make sense. To me, an inconsistency would be something like the BRs saying "MUST NOT issue for curves other than P256 and P384", while a CA's own CP says "MUST NOT issue for curves other than P244, P256, and P384". The CA's CP appears to allow something that would be inconsistent with the BRs, so instead the BRs take precedence and issuance for P521 is still forbidden. But if the BRs say "MUST NOT issue for curves other than P256 and P384", while a CA's CPS says "as part of issuance we ensure that the public key in the CSR is a valid point on the P244, P256, or P384 named curves", that's not an inconsistency -- that's saying that the CA actively engages in behavior which is in violation of the Baseline Requirements. That's an incident. On Fri, Jun 14, 2024 at 9:50 AM Mike Shaver <[email protected]> wrote: > If you’re referring to the CPS forbidding something that the BRs permit > but don’t require, then I don’t think there’s a conflict that needs an > override order to resolve. > To put it another way, I don't think a CPS can "forbid" something, though I certainly see why it can be useful to use that phrasing. I think that a CPS describes behavior, and behavior outside of that description is forbidden not by the CPS itself, but by the fact that a CPS is required to be accurate. Aaron -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEre7JSUh9dOPj_db1vNMsyCT%3DKw3smXKOh0rj7ovKe8xzA%40mail.gmail.com.
