The wisdom of private domain redaction

[Ben Laurie]

As I hope people are aware, RFC 6962-bis contains a mechanism for
redacting parts of private domains.

I have been suggesting informally that we would backport this feature
to the existing CT logs, and may even have suggested we may allow it
for the initial EV/CT rollout.

I've been looking a bit more closely at EV requirements, and it seems
this idea is problematic.

In particular (see
https://cabforum.org/wp-content/uploads/EV-SSL-Certificate-Guidelines-Version-1.5.0.pdf):

1. EV has, amongst its aims, "Make it more difficult to mount phishing
and other online identity fraud attacks using Certificates"
(2.1.2(1)). Domains of the form paypal.example.com are used for this
purpose. Name redaction would hide such domains.

2. EV forbids wildcard certificates (9.2.2). Name redaction would
allow these to be hidden

3. "EV Certificates MAY include Domain Names containing mixed
character sets only in compliance with the rules set forth by the
domain registrar." (11.6.1(2)). Name redaction prevents verification
of this requirement.

4. 11.11.1 observes that 11.5 of the Baseline Requirements also apply
to EV certificates. 11.5 says that "high risk" certificates should get
extra checking - in other words, similar to 2.1.2(1) in the EV
requirements.

Note that 11.5 of the BR also apply to DV certificates, calling into
doubt the applicability of name redaction to those, too - though
clearly that is not something we need to nail down right now.

I invite comments, but right now my feeling is that these requirements
mean that allowing name redaction for EV would defeat the purpose of
CT (i.e. allowing verification of the correct issuance of
certificates).

I apologise for any confusion my poor understanding of the
requirements may have caused.

[Eran Messeri]

RFC6962-bis also specifies the use of name-constrained intermediate CA certificates (section 3.2.3.).

Is it reasonable to assume that this mechanism couldn't be used for EV certificates either, given the requirements outlined below?

[Ryan Sleevi]

A name constrained intermediate is functionally equivalent to a wildcard cert.

As it stands, any name-constrained intermediates should likely be subject to the same auditing and technical rigeur as the CAs infrastructure.

So no, I believe that not only are constrained sub-CAs not viable within the letter of the EVGs, but they are also strongly non-desirable within the spirit of them.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/9e0ddffb-6d23-4aa4-b1c7-df8b1da6df68%40chromium.org.

[Kathleen Wilson]

This was brought to my attention in the mozilla.dev.security.policy discussion forum, so I would like to add my 2 cents.

I understand why a customer would not want their "internal" domain (like billing.example.com) to be public.

But, on the other hand, I do not understand why they would need EV treatment for an internal site like that. For such an internal site, they already know who the O/OU is.

For DV, *.example.com is allowed, so allowing <PRIVATE>.example.com doesn’t add risk.

But wildcards are not allowed for EV, so I don’t think we should reduce our ability to use CT by allowing <PRIVATE>.example.com.

So, I agree with Ben’s proposal that <PRIVATE>.example.com is OK for DV, but not for EV.

Kathleen

[Rob Stradling]

Ben, thanks for doing this analysis. My conclusion is that private
domain redaction does weaken CT-for-EV to some extent, but I wouldn't go
as far as saying it defeats its purpose. (For example, you can still
detect misissuances for <whatever>.google.com).

I wrote the current 6962-bis text for the private domain redaction
mechanism because it solves the only major objection to CT that I was
hearing from my colleagues at Comodo. I want to see CT succeed, and
this mechanism seemed necessary to ensure that success.

If you don't implement private domain redaction for the initial EV/CT
rollout, then I guess we'll have to give our EV cert customers the
option to instruct us to _not_ generate a Precertificate and/or send
their EV certs to the logs. We would have to make it clear to them that
selecting this option means losing the EV indicator in Chrome.

Or, maybe we could thrash out a compromise...

Consider the approach CABForum has taken over the practice of issuing
certs with internal server names:
1. Recognize that it's not best practice.
2. Accept the reality: it's widely deployed.
3. Don't kill it immediately, but instead declare a sunset date, so
that affected cert holders can transition to using Internet domain names
instead.

Or consider CABForum's approach to non-critical Name Constraints or
phasing out SHA-1 certificate signatures: using critical Name
Constraints today is a non-starter, forcing all certs to be signed using
SHA-2 today is a non-starter. The solution? Move the dial a little
away from Security and towards Useability, intending to move it back
towards Security at a later date, when it becomes feasible to do so.

Or consider Google's approach to hard-fail online revocation checking in
Chrome: Ignore BRs section 18.2, because the Useability of hard-fail
sucks! Move the dial a little away from Security...

Anyway, my best-compromise-I-can-think-of proposal...
1. Accept the reality that private domain names are widely deployed.
2. Implement the private domain redaction mechanism in the initial
rollout of CT/EV in Chrome (and leave it in 6962-bis).
3. Set a sunset date N years in the future, after which Chrome will
no longer support the private domain redaction mechanism.

What do you think?

[Ryan Sleevi]

On Wed, Aug 13, 2014 at 1:52 PM, Rob Stradling <robs...@gmail.com> wrote:

Ben, thanks for doing this analysis.  My conclusion is that private domain redaction does weaken CT-for-EV to some extent, but I wouldn't go as far as saying it defeats its purpose.  (For example, you can still detect misissuances for <whatever>.google.com).

I wrote the current 6962-bis text for the private domain redaction mechanism because it solves the only major objection to CT that I was hearing from my colleagues at Comodo.  I want to see CT succeed, and this mechanism seemed necessary to ensure that success.

If you don't implement private domain redaction for the initial EV/CT rollout, then I guess we'll have to give our EV cert customers the option to instruct us to _not_ generate a Precertificate and/or send their EV certs to the logs.  We would have to make it clear to them that selecting this option means losing the EV indicator in Chrome.

Or, maybe we could thrash out a compromise...

Consider the approach CABForum has taken over the practice of issuing certs with internal server names:
  1. Recognize that it's not best practice.
  2. Accept the reality: it's widely deployed.
  3. Don't kill it immediately, but instead declare a sunset date, so that affected cert holders can transition to using Internet domain names instead.

Or consider CABForum's approach to non-critical Name Constraints or phasing out SHA-1 certificate signatures: using critical Name Constraints today is a non-starter, forcing all certs to be signed using SHA-2 today is a non-starter.  The solution?  Move the dial a little away from Security and towards Useability, intending to move it back towards Security at a later date, when it becomes feasible to do so.

Hi Rob,

These are both excellent examples... of where Chromium policy and the CA/Browser Forum have ultimately disagreed on suitable time-frames.

For example, Chromium now warns users of internal server names issued from publicly trusted CAs. Soon, this will become a hard error. This is well in advance of the CA/Browser Forum's sunset, but we believe it's an important part of ensuring our users security.

Similarly, "very soon" (i.e. by Chrome 39, more than likely), Chromium will begin warning users whose end-entity certificates are signed with SHA-1 based algorithms whose validity periods exceed the sunsets, and treating such content as mixed content (requiring users to click through). This is not as strong as an interstitial, but it's also not misleading. Based on a recent analysis of data from the Pilot CT log, it seems that Comodo is still issuing these certificates (I see 37,789 certificates valid beyond the 1/1/2017).

We announced these plans for SHA-1 back during the CA/Browser Forum's Mountain View Face to Face, in the hope this would spur CA's to helping ensure these certificates were transitioned away from, but that's unfortunately not the case. Indeed, we've seen several CAs increasing the relative number of SHA-1 certs they issue, compared to the alternatives.

 

Or consider Google's approach to hard-fail online revocation checking in Chrome: Ignore BRs section 18.2, because the Useability of hard-fail sucks!  Move the dial a little away from Security...

Anyway, my best-compromise-I-can-think-of proposal...
  1. Accept the reality that private domain names are widely deployed.
  2. Implement the private domain redaction mechanism in the initial rollout of CT/EV in Chrome (and leave it in 6962-bis).
  3. Set a sunset date N years in the future, after which Chrome will no longer support the private domain redaction mechanism.

What do you think?

I think it's important to note the difference between what is technically possible, and what is in line with Chromium's security goals for its EV program (and, in general, for the handling of certificates).

You seem to have focused on Google being able to detect <private>.google.com, which is certainly an important property of CT. I can definitely say that our server folks are definitely ready to be able to detect CA misissuance for Google properties, as that's unfortunately been far to common, especially of late.

However, that's only one aspect of CT, and only one reason why Chrome/Chromium is adopting it.

Another reason, far more common than misissuance of a google.com certificate, is a CA failing to adhere to its CP/CPS or to the Baseline Requirements or EV Guidelines. These failures undermine the most core element of the system - trust - and we need to take steps to restore that. From my perspective, CT is a tool to help us (the Chromium Authors) ensure that CAs are conforming to our EV inclusion policy, which includes conformance to the EV guidelines.

The private name redaction prevents us from being able to monitor this, and we have enough evidence just from the crawls that Google has done to believe that third-party audits are no longer sufficient. Even for the BRs, you can see this is often insufficient ( http://news.netcraft.com/archives/2013/09/23/certificate-authorities-struggle-to-comply-with-baseline-requirements.html)

Because of this, and because we so highly value open-discourse and transparency, I don't think it's in the interest of the Chromium program to support these redacted names for EV, even if/when we were to adopt support for 6962-bis in both policy and implementation.

As for sunset periods, we announced our CT plans some time ago, and have repeated these announcements for a while. I think we're absolutely committed to exploring name redactions, particularly for DV certificates, where they're indistinguishable from wildcard certs or name constraints, but I think our transition to CT for EV serves as the effective sunset period for these sorts of certs. It's equally unlikely, at present, that our whitelist will be containing these redacted certs - only certs that have been publicly logged - so I think this would be entirely consistent with the message we've been communicating.

If/when we're able to get to a point where we require SCTs for DV as well, I think it's likely that certificates with an EV policy OID, but that use name redaction, will be downgraded to DV certificates, the same as EV certificates without SCTs will be downgraded to DV, and similar to how certificates from an recognized EV root but lacking the EV policy OID are also downgraded.

[Rob Stradling]

On 13/08/14 22:23, Ryan Sleevi wrote:
> On Wed, Aug 13, 2014 at 1:52 PM, Rob Stradling <robs...@gmail.com

<snip>

> Or, maybe we could thrash out a compromise...
>
> Consider the approach CABForum has taken over the practice of
> issuing certs with internal server names:
> 1. Recognize that it's not best practice.
> 2. Accept the reality: it's widely deployed.
> 3. Don't kill it immediately, but instead declare a sunset date,
> so that affected cert holders can transition to using Internet
> domain names instead.
>
> Or consider CABForum's approach to non-critical Name Constraints or
> phasing out SHA-1 certificate signatures: using critical Name
> Constraints today is a non-starter, forcing all certs to be signed
> using SHA-2 today is a non-starter. The solution? Move the dial a
> little away from Security and towards Useability, intending to move
> it back towards Security at a later date, when it becomes feasible
> to do so.
>
> Hi Rob,
>
> These are both excellent examples... of where Chromium policy and the
> CA/Browser Forum have ultimately disagreed on suitable time-frames.

Ah yes. Good point.

> For example, Chromium now warns users of internal server names issued
> from publicly trusted CAs. Soon, this will become a hard error. This is
> well in advance of the CA/Browser Forum's sunset, but we believe it's an
> important part of ensuring our users security.
>
> Similarly, "very soon" (i.e. by Chrome 39, more than likely), Chromium
> will begin warning users whose end-entity certificates are signed with
> SHA-1 based algorithms whose validity periods exceed the sunsets, and
> treating such content as mixed content (requiring users to click
> through). This is not as strong as an interstitial, but it's also not
> misleading.

I wasn't at the CABForum Mountain View F2F, but I did see
https://code.google.com/p/chromium/issues/detail?id=401365 that you
filed a few days ago.

> Based on a recent analysis of data from the Pilot CT log, it
> seems that Comodo is still issuing these certificates (I see 37,789
> certificates valid beyond the 1/1/2017).

Yes. I presume you're aware that Microsoft intends to "Re-examine the
impact of this Policy at mid-term" [1] and that CABForum hasn't set a
SHA-1 sunset date yet.

Chrome 39 is indeed "very soon" (1.5 months from now? [2]) to be doing
this! To repeat: CABForum hasn't set a sunset date yet, Microsoft
intend to review the impact of their plans, and Microsoft haven't
announced any plans to treat SHA-1 certs with notAfter dates exceeding
the "sunset" date as mixed-content.

I would love to see the back of SHA-1, but with your aggressive
timescale I think you are going to catch most CAs and most of their
customers by surprise!

[1]
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

[2] http://www.chromium.org/developers/calendar

<snip>

> I think we're absolutely committed to exploring name redactions,
> particularly for DV certificates, where they're indistinguishable from
> wildcard certs or name constraints, but I think our transition to CT
> for EV serves as the effective sunset period for these sorts of certs.

OK, that's good to hear. Ben seemed to imply that name redaction for DV
was losing favour too.

BTW, Ben, Eran,
Assuming we retain the name redaction text in 6962-bis, do you think we
should mention any of the points from this thread in the Security
Considerations?

--

[Ryan Sleevi]

On Wed, Aug 13, 2014 at 3:14 PM, Rob Stradling <robs...@gmail.com> wrote:

Yes.  I presume you're aware that Microsoft intends to "Re-examine the impact of this Policy at mid-term" [1] and that CABForum hasn't set a SHA-1 sunset date yet.

Chrome 39 is indeed "very soon" (1.5 months from now? [2]) to be doing this!  To repeat: CABForum hasn't set a sunset date yet, Microsoft intend to review the impact of their plans, and Microsoft haven't announced any plans to treat SHA-1 certs with notAfter dates exceeding the "sunset" date as mixed-content.

I would love to see the back of SHA-1, but with your aggressive timescale I think you are going to catch most CAs and most of their customers by surprise!

[1] http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

[2] http://www.chromium.org/developers/calendar

Not to diverge too much from the original point, but it's been repeatedly reaffirmed that very little will change that date, and it's very much a realistic target.

However, it does highlight one of the important challenges. In order for any improvements to the CA ecosystem to happen, especially with sunsets, it's important for CAs to help their customers be aware of those sunsets. To date, every sunset we've seen so far has included CAs issuing certificates whose validity extends well beyond that period, meaning well intentioned customers will suddenly find their sites "stop working" on the flag day.

Luckily, in the case of SHA-1 in particular, CAs can easily remediate this by making sure their customer is forcibly aware of the sunset, by making the certificate unusuable beyond that sunset. Since CAs have been unwilling to do this to date, despite repeated requests, it ultimately falls upon UAs to help inform their customers.

Sites that are affected by this will be able to talk to their CA and get a SHA-1 certificate valid up until the 2016/2017 time, at which point they will HAVE to switch to a stronger certificate (in addition to/independent of Microsoft's AND Chrome's time frame). Or they can switch now and get a SHA-256 certificate that is valid beyond 2016/2017.

Regardless of Microsoft's position of evaluation, it was affirmed on the CA/B Forum list and during the F2F our commitment to those dates, even if Microsoft decides to push them back. Exciting times are ahead, and this is a two year advance notice, with a requirement that CAs help prepare their customers for migration.

As it relates to this thread at hand, I think these sorts of experiences - where undesirable practices are repeatedly communicated to CAs, with deadlines, but with little change in issuance practices - is why a sunset period for internal-name EV certs is not really desirable. The experience, so far, with sunset periods is that they're not handled responsibly, which is to say, in a way where CAs aren't forcing UAs to make a flag day anyway (as this effectively is)

 

<snip>

I think we're absolutely committed to exploring name redactions,
particularly for DV certificates, where they're indistinguishable from
wildcard certs or name constraints, but I think our transition to CT
for EV serves as the effective sunset period for these sorts of certs.

OK, that's good to hear.  Ben seemed to imply that name redaction for DV was losing favour too.

As Ben notes, I think name redaction is "not ideal" from a policy evaluation perspective, but given that it's fundamentally indistinguishable from both wildcard certificates and name constrained intermediates - both things that we (Chromium) view as good and valuable for the TLS using community - I think it's highly likely that if/when Chromium adopts 6962-bis, which has a good chance of being done before we're ready to require CT for DV, that name-redacted DV certs will be allowed.

However, no promises - but you can be sure this is where the discussion will be :)

[Matt Palmer]

On Wed, Aug 13, 2014 at 12:46:43PM -0700, Kathleen Wilson wrote:
> I understand why a customer would not want their "internal" domain (like
> billing.example.com) to be public.
>
> But, on the other hand, I do not understand why they would need EV
> treatment for an internal site like that. For such an internal site, they
> already know who the O/OU is.

Hmm... what if I'm an attacker in your network, and I want to MitM your
billing site? If I can use a fraudulently-obtained DV cert to do that, so
much the better than having to get an EV cert.

Also, consider the glorious future where CT is universally deployed, and
every cert needs SCTs to get past the "OMG! UNTRUSTED CERT!" scare page...

> For DV, *.example.com is allowed, so allowing <PRIVATE>.example.com doesn’t
> add risk.

Sure, but I'm not going to hand everyone in my org the ability to pwn up the
rest of my org by giving every internal service a cert for `*.example.com`
-- one key gets stolen from one server and *everything* is suddenly MitM'd.
No, I'm going to get individual certs for individual services, thank you
very much.

- Matt
(removes hypothetical enterprise security weenie hat)

--
"I'm tempted to try Gentoo, but... I have better things to do with my CPU
cycles than to compile Python so that it can compile the compiler
so that it can compile the kernel."
-- Dave Brown, ASR

[Ryan Sleevi]

On Wed, Aug 13, 2014 at 3:08 PM, Matt Palmer <mpa...@hezmatt.org> wrote:

On Wed, Aug 13, 2014 at 12:46:43PM -0700, Kathleen Wilson wrote:
> I understand why a customer would not want their "internal" domain (like
> billing.example.com) to be public.
>
> But, on the other hand, I do not understand why they would need EV
> treatment for an internal site like that. For such an internal site, they
> already know who the O/OU is.

Hmm... what if I'm an attacker in your network, and I want to MitM your
billing site?  If I can use a fraudulently-obtained DV cert to do that, so
much the better than having to get an EV cert.

Also, consider the glorious future where CT is universally deployed, and
every cert needs SCTs to get past the "OMG!  UNTRUSTED CERT!" scare page...

With the enterprise security weenie hat on, EV is not gonna be your saving grace there, in as much as it relies on user training, and every enterprise security weenie knows how futile that is in practice.

Luckily, there's public key pinning, good enough for the most paranoid of us :)

Which is to say, differently, that the purposes of EV certs (see 2.1 of EV G 1.5.0) and the attack you just described are... fairly disjoint :)

 

