On 07/02/17 18:23, Ryan Sleevi wrote:
> For something technical, would you prefer an onlist wording suggestion or
> as an on-github submission/pull request?
Happy with either, as long as the PR includes any relevant additional
text from my recently-posted proposal here.
Gerv
_
On Tue, Feb 7, 2017 at 9:45 AM, Gervase Markham wrote:
> >> 4) Do we want to do the spec using AlgorithmIdentifiers instead of free
> >> text?
>
> If someone wants it phrased this way, I need draft text. Otherwise it'll
> be staying the way it is :-)
>
For something technical, would you prefer a
On 24/01/17 21:34, Jeremy Rowley wrote:
> Why not just make the changes at the CAB Forum? That's the purpose of the
> CAB Forum afterall - to discuss these policies. Seems like it would be
> better to add restrictions there first before creating a separate policy.
Mozilla's policy is wider in scop
On 27/01/17 18:53, Ryan Sleevi wrote:
> Nits and niggles: Perhaps 2048, 3072, 4096?
>
> - 8K RSA keys cause Web PKI interop problems
> - RSA keys that aren't modulo 8 create interop problems
This raises the question if, should our approach to interop problems be:
a) We ban anything which Firefox
On 07/02/2017 08:11, Tom wrote:
> Le 07/02/2017 à 05:01, Patrick Figel a écrit :
>> On 27/01/2017 19:53, Ryan Sleevi wrote:
>>> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham
>>>
> wrote:
* RSA keys with a minimum modulus size of 2048 bits
>>>
>>> Nits and niggles: Perhaps 204
Le 07/02/2017 à 05:01, Patrick Figel a écrit :
> On 27/01/2017 19:53, Ryan Sleevi wrote:
>> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham
wrote:
>>>
>>> * RSA keys with a minimum modulus size of 2048 bits
>>>
>>
>> Nits and niggles: Perhaps 2048, 3072, 4096?
>>
>> - 8K RSA keys cause Web PKI
On 27/01/2017 19:53, Ryan Sleevi wrote:
> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham wrote:
>>
>> * RSA keys with a minimum modulus size of 2048 bits
>>
>
> Nits and niggles: Perhaps 2048, 3072, 4096?
>
> - 8K RSA keys cause Web PKI interop problems
> - RSA keys that aren't modulo 8 create
On Saturday, 28 January 2017 06:51:10 CET Peter Gutmann wrote:
> Jakob Bohm writes:
> >DSA and ECDSA signatures are only secure if the hash algorithm is specified
> >in the certificate, presumably as part of the AlgorithmIdentifier in the
> >SubjectPublicKeyInfo.
>
> It's in the (badly-named) sig
Jakob Bohm writes:
>This changed the moment SHA-2 came out, though one could interpret that the
>length of the signature elements would uniquely indicate the SHA variant.
>With SHA-256/160 and SHA-3, that is completely gone as there are now two SHA
>hash algorithms for each length. Plus any non-
On 30/01/2017 14:24, Peter Gutmann wrote:
Jakob Bohm writes:
Surprised you didn't know that, considering who you are.
Uhh, I did know that, that's why I checked it about 15-odd years ago to see if
anything would notice if it was done wrong (I can't remember the exact date,
it was when I was
Jakob Bohm writes:
>Surprised you didn't know that, considering who you are.
Uhh, I did know that, that's why I checked it about 15-odd years ago to see if
anything would notice if it was done wrong (I can't remember the exact date,
it was when I was still updating the X.509 Style Guide so aroun
On 28/01/2017 07:51, Peter Gutmann wrote:
Jakob Bohm writes:
DSA and ECDSA signatures are only secure if the hash algorithm is specified
in the certificate, presumably as part of the AlgorithmIdentifier in the
SubjectPublicKeyInfo.
It's in the (badly-named) signature field of the cert, if it
On 27/01/17 18:53, Ryan Sleevi wrote:
> There's the AlgorithmIdentifier of the key, and the AlgorithmIdentifier of
> the signature produced with that key. For the key, you can allow something
> like P-256, but for the signature, you want to restrict it to P-256 with
> SHA-256.
>
> This is similar
On 2017-01-28 07:51, Peter Gutmann wrote:
Jakob Bohm writes:
DSA and ECDSA signatures are only secure if the hash algorithm is specified
in the certificate, presumably as part of the AlgorithmIdentifier in the
SubjectPublicKeyInfo.
It's in the (badly-named) signature field of the cert, if it
Jakob Bohm writes:
>DSA and ECDSA signatures are only secure if the hash algorithm is specified
>in the certificate, presumably as part of the AlgorithmIdentifier in the
>SubjectPublicKeyInfo.
It's in the (badly-named) signature field of the cert, if it was in the
signatureAlgorithm it wouldn't
On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham wrote:
>
> * RSA keys with a minimum modulus size of 2048 bits
>
Nits and niggles: Perhaps 2048, 3072, 4096?
- 8K RSA keys cause Web PKI interop problems
- RSA keys that aren't modulo 8 create interop problems
> 2) Brian has also suggested we ma
On 27/01/2017 12:47, Gervase Markham wrote:
On 25/01/17 17:55, Ryan Sleevi wrote:
Yes, I think it results in a clearer communication that is otherwise
identical, and ensures that there is community consensus on policy changes
:)
Draft of new Maintenance Policy section, bullet 8:
We consider t
On 25/01/17 17:55, Ryan Sleevi wrote:
> Yes, I think it results in a clearer communication that is otherwise
> identical, and ensures that there is community consensus on policy changes
> :)
Draft of new Maintenance Policy section, bullet 8:
We consider the following algorithms and key sizes to b
On Wed, Jan 25, 2017 at 3:21 AM, Gervase Markham wrote:
> On 24/01/17 17:12, Ryan Sleevi wrote:
> > This means, as a practical matter, I strongly agree with Brian Smith's
> > suggestion of having an explicit, enumerated list of algorithms (and
> > parameters) in the Mozilla policy, with the cavea
On 24/01/17 17:12, Ryan Sleevi wrote:
> This means, as a practical matter, I strongly agree with Brian Smith's
> suggestion of having an explicit, enumerated list of algorithms (and
> parameters) in the Mozilla policy, with the caveat/expectation that Mozilla
> policy will be able to be updated in
urity-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Tuesday, January 24, 2017 10:12 AM
To: Richard Barnes
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham
Subject: Re: Appropriate role for lists of algorithms and key sizes
I mostly agree
I mostly agree with Richard's sentiments - that is, the BRs are likely to
be more liberal than what Mozilla may want - but not sure how 0/1 falls out
from that.
I think 2/3 are implemented the same, just different expressions of 'why' -
and I think both reasons are valid. That is, Mozilla may want
On 24/01/17 16:26, Richard Barnes wrote:
My gut reaction is 0+1, maybe 2.
- The CAB Forum should specify the overall envelope of what is acceptable
in the Web PKI
- Firefox will enforce restrictions that are mores strict than the BRs
requirements
The BRs say that SHA-1 has been unacceptable in
My gut reaction is 0+1, maybe 2.
- The CAB Forum should specify the overall envelope of what is acceptable
in the Web PKI
- Firefox will enforce restrictions that are mores strict than the BRs
requirements
If we do (2), then this will just be a three level hierarchy, with BRs <
Mozilla Policy < F
A discussion inspired by
https://github.com/mozilla/pkipolicy/issues/5
Should Mozilla's root store policy contain any list of approved and/or
disapproved algorithms/key sizes, or not? Possible positions include at
least:
0) No; what algorithms and/or key sizes are supported by Firefox and/or
NSS
25 matches
Mail list logo
