RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

> -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: even after reviewing your extensive responses to the issues
> list, I feel that all the 8 questions on my questions list are still 
> outstanding and
> require answers.
> 
> Thanks :-)
> 
> Gerv

Answer 1:

A. See Symantec response for Issue V 
[https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70].
B. This was a continuation of the first paragraph, referring to Intel, Aetna, 
Unicredit, Google, & Apple. See issue V.
C. For both the RA program and the GeoRoot program clarified in Issue V, KPMG 
focused on our receipt of audit reports from these third parties, continuity 
from previous periods, the audit opinions, and in the cases where there were 
issues identified, Symantec’s plan of action to remediate.

In this case, Symantec and KPMG failed to note that we were missing some of the 
required audits.

Answer 2:

The start dates of our SSL/TLS RA partnerships are all prior to 2010 when 
Symantec acquired the Trust Services business from VeriSign and prior to the 
BRs going into effect. During the period of 2011-2014 we significantly reduced 
the number of these RA partners that could issue SSL/TLS certificates and 
restricted all but CrossCert, Certisur, Certisign, and CertSuperior to perform 
validation for SSL/TLS certificates. We imposed technical measures to prevent 
all SSL/TLS validation and issuance capabilities by all RA’s except for these 
four partners, In 2017 we took the additional step of removing the ability of 
these remaining four partners to issue SSL/TLS certificates which represented a 
complete wind-down of the SSL/TLS RA program.
 
See Item W for more details of the RA program: 
[https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70].

The following affiliates operated as an RA for Symantec SSL/TLS certificates, 
conducting authentication and issuance activities. This list does not include 
additional partners who had been terminated prior to the acquisition of the 
Trust Services business from VeriSign, Inc. in August 2010 as there are no 
unexpired certificates issued by these former partners. The end date referenced 
below is the date of the last SSL/TLS authentication event by the affiliate 
within a customer’s Enterprise RA account. 

As of April 19, 2017 all certificates counted below were certificates issued 
out of domain-constrained Enterprise RA accounts originally authenticated by 
the affiliate. Numbers represent still active certificates issued using the 
authentication work by the affiliate. That issuance, subsequent to the 
affiliate SSL/TLS termination, has been possible leveraging the 39-month data 
validity rule for OV/DV certificates. 

End date in 2017:
Audits at https://bugzilla.mozilla.org/show_bug.cgi?id=1334377

CrossCert
End date: January 19, 2017
Active certificates: 10,603

CertSuperior
End date: April 4, 2017
Active certificates: 4,430

CertiSign
End date: April 11, 2017
Active certificates: 13,521

CertiSur
End date: April 14, 2017
Active certificates: 2,935

-
End date between 2011 - 2014:
These RA for SSL/TLS relationships were wound down as the BR’s went into 
effect. We do not have audits for them. 

Note, while no longer authorized as affiliate RAs for SSL/TLS, many of these 
partners continue to offer SSL/TLS for sale as Symantec resellers. 

Adacom S.A.
End date: November 15, 2012 
Active certificates: 2 

Comsign, Ltd
End date: February 14, 2013 
Active certificates: 15

e-Sign S.A.
End date: March 4, 2013 
Active certificates: 16

iTrusChina
End date: January 11, 2013 
Active certificates: 52

NamITech
End date: November 7, 2012
Active certificates: 167

Telefonica S.A.
End date: February 5, 2014
Active certificates: 88
* Note, in our response on issue T indicated that the RA program for SSL/TLS 
was wound down in 2013. That should have stated 2014 to reflect Telefonica.

MSC Trustgate.com Sdn Bhd
End date: February 8, 2013 
No active certificates

mySecureSign, Inc. 
End date: August 22, 2011 
No active certificates

Safescrypt Ltd
End date: June 25, 2012
No active certificates

NIFTeTrust
End date:  September 6, 2013 
No active certificates

With the exception of Telefonica, all previous org/domain validation data is 
now outside of the 39 month rule. In the case of Telefonica, we are disabling 
use of previously validated org/domain information otherwise still valid under 
the 39 month rule. After this update Symantec will solely authenticate new 
certificate issuance for all of these customer accounts originally 
authenticated by these partners.  

There were also questions regarding issuance controls on RA certificates. In 
our infrastructure 

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

> -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: [EXT] Re: Questions for Symantec
>
> On 03/04/17 13:11, Gervase Markham wrote:
> > Hi Steve and Rick,
>
> Q8) The accountant's letters for the 2015-2016 audits are dated February 28th
> 2017. The audits were supplied to Mozilla, and published, on the 1st of April
> 2017. Why the delay?
>
> Gerv

