Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements

[Wayne Thayer]

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:


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

[Ryan Sleevi]

Thanks for raising this, Wayne.

As mentioned on the issue, this heavily overlaps with the RSA combinations
- and, of course, Mozilla policy being more strict than the BRs in
forbidding DSA.

Given that CAs have struggled with the relevant encodings, both for the
signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if you’d
be open to instead enumerating the allowed (canonical) encodings for both.
This would address open Mozilla Problematic Practices as well - namely, the
encoding of NULL parameters with respect to certain signature algorithms.

[Brian Smith]

Ryan Sleevi wrote:

> Given that CAs have struggled with the relevant encodings, both for the
> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if you’d
> be open to instead enumerating the allowed (canonical) encodings for both.
> This would address open Mozilla Problematic Practices as well - namely, the
> encoding of NULL parameters with respect to certain signature algorithms.
>

I agree with Ryan. It would be much better to list more precisely what
algorithm combinations are allowed, and how exactly they should be encoded.
>From my experience in implementing webpki [1], knowing the exact allowed
encodings makes it much easier to write software that deals with
certificates and also makes it easier to validate that certificates conform
to the requirements.

These kinds of details are things that CAs need to delegate to their
technical staff for enforcement, and IMO it would make more sense to ask a
programmer in this space to draft the requirements, and then have other
programmers verify the requirements are accurate. In particular, it is
hugely inefficient for non-programmers to try to attempt to draft these
technical requirements and then ask programmers and others to check them
because it's unreasonable to expect people who are not programmers to be
able to see which details are important and which aren't.

You can find all the encodings of the algorithm identifiers at [2].

[1] https://github.com/briansmith/webpki
[2] https://github.com/briansmith/webpki/tree/master/src/data

Cheers,
Brian
--
https://briansmith.org/

[Wayne Thayer]

On Thu, Apr 4, 2019 at 1:50 PM Brian Smith <br...@briansmith.org> wrote:

> Ryan Sleevi wrote:
>
>> Given that CAs have struggled with the relevant encodings, both for the
>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if
>> you’d
>> be open to instead enumerating the allowed (canonical) encodings for both.
>> This would address open Mozilla Problematic Practices as well - namely,
>> the
>> encoding of NULL parameters with respect to certain signature algorithms.
>>
>
>

I would be happy with that approach if it makes our requirements clearer -
I'm just not convinced that doing so will eliminate the confusion I
attempted to describe.

I agree with Ryan. It would be much better to list more precisely what
> algorithm combinations are allowed, and how exactly they should be encoded.
> From my experience in implementing webpki [1], knowing the exact allowed
> encodings makes it much easier to write software that deals with
> certificates and also makes it easier to validate that certificates conform
> to the requirements.
>
> These kinds of details are things that CAs need to delegate to their
> technical staff for enforcement, and IMO it would make more sense to ask a
> programmer in this space to draft the requirements, and then have other
> programmers verify the requirements are accurate. In particular, it is
> hugely inefficient for non-programmers to try to attempt to draft these
> technical requirements and then ask programmers and others to check them
> because it's unreasonable to expect people who are not programmers to be
> able to see which details are important and which aren't.
>
>

Agreed - is someone willing to take on this task?

[Jakob Bohm]

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

[Brian Smith]

Wayne Thayer <wth...@mozilla.com> wrote:

> Brian Smith <br...@briansmith.org> wrote:
>
>> Ryan Sleevi wrote:
>>
>>> Given that CAs have struggled with the relevant encodings, both for the
>>> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if
>>> you’d
>>> be open to instead enumerating the allowed (canonical) encodings for
>>> both.
>>> This would address open Mozilla Problematic Practices as well - namely,
>>> the
>>> encoding of NULL parameters with respect to certain signature algorithms.
>>>
>>
>>
> I would be happy with that approach if it makes our requirements clearer -
> I'm just not convinced that doing so will eliminate the confusion I
> attempted to describe.
>

There are three (that I can think of) sources of confusion:

1. Is there any requirement that the signature algorithm that is used to
sign a certificate be correlated in any way to the algorithm of the public
key of the signed certificate? AFAICT, the answer is "no."

2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA),
Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256,
SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely*
right in natural language, but easy to get right with a list of encodings.

3. Given a particular combination of algorithm, curve, and digest
algorithm, which encodings of that information are acceptable? For example,
when a a NULL parameter required and when is it optional. Again, this is
hard to get right in natural language, and again, listing the encodings
makes this trivial to get exactly right.

Agreed - is someone willing to take on this task?
>

I could transform what I did with webpki into some text.

However, first I think it would be useful if somebody could check that the
encodings that webpki expects actually match what certificates in
Certificate Transparency are doing. For example, does every CA already
encode a NULL parameter when one is required by RFC 4055 (which is included
by reference from RFC 5280)? Are there any algorithm combinations in use
that aren't in webpki's list? This is something I don't have time to
thoroughly check.

Thanks,
Brian

[Ryan Sleevi]

On Mon, Apr 22, 2019 at 6:20 PM Brian Smith <br...@briansmith.org> wrote:

> There are three (that I can think of) sources of confusion:
>
> 1. Is there any requirement that the signature algorithm that is used to
> sign a certificate be correlated in any way to the algorithm of the public
> key of the signed certificate? AFAICT, the answer is "no."
>
> 2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA),
> Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256,
> SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely*
> right in natural language, but easy to get right with a list of encodings.
>
> 3. Given a particular combination of algorithm, curve, and digest
> algorithm, which encodings of that information are acceptable? For example,
> when a a NULL parameter required and when is it optional. Again, this is
> hard to get right in natural language, and again, listing the encodings
> makes this trivial to get exactly right.
>
> Agreed - is someone willing to take on this task?
>>
>
> I could transform what I did with webpki into some text.
>
> However, first I think it would be useful if somebody could check that the
> encodings that webpki expects actually match what certificates in
> Certificate Transparency are doing. For example, does every CA already
> encode a NULL parameter when one is required by RFC 4055 (which is included
> by reference from RFC 5280)? Are there any algorithm combinations in use
> that aren't in webpki's list? This is something I don't have time to
> thoroughly check.
>

I agree with Brian here, unsurprisingly. Luckily, my colleague, David
Benjamin, had some time to do just what Brian proposes.

The following pull request - https://github.com/mozilla/pkipolicy/pull/183 -
demonstrates an attempt to resolve those three questions highlighted by
Brian.

This does not, however, address the last part of what Brian proposes -
which is examining if, how many, and which CAs would fail to meet these
encoding requirements today, either in their roots, subordinates, or leaf
certificates.

While this includes RSA-PSS, it's worth noting that mozilla::pkix does not
support these certificates, and also worth noting that the current encoding
scheme is substantially more verbose than desirable.

[Wayne Thayer]

Thank you David and Ryan! This appears to me to be a reasonable improvement
to our policy.

Brian: could I ask you to review the proposed change?

> This does not, however, address the last part of what Brian proposes -
> which is examining if, how many, and which CAs would fail to meet these
> encoding requirements today, either in their roots, subordinates, or leaf
> certificates.
>
>

While I agree that this would be useful information, for the purpose of
moving ahead with this policy change would it instead be reasonable to set
an effective date and require certificates issued (notBefore) after that
date to comply, putting the burden on CAs to verify their implementations
rather than relying on someone else to do that work?

[Ryan Sleevi]

On Fri, Apr 26, 2019 at 5:39 PM Wayne Thayer <wth...@mozilla.com> wrote:

> This does not, however, address the last part of what Brian proposes -
>> which is examining if, how many, and which CAs would fail to meet these
>> encoding requirements today, either in their roots, subordinates, or leaf
>> certificates.
>>
>>
> While I agree that this would be useful information, for the purpose of
> moving ahead with this policy change would it instead be reasonable to set
> an effective date and require certificates issued (notBefore) after that
> date to comply, putting the burden on CAs to verify their implementations
> rather than relying on someone else to do that work?
>

