On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy
wrote:
> On 05/05/2017 22:45, Dimitris Zacharopoulos wrote:
>>
>>
>>
>> On 5/5/2017 10:58 μμ, Peter Bowen wrote:
>>>
>>
>> I don't know if all implementations doing path validation, use the EKUs
>> at the CA level but it seems that
On 05/05/2017 22:45, Dimitris Zacharopoulos wrote:
On 5/5/2017 10:58 μμ, Peter Bowen wrote:
On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:
On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacha
On 5/5/2017 10:58 μμ, Peter Bowen wrote:
On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:
On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
Looking at
On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
>
>
> On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:
>>
>> On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
>> dev-security-policy wrote:
>>>
>>> Looking at https://github.com/mozill
On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote:
On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
Looking at https://github.com/mozilla/pkipolicy/issues/69
do you have a proposed language that takes all comments into account? From
what I u
On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
>
> Looking at https://github.com/mozilla/pkipolicy/issues/69
>
> do you have a proposed language that takes all comments into account? From
> what I understand, the Subordinate CA Certificate to be considered
>
Looking at https://github.com/mozilla/pkipolicy/issues/69
do you have a proposed language that takes all comments into account?
From what I understand, the Subordinate CA Certificate to be considered
Technically Constrained only for S/MIME:
* MUST include an EKU that has the id-kp-emailProt
(Resending as the attached file was too large)
On Fri, May 5, 2017 at 10:46 AM, Peter Bowen wrote:
> On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via
> dev-security-policy wrote:
>> On 15/04/17 17:05, Peter Bowen wrote:
>>> Should the Mozilla policy change to require disclosure of all CA
>>>
On 05/05/2017 17:37, Gervase Markham wrote:
On 04/05/17 19:30, Jakob Bohm wrote:
1. Issue D actually seems to conflate three *completely different*
issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
I am referring to the "summary" of D in
On Fri, 5 May 2017 17:18:38 +0100
Gervase Markham via dev-security-policy
wrote:
> On 05/05/17 17:09, Peter Bowen wrote:
> > We know that the RAs could use different certificate profiles, as
> > certificates they approved had varying issuers, and "Issuer DN" has
> > the same "No(1)" that CP has i
On Fri, May 5, 2017 at 9:18 AM, Gervase Markham wrote:
> On 05/05/17 17:09, Peter Bowen wrote:
>> We know that the RAs could use different certificate profiles, as
>> certificates they approved had varying issuers, and "Issuer DN" has
>> the same "No(1)" that CP has in the table in the doc you lin
On 05/05/17 17:09, Peter Bowen wrote:
> We know that the RAs could use different certificate profiles, as
> certificates they approved had varying issuers, and "Issuer DN" has
> the same "No(1)" that CP has in the table in the doc you linked. I
> don't see any indication of what profiles each RA w
On 01/05/17 09:55, Gervase Markham wrote:
> "Each entry in permittedSubtrees must either be or end with a Public
> Suffix." (And we'd need to link to publicsuffix.org)
Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual
domain owned by someone.
> The second option is harder to
CrossCert appear to be issuing BR-noncompliant certs under KISA roots now:
https://crt.sh/?cablint=101&iCAID=40347&opt=cablint
We don't trust KISA as it's a Super-CA:
https://crt.sh/?caid=55&opt=cablint
https://bugzilla.mozilla.org/show_bug.cgi?id=335197
https://bugzilla.mozilla.org/show_bug.cgi?i
On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via
dev-security-policy wrote:
> On 04/05/17 21:58, Ryan Sleevi wrote:
>
> I asked Symantec what fields CrossCert had control over. Their answer is
> here on page 3:
> https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
> It says CrossCer
On 05/05/17 04:30, Steve Medin wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
It feels somewhat strange to have this disjointed blog-vs.f
On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the
evidence that there were issues
> and patterns that were unresolved, and thus sought to minimize the impact
> of an eventual total distrust in a gradual way.
So the first Chrome proposal had the explicit target of an eventual
total
On 04/05/17 19:30, Jakob Bohm wrote:
> 1. Issue D actually seems to conflate three *completely different*
> issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
> 2. If the remaining unconstrained SubCAs are operated by Symantec and
> subject t
On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote:
On 05/05/17 10:22, Rob Stradling wrote:
Mozilla could CNAME from ccadb.org to .force.com, and then
declare that the ccadb.org URLs are the official ones.
It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an intr
On 05/05/17 10:22, Rob Stradling wrote:
> Mozilla could CNAME from ccadb.org to .force.com, and then
> declare that the ccadb.org URLs are the official ones.
It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an introductory website for the CCADB, once Mozilla IT
configures things
On 04/05/17 18:42, Kathleen Wilson wrote:
> Gerv is leading the effort to clean up Mozilla's Root Store related
> wiki pages.
With lots of help from Kathleen :-)
> Please let me know if information that you need disappears, and you
> are not able to find it by starting with https://wiki.mozilla.o
It is clear to me from reading this that there is a significant gap between
Symantec's perspective on the severity of the issues discussed and the
perspective of many m.d.s.p. participants. Hopefully this email will serve
to highlight some specific areas that contribute to this gap, and which
leads
On 2017-05-04 22:55, Alex Gaynor wrote:
I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.
The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or th
Yes
On Fri, May 5, 2017 at 2:22 AM Rob Stradling
wrote:
> On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
> > On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
> > dev-security-policy wrote:
> >> All,
> >>
> >> I think it is time for us to change the domains that we are using fo
Steve,
I am glad to see that Symantec is willing to continue public discussion on
possible paths forward. But these responses still seem to continue to focus on
the RA issue, and do not respond to or address all of the other serious issues
identified here. For example, issue Y (Q9) -- un- or un
Steve,
Thank you for the prompt response, and I am glad this certificate was in fact
validated internally by Symantec.
On Tuesday, May 2, 2017 at 6:55:13 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin
On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote:
On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via
dev-security-policy wrote:
All,
I think it is time for us to change the domains that we are using for the CCADB
as follows.
Change the links for...
1) CAs to login to the CCAD
27 matches
Mail list logo