> For DV, *.example.com is allowed, so allowing <PRIVATE>.example.com doesn’t
> add risk.

Sure, but I'm not going to hand everyone in my org the ability to pwn up the
rest of my org by giving every internal service a cert for `*.example.com`
-- one key gets stolen from one server and *everything* is suddenly MitM'd.
No, I'm going to get individual certs for individual services, thank you
very much.

- Matt
(removes hypothetical enterprise security weenie hat)

I think you may has misread/misunderstood this point. From the point of view of "CT as an audit-enabling mechanism", how a given customer uses *.example.com is opaque to the CA and the public, ergo having <PRIVATE>.example.com, which is opaque to the relying public, is no different. So for DV (which permits wildcards, something EV expressly forbids), this is the same amount of information as a wildcard cert - whereas for EV, it's a "loss" of information. 

[Matt Palmer]

On Wed, Aug 13, 2014 at 03:39:13PM -0700, Ryan Sleevi wrote:
> On Wed, Aug 13, 2014 at 3:08 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > On Wed, Aug 13, 2014 at 12:46:43PM -0700, Kathleen Wilson wrote:
> > > I understand why a customer would not want their "internal" domain (like
> > > billing.example.com) to be public.
> > >
> > > But, on the other hand, I do not understand why they would need EV
> > > treatment for an internal site like that. For such an internal site, they
> > > already know who the O/OU is.
> >
> > Hmm... what if I'm an attacker in your network, and I want to MitM your
> > billing site? If I can use a fraudulently-obtained DV cert to do that, so
> > much the better than having to get an EV cert.
> >
> > Also, consider the glorious future where CT is universally deployed, and
> > every cert needs SCTs to get past the "OMG! UNTRUSTED CERT!" scare page...
>
> With the enterprise security weenie hat on, EV is not gonna be your saving
> grace there, in as much as it relies on user training, and every enterprise
> security weenie knows how futile that is in practice.

