On Thu, Mar 28, 2019 at 7:14 PM Wayne Thayer wrote:
> The confusion that motivated the proposal was with the inconsistent
> definition of the term "technically constrained" in sections 1.1 and 5.3.
> It was not directly related to the BRs. My proposed changes take into
> account the definition in
On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer wrote:
> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>
>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> **Incidents**
>>> > When a CA fails to comply with any requ
On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi wrote:
>
> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> We currently expect CAs to deliver incident reports whenever they fail to
>> comply with our policy, but this is not a
The confusion that motivated the proposal was with the inconsistent
definition of the term "technically constrained" in sections 1.1 and 5.3.
It was not directly related to the BRs. My proposed changes take into
account the definition in the BRs and attempt to avoid inconsistencies in
the context o
On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We currently expect CAs to deliver incident reports whenever they fail to
> comply with our policy, but this is not a requirement of our policy. There
> is no obvious place to add
On Thu, Mar 28, 2019 at 4:53 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Our current Root Store policy assigns two different meanings to the term
> "technically constrained":
> * in sections 1.1 and 3.1, it means 'limited by EKU'
> * in section 5.3 it
We currently expect CAs to deliver incident reports whenever they fail to
comply with our policy, but this is not a requirement of our policy. There
is no obvious place to add this in the existing policy, so I propose
creating a new top-level section that reads as follows:
**Incidents**
> When a C
Our current Root Store policy assigns two different meanings to the term
"technically constrained":
* in sections 1.1 and 3.1, it means 'limited by EKU'
* in section 5.3 it means 'limited by EKU and name constraints'
The BRs already define a "Technically Constrained Subordinate CA
Certificate" as:
I'd like to remind CAs of Mozilla's disclosure requirement for
unconstrained intermediate CA certificates:
The CA with a certificate included in Mozilla’s root program MUST disclose
> this information within a week of certificate creation, and before any such
> subordinate CA is allowed to issue c
9 matches
Mail list logo
