On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:
On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy wrote:
On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy
wrote:
I don't believe that disclosure of root certificates is the responsibility
of
On 09/06/2017 11:57, Rob Stradling wrote:
On 09/06/17 03:16, Peter Bowen via dev-security-policy wrote:
On Thu, Jun 8, 2017 at 7:09 PM, Jonathan Rudenberg via
dev-security-policy wrote:
On Jun 8, 2017, at 20:43, Ben Wilson via dev-security-policy
wrote:
I don't believe that disclosure of
On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certificate chains
*explicitly* here, not just say they saw it "someho
On 08/06/17 19:46, Jakob Bohm wrote:
> How about the following, which seems more correct
Yes; I'm not sure why David thought the original version's two sentences
were contradicting rach other.
> Insofar as the Baseline Requirements attempt to define their own scope,
> the scope of this policy (se
On 08/06/17 15:37, Jeremy Rowley wrote:
> If you added them automatically to OneCRL, how would you create new
> intermediates? Would it be anything over X days old and undisclosed is
> automatically added?
Yes, that :-) Sorry if that wasn't clear. The deadline, as of policy
2.5, is a week (sectio
On 09/06/17 11:29, Rob Stradling wrote:
> These two certs share the same Name and Key. Therefore, the signature
> on the first can be verified by the public key in the second; and vice
> versa. And clearly the Subject Name in each one matches the Issuer Name
> in the other. This means that the f
On 09/06/2017 12:29, Rob Stradling wrote:
On 09/06/17 11:16, Jakob Bohm via dev-security-policy wrote:
What in the policy says they become in-scope from a certificate chain
that isn't "anchored" at a Mozilla trusted root?
And would someone please post those alleged certificate chains
*explici
For these self-signed roots which have a certificate subject and key which
match to a different certificate which is in a trusted path (like an
intermediate to a trusted root), the concern is that the mere existence of the
certificate speaks to a signature produced by a private key which DOES ha
On Fri, Jun 9, 2017 at 9:11 AM, Matthew Hardeman via
dev-security-policy wrote:
> For these self-signed roots which have a certificate subject and key which
> match to a different certificate which is in a trusted path (like an
> intermediate to a trusted root), the concern is that the mere exis
On Thu, Jun 8, 2017 at 10:16 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> There are two important things about self-issued certificates:
>
> 1) They cannot expand the scope of what is allowed.
> Cross-certificates can create alternative paths with diff
On Friday, June 9, 2017 at 11:52:53 AM UTC-5, Ryan Sleevi wrote:
> So that would be an arguement for disclosing both self-signed and
> self-issued certificates, and align with the "Disclose what the key does"
> mentality.
That was essentially the point I was trying to make. Of all the things to
11 matches
Mail list logo