On 04/04/2019 02:22, Wayne Thayer wrote:
A number of ECC certificates that fail to meet the requirements of policy
section 5.1 were recently reported [1]. There was a lack of awareness that
Mozilla policy is more strict than the BRs in this regard. I've attempted
to address that by adding this to the list of "known places where this
policy takes precedence over the Baseline Requirements" in section 2.3 [2].
This proposal is to clarify the 'ECDSA' language in section 5.1. That
language was introduced in version 2.4 of our policy [3]. The description
of this issue on GitHub [4] states "Section 5.1's language seems ambiguous
because it doesn't clarify whether the allowed curve-hash pair is related
to the CA key or the Subject Key." For example, does the policy permit a
P-384 key in an intermediate CA certificate to sign a P-256 key in an
end-entity certificate with SHA-256, SHA-384, or not at all? My limited
understanding of the intent is that the key and signature algorithm in each
certificate must match - e.g. it permits a P-384 key in an intermediate CA
certificate to sign a P-256 key in an end-entity certificate with SHA-256 -
but I could be wrong about that and would appreciate everyone's input on
what this is supposed to mean.
If my understanding of the desired policy is correct, then I propose the
following clarification:
This is cryptographically wrong and insecure.
The common requirement for all DSA-style algorithms is that each
private key is used with exactly one hash algorithm, of a size
matching the (sub)group used. No other hash algorithm shall be
signed for the lifetime of the private key, even if that is not
expressed in the X.509 data structure. This technical security
requirement applies for the lifetime of the private key.
Thus the permissible combinations under the current Mozilla policy
should be:
P-256 signing using SHA-256
P-384 signing using SHA-384
While the BRs also allow:
P-512 signing using SHA-512
In all 3 cases, the signed certificate could use any permitted
public key algorithm, EKU, name etc. subject to the general
policy restrictions on those fields. For example a P-384+SHA-384
CA key can sign an P-256+SHA-256 cert. Signing a stronger cert at
the next level is less useful, except to cross sign new roots with
old roots.
This is of cause completely different for RSA, because PKCS#1 RSA
incorporates the hash identifier into the signature in such a way that a
signature on one hash isn't also a valid signature on a completely
different hash that happens to have the same bit pattern.
Root certificates in our root program, and any certificate which
chains up to them, MUST use only algorithms and key sizes from the following
set:
[...]
- ECDSA keys using one of the following curve-hash pairs:
- P‐256 signed with SHA-256
- P‐384 signed with SHA-384
The only change is the addition of the word "signed" to signify that the
pairing represents the combination of the key and signature in a given
certificate.
An enumeration of the permitted combinations has also been suggested, but
it's not clear to me how that solves the confusion that currently exists.
It would be great if someone who prefers this approach would make a
proposal.
This is https://github.com/mozilla/pkipolicy/issues/170
I will greatly appreciate everyone's input on both the intent of the
current policy, and how best to clarify it.
- Wayne
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/mCKvUmYUMb0/sqZVnFvKBwAJ
[2]
https://github.com/mozilla/pkipolicy/commit/3e38142acd28b152eca263e7528fac940efb20e2
[3] https://github.com/mozilla/pkipolicy/issues/5
[4] https://github.com/mozilla/pkipolicy/issues/170
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