Proofreading of the reports, corrections, and clarifications took an additional 
four weeks. KPMG provided an explanation of the delay in their explanatory 
letter which has been provided, and which centered on the large scope and 
resulting sheer volume of audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

> -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:
> > Hi Steve and Rick,
>
> Q9) Can you please tell us which audit covers the following two intermediate
> CAs, which are subordinates of or cross-certified by VeriSign Universal Root
> Certification Authority?
>

These Intermediate CAs are sub-CAs under the Verisign Universal Root CA. They 
are covered under Symantec’s Non-Fed SSP audits, and the latest unqualified 
audits that we just received are being published.

The customer-specific CAs (the subordinate ICAs) signed by these sub-CAs are 
path length constrained and operate fully within Symantec’s infrastructure. 
Under the Non-Federal SSP program, they are used to issue certificates for 
Microsoft Windows domain controllers and IPSec endpoints. End entity 
certificates issued under this program are designed only to contain Federal PKI 
policy OIDs and to exclude any CA/B Forum required policy OIDs.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

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.


> -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:
> > Hi Steve and Rick,
>
> Q9) Can you please tell us which audit covers the following two intermediate
> CAs, which are subordinates of or cross-certified by VeriSign Universal Root
> Certification Authority?
>
> VeriSign Class 3 SSP Intermediate CA - G2
>
> Symantec Class 3 SSP Intermediate CA - G3
>
>
> The following period-of-time audit is the most recent one which covers the
> VeriSign Universal Root Certification Authority:
> https://www.symantec.com/content/en/us/about/media/repository/18_Sy
> mantec_STN_WTCA_period_end_11-30-2016.pdf
> However, these certificates are not on the accompanying list of
> intermediates.
>
> Is it correct that these intermediates are unconstrained and fully capable of
> issuing server authentication (SSL/TLS) certificates which are trusted by
> Mozilla browsers?
>
> Thanks,
>
> Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Matt Palmer via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

[Jakob Bohm via dev-security-policy]

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, Section 4.2.1.6.  Subject Alternative Name
   When the subjectAltName extension contains an Internet mail address,
   the address MUST be stored in the rfc822Name.  The format of an
   rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821].
   A Mailbox has the form "Local-part@Domain".  Note that a Mailbox has
   no phrase (such as a common name) before it, has no comment (text
   surrounded in parentheses) after it, and is not surrounded by "<" and
   ">".  Rules for encoding Internet mail addresses that include
   internationalized domain names are specified in Section 7.5.

Note that RFC 2821 was OBSOLETEd by RFC 5321. RFC 5321 Section 4.1.2 states

   Mailbox= Local-part "@" ( Domain / address-literal )
   address-literal  = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
; See Section 4.1.3
   Domain = sub-domain *("." sub-domain)
   sub-domain = Let-dig [Ldh-str]
   Let-dig= ALPHA / DIGIT
   Ldh-str= *( ALPHA / DIGIT / "-" ) Let-dig

Section 4.1.3 states
   IPv4-address-literal  = Snum 3("."  Snum)
   IPv6-address-literal  = "IPv6:" IPv6-addr
   General-address-literal  = Standardized-tag ":" 1*dcontent
   Standardized-tag  = Ldh-str
 ; Standardized-tag MUST be specified in a
 ; Standards-Track RFC and registered with IANA

To confirm, I also checked the IANA registry established, which is
https://www.iana.org/assignments/address-literal-tags/address-literal-tags.xhtml

The only address literal defined is IPv6.

Could you indicate where you believe RFC 5280 supports the conclusion that
a "bang!path" is permitted and relevant to Mozilla products?



The older RFC 2459 allowed the full RFC 822 syntax (minus comments),
which included bang paths.  While RFC 2459 and RFC 822 are obsolete, it
is still possible, sans explicit policy to the contrary, for a CA to
issue valid certificates for this older address type, perhaps as a
service to someone running historic system configurations.

Even them, I think wording is still needed to state that the
"domain"/"address-literal" part of the RFC5321 syntax is the part to
which the "domain name" revocation BRs apply.

Plus there is the additional situation of an e-mail domain
operator/owner telling a CA that an e-mail cert should be revoked for
various reasons (misissued cert, misissued e-mail address, e-mail
address removed from cert holder, possibly others).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

