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

[Matt Palmer via dev-security-policy]

On Fri, Apr 21, 2017 at 02:12:51AM -0700, Nick Lamb via dev-security-policy 
wrote:
> On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham  wrote:
> > I propose this section be removed from the document.
> 
> I am not so sure the section ought to be removed. Wildcard DV is
> potentially problematic.  Historically we have seen problems that wouldn't
> have happened or would be much less serious without Wildcard DV issuance. 
> In particular because domain "validation" for the wildcard is sketchy.

Can you remind me (and the list) what specific instances you're referring
to?

- Matt

-- 
A woman in liquor production / Owns a still of exquisite construction.
The alcohol boils / Through magnetic coils.
She says that it's "proof by induction."
-- http://limerickdb.com/?34

___
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 Fri, Apr 21, 2017 at 04:09:57AM -0700, Nick Lamb via dev-security-policy 
wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for
> verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> controls a web server, it seems quite likely they have neither the legal
> authority nor the practical ability to control servers with other names in
> that domain.  I can see arguments either way for 3.2.2.4.4, depending on
> how well email happens to be administrated in a particular organisation.
> 
> That adds up to an opportunity for someone to get a nasty surprise, one
> rogue employee at a cheap shared host can turn their ability to pass
> 3.2.2.4.6 for a brochureware site on www.example.com into a working
> *.example.com wildcard that can MitM SMTP, HTTPS-based APIs, VPNs, any
> sort of TLS traffic at all into any name in example.com.

Didn't a CA get caught fairly recently issuing certs with sAN:example.com
when the validation was for www.example.com, and got a stern talking to as a
result?  I vaguely recall something about that, but not with enough detail
to trawl the archives looking for it.

At any rate, I don't believe the BRs permit such an issuance.  At most, if
someone demonstrated control of www.example.com they would be able to get a
cert for sAN:*.www.example.com (which is still not great, but not quite the
complete disaster getting one for sAN:*.example.com would be).  If your read
of the BRs indicates otherwise, I'd be interested in your reasoning.

That being said, I certainly agree that demonstrating control of a website
is not *nearly* the same thing as demonstrating control over DNS, and I
wouldn't be a sad panda if demonstrating control over a website didn't
permit wildcard issuance.  Perhaps Mozilla policy (or the BRs) could
differentiate between "wildcard-permitted" vs "literal FQDN only" validation
methods?  That would, presumably, be applied independent of DV/OV validation
grade.

- Matt

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

Re: Extend deadline for April 2017 CA Communication?

[Kathleen Wilson via dev-security-policy]

> might be able to capture freeform text (perhaps unattributed) as to why

Sure, below is a summary in my own words of why CAs are asking for an 
extension. Note that the April 2017 survey has many more action items than 
previous CA Communications, so I think it is reasonable that CAs might need 
more time to prepare all the answers. 

- people out-of-office who are needed to respond to the survey (vacations, 
business, health)

- in the middle of an audit, so the people who are needed to respond to the 
survey are extremely busy

- in the middle of data center upgrade/move, so the people who are needed to 
respond to the survey are extremely busy

Kathleen

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

Re: Extend deadline for April 2017 CA Communication?

[Ryan Sleevi via dev-security-policy]

That sounds reasonable.

I think it'd be useful to consider, in granting this extension, if you
might be able to capture freeform text (perhaps unattributed) as to why
these CAs need more time. This might help improve the process in the future
without running the risk of coordinated non-answering :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Extend deadline for April 2017 CA Communication?

[Kathleen Wilson via dev-security-policy]

All,

I've been receiving requests from CAs for an extension to when they need to 
respond to the April 2017 CA Communication.

https://wiki.mozilla.org/CA:Communications#April_2017
"To respond to this survey, login to the Common CA Database (CCADB), click on 
the 'CA Communications (Page)' tab, and select the 'April 2017 CA 
Communication' survey. Please enter your response by April 28, 2017."