To the extent a phase-in approach is valuable, I think such a phase-in
would require that the *chains* of certificates issued after that date must
comply.

The concern is that if there are existing issuing intermediates that do not
comply, putting a phase-in date for leaf certificates doesn't resolve any
of the ambiguities or issues this proposal seeks to resolve, nor does it
address the security issues that are mitigated by it. However, as CAs can
always construct new issuing intermediates that do comply with this policy,
that's more preferable.

To be explicit here: It's not requiring that CAs would revoke their
existing intermediates. Rather, that by some particular phase in date, they
must have constructed new issuing intermediates (or, more generally, a new
issuing hierarchy) that does comply - shifting issuing new certificates
onto the new hierarchy, while no longer issuing certificates from the old
hierarchy and letting the existing certificates naturally age out.

However, I'd be curious if this is even needed - perhaps its something that
can be revisited closer to finalizing policy, if it turns out there's no
publicly detectable technical need.

[Brian Smith]

On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer <wth...@mozilla.com> wrote:

> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi <ry...@sleevi.com> wrote:
>
>> Thank you David and Ryan! This appears to me to be a reasonable
>> improvement to our policy.
>>
>
> Brian: could I ask you to review the proposed change?
>
>

>> This does not, however, address the last part of what Brian proposes -
>> which is examining if, how many, and which CAs would fail to meet these
>> encoding requirements today, either in their roots, subordinates, or leaf
>> certificates.
>>
>>
> While I agree that this would be useful information, for the purpose of
> moving ahead with this policy change would it instead be reasonable to set
> an effective date and require certificates issued (notBefore) after that
> date to comply, putting the burden on CAs to verify their implementations
> rather than relying on someone else to do that work?
>

My understanding here is that the proposed text is not imposing a new
requirement, but more explicitly stating a requirement that is already
imposed by the BRs. AFAICT BRs require syntactically valid X.509
certificates, RFC 5280 defines what's syntactically valid, RFC 5280 defers
to other documents about what is allowed for each algorithm identifier, and
this is an attempt to collect all those requirements into one spot for
convenience.

It would be easier to understand if this is true if the proposed text cited
the RFCs, like RFC 4055, that actually impose the requirements that result
in the given encodings.

>
> While this includes RSA-PSS, it's worth noting that mozilla::pkix does not
>> support these certificates, and also worth noting that the current encoding
>> scheme is substantially more verbose than desirable.
>>
>

I agree the encoding is unfortunate. But, also, there's no real prospect of
a shorter encoding being standardized and implemented in a realistic time
frame.

[Ryan Sleevi]

On Thu, May 9, 2019 at 4:48 PM Brian Smith <br...@briansmith.org> wrote:

> On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer <wth...@mozilla.com> wrote:
>
>> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi <ry...@sleevi.com> wrote:
>>
>>> Thank you David and Ryan! This appears to me to be a reasonable
>>> improvement to our policy.
>>>
>>
>> Brian: could I ask you to review the proposed change?
>>
>>
>>> This does not, however, address the last part of what Brian proposes -
>>> which is examining if, how many, and which CAs would fail to meet these
>>> encoding requirements today, either in their roots, subordinates, or leaf
>>> certificates.
>>>
>>>
>> While I agree that this would be useful information, for the purpose of
>> moving ahead with this policy change would it instead be reasonable to set
>> an effective date and require certificates issued (notBefore) after that
>> date to comply, putting the burden on CAs to verify their implementations
>> rather than relying on someone else to do that work?
>>
>
> My understanding here is that the proposed text is not imposing a new
> requirement, but more explicitly stating a requirement that is already
> imposed by the BRs. AFAICT BRs require syntactically valid X.509
> certificates, RFC 5280 defines what's syntactically valid, RFC 5280 defers
> to other documents about what is allowed for each algorithm identifier, and
> this is an attempt to collect all those requirements into one spot for
> convenience.
>

I unintentionally let this drop off my radar.

I did some light analysis, based on analyzing simply the bytes of the cert
(i.e. without structural parsing), simply looking at whether or not one of
the prescribed sequences appears, first for SPKIs, then for signatures.