Oh, if only they did... enterprises would be a lot more secure (and I'd want
shares in Yubico).

> Luckily, there's public key pinning, good enough for the most paranoid of
> us :)

Which requires the same general degree of contortions as rolling out a
private CA.

> Which is to say, differently, that the purposes of EV certs (see 2.1 of EV
> G 1.5.0) and the attack you just described are... fairly disjoint :)

That's fine as far as it goes, but it appears that CAs are issuing private
EV certificates -- at the very least, they're pushing pretty hard for
redaction to be supported.

> > > For DV, *.example.com is allowed, so allowing <PRIVATE>.example.com
> > doesn’t
> > > add risk.
> >
> > Sure, but I'm not going to hand everyone in my org the ability to pwn up
> > the
> > rest of my org by giving every internal service a cert for `*.example.com`
> > -- one key gets stolen from one server and *everything* is suddenly MitM'd.
> > No, I'm going to get individual certs for individual services, thank you
> > very much.
>

> I think you may has misread/misunderstood this point. From the point of
> view of "CT as an audit-enabling mechanism", how a given customer uses *.
> example.com is opaque to the CA and the public, ergo having <PRIVATE>.
> example.com, which is opaque to the relying public, is no different. So for
> DV (which permits wildcards, something EV expressly forbids), this is the
> same amount of information as a wildcard cert - whereas for EV, it's a
> "loss" of information.