I propose that we extend the response date one week, to May 5, 2017.

Please let me know if you foresee any problems with this.

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

Re: Certificate issues

[Nick Lamb via dev-security-policy]

On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm  wrote:
> I believe the point was to check the prospective contents of the
> TBSCertificate *before* CT logging (noting that Ryan Sleevi has been
> violently insisting that failing to do that shall be punished as
> harshly as actual misissuance) and *before* certificate signing.

I come to this as always as someone focused on prevention of future harm. I 
can't speak for Ryan but I'm not interested in "punishing" anybody because 
retribution does not avoid future harm in itself. For example distrust of a CA 
is not a "punishment" of that CA, but a step taken to protect relying parties 
from certificates which shouldn't exist.

Detecting already bad situations still counts as prevention of future harm, 
this is because almost always the bad situation might get worse if undetected. 
This is why we fit smoke alarms - it would be bad if my flat was on fire, but 
it would be much worse if in the absence of an alarm it simply burned down with 
me inside it.

If some CA comes to m.d.s.policy twice a year with a problem where a 
certificate was issued that shouldn't have been, but they've cured it and 
altered their systems so that won't happen again - I can't say I'm ecstatic to 
see that, but at least they're paying attention.

In contrast if they're here twice a year because an independent researcher 
found a year-old certificate that shouldn't exist, and Gerv has to ask them for 
comment, then they investigate what went wrong and promise to cure it, I have 
to say I look on that much less kindly, and I suspect Ryan does too.
___
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

[Eric Mill via dev-security-policy]

On Thu, Apr 20, 2017 at 8:04 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > -Original Message-
> > 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.
>

For reference, the two links Gerv referenced were for unexpired
certificates issued by these two sub-CAs:

https://crt.sh/?Identity=%25=1384=expired
https://crt.sh/?Identity=%25=12352=expired

"pathlen:0" displays on crt.sh as a basic constraint for all certificates
listed there.

The FPKI cross-signs at issue in Issue L are now expired (and so don't show
on the links above). They do show when expired certificates are included --
there are 6 of them with OU=FPKI:
https://crt.sh/?Identity=%25=1384

Each of those certificates lack a pathlen:0 constraint, and appear to be
the only ones that do. Symantec noted that they are path length constrained
in their response, but since they also referenced Federal PKI policy OIDs
(which are not respected by Web PKI clients), I thought it was worth being
explicit about the difference between the certificates referenced here and
those referenced in Issue L.

-- Eric
___
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"

[Eric Mill via dev-security-policy]

I strongly support removing any ambiguity about CAs not being required to
police certificate issuance, and agree on the unuseful level of
subjectivity that would be present in any attempt to enforce this clause.

-- Eric

On Thu, Apr 20, 2017 at 7:11 PM, Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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



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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

[blake.morgan--- via dev-security-policy]

On Thursday, March 16, 2017 at 11:00:51 AM UTC, Gervase Markham wrote:
> Hi Blake,
> 
> On 02/03/17 16:26, blake morgan wrote:
> > We have engaged with our external auditors in relation to this and the 
> > previous certificate that was reported. Once that activity has concluded we 
> > will be providing further information.
> 
> Do you have an ETA for this incident report? It's been quite some time
> now. I am still interested to understand how a "full investigation" of
> the first certificate failed to turn up the second.
> 
> Gerv

Hi Gerv,

Following further discussion with, and guidance from Mozilla, it has been 
determined that the getset.trustis.com certificate issued in November 2016 was 
a mis-issuance.  This incident has highlighted an ambiguity arising from the 
mismatch of scope between CAB Forum BRs v1.3 and Mozilla CP v2.3.  It is useful 
to note that the Mozilla CP v2.4 provides revised wording which represents an 
improvement in this regard. 

However, it is suggested that careful attention is given when issuing 
certificates which fall outside the scope of CAB Forum BRs, but may 
nevertheless be subject to provisions of the CAB Forum BRs under the Mozilla 
CP.  

