RAs and the BRs

[Jeremy Rowley via dev-security-policy]

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

 

Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  

 

I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 

 

Jeremy 



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

RE: Policy 2.6 Proposal: Require CAs to support problem reports via email

[Jeremy Rowley via dev-security-policy]

I believe the intent of the certificate problem reporting in the BRs is to 
encourage CAs to accept and respond to issues. Although the intent is not 
specifically stated, my reasoning is based on the fact the BRs requiring CAs to 
maintain a 24x7 ability to respond, a 24 hour ability to process certificate 
problems, and a public reporting mechanism. To support this objective, I think 
we should make the process as easy as possible for reporters, including 
mandating email. Finding the email addresses is a pain with little reward. 
Having to go through captchas to even get the email sent is just another 
obstacle in getting the CA a timely certificate problem report.  Therefore, I'd 
adopt Ryan Hurst's proposal and require that the email be in a standardized 
format (no more hunting for email aliases) without any blockers to prevent the 
certificate problem report. Filtering through the mess of emails you get on 
those aliases is the CAs responsibility. 

Jeremy

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Tuesday, April 17, 2018 10:50 AM
To: mozilla-dev-security-policy 
Subject: Policy 2.6 Proposal: Require CAs to support problem reports via email

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says:
"The CA SHALL provide Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties with clear instructions for reporting 
suspected Private Key Compromise, Certificate misuse, or other types of fraud, 
compromise, misuse, inappropriate conduct, or any other matter related to 
Certificates. The CA SHALL publicly disclose the instructions through a readily 
accessible online means.”

Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it 
turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. 
It is proposed that Mozilla policy go above and beyond the BR requirement to 
state that email must be one of the problem reporting methods supported.

Another argument in favor or requiring CAs to accept problem reports via email 
is that it provides the reporter with evidence of the submission via their 
email client and server logs.

Arguments against this requirement include the burden placed on CAs who must 
sort through the large quantities of SPAM received by any published email 
address, concerns with email reliability, and the reporter's inability to 
confirm that their email has been received by the CA.

According to CCADB [1], all but a handful of CAs already support problem 
reporting via email.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/98

[1]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
---

This is a proposed update to Mozilla's root store policy for version 2.6. 
Please keep discussion in this group rather than on GitHub. Silence is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

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

[Jeremy Rowley via dev-security-policy]

If you don't specify by EKU, the exercise of determining intent becomes
impossible as illustrated by our (many) attempts to define a server cert in
CAB Forum. Better to list the EKUs allowed and not allowed in the same cert
than rely on another intent requirement. 

-Original Message-
From: dev-security-policy

On Behalf Of Doug Beattie via dev-security-policy
Sent: Tuesday, April 17, 2018 1:37 PM
To: Wayne Thayer ; mozilla-dev-security-policy

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



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, April 17, 2018 2:24 PM
> To: mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Require separate intermediates for 
> different usages (e.g. server auth, S/MIME)
> 
> This proposal is to require intermediate certificates to be dedicated 
> to specific purposes by EKU. Beginning at some future date, all newly 
> created intermediate certificates containing either the 
> id-kp-serverAuth or id-kp- emailProtection EKUs would be required to
contain only a single EKU.

We'll need to support a list of EKUs if this becomes a requirement.  Server
Auth certificates should be able to support lots of different EKUs, for
example: 
id-kp-serverAuth
id-kp-clientAuth
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser
KDC Authentication
Smart Card Logon
iPSec IKE
IKE Intermediate

> Arguments for this requirement are that it reduces risk of an incident 
> in which one type of certificate affecting another type, and it could 
> allow some policies to be restricted to specific types of certificates.
> 
> It was pointed out that Microsoft already requires dedicated 
> intermediates [1].

I agree with using dedicated intermediates, but I'd prefer that they should
not be required to be EKU constrained.

> I would appreciate everyone's input on this topic.
> 
> I suspect that it will be tempting to extend this discussion into 
> intermediate rollover policies, but I would remind everyone of the 
> prior inconclusive discussion on that topic [2].
> 
> This is: https://github.com/mozilla/pkipolicy/issues/26
> 
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-
> TQ8/hgVsCofcAgAJ
> ---
> 
> This is a proposed update to Mozilla's root store policy for version 2.6.
> Please keep discussion in this group rather than on GitHub. Silence is
consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

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

