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
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
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-
> -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>
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
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 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.
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
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,
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
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
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
12 matches
Mail list logo