For SPKIs, I only found a total of 9 unexpired certs, so I've just
reproduced them here:
-
https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f23f7af38b
-
https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db61571bc0fd98b
-
https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d528ea0c690
-
https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee43d5eec11
-
https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d063ad56c7
-
https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c07948d9d5c
-
https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d37b884dbb
-
https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0fba0728c
- (Revoked)
https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437094f0e13

Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
are all RSA keys that lack the explicit NULL parameter, and thus violate
the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1

These are flagged by cablint (but not zlint), so that is an opportunity for
CAs to improve things - both in how they encode and how they lint.

I haven't (yet) gone through the Signature encodings, but that should
hopefully address the SPKI concerns. Of course, I may have botched things
rather significantly in my queries, but at least sharing my data provides a
way for people to prove that :)

>
> It would be easier to understand if this is true if the proposed text
> cited the RFCs, like RFC 4055, that actually impose the requirements that
> result in the given encodings.
>

Could you clarify, do you just mean adding references to each of the
example encodings (such as the above example, for the SPKI encoding)?

[Daniel McCarney]

>
>
> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
> are all RSA keys that lack the explicit NULL parameter, and thus violate
> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1


> These are flagged by cablint (but not zlint), so that is an opportunity for
> CAs to improve things - both in how they encode and how they lint.

Ryan: Thanks for flagging this difference between cablint and zlint.

Let's Encrypt uses zlint and so I took some time today to submit a PR to
address this missing lint finding: https://github.com/zmap/zlint/pull/285 Extra
eyes on that would be most welcome.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

On Tue, May 21, 2019 at 3:32 PM Daniel McCarney <c...@letsencrypt.org> wrote:

>
>> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
>> are all RSA keys that lack the explicit NULL parameter, and thus violate
>> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1
>
>
>> These are flagged by cablint (but not zlint), so that is an opportunity
>> for
>> CAs to improve things - both in how they encode and how they lint.
>
>
> Ryan: Thanks for flagging this difference between cablint and zlint.
>
> Let's Encrypt uses zlint and so I took some time today to submit a PR to
> address this missing lint finding: https://github.com/zmap/zlint/pull/285 Extra
> eyes on that would be most welcome.
>

Thanks. I left some comments, and also spent some time digging into the
signature algorithm encodings.

Using an algorithm that undercounts (meaning if they got it right in the
SPKI, but botched it in the signature, or vice-versa, I'm not counting it),
I still only found 415 certificates. I sampled around 40 of these, and they
were all revoked, and all fell into the class of RSA omitting the NULL.

Note that this is applicable for signatureAlgorithms as well (and the same
section of the RFC), and this is again something cablint picks up and zlint
misses. However, it seems CAs happened to already have revoked these
certificates - perhaps from internal linting efforts that looked at all
their certificates, or crt.sh, or some other bit. It's also not too
surprising, given that this is the logic that mozilla::pkix implements
directly in its implementation.

So I'm fairly confident that the increased expression in policy does not
harm things, makes it easier to implement safe linters. Not to pick on
Daniel, but it looks like the PR made for zlint missed some edge corner
cases - perfectly understandable, in context, but exactly why/where the
direct comparison makes it easier :)

[Arvid Vermote]

GlobalSign has revoked the respective certificates and is investigating root
cause. Thanks.

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: dinsdag 21 mei 2019 6:06
> To: Brian Smith <br...@briansmith.org>
> Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-security-policy
<mozilla-dev-
> securit...@lists.mozilla.org>; Wayne Thayer <wth...@mozilla.com>
> Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash
> Requirements

> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
are all
> RSA keys that lack the explicit NULL parameter, and thus violate the
requirements
> of https://tools.ietf.org/html/rfc3279#section-2.3.1
>
> These are flagged by cablint (but not zlint), so that is an opportunity
for CAs to
> improve things - both in how they encode and how they lint.
>

[Daniel McCarney]

