Thanks, Nick, for the comment on the scope difference in the dnsName
constraints vs. SAN wildcard. I hadn't contemplated that. As you note, the
real risk isn't dissimilar. (I would presume that this is because a CA willing
to issue a SAN dnsName of *.example.com would also presumably issue a
On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman wrote:
> From a perspective of risk to the broader web PKI, it would appear that a
> properly name constrained intermediate with (for example) only the Server
> and Client TLS authentication ekus with name constraints limited to
> particu
On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via
dev-security-policy wrote:
>
> Gerv, thank you for all the effort you have been putting into this
> investigation into Symantec's mis-issuances, and in identifying the best way
> to move forward with the primary goal being to help ke
On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote:
Hi Kathleen. I'm not quite sure how to interpret this part...
- I'm not sold on the idea of requiring Symantec to use third-party CAs to
perform validation/issuance on Symantec's behalf. The most serious concerns
that I have
On 19/05/2017 17:41, Gervase Markham wrote:
Hi m.d.s.p.,
Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and
On 19/05/2017 22:04, Kathleen Wilson wrote:
On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:
I have passed that document to Kathleen, and I hope she will be
endorsing this general direction soon, at which point it will no longer
be a draft.
Assuming she does, this will effec
On Thursday, May 18, 2017 at 10:08:32 AM UTC-7, Kathleen Wilson wrote:
>
> On May 19 the following three breaking changes are planned, meaning that the
> old URLs will no longer work. Any links or bookmarks to these URLs will need
> to be updated. ...
>
> 1) The CA login page and the domain CAs
On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote:
>
> I have passed that document to Kathleen, and I hope she will be
> endorsing this general direction soon, at which point it will no longer
> be a draft.
>
> Assuming she does, this will effectively turn into a 3-way conversati
Not speaking as to the status quo, but rather in terms of updates/changes which
might be considered for incorporation into policy would be to recognize the
benefit of name constrained intermediates and allow a reduction in burden to
entities holding and utilizing name constrained intermediates,
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Friday, May 19, 2017 11:42 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EX
> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy
> wrote:
>
> On 18/05/17 23:40, Nick Lamb wrote:
>> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
>> here? Judging from self-assessment document, TrustCor's actual
>> practices are all intended to be 3.2.2.4
Hi m.d.s.p.,
Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan ha
On 19/05/17 16:06, Inigo Barreira wrote:
> Yes, I wanted to know if a regular user can use its Gmail account to get an
> s/mime cert but that can´t be issued because the CA can´t validate the
> domain properly because it´s not his or authorized to use it when doing the
> 3.2.2.4
This is about tech
On Fri, May 19, 2017 at 11:04 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 19/05/2017 16:15, Gervase Markham wrote:
>
>> On 19/05/17 14:58, Jakob Bohm wrote:
>>
>>> Because the O and other dirname attributes may be shown in an e-mail
>>> client (curre
On 19/05/2017 16:37, Gervase Markham wrote:
On 19/05/17 15:16, Inigo Barreira wrote:
What about those for gmail, Hotmail, etc.? Are out of scope?
I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, be
Yes, I wanted to know if a regular user can use its Gmail account to get an
s/mime cert but that can´t be issued because the CA can´t validate the
domain properly because it´s not his or authorized to use it when doing the
3.2.2.4
Best regards
Iñigo Barreira
CEO
StartCom CA Limited
-Origina
On 19/05/2017 16:15, Gervase Markham wrote:
On 19/05/17 14:58, Jakob Bohm wrote:
Because the O and other dirname attributes may be shown in an e-mail
client (current or future) as a stronger identity than the technical
e-mail address.
Do you know of any such clients?
No, but it would be sim
On Friday, May 19, 2017 at 7:19:27 AM UTC-5, Gervase Markham wrote:
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"
Should we specify somewhere that multi-factor auth encompasses two _different_
factors and not
On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?
I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, because no dirName can cover all of their custom
On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate. They have indicated that the SSP customers have
> some level of issuance capability.
Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.
Gerv
_
On 19/05/17 14:26, Kurt Roeckx wrote:
> I'm wondering why something like this should be in the Mozilla policy
> and not be part of something else that they get audited for.
Section 6.5.1 of the BRs states:
"The CA SHALL enforce multi‐factor authentication for all accounts
capable of directly caus
On Fri, May 19, 2017 at 7:25 AM, Gervase Markham via
dev-security-policy wrote:
> On 15/05/17 21:06, Michael Casadevall wrote:
>
>>> Are there any RA's left for Symantec?
>>
>> TBH, I'm not sure. I think Gervase asked for clarification on this
>> point, but its hard to keep track of who could issu
On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any
On 15/05/17 22:08, Michael Casadevall wrote:
> RA & EV:
> Were all the certificates issued by the RAs uploaded to a CT log? If
> not, what, if any, subsets were uploaded?
>
> I'm aware Symantec was required to upload certificates to CT or if it
> was retroactive, but I'm unsure if that requirement
What about those for gmail, Hotmail, etc.? Are out of scope?
Best regards
Iñigo Barreira
CEO
StartCom CA Limited
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
On 19/05/17 14:58, Jakob Bohm wrote:
> Because the O and other dirname attributes may be shown in an e-mail
> client (current or future) as a stronger identity than the technical
> e-mail address.
Do you know of any such clients?
> Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
On 19/05/2017 15:13, Gervase Markham wrote:
On 08/05/17 11:32, Dimitris Zacharopoulos wrote:
On 8/5/2017 1:18 μμ, Gervase Markham wrote:
+ dirName entries scoped in the Organizational name and
location
Help me understand how dirName interacts with id-kp-emailProtection?
When the Su
We need to have a discussion about the appropriate scope for:
1) the applicability of Mozilla's root policy
2) required disclosure in the CCADB
The two questions are related, with 2) obviously being a subset of 1).
It's also possible we might decide that for some certificates, some
subset of the
On 2017-05-19 14:18, Gervase Markham wrote:
Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:
"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"
to
"enforce multi-factor authentication
On 17/05/17 15:12, Gervase Markham wrote:
On 17/05/17 15:08, Rob Stradling wrote:
Incidentally, it's true that Mozilla have said that they don't care
about the Code Signing trust bit any more, but the
CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low prior
On 08/05/17 11:32, Dimitris Zacharopoulos wrote:
> On 8/5/2017 1:18 μμ, Gervase Markham wrote:
>>> + dirName entries scoped in the Organizational name and
>>> location
>> Help me understand how dirName interacts with id-kp-emailProtection?
>
> When the Subscriber belongs to an Organizati
On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want something
> like this:
>
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on rfc822
At the moment, the CAB Forum's Network Security guidelines are audited
as part of an SSL BR audit. This means that CAs or sub-CAs which only do
email don't technically have to meet them. However, they also have a
number of deficiencies, and the CAB Forum is looking at replacing them
with something
Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:
"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"
to
"enforce multi-factor authentication for all accounts capable of causing
certifica
On 12/05/17 14:00, Gervase Markham wrote:
> Because the Mozilla root store is used by more people than Mozilla,
> Kathleen would like to put anyEKU in scope even though Firefox ignores it.
Implemented as specced.
Gerv
___
dev-security-policy mailing lis
On 12/05/17 14:21, Gervase Markham wrote:
> Specifically, we could add text to the top of section 5.2 ("Forbidden
> and Required Practices"):
>
> "CA operations MUST at all times be in accordance with the applicable CP
> and CPS."
Implemented as specced.
Gerv
On 12/05/17 18:54, Jakob Bohm wrote:
> Perhaps tweak the wording to make the document submitted to the CCADB
> binding, rather than any CP/CPS published elsewhere.
While that certainly seems attractive, changing the location of the
canonical CP/CPS from the CA's repository to Mozilla's repository
On 12/05/17 14:18, Gervase Markham wrote:
> I propose instead:
>
> "Changes that are motivated by a security concern such as certificate
> misissuance or a root or intermediate compromise MUST be treated as a
> security-sensitive, and a secure bug filed in Bugzilla.
Implemented as proposed.
Gerv
On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it mig
39 matches
Mail list logo