In support of improving clarity Mozilla has posted an issue here 
https://github.com/mozilla/pkipolicy/issues/72.

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

Re: Symantec Conclusions and Next Steps

[Ryan Sleevi via dev-security-policy]

On Fri, Apr 21, 2017 at 6:16 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I've updated the Issues list:
> https://wiki.mozilla.org/CA:Symantec_Issues
> with the latest information. 3 issues have been marked as STRUCK due to
> lack of evidence of anything actually being wrong - including,
> importantly, the suggestion that they have unaudited unconstrained
> intermediates (further audits have been published).
>

Gerv,

I would encourage you to talk to Kathleen before considering that matter
resolved, because it is different than the advice and requirements that
have been given to other CAs, and to the work required of them.

For example, as you know, Mozilla required that the Belgian subordinates
previously under the Verizon brands, now under Digicert, under go a BR
audit to attest that no SSL certificates have been issued. This is not the
only CA, but it was merely the most recent for which such a requirement was
made - of both the sub-CA and the parent CA. The conclusion to strike this
would thus be be an inconsistent application of Mozilla policy. I believe
you're on some of those threads.

The audits provided are also not consistent with the Mozilla Root Program
requirements, which define technical capability of issuance and the
appropriate audit standards. Specifically, section 5.3 of the policy
appears to provide unambiguous clarification that the audit scheme used for
these sub-CAs, and their sub-CAs, is not consistent with Mozilla policy,
and this non-consistency has been made clear to other CAs with a
requirement for remediation or revocation.
___
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

[Nick Lamb via dev-security-policy]

On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham  wrote:
> This is all a bit inchoate :-) Can you give me any idea at all of what
> such a policy would look like? Requiring OV is not an option IMO.

Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be 
proposing that policy, rather than expressing my concern that just removing 
this from the problematic list isn't solving a real problem.

I have no interest in requiring OV for wildcards. The two things have nothing 
to do with each other, so that wouldn't make any sense.

Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for 
verifying that the applicant controls the entire domain and thus *.example.com, 
whereas say 3.2.2.4.6 proves only that the applicant controls a web server, it 
seems quite likely they have neither the legal authority nor the practical 
ability to control servers with other names in that domain. I can see arguments 
either way for 3.2.2.4.4, depending on how well email happens to be 
administrated in a particular organisation.

That adds up to an opportunity for someone to get a nasty surprise, one rogue 
employee at a cheap shared host can turn their ability to pass 3.2.2.4.6 for a 
brochureware site on www.example.com into a working *.example.com wildcard that 
can MitM SMTP, HTTPS-based APIs, VPNs, any sort of TLS traffic at all into any 
name in example.com.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Conclusions and Next Steps

[Kurt Roeckx via dev-security-policy]

On Fri, Apr 21, 2017 at 11:16:56AM +0100, Gervase Markham via 
dev-security-policy wrote:
> Minor:
> Issue B: Issuance of 1024-bit Certificate Expiring After Deadline

I'm still concerned that they don't seem to have an idea of what
software they're all (still) running, and they didn't reply to any
question about it.


Kurt

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

Symantec Conclusions and Next Steps

[Gervase Markham via dev-security-policy]

The deadline for Symantec to submit comments passed yesterday; they
chose to issue a large PDF[0] of responses just before the deadline,
leaving no time for further discussion and clarification. That's their
right, of course, but it may leave some places where we have to make
assumptions.

I've updated the Issues list:
https://wiki.mozilla.org/CA:Symantec_Issues
with the latest information. 3 issues have been marked as STRUCK due to
lack of evidence of anything actually being wrong - including,
importantly, the suggestion that they have unaudited unconstrained
intermediates (further audits have been published).

I would assess the situation now as follows:

Major:
Issue D: Test Certificate Misissuance
Issue L: Cross-Signing the US Federal Bridge
Issue P: UniCredit Sub CA Failing To Follow BRs
Issue T: CrossCert Misissuances
Issue V: GeoRoot Program Audit Issues
Issue W: RA Program Audit Issues

