On Thu, Nov 14, 2019 at 3:24 PM Wayne Thayer wrote:
> On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi wrote:
>
>>
>> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> A few more questions have come up about this change:
>>>
On Fri, Nov 8, 2019 at 12:06 PM Ryan Sleevi wrote:
>
> On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> A few more questions have come up about this change:
>>
>> * Since mozilla::pkix doesn't currently support the RSA-PSS
On Fri, Nov 8, 2019 at 1:54 PM Wayne Thayer via dev-security-policy <
dev-security-policy@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 w
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 i
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
On Fri, May
Brian Smith
Cc: Ryan Sleevi ; mozilla-dev-security-policy
; Wayne Thayer
Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash
Requirements
On Wed, May 22, 2019 at 7:43 PM Brian Smith wrote:
> Ryan Sleevi wrote:
>
>>
>>
>>> It would be easier to
On Wed, May 22, 2019 at 7:43 PM Brian Smith wrote:
> Ryan Sleevi 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,
Ryan Sleevi 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 enco
> 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
zilla-dev-security-policy
security-pol...@lists.mozilla.org>; Wayne Thayer
> Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash
> Requirements
>
> On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote:
>
> > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer
wro
On Tue, May 21, 2019 at 3:32 PM Daniel McCarney 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 ar
>
>
> 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 opportuni
On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote:
> On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote:
>
>> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>>
>>> Thank you David and Ryan! This appears to me to be a reasonable
>>> improvement to our policy.
>>>
>>
>> Brian: could I ask yo
On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote:
> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi 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
On Fri, Apr 26, 2019 at 5:39 PM Wayne Thayer 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.
>>
On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote:
>
> On Mon, Apr 22, 2019 at 6:20 PM Brian Smith 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 wa
On Mon, Apr 22, 2019 at 6:20 PM Brian Smith 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 certificat
Wayne Thayer wrote:
> Brian Smith 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
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
On Thu, Apr 4, 2019 at 1:50 PM Brian Smith 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
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 Prac
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 subjectP
22 matches
Mail list logo
