RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

We should allow someone to obtain/view the P12 password and to download the P12 over an authenticated web site (managed portal), and that seems to be precluded by the definition below. Doug From: Tim Hollebeek [mailto:tim.holleb...@digicert.com] Sent: Monday, April 30, 2018 3:05 PM To: Wayne

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

OOB passwords are generally tough to integrate into automation, and if the channel really is “secure” then they might not be buying you anything, depending where the “secure” channel starts and ends and how it is authenticated. That might not be a GOOD reason to allow it, but it is the one

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

Seeing no additional comments, I've gone ahead and added this change to the 2.6 branch of the policy: https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10 - Wayne On Tue, Apr 24, 2018 at 6:02 PM, Wayne Thayer wrote: > On Tue, Apr 24, 2018

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

The current policy seems inconsistent on the trust placed in passwords to protect PKCS#12 files. On one hand, it forbids transmission via insecure electronic channels regardless of password protection. But it goes on to permit transmission of PKCS#12 files on a storage device as long as a

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

Hi Ryan, thanks for your enlightening feedback to my poor comments... let me try to add some more here. El lunes, 30 de abril de 2018, 17:22:38 (UTC+2), Ryan Sleevi escribió: > On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy < > dev-security-policy@lists.mozilla.org>

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Once again, CSPRNGs are not overkill. They are widely available in virtually every programming language in existence these days. I have never understood why there is so much pushback against something that often appears near the top of many top ten lists about basic principles for secure

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

I agree we need to tighten up Wayne's initial proposal a little. - Initial proposal (Wayne): CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi wrote: > > > On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: > >> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: >> >>> I'm not sure I underestand the use case. I'm hoping that they

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: > On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: > >> I'm not sure I underestand the use case. I'm hoping that they can clarify >> more. >> >> Pedro - can you explain more about why this is

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Mon, 30 Apr 2018, Tim Hollebeek wrote: What about the cases we discussed where there is DNSSEC, but only for a subtree? I don't know what that means? You mean a trust island not chained to the root? If so, then yes, that is a zone without DNSSEC since it is missing a DS in its parent (or

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

I think a reasonable approach is to consider a domain having deployed DNSSEC when there is a DS record at the parent zone (*). Missing DS record => No DNSSEC. Existing DS record => Require valid DNSSEC signatures (*) More precisely, a chain of DS records through all the parent zones down to

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > With all my respects to the experts involved in this discussion, my > statement is based in risk management, and I just think there's maybe no > need to over-regulate

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

What about the cases we discussed where there is DNSSEC, but only for a subtree? Or do you consider that "not DNSSEC" ? -Tim > -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Monday, April 30, 2018 11:07 AM > To: Tim Hollebeek > Cc:

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote: I don't think this opinion is in conflict with the suggestion that we required DNSSEC validation on CAA records when (however rarely) it is deployed. I added this as https://github.com/mozilla/pkipolicy/issues/133 One of the

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

32 bits is rather ... low. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Buschart, > Rufus via dev-security-policy > Sent: Monday, April 30, 2018 2:25 AM > To: mozilla-dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

> I don't think this opinion is in conflict with the suggestion that we > required > DNSSEC validation on CAA records when (however rarely) it is deployed. I > added this as https://github.com/mozilla/pkipolicy/issues/133 One of the things that could help quite a bit is to only require DNSSEC

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Am Montag, 30. April 2018 08:25:39 UTC+2 schrieb Buschart, Rufus: > ---=== Intern ===--- > Hello! > > I would like to suggest to rephrase the central sentence a little bit: > > Original: > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form through > insecure electronic

AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

---=== Intern ===--- Hello! I would like to suggest to rephrase the central sentence a little bit: Original: CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must