Aha, I get the point now, and I agree with it.

- Matt


--
"I invented the term object-oriented, and I can tell you I did not have C++
in mind." -- Alan Kay

[Dean Coclin]

Extended Validation certificates are issued only to organizations that successfully pass a standardized rigorous authentication process. The idea that this is valuable only for externally facing sites and applications is flawed. We're the largest EV issuer in the world and we have 30-40% of our EV Certs issued for internal domains (based on our scans of our EV customers) and we have many customers who, as a policy, insist that any SSL certificate they use for any purpose is issued only after meeting the EV authentication standards.

 

Separately but related, the intent of CT was originally described as creating a model to enable customers to detect mis-issuance. That objective can be met without any certificate details other than the first-level domain name(s), serial number and issuer name. The discussion has now evolved to somehow use CT to determine whether or not certs have been issued following the CABF guidelines.  That can be accomplished in lots of ways including third party process audits (which we do), crawling for SSL Certs (which Netcraft does), and browser-based certificate policies (which each of the browsers do).

 

It seems that the private option is now tied up in this latter evolving objective. We recognize that audits are not perfect, but with the privacy option, every aspect of cert issuance (except for second- and higher-level domain names) can be publicly audited in CT. Furthermore, we value our customers’ privacy and believe that they should be given the choice to decide if their second- and higher-level domain names need to be kept private.

