> Certificates that are capable of being used to issue new certificates MUST
> either be Technically Constrained in line with section 7.1.5 and audited in
> line with section 8.7 only, or Unconstrained and fully audited in line with
> all remaining requirements from this section
>
> Section
On 26/10/16 18:53, Ryan Sleevi wrote:
> interpretation of #2. This is also why I support the mandatory
> disclosure of TCSCs to Mozilla Salesforce, to ensure that the
> Technical Constraints are properly implemented and conforming in
> order for the CA to claim its exclusion.
If we were to
-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, October 26, 2016 11:53 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Technically Constrained Sub-CAs and the BRs
On Wednesday, October 26
On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote:
> Perhaps it would be worth revisiting the reasons why technically
> constrained sub-CAs were excluded from Mozilla policy. As I remember,
> this was a privacy requirement - CAs wanted to be able to have some
> sub-CAs
Reading this makes me wonder. Will it still be possible to have such a thing as
a non disclosed sub-CA now that Chrome has announced that they soon will
require CT?
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:
> 8. 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
>
On 26/10/16 02:30, Ryan Sleevi wrote:
> So we certainly know that Mozilla's policies are, in some ways,
> designed to minimize the number of errors that users are presented
> with, by allowing a gradual fade out of insecure or undesirable
> practices. A change in the BRs is, in theory, supposed to
On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi wrote:
> Yes. There is no obligation or expectation, presently communicated, to revoke
> extant certificates. Indeed, CAs were adamantly opposed to such a
> requirement. So these certificates will still very much be valid.
Ah yes, I had
On Tuesday, October 25, 2016 at 4:56:57 PM UTC-7, Nick Lamb wrote:
> Is it possible for someone to write up the details of the non-compliant
> issuances and so on ? I would find it much easier to comment on the
> particulars of 1311200 if they were more specific.
This doesn't seem relevant;
On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote:
> The linked bug is a concrete example, where an unconstrained sub-CA was
> revoked, due to non-compliance with the BRs, but has now been cross-certified
> as a constrained sub-CA. All of these non-BR compliant certificates are now
On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote:
> That is, according to the BRs, the issuer of a technically constrained
> subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to
> the BRs and the issuing CA's policies and practices, as well as conduct a
>
In https://bugzilla.mozilla.org/show_bug.cgi?id=1311200 , Kathleen suggested I
bring the broader discussion to mozilla.dev.security.policy, so this is that
thread.
At present, there's an element of inconsistency between the BRs and Mozilla
Policy that leads to some confusion.
With respect to
12 matches
Mail list logo
