> 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
>
11 matches
Mail list logo