[Doug Beattie via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, April 17, 2018 2:24 PM
> To: mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Require separate intermediates for different
> usages (e.g. server auth, S/MIME)
> 
> This proposal is to require intermediate certificates to be dedicated to
> specific purposes by EKU. Beginning at some future date, all newly created
> intermediate certificates containing either the id-kp-serverAuth or id-kp-
> emailProtection EKUs would be required to contain only a single EKU.

We'll need to support a list of EKUs if this becomes a requirement.  Server 
Auth certificates should be able to support lots of different EKUs, for 
example: 
id-kp-serverAuth
id-kp-clientAuth
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser
KDC Authentication
Smart Card Logon
iPSec IKE 
IKE Intermediate

> Arguments for this requirement are that it reduces risk of an incident in 
> which
> one type of certificate affecting another type, and it could allow some
> policies to be restricted to specific types of certificates.
> 
> It was pointed out that Microsoft already requires dedicated intermediates
> [1].

I agree with using dedicated intermediates, but I'd prefer that they should not 
be required to be EKU constrained.

> I would appreciate everyone's input on this topic.
> 
> I suspect that it will be tempting to extend this discussion into intermediate
> rollover policies, but I would remind everyone of the prior inconclusive
> discussion on that topic [2].
> 
> This is: https://github.com/mozilla/pkipolicy/issues/26
> 
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-
> TQ8/hgVsCofcAgAJ
> ---
> 
> This is a proposed update to Mozilla's root store policy for version 2.6.
> Please keep discussion in this group rather than on GitHub. Silence is 
> consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

On 17/4/2018 9:24 μμ, Wayne Thayer via dev-security-policy wrote:

This proposal is to require intermediate certificates to be dedicated to
specific purposes by EKU. Beginning at some future date, all newly created
intermediate certificates containing either the id-kp-serverAuth or
id-kp-emailProtection EKUs would be required to contain only a single EKU.


We should not require a single EKU but separation of id-kp-serverAuth 
and id-kp-emailProtection. This means that if an Intermediate CA 
Certificate includes the id-kp-serverAuth, it MUST NOT include 
id-kp-emailProtection but it MAY also include (for example) the 
id-kp-clientAuth EKU.


Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Define/clarify policy for transfer of intermediate CA certificates

[Wayne Thayer via dev-security-policy]

This issue was brought up in the thread that kicked off the 2.6 root store
policy update [1]. Mozilla policy section 5.3.2 requires CAs to disclose
new unconstrained intermediate CA certificates within one week of creation.
Section 8 covers [in my opinion] transfers of roots but not intermediates.
This leaves a loophole for a CA to create a new intermediate CA
certificate, then transfer it without notice or approval. This problem also
applies to cross-signatures from one CA to another.

I am aware of three potential solutions:

1. In section 5.3.2, require CAs to also disclose a change in the ownership
or control of an unconstrained intermediate CA certificate within one week
of the change.

2. Modify section 8 to explicitly include transfers of trust via
intermediate CA certificates and cross signatures. Under section 8.1, this
would require notice and approval:

If the receiving or acquiring company is new to the Mozilla root program,
> there MUST be a public discussion regarding their admittance to the root
> program, which Mozilla must resolve with a positive conclusion before
> issuance is permitted.
>
3. Require organizations that are receiving subordinate CA certificates to
go through the whole Mozilla inclusion process as if they were applying for
a new root.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/122

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/
xGGGaI1_uo0/POMANRWRAAAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Wayne Thayer via dev-security-policy]

This proposal is to require intermediate certificates to be dedicated to
specific purposes by EKU. Beginning at some future date, all newly created
intermediate certificates containing either the id-kp-serverAuth or
id-kp-emailProtection EKUs would be required to contain only a single EKU.

Arguments for this requirement are that it reduces risk of an incident in
which one type of certificate affecting another type, and it could allow
some policies to be restricted to specific types of certificates.

It was pointed out that Microsoft already requires dedicated intermediates
[1].

I would appreciate everyone's input on this topic.

I suspect that it will be tempting to extend this discussion into
intermediate rollover policies, but I would remind everyone of the prior
inconclusive discussion on that topic [2].

This is: https://github.com/mozilla/pkipolicy/issues/26

[1] https://aka.ms/rootcert
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-TQ8/hgVsCofcAgAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

[Wayne Thayer via dev-security-policy]

Section 5.3 of Mozilla policy states:

All certificates that are capable of being used to issue new certificates,
> and which directly or transitively chain to a certificate included in
> Mozilla’s CA Certificate Program, MUST be operated in accordance with this
> policy and MUST either be technically constrained or be publicly disclosed
> and audited.
>

This could be interpreted as exempting technically constrained subordinate
CA certificates from the self-audit requirements in BR section 8.1, or even
from any BR compliance requirement. Since the original discussion of this
issue [1] back in 2016, we have updated the scope of our policy to clearly
include technically constrained certificates, and thus the requirement for
BR conformance in section 2.3 does apply to these certificates. I believe
that our current policy already resolves this issue.