In the wake of Snowden, the world has focused on privacy. We feel it’s imperative to preserve privacy for those customers who value it, and we believe that nearly all of CT’s promise can be realized even with the private option. It’s a good compromise.

Dean Coclin

Symantec

[Ryan Sleevi]

On Mon, Aug 18, 2014 at 1:24 PM, Dean Coclin <dean...@gmail.com> wrote:

Extended Validation certificates are issued only to organizations that successfully pass a standardized rigorous authentication process. The idea that this is valuable only for externally facing sites and applications is flawed. We're the largest EV issuer in the world and we have 30-40% of our EV Certs issued for internal domains (based on our scans of our EV customers) and we have many customers who, as a policy, insist that any SSL certificate they use for any purpose is issued only after meeting the EV authentication standards.

 

Separately but related, the intent of CT was originally described as creating a model to enable customers to detect mis-issuance.

Hi Dean,

I'm sorry that there's been confusion, but that has never, ever been the only goal of CT, especially with respect to Chromium's requiring of CT.

The sheer number of CAs that are not conforming to reasonable guidelines, and thus leaving users at real risk, is of serious concern for us, which is why we continue to deploy programatic controls.

 

That objective can be met without any certificate details other than the first-level domain name(s), serial number and issuer name. The discussion has now evolved to somehow use CT to determine whether or not certs have been issued following the CABF guidelines.  That can be accomplished in lots of ways including third party process audits (which we do), crawling for SSL Certs (which Netcraft does), and browser-based certificate policies (which each of the browsers do).

