Thanks Nick. I'm missing something on this, so I appreciate the help so
far. I replied to each section.
Perhaps you have confused transitivity with commutativity or one of the
other simple properties. Transitivity is the property whereby if F(A,B) and
F(B,C) then F(A,C), for example the "greater
On Monday, 3 July 2017 23:05:53 UTC+1, Jeremy Rowley wrote:
> And it's hardly fair to deride my lack of understanding on what transitive
> trust entails in the digital certificate space considering it's outside of
> the usual trust paths, not defined in the standard RFCs, and not the same as
> the
On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote:
> > > I suspect, means anyone could plug
> > > in a modern CI
>
> CI meaning Continuous Integration ?
>
Yes. Gerv's proposal rests on the idea of having a file committed that
explains it in human-readable and machine-readable (simultaneously) fo
We've now uploaded the self-signed root into the CCADB as a subordinate CA
to the same self-signed root, if that makes sense.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Jeremy Rowley via dev-security-po
"Previously accepted without comment" is hardly accurate. There's lots of
comments on the Mozilla policy (including Ben's comment on this very term).
And it's hardly fair to deride my lack of understanding on what transitive
trust entails in the digital certificate space considering it's outside of
On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley wrote:
> Link please to a formal definition? As your email alleges a policy violation
> by one a cross-signed CAs, we take the investigation and response very
> seriously. I'd like to know the basis for the definition before formulating
> an
Link please to a formal definition? As your email alleges a policy violation by
one a cross-signed CAs, we take the investigation and response very seriously.
I'd like to know the basis for the definition before formulating an official
report and potentially penalizing the Sub CA for non-complia
On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote:
I am surprised you decided to fork the thread from here
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM
where this was already being discussed. Seems unnecessary.
Hi Jeremy. That thread discusses
We still need to get the policy changed, even with the ballot. As
written right now, all name constrained certificates are no longer
considered constrained.
On Mon, Jul 3, 2017 at 9:42 AM, Jeremy Rowley
wrote:
> Isn't this ballot ready to go? If we start the review period now, it'll be
> passed
Isn't this ballot ready to go? If we start the review period now, it'll be
passed by the time the Mozilla policy is updated.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-sec
Thank you, Gerv (and have a great vacation!)
Best,
Peter
-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, July 03, 2017 12:21 PM
To: Loshin, Peter; mozilla-dev-security-pol...@lists.mozilla.org
Cc: pr...@mozilla.com; Justin O'Kelly
Subject: Re: Symantec m
In reviewing the Mozilla CA policy, I noticed one bug that is probably
my fault. It says:
"name constraints which do not allow Subject Alternative Names (SANs)
of any of the following types: dNSName, iPAddress, SRVName,
rfc822Name"
SRVName is not yet allowed by the CA/Browser Forum Baseline
Requ
Hi Peter,
I note you have copied in our press team and that you are a journalist;
I will answer your question as I would the same question from any member
of our community here if it were asked in this forum.
On 03/07/17 16:54, Loshin, Peter wrote:
> Other than stating that it will be publishing
Hi Gerv:
Thank you for posting this update on last week's meeting with Symantec.
Are you able to share any additional information about what transpired at this
meeting?
Other than stating that it will be publishing its proposal for implementing the
consensus remediation plan, did Symantec prov
On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote:
> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote:
> > Well, the fact that we now use Git,
NSS and the root store don't use Git, it uses HG/Mercurial.
> > I suspect, means anyone could plug
> > i
I am surprised you decided to fork the thread from here
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM
where this was already being discussed. Seems unnecessary.
I don't agree this is a policy violation, and I doubt any CA not involved in
the previously mention
On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote:
>
> > I think the new format should be as complete as possible, including both
> > trust
> > and distrust information, including EV and description of rules for partial
> > distrust.
>
> I agree, as long as we can stay away from defining a
Hi everyone,
As I was in the Bay Area for the Mozilla All Hands, Symantec requested a
face-to-face meeting with Mozilla, which happened last Friday. In
attendance were Tom Ritter, Aaron Wu and I for Mozilla, and the
following people from Symantec (I hope I have the titles right):
* Quentin Liu (H
Hi Kai,
On 30/06/17 17:38, Kai Engert wrote:
> given that today we don't have a single place where all of Mozilla's
> certificate
> trust decisions can be found, introducing that would be a helpful.
I'm glad you see the value in my goal :-)
> I think the new format should be as complete as poss
https://crt.sh/mozilla-disclosures#undisclosed has listed
https://crt.sh/?id=160110886 for over 1 week.
This is a violation of section 5.3.2 of the Mozilla Root Store Policy
v2.5 [1], which says (emphasis mine):
"All certificates that are capable of being used to issue new
certificates, that a
20 matches
Mail list logo