Re: CA generated keys

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

Re: [FORGED] Re: CA generated keys

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

Re: CA generated keys

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:

RE: CA generated keys

> 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

Re: CA generated keys

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, >

Re: CA generated keys

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.

Re: CA generated keys

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

Re: CA generated keys

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: > >> > >>>

Re: CA generated keys

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

RE: CA generated keys

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 <tim.holleb...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA gen

Re: [FORGED] Re: CA generated keys

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

Re: [FORGED] Re: CA generated keys

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

Re: CA generated keys

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

Re: CA generated keys

> 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

Re: CA generated keys

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.

RE: CA generated keys

ty-pol...@lists.mozilla.org Subject: Re: 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-

Re: CA generated keys

> 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

Re: CA generated keys

ng 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 <tim.holleb...@digicert.com> > Cc: mozilla-dev-security-pol...@lists.mo

Re: CA generated keys

cure, 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 entropy > from detection), while not allowing the CA to participate - but I think > that's consiste

RE: CA generated keys

Hollebeek <tim.holleb...@digicert.com> 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 <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> &

Re: CA generated keys

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 the SSL/TLS ecosystem in particular, an

RE: CA generated keys

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

Re: CA generated keys

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.

Re: CA generated keys

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

Re: CA generated keys

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

RE: CA generated keys

> 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

Re: CA generated keys

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

RE: CA generated keys

> 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

RE: CA generated keys

illa-dev-security- > pol...@lists.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-rep

RE: CA generated keys

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 assume there are no other

Re: CA generated keys

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

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 assume there are no other policy barriers.) I suspect there are several simpler workflows for

CA generated keys

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