Respectfully, our experience is otherwise, which is why we view this as a necessary and complementary step.

It has been shown time and time again that audits fail to capture even the most basic of PKI failures, which is something of an active discussion in the Mozilla security policy forum, and which I hope you can contribute. The most reasonable alternative is to require audits to do full and complete audits of a CA's infrastructure, rather than the limited sampling audit today.

I'm sure you can realize how much that would cost all CAs, particularly large CAs that issue a significant amount of certs, and be required on a regular basis (quarterly), and it would still be far less efficient or sufficient compared to a CT-based audit.

 

 

It seems that the private option is now tied up in this latter evolving objective. We recognize that audits are not perfect, but with the privacy option, every aspect of cert issuance (except for second- and higher-level domain names) can be publicly audited in CT. Furthermore, we value our customers’ privacy and believe that they should be given the choice to decide if their second- and higher-level domain names need to be kept private.

I heartily agree, and for those customers, EV is likely not an appropriate option for them. For so many CAs that have wished to establish EV as a brand of distinction, it seems important to make sure that matters.

 

In the wake of Snowden, the world has focused on privacy.

In a post-Snowden world, it's important to realize that privacy is one aspect. If reports are to believed, nation-state adversaries are regularly breaching corporate networks. We know that many of the recent CA failures have not even been due to nation-state level attackers, and we also know in a post-Snowden world that there is significant overreach in terms of judicial compulsion for compromise or disclosure.

For all these things, it seems important to recognize that the value of trust far outweighs the value of privacy, since without this trust, there can be no privacy.

 

We feel it’s imperative to preserve privacy for those customers who value it, and we believe that nearly all of CT’s promise can be realized even with the private option. It’s a good compromise.

Unfortunately, I think we'll have to disagree here.

In particular, for Chromium's goals, CT is not, has not, should not, and will not be only for the misissuance case.

 

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/9db378b5-c231-4c71-8340-57b9164daf88%40chromium.org.

[Ben Laurie]

On 18 August 2014 13:24, Dean Coclin <dean...@gmail.com> wrote:
> The discussion has now evolved to somehow use CT to determine whether or not
> certs have been issued following the CABF guidelines.

In other words, whether they have been mis-issued - mis-issuance is
_not_ just about who gets the cert.

[Sigbjørn Vik]

Hi,

Part of our hope for CT, is that it will ensure that certificates are
issued correctly (in every way), and help restore the trust in the
certificate ecosystem. Hiding parts of certificates will work against
both those goals. If private parts were hidden, it might take only a
single paypal.example.com example phish to destroy people's trust that
CT is an effective tool for this.

To live up to the name of extended validation, certificates need to be
open, so that they can be validated, not only by the CA, but by anyone.
The customers are explicitly requesting public certificates, usable
anywhere, so they should expect the details to be public. If they wanted
private certificates, there are other ways to accomplish that. Internal
domain names cannot be considered confidential in any case, they leak
too easily[1].

> On Mon, Aug 18, 2014 at 1:24 PM, Dean Coclin <dean...@gmail.com
> <mailto:dean...@gmail.com>> wrote:
>
> we have 30-40% of our EV Certs issued for internal domains

