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
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
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
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
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
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 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
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 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 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 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 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 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
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 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
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 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 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 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
(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
>>>
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
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
>
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: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 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 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 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
27 matches
Mail list logo