[Ryan Sleevi via dev-security-policy]

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 Name
   When the subjectAltName extension contains an Internet mail address,
   the address MUST be stored in the rfc822Name.  The format of an
   rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821].
   A Mailbox has the form "Local-part@Domain".  Note that a Mailbox has
   no phrase (such as a common name) before it, has no comment (text
   surrounded in parentheses) after it, and is not surrounded by "<" and
   ">".  Rules for encoding Internet mail addresses that include
   internationalized domain names are specified in Section 7.5.

Note that RFC 2821 was OBSOLETEd by RFC 5321. RFC 5321 Section 4.1.2 states

   Mailbox= Local-part "@" ( Domain / address-literal )
   address-literal  = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
; See Section 4.1.3
   Domain = sub-domain *("." sub-domain)
   sub-domain = Let-dig [Ldh-str]
   Let-dig= ALPHA / DIGIT
   Ldh-str= *( ALPHA / DIGIT / "-" ) Let-dig

Section 4.1.3 states
   IPv4-address-literal  = Snum 3("."  Snum)
   IPv6-address-literal  = "IPv6:" IPv6-addr
   General-address-literal  = Standardized-tag ":" 1*dcontent
   Standardized-tag  = Ldh-str
 ; Standardized-tag MUST be specified in a
 ; Standards-Track RFC and registered with IANA

To confirm, I also checked the IANA registry established, which is
https://www.iana.org/assignments/address-literal-tags/address-literal-tags.xhtml

The only address literal defined is IPv6.

Could you indicate where you believe RFC 5280 supports the conclusion that
a "bang!path" is permitted and relevant to Mozilla products?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

[Jakob Bohm via dev-security-policy]

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 fraudulently misleading
subordinate Fully-Qualified Domain Name;"

But that's because such e-mail CAs are effectively wildcards (e.g. they can
issue for subdomains, unless a nameconstraint includes a leading . to
indicate for host not domain)


I believe this is about end certificates, not constrained Intermediary
CA certificates.



But given that e-mail addresses include Domain portions (after all, that is
the definition, localpart@domain), and Fully-Qualified Domain Name doesn't
imply a sAN of type dNSName, this all seems... ok as is?



Technically, the part after the @ could also be a bang!path, though
this is rare these days.

So maybe some wording in the Mozilla e-mail end cert requirements for
how the phrase "Domain Name" in the TLS cert BRs maps to rfc822-names.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

[Ryan Sleevi via dev-security-policy]

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 Domain Name;"

But that's because such e-mail CAs are effectively wildcards (e.g. they can
issue for subdomains, unless a nameconstraint includes a leading . to
indicate for host not domain)

But given that e-mail addresses include Domain portions (after all, that is
the definition, localpart@domain), and Fully-Qualified Domain Name doesn't
imply a sAN of type dNSName, this all seems... ok as is?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

[Gervase Markham via dev-security-policy]

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 relevant
ones? I was particularly thinking of, if memory serves, 4.9.1.1 bullets
4 and 5, both of which use the defined term "Domain Name".

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Patrick Tronnier via dev-security-policy]

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 of GDCA’s 
> CP and CPS with the Baseline Requirements (published on March 25, 2017)” 
> promised to disclose have been included in this version, and we will update 
> the compliance analysis document as soon as possible. Please find the new 
> version at:
> CP V1.6: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860016
> CPS V4.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860018
> EV CP V1.4: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860019
> EV CPS V1.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860020
> 
> We wish these documents will be fully discussed by the public, so that 
> Mozilla can make decision on this root inclusion application.
> All comments and suggestions are welcomed. Thanks.

I updated your bug with a review of your initial BR-self-assessment using the 
previously posted CPS's. The review is attachment 
https://bugzilla.mozilla.org/attachment.cgi?id=8860075. 

Would you please complete a second BR-self-assessment against the just posted 
CPS's and CP's and use my attachment as your starting point? Thank you.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[Ryan Sleevi via dev-security-policy]

+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

Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

[Gervase Markham via dev-security-policy]

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 you prove a CA "knowingly" did this?

How can a CA tell a certificate "appears to be intended for fraudulent
use"? As bad actors don't set the "evil bit", the only way I can think
of that a CA might do this check is by looking at the domain name and
checking to see if it's anything like a "famous" brand. But Mozilla has
taken the position that we don't believe it's the responsibility of CAs
to police the domain name space.

We already have the power to chuck out misbehaving CAs, or not include
ones which are dodgy; we don't need this clause for that either.