I propose that we further clarify the requirements for technically
constrained certificates by adding a second sentence to the second
paragraph of section 5.3.1 of the Mozilla policy as follows:

If the certificate includes the id-kp-serverAuth extended key usage, then
> the certificate MUST be Name Constrained as described in section 7.1.5 of
> version 1.3 or later of the Baseline Requirements. The Baseline
> Requirements Conformance policy, as defined in section 2.3, applies to
> technically constrained subordinate CA certificates.
>

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/36

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.6 Proposal: Require CAs to support problem reports via email

[Wayne Thayer via dev-security-policy]

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says:
"The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter
related to Certificates. The CA SHALL publicly disclose the instructions
through a readily accessible online means.”

Mozilla has made a central list of these mechanisms in the CCADB [1] but,
as it turns out, some of them (such as web forms with CAPTCHAs) are
difficult to use. It is proposed that Mozilla policy go above and beyond
the BR requirement to state that email must be one of the problem reporting
methods supported.

Another argument in favor or requiring CAs to accept problem reports via
email is that it provides the reporter with evidence of the submission via
their email client and server logs.

Arguments against this requirement include the burden placed on CAs who
must sort through the large quantities of SPAM received by any published
email address, concerns with email reliability, and the reporter's
inability to confirm that their email has been received by the CA.

According to CCADB [1], all but a handful of CAs already support problem
reporting via email.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/98

[1]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
---

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 17, 2018 at 12:24 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/04/2018 00:13, Ryan Sleevi wrote:
>
>> If you expect that, you're absolutely wrong for expecting that, because
>> that's not what a High Risk Request is.
>>
>>
> I am not the only one with that expectation.  In the concrete case the
> expectation was succinctly stated by Mathew in Message-ID
> mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
>

And someone else is wrong on the Internet. That doesn't make it any more
correct or reasonable assumption, no more than if you and I both agreed we
deserved to be paid $1 million a year by CAs for exchanging emails on this
list.


> The definition is in section 1.6.1 of the BRs and does not limit itself
> to blacklisted site names.


Nor does it require blacklisted site names. That's the point. It's
describing illustrative, not normative, examples of a process, not an exact
output. That is hugely meaningful in explaining why your expectations have
no basis in the requirements - nor, for that matter, are desirable.


>
>>> But just to please your pedantry, I will add two additional outcome
>>> options:
>>>
>>> -1. Thay CA does not really check for high risk names at all.  This
>>>might be permitted by some readings of BR 4.2.1 / Ballot 78.
>>>
>>>
>> It absolutely is permitted, and not a negative. Your expectations are
>> wrong, and you should adjust them, because they're not based in reality.
>>
>>
> BR 4.2.1 is a SHALL, not a SHOULD.
>

Yes - that you have a process. It does define the process for what
quantifies as that high risk in any form of MUST/SHALL language. I can say
high-risk requests are anything received via an InterPlanetaryNetwork (
https://en.wikipedia.org/wiki/Interplanetary_Internet ) and that is fully
conforment - and in line with expectations. The notion of "High-risk" is
fundamentally at the definition of the CA - what the objectives of
certificates are, from the CAs view. Thankfully, there are competent CAs
that recognize that certificates are not a phishing mitigation, and treat
"risk" as an operational risk category (or, to sate some of the frothing
masses, a PR risk), since there fundamentally is not some enhanced
'phishing' risk from certifying a domain.


> Weak is a common security term and a common English term with similar
> meaning in both contexts.
>

This is patently false.


> The question asked by Matthew and me, and which you keep blocking, is if
> jomo has publicly disclosed a case in which that CA's procedures
> accidentally fail to achieve that CA's security goals for those
> procedures.  This is a perfectly normally vulnerability issue
> investigation, which jomo (not I) made public 4 days ago.


No, this is not. Because you're hinging on a flawed understanding of what
you're asking, a flawed set of expectations, Matthew is working from a
flawed sense of angst, which all are rooted in an improper understanding of
the BRs or the goals of certificates, and for which the notion of "security
goals" is clearly one you Have Opinions about, but those opinions are not
in line with industry best practice or stated CA goals. So your questioning
is not whether the CA has failed to achieve their goals, but whether
they've failed to achieve your goals, and that's very much a nonsequitur
with no basis in the actual goals of certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

I believe the wording "insecure electronic channels" leaves a lot of space for 
interpretation. In corporate PKIs for email encryption it is quite common to 
transfer centrally generated email encryption p12-files to mobile device 
management systems, email encryption gateways or directly to mobile devices 
using a wide variety of 'electronic channels'. From the proposed wording it 
doesn't seem to be clear which of those channels are 'insecure' and which not. 
Even if not that common, the same applies for email signature p12-files for 
e.g. email signature on mail gateways or mobile devices. Most of the mobile 
devices out in the field neither support hardware token, key-pair-generation in 
the mailer software nor installation of downloaded p12-files (prohibited by app 
sandboxing).

Maybe it would be possible to restrict the new wording to the EKU kp-ServerAuth 
first and have a detailed discussion about email-encryption and user 
authentication with more interested parties in the next months?

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

www.siemens.com/ingenuityforlife

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+rufus.buschart=siemens@lists.mozilla.org]
 On Behalf Of Wayne Thayer via dev-security-policy