How many of those object to having the internal domain names public?
Could you share any reasons they object?

> we have many customers
> who, as a policy, insist that any SSL certificate they use for any
> purpose is issued only after meeting the EV authentication standards.

That's good :) They can still apply DV certificates, even though the
standards are EV, or they can get EV certificates, which show up as DV
in browsers.

If these are widespread issues, it sounds like you might have a use case
for some way for a sysadmin to mandate that browsers apply minimal
certificate practices for a subnet, similar to CAA. It does not sound to
me as a reason to hide the internal domain names.

[1] E.g. search suggestions while typing, DNS lookups when taking the
laptop outside the intranet, fraud/AV/online checks, browsers can easily
be used as proxies to domain scan intranets, certificates are uploaded
to be compared, etc.

--
Sigbjørn Vik
Opera Software

[Dean Coclin]

Thanks Ryan, Sig and Ben.  But has anyone spoken to customers to get their viewpoint? You may recall a discussion a while back in the CABF about sun-setting of internal names. Everyone wanted to take quick action until a customer survey was produced which showed valid reasons why customers were using internal names (mostly following vendor instructions). Following that, a terrific white paper was written instructing them how to avoid those names and an appropriate sunset period was reached which satisfied all constituents (more or less).

Here it seems that a grand technical solution is being reached without sufficient end user (customer) feedback. Sure, there may be some high profile users that have provided some input but I haven't seen a broad survey to determine impacts. I said in my earlier message that Symantec, as the largest EV issuer, found some 30-40% of customers were using these internally but that statistic appears to be ignored or brushed aside. Sure they could switch to OV but that would only be a temporary fix as Google has announced plans to expand CT to OV and DV certs.  I'd be willing to conduct such a survey if I knew the results would be taken seriously, resulting in meaningful action.

I don't want my comments to be misinterpreted, we do support CT. In fact, implementing a 'private option' is actually more work for us. But we do want to be a voice for customers as best we can.  However, I don't believe providing that data here will change anything. Feel free to tell me I'm wrong...

Dean Coclin
Symantec

On Tuesday, August 12, 2014 7:41:23 PM UTC-4, Ben Laurie wrote:

[Ryan Sleevi]

On Tue, Aug 19, 2014 at 12:23 PM, Dean Coclin <dean...@gmail.com> wrote:

Thanks Ryan, Sig and Ben.  But has anyone spoken to customers to get their viewpoint? You may recall a discussion a while back in the CABF about sun-setting of internal names. Everyone wanted to take quick action until a customer survey was produced which showed valid reasons why customers were using internal names (mostly following vendor instructions). Following that, a terrific white paper was written instructing them how to avoid those names and an appropriate sunset period was reached which satisfied all constituents (more or less).

And Chrome no longer recognizes such names, because we believe they represent a security risk, much the same way that allowing CA's to hide potential misissuances from CT represents a real security risk.

 

Here it seems that a grand technical solution is being reached without sufficient end user (customer) feedback. Sure, there may be some high profile users that have provided some input but I haven't seen a broad survey to determine impacts. I said in my earlier message that Symantec, as the largest EV issuer, found some 30-40% of customers were using these internally but that statistic appears to be ignored or brushed aside. Sure they could switch to OV but that would only be a temporary fix as Google has announced plans to expand CT to OV and DV certs.  I'd be willing to conduct such a survey if I knew the results would be taken seriously, resulting in meaningful action.

EV has always been first and foremost a statement by browsers as to what represents a meaningful level of verification that deserves special affordances within browser UI. Certainly, it's not a universally shared belief within the browser community that this is even itself valuable - after all, because EV is the same origin, it's trivially bypassable as a security mechanism.

As Sigbjorn says, I think we're seeing the world move in such that CAs, operating in the public trust afforded to them by browser root programs, are expected to operate transparently and in the public interest. The failure to do so has been responsible for significant harm - and potential risk to life and liberty - and so cannot be easily dismissed because some customers wish to hide a DNS name.

I realize that Symantec may have sold a product to 30-40% of their users, based on assurances that Symantec would not disclose their certificate. However, I don't believe such assurances are guaranteed by the EV guidelines, nor are they aligned with the goal of Chromium's EV program requirements - which is to operate in a way worthy of the public trust, and ensure that the CAs participating do so as well.

Such customers will still be assured their connections are secure - such certificates will still retain the DV distinction (reminder: No browser distinguishes OV to the best of my knowledge, and Chromium has no plans to) - but because Chromium developers and the public cannot be assured the CA has done necessary due diligence in issuing the EV cert, it will not be marked as such.

