On 13/04/17 14:50, Gervase Markham wrote:
On 12/04/17 21:21, Rob Stradling wrote:
Mozilla also requires CAs to disclose intermediate cert revocations to
CCADB. Should there be a corresponding time limit in the policy
regarding how soon after revocation this disclosure must occur?
There is:
On 12/04/17 21:21, Rob Stradling wrote:
> Mozilla also requires CAs to disclose intermediate cert revocations to
> CCADB. Should there be a corresponding time limit in the policy
> regarding how soon after revocation this disclosure must occur?
There is:
"If a non-exempt intermediate
On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote:
On 27/03/17 22:12, Andrew Ayer wrote:
[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67
]
This has now been added to the policy 2.5 draft with a one-week deadline.
Gerv
Gerv,
Mozilla also
On 27/03/17 22:12, Andrew Ayer wrote:
> [ Corresponding issue on GitHub:
> https://github.com/mozilla/pkipolicy/issues/67 ]
This has now been added to the policy 2.5 draft with a one-week deadline.
Gerv
___
dev-security-policy mailing list
On Tuesday, 4 April 2017 04:18:41 UTC+1, Jakob Bohm wrote:
> So why does Mozilla want disclosure and not just a blanket X on a form
> stating that all SubCAs are adequately audited, follow BRs etc.?
Not speaking for Mozilla of course, but as a fan of disclosure provisions:
Mandating disclosure
On 04/04/2017 05:30, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
So why does Mozilla want disclosure and not just a blanket X on a form
stating that all SubCAs are adequately audited, follow BRs etc.?
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 04/04/2017 05:03, Ryan Sleevi wrote:
>
>> On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> I see it
On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I see it as part of the underlying reasoning. Mozilla et al wants
> disclosure in order to take action if the disclosed facts are deemed
> unacceptable (under policy or
On 04/04/2017 00:31, Peter Bowen wrote:
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 21:48, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> The
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptions are:
0. All relevant root programs set similar/identical policies or they
get incorporatated into the CAB/F BRs on a
Further to Ryan's reply, we can once again take lessons from the real world
Ordinarily notice in law can be given by sending a letter and waiting a few
days. There is no obligation to prove the letter was delivered, let alone read
and comprehended, only that it was sent and that it was
On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 19:24, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>>
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The assumptions are:
>
> 0. All relevant root programs set similar/identical policies or they
> get incorporatated into the CAB/F BRs on a future date.
>
This is not correct at
On 03/04/2017 19:24, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
taking a holiday and not being able to process a disclosure of a new
SubCA.
Considering that the CCADB does not require any of these
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> taking a holiday and not being able to process a disclosure of a new
> SubCA.
>
Considering that the CCADB does not require any of these parties to process
a disclosure, can you
On 01/04/2017 03:49, Ryan Sleevi wrote:
On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
As previously stated, I think this will be too short if the issuance
happens at a time when a non-CCADB root program (or the CCADB
On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> As previously stated, I think this will be too short if the issuance
> happens at a time when a non-CCADB root program (or the CCADB
> infrastructure) is closed for holidays,
On 30/03/17 13:11, Gervase Markham via dev-security-policy wrote:
On 28/03/17 12:21, Rob Stradling wrote:
Increased attack surface. An undisclosed dormant sub-CA most likely has
its private key in an online HSM, and so I think it's prudent to assume
that it's more vulnerable (to being
On 28/03/17 12:21, Rob Stradling wrote:
> Increased attack surface. An undisclosed dormant sub-CA most likely has
> its private key in an online HSM, and so I think it's prudent to assume
> that it's more vulnerable (to being compromised by an attacker, or to
> being accidentally used to misissue
On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote:
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
Your case is missing the part where you explain why you think this is
bad :-) What risks are associated with undisclosed dormant sub-CA certs?
Actually, I think
On 28/03/2017 12:21, Rob Stradling wrote:
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
On 27/03/17 23:12, Andrew Ayer wrote:
My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away.
On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote:
On 27/03/17 23:12, Andrew Ayer wrote:
My interpretation of the policy is that a CA could delay disclosure for
quite some time if the sub-CA is not used to issue certificates right
away. If the sub-CA is created as a backup that
On 27/03/17 23:12, Andrew Ayer wrote:
> My interpretation of the policy is that a CA could delay disclosure for
> quite some time if the sub-CA is not used to issue certificates right
> away. If the sub-CA is created as a backup that is never used, the
> disclosure would never need to happen.
>
mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jakob Bohm via dev-security-policy
Sent: Monday, March 27, 2017 3:58 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Grace Period for Sub-CA Disclosure
On 27/03/2017 23:41, Rob Stradling wrote:
On 27/0
On 27/03/2017 23:41, Rob Stradling wrote:
On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote:
It should also be made a requirement that the issued SubCA certificate
is provided to the CCADB and other root programs before providing it to
the SubCA owner/operator,
That'd be a bit
[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67
]
Mozilla's CA Certificate Policy says:
> All certificates that are capable of being used to issue new
> certificates, that are not technically constrained, and that directly
> or transitively chain to a certificate
27 matches
Mail list logo