Major +1. Removing this language is consonant with Mozilla objectives, with
Web PKI trends, and with the health of the open web.
-- Eric
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> There is an entry on Mozilla's Poten
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Tuesday, April 11, 2017 6:42 AM
> To: Steve Medin ; Rick Andrews
> ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
>
> Hi Steve and Rick,
>
> Just to confirm: eve
Thanks Mike for bringing this up. We’ve looked into it and have an initial
report to share.
After receiving the email on the Mozilla list, we investigated the identified
certificates and discovered a couple of very related issues in our process that
led to certificates with bad info:
1. As Jako
> -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: Tuesday, April 04, 2017 9:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject:
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Thursday, April 13, 2017 9:13 AM
> To: Steve Medin ; Rick Andrews
> ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
>
> On 03/04/17 13:11, Gervase Markham wrote:
>
Gerv,
In the interest of an easy to read set of responses to your questions and many
submitted in response to our recent posts, we have prepared a PDF and attached
it to the Bugzilla tracking this discussion.
That PDF is available at https://bugzilla.mozilla.org/attachment.cgi?id=8860216.
> -
On Thu, Apr 20, 2017 at 02:02:59PM +0100, Gervase Markham via
dev-security-policy wrote:
> I propose this section be removed from the document.
My name is Matt Palmer, and I endorse this proposal.
- Matt
___
dev-security-policy mailing list
dev-secu
On Thu, Apr 20, 2017 at 02:39:12PM +0100, Gervase Markham via
dev-security-policy wrote:
> So I propose removing it, and reformatting the section accordingly.
Do t. Do t nw!
(That's me strongly agreeing with the proposal, in case my faux-Ren accent
is impenetrable)
- Matt
On 21/04/2017 00:36, Ryan Sleevi wrote:
On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Technically, the part after the @ could also be a bang!path, though
this is rare these days.
No, technically, it could not.
RFC 5280, S
On Thu, Apr 20, 2017 at 6:15 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Technically, the part after the @ could also be a bang!path, though
> this is rare these days.
>
No, technically, it could not.
RFC 5280, Section 4.2.1.6. Subject Alternative N
On 20/04/2017 21:15, Ryan Sleevi wrote:
Gerv,
I must admit, I'm not sure I understand what you consider irrelevant
reasons for 4.9.1 in the context of e-mail addresses.
The only one I can think of is
"7. The CA is made aware that a Wildcard Certificate has been used to
authenticate a fraudulent
Gerv,
I must admit, I'm not sure I understand what you consider irrelevant
reasons for 4.9.1 in the context of e-mail addresses.
The only one I can think of is
"7. The CA is made aware that a Wildcard Certificate has been used to
authenticate a fraudulently misleading
subordinate Fully-Qualified
On 20/04/17 15:10, Jakob Bohm wrote:
> Note that some reasons applicable to domain names would be equally
> applicable to the domain name part of e-mail addresses.
So can you read section 4.9.1 of the BRs and help me to define wording
which excludes the irrelevant items while including all the rel
On Thursday, April 20, 2017 at 9:30:31 AM UTC-4, wangs...@gmail.com wrote:
> We have just published the updated CP/CPS documents, this version has been
> revised according to the latest Baseline Requirements and has been reviewed
> internally, meanwhile, the points our “Analysis on the Compliance
+1 to what sounds like a perfectly reasonable position
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
On 20/04/2017 15:46, Gervase Markham wrote:
Section 6 of the Root Store Policy gives a list of reasons for
revocation, as do the BRs. The BRs list is somewhat more comprehensive
than ours; ours may be an earlier version of theirs.
We should remove the duplication by referencing the list in the B
Section 6 of the Root Store Policy gives a list of reasons for
revocation, as do the BRs. The BRs list is somewhat more comprehensive
than ours; ours may be an earlier version of theirs.
We should remove the duplication by referencing the list in the BRs and
add any extra ones we might need, beari
Section 7.1 of the policy says that we reserve the right not to include
certificates from a CA which has:
"knowingly issue certificates that appear to be intended for fraudulent
use."
There are a few problems with this.
* It's only in the inclusion section.
* It's really subjective - how could y
On 12/04/17 17:02, Gervase Markham wrote:
> Add to the end of that exception sentence ", or refuse audits from
> auditors who do."
Adopted as proposed, with this addition.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
h
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
We currently have 3 policy documents - the main policy, the CCADB
policy, and a "Mozilla CCADB policy", which contains some CCADB stuff
which isn't in the CCADB policy because it's not been agreed by all
CCADB participants.
We should consider whether we can just put that stuff into the CCADB
secti
We have just published the updated CP/CPS documents, this version has been
revised according to the latest Baseline Requirements and has been reviewed
internally, meanwhile, the points our “Analysis on the Compliance of GDCA’s CP
and CPS with the Baseline Requirements (published on March 25, 201
On 12/04/17 10:47, Gervase Markham wrote:
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on rfc822Name, with at least one name in permittedSubtrees."
As worded, this would allow for a set
+1 on removal, that paragraph doesn't square with current ideas about
what's problematic in the WebPKI; as you've noted wildcards and DV are
really orthogonal concerns.
Alex
On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
On 12/04/17 10:47, Gervase Markham wrote:
> The proposal is to add the following bullets to section 3.1.3 ("Public
> Audit Information"), perhaps reordering the list as appropriate:
Adopted as proposed, with the exception (for simplicity) of removing the
option of providing a "SHA1" fingerprint.
There is an entry on Mozilla's Potentially Problematic CA Practices list
for Wildcard DV certs:
https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_Certificates
This text was added by Frank Hecker when this page was very new back in
2008, and has been basically unchanged since then:
On Thu, Apr 20, 2017 at 6:42 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> One thing:
>
> Could this be a result of the common (among CAs) bug of requiring entry
> of a US/Canada State/Province regardless of country, forcing applicants
> to fill in rando
One thing:
Could this be a result of the common (among CAs) bug of requiring entry
of a US/Canada State/Province regardless of country, forcing applicants
to fill in random data in that field?
On 20/04/2017 03:48, Jeremy Rowley wrote:
FYI - still looking into this. I should have a report tomor
On 15/04/17 17:05, Peter Bowen wrote:
> Should the Mozilla policy change to require disclosure of all CA
> certificates issued by an unconstrained CA (but not necessarily
> require audits, CP/CPS, etc)? This would help identify unintentional
> gaps in policy.
https://github.com/mozilla/pkipolicy/i
29 matches
Mail list logo