As CT expands to DV, this policy will likely be revisited, in light of both name constraints and wildcard certs, both of which are equivalent (with respect to auditing) as private labels. But since neither are supported with EV, such discussions need not happen now.

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/9894814c-c997-4c9d-a2cb-8231cbd58c59%40chromium.org.

[Dean Coclin]

There were never any "assurances" made to EV cert customers about the privacy of their data. I'm sure this is the case for other CAs as well. CT didn't exist when these certs were sold. But consider the scenario of a website owner requesting an EV cert (pre-CT) for an application behind the firewall. Since no one else can see this cert, other than corporate users, is it unreasonable to expect that they might think the cert data would be private?

I think Symantec and Google actually agree on a lot here with respect to the goals of CT. To the extent though that full disclosure is going to be required for website owners then our belief is a longer transition period is needed to avoid disclosing possibly private names. Once customers understand it, I’m confident they’ll make sure that they put no private info in their second- and higher-level domain names. That said, requiring disclosure by January would be without precedent in terms of a transition period for these kind of mandates. 

So if name redaction won’t be supported for EV certs, we support Rob Stradling’s suggestion of a sunset date to allow customers to phase out certs with private names before they’re publicly disclosed.

Respectfully,
Dean Coclin
Symantec

On Tuesday, August 12, 2014 7:41:23 PM UTC-4, Ben Laurie wrote:

[Ryan Sleevi]

On Aug 20, 2014 5:08 PM, "Dean Coclin" <dean...@gmail.com> wrote:
>
> There were never any "assurances" made to EV cert customers about the privacy of their data. I'm sure this is the case for other CAs as well. CT didn't exist when these certs were sold. But consider the scenario of a website owner requesting an EV cert (pre-CT) for an application behind the firewall. Since no one else can see this cert, other than corporate users, is it unreasonable to expect that they might think the cert data would be private?

Yes.

>
> I think Symantec and Google actually agree on a lot here with respect to the goals of CT. To the extent though that full disclosure is going to be required for website owners then our belief is a longer transition period is needed to avoid disclosing possibly private names.

Your concern has been duly noted. Full disclosure is only required for sites that wish to receive EV badging. As EV badging is not necessary for a secured connection, a graceful fallback already exists.

That is, there is inherently no risk of disclosing private names for certificates that are not logged, and certificates only need to be logged for EV.

For CAs - or their customers - who choose not to log, they will no longer receive EV badging.

There is no need to hold back Internet security in order to convince these certificate holders - or their issuing CAs - that any publicly trusted CA is responsible for operating in the public trust, and that part of that public trust is that the CA is required to operate honestly and transparently and held accountable for mistakes.

> Once customers understand it, I’m confident they’ll make sure that they put no private info in their second- and higher-level domain names. That said, requiring disclosure by January would be without precedent in terms of a transition period for these kind of mandates. 
>

The Internet moves quickly.

That said, there is a graceful fallback path, and browsers have never been obligated to guarantee that they treat a particular certificate as EV. We have seen this revoked in the past for specific incidents, such as that of TurkTrust, and we see it happening now across the board for CT.

> So if name redaction won’t be supported for EV certs, we support Rob Stradling’s suggestion of a sunset date to allow customers to phase out certs with private names before they’re publicly disclosed.

This sunset is already built into the plan. It's called "treated as DV". This is a sufficient balance between the risks to users and the Internet from a CA failing to meet program requirements and the needs of existing certificate holders.

It is up to the CA - or, if the CA is unwilling to act, the certificate holder - to determine which factor is more important for their individual needs, but for the collective Internet and Chromium user community, it is unquestionable that the audit needs are far more valuable and necessary.

> --
> You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
> To post to this group, send email to ct-p...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/dbe16acd-c8e2-405e-a0d0-054c8418bc24%40chromium.org.

[kirk...@trendmicro.com]

As I understand it, CAs who choose to participate in CT will have all EV certs issued on or before Dec. 31, 2014 “whitelisted” by Chrome, and so treated as EV (green bar) through their expiration date without ever being logged in a CT log.

 

Is that still correct?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvYZaQs%3DBz%3Do%2BjV7%2BwKEXGUcfpgJ_sT4UyiGGcZmR%2BXvkA%40mail.gmail.com.

TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

[Ryan Sleevi]

On Wed, Aug 20, 2014 at 5:33 PM, kirk...@trendmicro.com <kirk...@trendmicro.com> wrote:

As I understand it, CAs who choose to participate in CT will have all EV certs issued on or before Dec. 31, 2014 “whitelisted” by Chrome, and so treated as EV (green bar) through their expiration date without ever being logged in a CT log.

 

Is that still correct?

It sounds like there's some confusion.

The whitelist will only be composed of certificates that have been publicly logged by logs recognized by Chromium. If it's not in one of those logs, it will not be whitelisted.