Section 6.1.5 Algorithms - Update for Mozilla policy

[lachellel]

Topic in the listservs; applicable to this CP and #577

• P-256 with SHA-256, and P-384 with SHA-384
• I think @fotisl posted a nicely detailed incident report that explains the possibility for confusion between the BRs and Mozilla Policy:
  https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/fotis%7Csort:date/mozilla.dev.security.policy/6LSRx8kvvVI/5zDSaKIqCQAJ

For this CP:

• Section 6.1.5 Algorithms in CP v 0.4 here
• Does not align perfectly with Mozilla Policy v 2.6, Section 5.1 here

Suggestion to update the subscriber table to change the ECC; specify the curve / allowed hash.

In practice, we need to check the controls for the end entity / subscriber and ECDSA.

[lachellel]

@debcooley @dcooper16 @regenscheid

Do you have time to take a quick peek at this one? My current suggestion is:

• Update the Subscriber table in Section 6.1.5
• Remove P-512 entirely
• Change the ECC row to be explicit for the ECDSA curve-hash pairs allowed for Mozilla

[dcooper16]

If I understand this CP correctly, the proposed change is not correct. I think you just need to remove P-521, but not change anything else.

As I interpret Section 6.1.5, an end-entity certificate may have an ECC subject public key, but all CAs will have RSA keys. (This is also what the certificate profiles say.) So, the signature on the end-entity certificate will be an RSA signature, and the Mozilla policy allows the use of any (SHA-256, SHA-384, or SHA-512) hash algorithm when signing with RSA.

That does, however, highlight an inconsistency in the CP. While Section 6.1.5 says that all certificates are signed using RSA keys, it says that the root and subordinate CA certificates must be signed using SHA-256, but the end-entity certificate may be signed using SHA-256, SHA-384 or SHA-512. Was this intentional, or were SHA-384 and SHA-512 included because it was mistakenly believed that the signature might be created using an ECC P-384 or P-521 key?

I also just noticed that the certificate profile for server authentication certificates says that the signature algorithm must be sha256WithRSAEncryption, so Section 6.1.5 is not consistent with that.

[debcooley]

The CP is completely fine as written.

The Mozilla policies only apply to the Root CA and sub CA. Both specify RSA w/ SHA256 (no ECC is specified either in section 6.1.5 or the profiles).

The subscriber certs are not in the mix here. In fact a hash is not specified at all in a subscriber cert. As long as you are happy w/ the algorithm choices, there is no reason for a change. Note: NSA is disallowing P521/SHA 512 as an option for the part of the environment that we have purview over (there are various reasons for this), but NIST allows it, so leaving it in is probably correct.

The only other thing you could do here is to just delete the digest algorithm altogether from the subscriber certificate. The issue here is that the creation of the subscriber request (p10) does require that the subscriber hash his request and sign it with his proposed public key. So, it does make sense to leave it in.

Also note in the subscriber cert profile: the signature algorithms are those of the sub CA. So, those are actually correct. The subscriber does not sign its own certificate (except the request).

[lachellel]

Tough crowd

I removed P-521 as a curve.