> Note that this is applicable for signatureAlgorithms as well (and the same
> section of the RFC), and this is again something cablint picks up and zlint
> misses. However, it seems CAs happened to already have revoked these
> certificates - perhaps from internal linting efforts that looked at all
> their certificates, or crt.sh, or some other bit. It's also not too
> surprising, given that this is the logic that mozilla::pkix implements
> directly in its implementation.

I'd love to see another CA with greater development resources volunteer the
time to implement the signatureAlgorithms coverage for zlint. I suspect
there are a number of CAs using zlint that aren't represented in the
repository contributor graph.

So I'm fairly confident that the increased expression in policy does not
> harm things, makes it easier to implement safe linters. Not to pick on
> Daniel, but it looks like the PR made for zlint missed some edge corner
> cases - perfectly understandable, in context, but exactly why/where the
> direct comparison makes it easier :)

:-) I should have known better than to think anything related to ASN.1
could be a quick PR. I'll work on integrating your feedback. Thanks again
for taking the time to review it.

On Wed, May 22, 2019 at 12:25 AM Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Tue, May 21, 2019 at 3:32 PM Daniel McCarney <c...@letsencrypt.org>
> wrote:
>
>>

>>> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and
>>> are all RSA keys that lack the explicit NULL parameter, and thus violate
>>> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1
>>
>>
>>> These are flagged by cablint (but not zlint), so that is an opportunity
>>> for
>>> CAs to improve things - both in how they encode and how they lint.
>>
>>

[Brian Smith]

Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
>> It would be easier to understand if this is true if the proposed text
>> cited the RFCs, like RFC 4055, that actually impose the requirements that
>> result in the given encodings.
>>
>
> Could you clarify, do you just mean adding references to each of the
> example encodings (such as the above example, for the SPKI encoding)?
>

Exactly. That way, it is clear that the given encodings are not imposing a
new requirement, and it would be clear which standard is being used to
determine to correct encoding.

I realize that determining the encoding from each of these cited specs
would require understanding more specifications, including in particular
how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
calling out all of these details individually less people get confused by
inevitable omissions.

[Ryan Sleevi]

On Wed, May 22, 2019 at 7:43 PM Brian Smith <br...@briansmith.org> wrote:

> Ryan Sleevi <ry...@sleevi.com> wrote:
>
>>
>>
>>> It would be easier to understand if this is true if the proposed text
>>> cited the RFCs, like RFC 4055, that actually impose the requirements that
>>> result in the given encodings.
>>>
>>
>> Could you clarify, do you just mean adding references to each of the
>> example encodings (such as the above example, for the SPKI encoding)?
>>
>
> Exactly. That way, it is clear that the given encodings are not imposing a
> new requirement, and it would be clear which standard is being used to
> determine to correct encoding.
>

Thanks, did that in
https://github.com/sleevi/pkipolicy/commit/80da8acded63618a058d26c73db1e2438a6df9ed

>
> I realize that determining the encoding from each of these cited specs
> would require understanding more specifications, including in particular
> how ASN.1 DER requires DEFAULT values to be encoded. I would advise against
> calling out all of these details individually less people get confused by
> inevitable omissions.
>

Hopefully struck the right balance. These changes are now reflected in the
PR at https://github.com/mozilla/pkipolicy/pull/183

[Doug Beattie]

Wayne recommended that we open up a Mozilla incident ticket to track the 8
GlobalSign certificates of that do not contain the required null a parameter

and thus violate the requirements of

https://tools.ietf.org/html/rfc3279#section-2.3.1.

https://bugzilla.mozilla.org/show_bug.cgi?id=1554259

Hopefully the other CAs will also open up tickets and provide their analysis
of how this happened so we can all learn how to avoid problems like this in
the future.

Initial analysis is that we accept the CSR and pass along the parameter (or
not) and that this specific field is not flagged during the validation
process, nor "fixed" by EJBCA when the certificate is issued. We're
currently looking at our options for solving this.

Doug

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, May 24, 2019 4:39 AM
To: Brian Smith <br...@briansmith.org>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>; Wayne Thayer
<wth...@mozilla.com>
Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash
Requirements

[Wayne Thayer]