So I propose removing it, and reformatting the section accordingly.

This is: https://github.com/mozilla/pkipolicy/issues/2

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Gervase Markham via dev-security-policy]

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 rfc822Name, with at least one name in permittedSubtrees."

Adopted as proposed.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.5 Proposal: Merge Mozilla CCADB policy into main Root Store policy

[Gervase Markham via dev-security-policy]

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
section of the main policy (section 4), and reduce the number of
documents people have to juggle.

This would basically mean copy-pasting the contents of:
https://github.com/mozilla/pkipolicy/blob/master/ccadb/mozilla.md
into section 4 of the main policy, with section numbers, removing the
reference to that dead document from the existing text, and adding
something like:

"Mozilla has requirements for the use of the CCADB above and beyond
those in the Common CCADB Policy, as follows:"

We would then remove mozilla.md from source control.

This is: https://github.com/mozilla/pkipolicy/issues/71

---

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Gervase Markham via dev-security-policy]

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 of constraints which looked like:

".com, .net, .edu, .us, .uk, ..."

The SSL BRs require:

"(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
Applicant has registered the dNSName or has been authorized by the
domain registrant to act on the registrant's behalf in line with the
verification practices of section 3.2.2.4."

That's not possible for e.g. ".com", so the problem is avoided.

Do we need to say that each entry in permittedSubtrees must be a Public
Suffix? Or do we need to require that each rfc822Name is
ownership-validated in a analogous way to the dNSNames in the BRs?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Alex Gaynor via dev-security-policy]

+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:

> 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:
> https://wiki.mozilla.org/index.php?title=CA:Problematic_Practices=
> 92109=92084
>
> I don't believe the issuance of wildcard DV certs is problematic in
> practice. Mozilla is of the view that ubiquitous SSL is the highest
> priority for the Web PKI, and wildcard certs are a part of that. Mozilla
> also doesn't believe that it's the job of CAs to police phishing, which
> is the concern raised.
>
> I propose this section be removed from the document.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

[Gervase Markham via dev-security-policy]

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.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Gervase Markham via dev-security-policy]

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:
https://wiki.mozilla.org/index.php?title=CA:Problematic_Practices=92109=92084

I don't believe the issuance of wildcard DV certs is problematic in
practice. Mozilla is of the view that ubiquitous SSL is the highest
priority for the Web PKI, and wildcard certs are a part of that. Mozilla
also doesn't believe that it's the job of CAs to police phishing, which
is the concern raised.

I propose this section be removed from the document.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Validation quality is failing

[Ryan Sleevi via dev-security-policy]

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 random data in that field?


That Is not common among CAs, because it's not how certificate information
is validated. Perhaps it would be best if you just waited for Jeremy to
respond, rather than attempting to speculate about the system. I appreciate
the eagerness to find answers, but those sorts of speculation don't really
help much.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Validation quality is failing

[Jakob Bohm via dev-security-policy]

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 tomorrow.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Wednesday, April 19, 2017 2:27 PM
To: r...@sleevi.com; Mike vd Ent 
Cc: Ben Wilson ; mozilla-dev-security-policy 

Subject: RE: CA Validation quality is failing

I’m looking into it right now. I’ll report back shortly.



Jeremy



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent 
Cc: mozilla-dev-security-policy ; Jeremy 
Rowley ; Ben Wilson 
Subject: Re: CA Validation quality is failing







On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy 
 > wrote:

Ryan,

My answers on the particular issues are stated inline.
But the thing I want to address is how could (in this case Digicert) validate 
such data and issues certificates? I am investigation more of them and afraid 
even linked company names or registration numbers could be false. Shouldn't 
those certificates be revoked?



You are correct that it appears these certificates should not have issued. 
Hopefully Jeremy and Ben from DigiCert can comment on this thread ( 
https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ
 for the archive) with details about the issues and the steps taken.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Email sub-CAs

[Gervase Markham via dev-security-policy]

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/issues/73

I think I understand your point but if you could expand a bit in the
bug, that would be most welcome.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Validation quality is failing

[Peter Gutmann via dev-security-policy]

Ryan Sleevi  writes:

>For an EV cert, you look in 
>https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf   

It was meant as a rhetorical question, the OP asked whether doing XYZ in an
EV certificate was allowed and I was pointing out that the CAB Forum 
guidelines should provide the answer.  Vincent Lynch's reply was the appropriate
one, pointing out the text that covers this situation.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy