On 04/05/2018 20:58, Wayne Thayer wrote:
The optimist in me thinks we might be getting close to resolving this issue
(the last one remaining for the 2.6 policy update). Here is another
proposal that attempts to account for most of the input we've received:
Add the following to section 5.2
> True, but CAs can put technical constraints on that to limit the acceptable
> passwords to a certain strength. (hopefully with a better strength-testing
> algorithm than the example Tim gave earlier)
Tim is the best of us -- this is hard to do well :)
On Friday, May 4, 2018 at 3:37:10 PM UTC-5, Ryan Hurst wrote:
> >
> > What about "or a user supplied password"?
> > -carl
>
> user supplied passwords will (in real world scenarios) not be as good as a
> one generated for them; this is in part why I suggested earlier if a user
> password to be
On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hey Doug,
>
> On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote:
> > Hey Wayne,
> >
> > This should be a really easy thing, but it's not.
> >
> > First comments on
>
> What about "or a user supplied password"?
> -carl
user supplied passwords will (in real world scenarios) not be as good as a one
generated for them; this is in part why I suggested earlier if a user password
to be used that it be mixed with a server provided value.
On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote:
> First comments on this: "MUST be encrypted and signed; or, MUST have a
> password that..."
> - Isn't the password the key used for encryption? I'm not sure if the "or"
> makes sense since in both cases the password is the key for
Hey Doug,
On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote:
> Hey Wayne,
>
> This should be a really easy thing, but it's not.
>
> First comments on this: "MUST be encrypted and signed; or, MUST have a
> password that..."
> - Isn't the password the key used for encryption? I'm
Hey Wayne,
This should be a really easy thing, but it's not.
First comments on this: "MUST be encrypted and signed; or, MUST have a password
that..."
- Isn't the password the key used for encryption? I'm not sure if the "or"
makes sense since in both cases the password is the key for
The optimist in me thinks we might be getting close to resolving this issue
(the last one remaining for the 2.6 policy update). Here is another
proposal that attempts to account for most of the input we've received:
Add the following to section 5.2 (Forbidden and Required Practices):
CAs MUST
Hi everyone,
I posted our announcement about deprecation of Symantec CT logs over on the
Google list a while ago. I figured I'd post something here as well so the
community is aware of our plans.
As part of our infrastructure consolidation DigiCert will be EOLing legacy
Symantec CT log
> Maybe you want n = 112 / 8 = 14 bytes.
Doh! Yes.
-Tim
smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 2018-05-04 12:10, Tim Hollebeek wrote:
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or
It has generally been understood that a string still "contains at least 112
bits of output from a CSPRNG" if that string has been fed through an
encoding mechanism like Base64 or Base32.
Furthermore, explicit requirements about including mixed case or special
characters leads to some very, very
13 matches
Mail list logo