Thank you Ryan. Brian reviewed these changes back in May, so I've gone
ahead and accepted them for the 2.7 policy update:
https://github.com/mozilla/pkipolicy/commit/5657ecf650d70fd3c6ca5062bee360fd83da9d27

I'll consider this issue resolved unless there are further comments.

- Wayne

[Wayne Thayer]

A few more questions have come up about this change:

* Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
would we include them in our policy?
* Related: would this detailed enumeration of requirements be better to
place in the BRs than in Mozilla policy?
* In that case it wouldn't cover S/MIME certs
* We'd still need to exclude P-521 in Mozilla policy
* It would end up in audit criteria and perhaps engineers implementing
it would be more likely to be aware of it
* Presumably the RSA-PSS encoding would be included in the BRs and
would then potentially need to be excluded from Mozilla policy

As always, I'll appreciate everyone's input on these questions.

- Wayne

[Ryan Sleevi]

On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> A few more questions have come up about this change:
>
> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
> would we include them in our policy?
>

They were included for completeness sake, as neither Mozilla Policy nor the
BRs presently forbid them.

I'm much in favor of not permitting them, but since the current restriction
on RSA keys does not restrict the signature algorithms used, we wanted to
make sure the combinations were suitable.

> * Related: would this detailed enumeration of requirements be better to
> place in the BRs than in Mozilla policy?
> * In that case it wouldn't cover S/MIME certs
> * We'd still need to exclude P-521 in Mozilla policy
> * It would end up in audit criteria and perhaps engineers implementing
> it would be more likely to be aware of it
> * Presumably the RSA-PSS encoding would be included in the BRs and
> would then potentially need to be excluded from Mozilla policy
>

I think the benefits are overstated relative the return and risk.

It should be deeply concerning if the BRs were to somehow be seen as taking
precedence over Mozilla Policy, or that CAs would ignore Mozilla Policy and
only pay attention to the BRs. To accept this argument is to suggest
Mozilla Policy is perhaps a less-valuable instrument for communicating
policy, at which point, the need for Mozilla Policy may be suspect.

While that likely sounds extreme, it carries to the logical conclusion the
same concerns we've seen with other elements of Mozilla Policy, such as
requirements on Intermediates, which were communicated for years, or in the
discussions of EKUs. That said, there are already in-progress efforts to
add these to the respective linting tools, which ostensibly brings greater
visibility than either audits or the BRs.

There's also an element which is that these specifications are themselves
already covered by the applicable standards (as previously shared). That
is, they are already an intrinsic part of the BRs, and it's precisely
because we know that people are not paying attention that the vehicle of
root policy becomes useful to *emphasize* and *clarify* the expectations.

This does seem an excellent candidate to add to Root Policy - in line with
existing and long-standing implementation and expectations - and then
potentially fold in as part of a browser root policy alignment effort.

[Wayne Thayer]

On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi <ry...@sleevi.com> wrote:

>
> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> A few more questions have come up about this change:
>>
>> * Since mozilla::pkix doesn't currently support the RSA-PSS encodings, why
>> would we include them in our policy?
>>
>
> They were included for completeness sake, as neither Mozilla Policy nor
> the BRs presently forbid them.
>
> I'm much in favor of not permitting them, but since the current
> restriction on RSA keys does not restrict the signature algorithms used, we
> wanted to make sure the combinations were suitable.
>
>

I understand the point that including the RSA-PSS encodings does not change
the literal meaning of the current policy, but it does imply that Mozilla
supports these encodings when in fact NSS does not. We could resolve this
by removing the RSA-PSS encodings or by adding a note stating that Firefox
doesn't currently support them. I prefer adding the note, since Firefox
could add support [1] for RSA-PSS much more quickly that this policy is
typically updated. I propose the following:

Note: as of version 70, RSASSA-PSS encodings are not supported by Firefox.
(with a link to [1])

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1088140

[Wayne Thayer]

I've gone ahead and made this change in the 2.7 branch of the policy:
https://github.com/mozilla/pkipolicy/commit/320d3a47c655c5b49f6465d9446ceea85be96d4b