Intermediate:
Issue Q: Symantec Audit Issues 2016
Issue J: SHA-1 Issuance After Deadline, Again

Minor:
Issue B: Issuance of 1024-bit Certificate Expiring After Deadline
Issue E: Domain Validation Vulnerability
Issue H: SHA-1 Issuance After Deadline
Issue N: Premature Manual Signing Using SHA-1

Informational:
Issue F: Symantec Audit Issues 2015

Struck:
Issue R: Insecure Issuance API
Issue X: Incomplete RA Program Remediation
Issue Y: Unaudited Unconstrained Intermediates

Symantec have also written to Mozilla to say the following:

"We have been working hard on a thorough and thoughtful proposal that
responds to community questions and concerns regarding our compliance
and issuance practices. In drafting this proposal, we’ve thoughtfully
considered the feedback posted on the Mozilla forums along with comments
on the Google forums and other community feedback. We’ve also solicited
input from our customers who are the ones that would bear the impact of
changes, whether as a result of our proposal or any other.

We plan to send a proposal for Mozilla’s and the community’s
consideration on Wednesday April 26th that addresses these important areas:

* The Integrity of our EV Validation Process
* Validity of Existing Certificates
* Increased Transparency
* Move to Shorter Validity Certificates
* Continuous Improvement of our CA Operations"

This date is in the middle of next week. We permitted WoSign to propose
a remediation plan; I think it is reasonable to do the same for
Symantec. So we will wait to hear what they have to say, and then
discuss appropriate action in the light of it.

Gerv

[0] https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216
___
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

[Gervase Markham via dev-security-policy]

On 21/04/17 10:12, Nick Lamb wrote:
> I'm not so uncomfortable with it that I want Mozilla to try to get it
> stopped, but I think signalling some residual discomfort here is
> worthwhile until somebody has thought through a good policy, and
> preferably at least got the big CAs to go along with it in principle
> even if we don't have it in formal Mozilla policy or the BRs.

This is all a bit inchoate :-) Can you give me any idea at all of what
such a policy would look like? Requiring OV is not an option IMO.

Are we going to do anything differently, today, for a CA who issues DV
wildcard certs compared to one who is not? I don't believe so. And if
that's the case, I can't see any value in having this issue on the list.

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

[Henri Sivonen via dev-security-policy]

On Thu, Apr 20, 2017 at 4:02 PM, Gervase Markham via
dev-security-policy  wrote:
> 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.

I support this proposal.

To get code isolation in a browser, you have to have different origins
for the things you are isolating from each other. A security system
(like Sandstorm.io) can mint new origins by minting hostnames. Even
with ACME, getting a non-wildcard cert for each throw-away
on-demand-minted hostname doesn't make sense in terms of CA latency
and CA rate limits.

A wildcard cert solves this, and the solution should be broadly
available (not just to those who pay for OV).

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
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

[Nick Lamb via dev-security-policy]

On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham  wrote:
> I propose this section be removed from the document.

I am not so sure the section ought to be removed. Wildcard DV is potentially 
problematic. Historically we have seen problems that wouldn't have happened or 
would be much less serious without Wildcard DV issuance. In particular because 
domain "validation" for the wildcard is sketchy.

While of course the Ballot 169 rules are a big improvement, I'm really not sure 
I'm comfortable with the implication today that well, we did one of the Ballot 
169 checks for example.com, so now we'll issue for *.example.com and everything 
is just fine.

I'm not so uncomfortable with it that I want Mozilla to try to get it stopped, 
but I think signalling some residual discomfort here is worthwhile until 
somebody has thought through a good policy, and preferably at least got the big 
CAs to go along with it in principle even if we don't have it in formal Mozilla 
policy or the BRs.
___
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

[Eric Mill via dev-security-policy]

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



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