Sent: Dienstag, 17. April 2018 02:24
To: mozilla-dev-security-policy
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Tue, Apr 10, 2018 at 7:22 AM, Jürgen Brauckmann via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
>
> Am 10.04.2018 um 01:10 schrieb Wayne Thayer via dev-security-policy:
>
>> Getting back to the earlier question about email certificates, I am 
>> now of the opinion that we should limit the scope of this policy 
>> update to TLS certificates. The current language for email 
>> certificates isn't clear and any attempt to fix it requires us to 
>> answer the bigger question of "under what circumstances is CA key generation 
>> acceptable?"
>>
>> My updated proposal is to add the following paragraphs to section 5.3 
>> “Forbidden and Required Practices”:
>>
>> CAs MUST not generate the key pairs for end-entity certificates, 
>> except for
>>
>>> email certificates with the Extended Key Usage extension present and 
>>> set to id-kp-emailProtection.
>>>
>>
>
> What about user certificates for logon/authentication? CN=John Doe, 
> extendedKeyUsage=clientAuth? Is that different from email certificates?
>
> Yes, but certificates with only the clientAuth EKU are out of scope
according to section 1.1 of the Mozilla policy

Wouldn't it be better to make that a positive list to really limit the
> scope of the change?
>
> Yes, I think so.

=
> CAs MUST NOT generate the key pairs for end-entity certificates the 
> scope of the Baseline Requirements.
> =
>
> But this is too vague. I propose that we add the following paragraphs 
> to
section 5.2:

CAs MUST NOT generate the key pairs for end-entity certificates that have
> EKU extension containing the KeyPurposeIds id-kp-serverAuth or 
> anyExtendedKeyUsage.
>

>
CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If a PKCS#12 file is distributed via a 
> physical data storage device, then:
> * The storage must be packaged in a way that the opening of the 
> package causes irrecoverable physical damage. (e.g. a security seal)
> * The PKCS#12 file must have a sufficiently secure password, and the 
> password must not be transferred together with the storage.


Here it is on GitHub:
https://github.com/mozilla/pkipolicy/commit/456f869a15b6b9ca9be1df1897852b0c508932c7

Are there any concerns with this approach?

- Wayne

Thanks,
>Jürgen
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

[jomo via dev-security-policy]

On 17.4.18 06:24, Jakob Bohm via dev-security-policy wrote:
> I am not the only one with that expectation.  In the concrete case the
> expectation was succinctly stated by Mathew in Message-ID
> mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
>
> Mathew> With respect to domain name labels, all CAs maintain high risk
> Mathew> lists.  I doubt  would issue for
> Mathew> paypal.any_valid_tld even if CAA would permit.
> [ Name of CA elided ]
> The question asked by Matthew and me, and which you keep blocking, is if
> jomo has publicly disclosed a case in which that CA's procedures
> accidentally fail to achieve that CA's security goals for those
> procedures.  This is a perfectly normally vulnerability issue
> investigation, which jomo (not I) made public 4 days ago.

I was merely interested if Matthew's statement was correct, as I assumed
it was not. This was not intended to be (and is not) a vulnerability
issue investigation. It turned out Let's Elide indeed does issue a
certificate [0], which I find nothing wrong with.

They maintain a blacklist of high risk domains, as has been discussed in
their community forums [1].
They do not make the list public, but have made previous statements
about it; they have, in the past, accidentally blacklisted permutations
of domains that were not malicious, but happened to use a similar name
as a "high risk" domain, which made them change their blacklisting
mechanisms [2]. They might, for example, blacklist TLD permutations of
"high risk" domains registered by the same corporation. In this case it
would include, for example, paypal.com and paypal.de, but not
paypal.cologne, as it is not registered by the same corporation (PayPal
Inc.) as the high risk paypal.com.

The BRs do not require CAs to exclude domains from DV only because a big
corporation uses a similar name. See also [3].


0: https://crt.sh/?id=393717424

1: https://community.letsencrypt.org/search?q=%22Name%20is%20blacklisted%22

2: https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19

3: https://letsencrypt.org/2015/10/29/phishing-and-malware.html


jomo

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy