On 15/12/2017 22:33, Ryan Hurst wrote:
On Tuesday, December 12, 2017 at 1:08:24 PM UTC-8, Jakob Bohm wrote:
On 12/12/2017 21:39, Wayne Thayer wrote:
On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 12/12/2017 19:39, Wayne T
Matthew Hardeman wrote:
> On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote:
>> In all of these cases, the device is going to be a safer place to generate
>> keys than the CA, in particular because (a) the CA is another embedded
>> controller somewhere so probably no better t
Ryan Hurst via dev-security-policy
writes:
>Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems
>is not a great candidate for the role of carrying keys anymore. You can see
>my blog post on this topic here: http://unmitigatedrisk.com/?p=543
It's even worse than that, I
> On 15/12/17 16:02, Ryan Hurst wrote:
> > So I have read this thread in its entirety now and I think it makes
sense for it
> to reset to first principles, specifically:
> >
> > What are the technological and business goals trying to be achieved,
> > What are the requirements derived from those go
On 15/12/17 16:02, Ryan Hurst wrote:
> So I have read this thread in its entirety now and I think it makes sense for
> it to reset to first principles, specifically:
>
> What are the technological and business goals trying to be achieved,
> What are the requirements derived from those goals,
> Wh
On Friday, December 15, 2017 at 1:34:30 PM UTC-8, Matthew Hardeman wrote:
> On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote:
>
> > Unfortunately, the PKCS#12 format, as supported by UAs and Operating
> > Systems is not a great candidate for the role of carrying keys anymore. Y
On Friday, December 15, 2017 at 3:21:54 PM UTC-6, Ryan Hurst wrote:
> Unfortunately, the PKCS#12 format, as supported by UAs and Operating Systems
> is not a great candidate for the role of carrying keys anymore. You can see
> my blog post on this topic here: http://unmitigatedrisk.com/?p=543
>
On Tuesday, December 12, 2017 at 1:08:24 PM UTC-8, Jakob Bohm wrote:
> On 12/12/2017 21:39, Wayne Thayer wrote:
> > On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 12/12/2017 19:39, Wayne Thayer wrote:
> >>
> >>> T
On Tuesday, December 12, 2017 at 11:31:18 AM UTC-8, Tim Hollebeek wrote:
> > A policy allowing CAs to generate key pairs should also include provisions
> > for:
> > - The CA must generate the key in accordance with technical best practices
> > - While in possession of the private key, the CA must s
instead of one and I tend to prefer avoiding
unnecessary complexity.
-Tim
From: Wayne Thayer [mailto:wtha...@mozilla.com]
Sent: Wednesday, December 13, 2017 5:40 PM
To: Tim Hollebeek
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA generated keys
On Wed, Dec 13, 2017
On Wed, Dec 13, 2017 at 4:06 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Wayne,
>
> For TLS/SSL certificates, I think PKCS #12 delivery of the key and
> certificate
> at the same time should be allowed, and I have no problem with a
> requirement
>
On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote:
> >Sitting on my desk are not less than 3 reference designs. At least two of
> >them have decent hardware RNG capabilities.
>
> My code runs on a lot (and I mean a *lot*) of embedded, virtually none of
> which has hardwa
Matthew Hardeman via dev-security-policy
writes:
>In principle, I support Mr. Sleevi's position, practically I lean toward Mr.
>Thayer's and Mr. Hollebeek's position.
I probably support at least one of those, if I can figure out who's been
quoted as saying what.
>Sitting on my desk are not les
On Wednesday, December 13, 2017 at 12:50:38 PM UTC-6, Ryan Sleevi wrote:
> On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman
> wrote:
>
> > As I pointed out, it can be demonstrated that quality ECDHE exchanges can
> > happen assuming a stateful DPRNG with a decent starting entropy corpus.
> >
>
> As an unrelated but funny aside, I once heard about a expensive, high
> assurance device with a embedded bi-stable circuit for producing high quality
> hardware random numbers. As part of a rigorous validation and review process
> in order to guarantee product quality, the instability was no
On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman
wrote:
> As I pointed out, it can be demonstrated that quality ECDHE exchanges can
> happen assuming a stateful DPRNG with a decent starting entropy corpus.
>
Agreed - but that's also true for the devices Tim is mentioning.
Which I guess is the
: CA generated keys
Tim,
I appreciate your reply, but that seems to be backwards looking rather than
forwards looking. That is, it looks and assumes static-RSA ciphersuites are
acceptable, and thus the entropy risk to TLS is mitigated by client-random to
this terrible TLS-server devices
> I appreciate your reply, but that seems to be backwards looking rather than
> forwards looking. That is, it looks and assumes static-RSA ciphersuites are
> acceptable, and thus the entropy risk to TLS is mitigated by client-random
> to this terrible TLS-server devices, and the issue to mitigate i
> recently looking at the state of the IoT world, and it’s not good.
>
>
>
> -Tim
>
>
>
> From: Ryan Sleevi [mailto:r...@sleevi.com]
> Sent: Wednesday, December 13, 2017 9:52 AM
> To: Tim Hollebeek
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> S
vendors to
> replace or repair them. This seems to overall make Mozilla users less
> secure, and the ecosystem less secure.
>
> I realize that there is somewhat a conflict - we're today requiring that
> CDNs and vendors can generate these keys (thus masking off the poor entro
Hollebeek
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA generated keys
On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Wayne,
For TLS/SSL certificates, I think PKCS #12 delivery of the k
ection), while not allowing the CA to participate - but I think
that's consistent with a viewpoint that the CA should not actively
facilitate insecurity, which I fear your proposal would.
Thus, I would suggest that the current status quo - a prohibition against
CA generated keys - is positive for
Wayne,
For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate
at the same time should be allowed, and I have no problem with a requirement
to delete the key after delivery. I also think server side generation along
the lines of RFC 7030 (EST) section 4.4 should be allo
On 12/12/2017 21:39, Wayne Thayer wrote:
On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 12/12/2017 19:39, Wayne Thayer wrote:
The outcome to be avoided is a CA that holds in escrow thousands of
private keys used for TLS.
On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/12/2017 19:39, Wayne Thayer wrote:
>
>> The outcome to be avoided is a CA that holds in escrow thousands of
>> private keys used for TLS. I don’t think that a policy permitti
On 12/12/2017 19:39, Wayne Thayer wrote:
On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I don't know but it's worth talking about. I think the discussion should
be
"when should this be allowed, and how can it be done secu
> A policy allowing CAs to generate key pairs should also include provisions
> for:
> - The CA must generate the key in accordance with technical best practices
> - While in possession of the private key, the CA must store it securely
Don't forget appropriate protection for the key while it is in
On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I don't know but it's worth talking about. I think the discussion should
> be
> "when should this be allowed, and how can it be done securely?"
>
> The outcome to be avoided
ets overlooked. The people shipping this stuff
respond to issues that cause high return rates.
Today, people aren't returning retail product for bad number generation.
I don't really think CA generated keys is the right answer in the general
case. However, recent events and market trend
> The more I think about it, the more I see this is actually a interesting
question :-)
I had the same feeling. It seems like an easy question to answer until you
start thinking about it.
> I suspect the first thing Mozilla allowing this would do would be to make
it much more common. (Let's ass
mozilla.org
> Subject: RE: CA generated keys
>
> I think key escrow services are pretty rare related to TLS certs. However,
> there's lots of CAs and services that escrow signing keys for s/MIME certs.
> Although, I'm not sure how companies can claim non-repudiation i
017 12:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA generated keys
Hi Tim,
The more I think about it, the more I see this is actually a interesting
question :-)
I suspect the first thing Mozilla allowing this would do would be to make it
much more common. (Let's assum
On Sat, 9 Dec 2017 18:20:56 +
Tim Hollebeek via dev-security-policy
wrote:
> First, third parties who are *not* CAs can run key generation and
> escrow services, and then the third party service can apply for a
> certificate for the key, and deliver the certificate and the key to a
> customer
Hi Tim,
The more I think about it, the more I see this is actually a interesting
question :-)
I suspect the first thing Mozilla allowing this would do would be to
make it much more common. (Let's assume there are no other policy
barriers.) I suspect there are several simpler workflows for certifi
Apologies for the new thread. It's difficult for me to reply to messages
that were sent before I joined Digicert.
With respect to CA generated SSL keys, there are a few points that I feel
should be considered.
First, third parties who are *not* CAs can run key generation and escrow
serv
35 matches
Mail list logo