Subject: [Trans] Name redaction - stay or go?

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Jun 2016 20:03:56 -0800

Hi, all:

As we approach the end of working group last call on 6962-bis,
it looks like we have an unresolved question about whether
name redaction should stay or go.  I just went through the
mailing list archive and it looks like we have squishy
agreement that it should go (for example, Rob's comment:
"Regarding fixing it: I'd rather nuke the redaction
option than add further complexity.").  So, if anybody has
particularly strong feelings about this, or disagrees
about removing name redaction, please weigh in.

Thanks,

Melinda

---

From: Peter Bowen <[email-masked]>
Date: Tue, 14 Jun 2016 21:05:32 -0700

> about removing name redaction, please weigh in.

To be clear, are you asking about 4.2 and 4.3 or just 4.2?

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Jun 2016 20:18:14 -0800

> To be clear, are you asking about 4.2 and 4.3 or just 4.2?

At the moment, just 4.2.

Melinda

---

From: Peter Bowen <[email-masked]>
Date: Tue, 14 Jun 2016 22:53:39 -0700

> about removing name redaction, please weigh in.

I disagree with removing name redaction.  There is value in having
redacted certificates and it isn't questionable that having some info
is better than none.  For example, a CA could choose to log every
certificate but redact some.  This would make it very clear if a
"rogue" certificate should up that didn't match any certificate on
record.

Symantec has also shown there is customer demand for redacted
certificates -- they swapped their default to "log full certificate" a
couple of weeks ago and have had several hundred certificates
explicitly opt for redaction.  From the domains, it seems that it is a
number of different customers spanning multiple countries and types of
organizations (commercial, government, non-profit, etc).

I think redaction should stay.

Thanks,
Peter

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Jun 2016 09:33:06 +0100

> I think redaction should stay.

Melinda, I think there are three potential ways forward...

1. (Stay) Keep the redaction mechanism in 6962-bis.

2. (Defer) Move the redaction mechanism into a separate I-D, so that 
TRANS can continue to work on defining redaction without holding up 
6962-bis from progressing to RFC.

3. (Go) Kill the redaction mechanism entirely.

Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Jun 2016 12:15:47 +0000

> I think redaction should stay.

Same here.  Strongly in favor

---

From: Eran Messeri <[email-masked]>
Date: Wed, 15 Jun 2016 13:47:18 +0100

Rich, why are you in favour of keeping redaction in?

I'd very much like to remove redaction of labels (4.2.) as it adds
significant complexity to the protocol - particularly burdening clients:

* Clients would have to take apart a TBScertificate, modifying it and
re-assembling it in the right manner to get the signature from the SCT to
validate over the reconstructed, redacted TBSCertificate.
* TLS client libraries don't usually support modification and re-encoding
of certificates (as I've discovered implementing 6962 clients several
times).
* If the original, redacted precert had encoding violations it will be very
hard for the client to re-encode it correctly (I'll point out that logs MAY
accept cert chains that are "not fully valid according to RFC 5280
verification rules in order to accommodate quirks of CA certificate-issuing
software"). This problem was narrowly avoided with RFC6962 and
precertificates by virtue of being able to use the TBSCertificate as-is to
assemble the PreCert structure signed by the SCT.

I believe a name-constrained intermediate logged instead of the end-entity
cert (4.3.) is a good enough solution:
* It is functionally equivalent to redaction in end-entity certificates:
Certificates with domain names that should be redacted would remain out of
the logs.
* It builds on an existing name constraining mechanism already supported in
browsers. As the discussion on the ct-policy Chromium mailing list
<https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/vsTzv8oNcws%5B1-25%5D>
has shown, no consensus could be reached regarding a mechanism to
constraint redaction any other way.
* It puts the cost of redaction on the party that's interested in it in the
first place - the issuer. I realize there may be operational costs making
it more difficult/expensive to get redacted certs. That may serve to
discourage unnecessary redaction.

I'm keen to hear about cases where a name-constrained intermediate cannot
be used, necessitating label redaction described in 4.2.

Eran

On Wed, Jun 15, 2016 at 1:15 PM, Salz, Rich <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Jun 2016 09:24:51 -0400

> about removing name redaction, please weigh in.

I agree that it should go -- it adds significant complexity for (what
seems to me to be) very little benefit... but than again, I'm of the
view that the whole idea of redaction is silly, and that trying to
hide internal domains a: is doomed to failure and b: smacks of
security though obscurity.
I understand that "the market" doesn't agree with me, so, well,
perhaps my opinion is not valid...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Jun 2016 14:01:59 +0000

> I'm keen to hear about cases where a name-constrained intermediate cannot be used, necessitating label redaction described in 4.2.

Not everybody can afford the cost of doing this (i.e., pay a public CA to create an intermediary for them).

	/r$

---

From: Eran Messeri <[email-masked]>
Date: Wed, 15 Jun 2016 15:05:06 +0100

On Wed, Jun 15, 2016 at 3:01 PM, Salz, Rich <[email-masked]> wrote:

>
> > I'm keen to hear about cases where a name-constrained intermediate
> cannot be used, necessitating label redaction described in 4.2.
>
Can't the CA create the intermediate and keep it to itself in order to
issue the end-entity certs?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Jun 2016 14:08:20 +0000

> Can't the CA create the intermediate and keep it to itself in order to issue the end-entity certs?

That doesn't address the issue.  Where can a startup, in stealth mode, go to get such a cert?

CT shouldn't require *everything* on the web to be public.  Nor should it require *everything* accessible via Chrome, Safari, or other CT browser, to be public.  And it should not limit privacy to those with deep pockets.

Now maybe you can argue that this is a business, not a protocol/technology issue.  And I'll agree.  :)

---

From: Eran Messeri <[email-masked]>
Date: Wed, 15 Jun 2016 15:24:33 +0100

> That doesn't address the issue.  Where can a startup, in stealth mode, go
Can you please elaborate on this scenario? Is it a startup with
topsecretname.com? or topsecretproject.publicstartupname.com? I can't see
redaction for the former (?.com)  allowed in any scenario, and a wildcard
cert (*.publicstartupname.com) would cover the other.

>
> CT shouldn't require *everything* on the web to be public.  Nor should it
> require *everything* accessible via Chrome, Safari, or other CT browser, to
> be public.

It doesn't. CT describes a protocol/mechanism for publicly disclosing
certs, TLS client software in general (and browsers in particular) would
decide on whether it's required.

> And it should not limit privacy to those with deep pockets.

This is where I truly lack data/insight. From a technical perspective,
redaction with a name-constrained intermediate is equivalent  to redaction
of domain name labels but I don't know how much more work it is for a CA to
set up (technical arguments on why they may not be equivalent are _very_
relevant to this discussion).
Redaction can also be achieved by certificates with wildcards, so the only
reason (I can see) to use 6962-bis redaction is to redact multiple levels
of a domain name.

> issue.  And I'll agree.  :)
If only we could separate the two neatly :)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Jun 2016 14:45:17 +0000

> Can you please elaborate on this scenario? Is it a startup with topsecretname.com? or topsecretproject.publicstartupname.com? I can't see redaction for >the former (?.com)  allowed in any scenario, and a wildcard cert (*.publicstartupname.com) would cover the other.

It's the latter, of course.  And a wildcard covers more.  And a skunkworks or secret project would not want the generic wildcard, and vice-versa.

>It doesn't. CT describes a protocol/mechanism for publicly disclosing certs, TLS client software in general (and browsers in particular) would decide on whether it's required. 

But name redaction greatly limits the choice.

> This is where I truly lack data/insight. From a technical perspective, redaction with a name-constrained intermediate is equivalent  to redaction of domain name labels but I don't know how much more work it is for a CA to set up (technical arguments on why they may not be equivalent are _very_ relevant to this discussion).

Go ask the folks who run pki.google.com how much is involved.

> Redaction can also be achieved by certificates with wildcards, so the only reason (I can see) to use 6962-bis redaction is to redact multiple levels of a domain name.

The original chromium proposal, right?

>If only we could separate the two.

But you can't.  Trust is a business and branding issue.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Jun 2016 09:33:02 -0800

> Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"?

I am asking "Stay or Go."  Note that in the IETF someone can
introduce a new topic/draft/whatever, and that in some sense
no question is ever completely closed.  But what I'm asking is
what should be in 6962-bis.

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Wed, 15 Jun 2016 18:48:36 +0100

I think on balance it should stay. My reasoning is that it is unclear
whether it will be used or not. Implementations that decide not to use
it are not burdened by the specification. Adding it back later is
substantial pain. If it really turns out to be useless, it can be
removed in a later iteration.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Jun 2016 16:04:21 -0400

Ben,

> removed in a later iteration.
Support for redacted certs seems to be optional for CAs (as per 4.2.1).
However, 10.2.2 seems to mandate support for redaction in TLS Clients. 
Thus it would seem that TLS Clients are burdened by redaction.

Steve

---

From: Matt Palmer <[email-masked]>
Date: Thu, 16 Jun 2016 07:53:02 +1000

On Wed, Jun 15, 2016 at 02:08:20PM +0000, Salz, Rich wrote:
> require *everything* accessible via Chrome, Safari, or other CT browser,
> to be public.  And it should not limit privacy to those with deep pockets.

CT doesn't require everything on the web to be public.  It only requires
everything authenticated by the web PKI to be public.

- Matt

-- 
There is no finite resource poor policy making can't make scarce.
		-- David Conrad, in NANOG

---

From: Sanjay Modi <[email-masked]>
Date: Wed, 15 Jun 2016 15:04:48 -0700

Redaction (4.2) should stay. It provides a necessary mechanism for domain
owners to protect the privacy and security of their domains when
participating
in certificate transparency. With redaction, domain owners are able to get
the full benefits of monitoring certificates issued to their domains and
also get the privacy protection they need. We have talked extensively with
customers
who have validated the requirement for privacy. Since we rolled out
redaction
support several days ago, we have already had hundreds of customers select
this option for over
1500 certificates.

Other solution paths, while fail to support all of the key use cases like
name
redaction can:

Wildcards  this could work for some organizations, however it is common
for large enterprises to have explicit IT
policies prohibiting the use of wildcard certificates.

Name Constrained Intermediate  this has proven to be unmanageable as it
is doesn¹t enable additional domains to be
added later, a key use case for most customers.

Private CA  this too can work but is relevant only for non-browser use
cases. Customers consistently choose publicly trusted certificates for
internal sites for root ubiquity and manageability.

Thanks,

Sanjay

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Jun 2016 22:29:15 +0000

> everything authenticated by the web PKI to be public.

Pretending that anyone can got an interoperable private PKI that's usable common browsers (Chrome Safari at least) is, well, just that: pretending.

---

From: Peter Bowen <[email-masked]>
Date: Wed, 15 Jun 2016 15:58:51 -0700

On Wed, Jun 15, 2016 at 7:24 AM, Eran Messeri <[email-masked]> wrote:
> reason (I can see) to use 6962-bis redaction is to redact multiple levels of
> a domain name.

The WebTrust for CA criteria require a full ceremony to generate CA
keys (see section 4.1 in
http://www.webtrust.org/homepage-documents/item54279.pdf).  This is
not cheap to execute.

Each subordinate also needs to be configured in the CA's systems.
Additionally many HSMs do have finite space -- so massively increasing
the number of subordinates may require purchasing more HSMs.

So a new intermediate is by no means free.

Thanks,
Peter

---

From: Matt Palmer <[email-masked]>
Date: Thu, 16 Jun 2016 09:11:06 +1000

On Wed, Jun 15, 2016 at 10:29:15PM +0000, Salz, Rich wrote:
> Pretending that anyone can got an interoperable private PKI that's usable
> common browsers (Chrome Safari at least) is, well, just that: pretending.

Now you're moving the goal posts.  You said nothing about widely
interoperable, and in fact, it's completely contrary to the idea of
something that is "private".  You can't have "private" and "accessible to
lots of people", the world just doesn't work that way.

Anything that's private enough that accidental or malicious disclosure isn't
a significant risk is also going to be accessed by a sufficiently small
group, or in a suitably constrained environment, that managing a private PKI
is a smaller cost (and one which is paid by the beneficiary) than the
external cost imposed upon the web PKI by redaction and other forms of
attempted secrecy.

For my money, I think redaction should go from 6962-bis.  To my knowledge,
the implementations of redaction are far less mature than the
implementations of the rest of the spec, the one major client-side
implementation of CT has made a policy decision not to support it, and
there's still a number of different proposals to make it less prone to
attack (hashed labels, et al).  I believe that it would be straightforward
to retrofit it into the system with a separate RFC at a later time, when all
the kinks have been worked out, so there's no reason not to remove it now
and have those people who believe redaction is worth pursuing work on it
separately.

- Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Jun 2016 01:03:46 +0000

> Now you're moving the goal posts.

No.  CT would move the goalposts.

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 15 Jun 2016 21:30:29 -0700

Having recently started work on code to reconstruct a precert
TBSCertificate given a name-redacted certificate, I agree that the
following is a concern:

On Wed, 15 Jun 2016 13:47:18 +0100 Eran Messeri <[email-masked]> wrote:

> * If the original, redacted precert had encoding violations it will
> be very hard for the client to re-encode it correctly (I'll point out
> that logs MAY accept cert chains that are "not fully valid according
> to RFC 5280 verification rules in order to accommodate quirks of CA
> certificate-issuing software").

A concrete example is a cert with trailing garbage at the end of the
subjectAltName, such as this one:

https://crt.sh/?q=cf144cad0599775dc273d02205f1fccfd042a43dbf382695950e82fa0b601ec7

When reconstructing a redacted pre-cert TBSCertificate, it is necessary
to parse the subjectAltName and then re-encode it.  Should
implementations be expected to remember the trailing garbage and
include it in the reconstructed TBSCertificate?  I think that would be
an unreasonable requirement due to the complexity.  However, if a
popular implementation decides to do that, and then the ecosystem gets
flooded with certs exhibiting this encoding error, it will become a de
facto requirement for other implementations, driving up the complexity
cost of supporting redaction.

Another challenge is non-ASCII characters in DNS SANs or IA5String
common names.  A client might normally ignore improperly-encoded
identifiers so the certificate can still work with the other
identifiers.  However, with redaction, for the certificate to work for
any identifier, the client needs to be able to decode all of them and
then re-encode the incorrectly-encoded ones with the same encoding
violation as the original certificate.

Regards,
Andrew

---

From: Matt Palmer <[email-masked]>
Date: Thu, 16 Jun 2016 14:42:00 +1000

> No.  CT would move the goalposts.

CT moves the goalposts to a good place.

- Matt

-- 
A polar bear is a rectangular bear after a coordinate transform.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 16 Jun 2016 10:45:00 +0100

On 16/06/16 00:11, Matt Palmer wrote:
<snip>
> and have those people who believe redaction is worth pursuing work on it

+1

For all of these reasons, I've been growing increasingly uncomfortable 
with the thought of the redaction mechanism (as currently defined in 
6962-bis section 4.2) going into the Standards Track RFC that 6962-bis 
is destined to become.

I think we should remove it from 6962-bis, and then work on a 
draft-trans-redaction I-D (with the aim of publishing it as an 
Experimental RFC).  If we take this approach, I'll volunteer to be a 
document (co)author.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2016 10:05:06 -0400

Peter,

> To be clear, are you asking about 4.2 and 4.3 or just 4.2?
As I noted in my message to Ben yesterday, section 10.2. is also 
relevant, as it mandates TLS client behavior that deals with 
name-redacted certs.

Steve

---

From: Eran Messeri <[email-masked]>
Date: Thu, 16 Jun 2016 17:31:14 +0100

Attempting to summarize a discussion for redaction (that took place on
another medium yesterday, Peter Bowen and Rich Salz will correct me if I'm
wrong):
- Redaction doesn't seem to be for domain names that are meant to be
publicly resolvable, because there's no guarantee that the first client to
connect to them will submit the certificate chain to a CT log (what
expectation of confidentiality can be had for a domain name that is
publicly registered, publicly resolvable to a non-internal IP and secured
with a certificate from a public root?).
- Redaction is needed for private namespaces: domains that utilize
split-horizon DNS with hostnames that resolve only if looked up from an
organization's internal network. Such domains are secured using public
roots because in the era of Bring-Your-Own-Device the claim is it's
infeasible to install private CA certificates on all devices that access
the network (some are user devices, some don't support that).
- In this scenario it is more reasonable to expect clients not to log the
unredacted chain (I don't expect clients to log certs without SCTs by
default due to privacy implications, though one can imagine a Firefox
extension doing so).
- My conclusion is that redaction is a defence-in-depth mechanism for
keeping internal domain names, which are considered confidential
information by some organizations, from leaking. Redaction does not provide
full defence against such leaks as clients may still submit unredacted
certs and logs may still log them.

Another downside to redaction is that it makes it more difficult to track
down what a redacted certificate is used for within an organization (i.e.
the security team observes, in a log, a certificate for ?.example.com not
issued by the CA that issues everything else for example.com. They would
then have to contact the issuer to get the identity of the requester,
whereas a similar certificate for something.example.com would only require
internal investigation to find out the system the certificate is used by).

On Thu, Jun 16, 2016 at 3:05 PM, Stephen Kent <[email-masked]> wrote:

> As I noted in my message to Ben yesterday, section 10.2. is also relevant,
> as it mandates TLS client behavior that deals with name-redacted certs.
>
That's also my understanding of section 10.2.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 16 Jun 2016 11:21:40 -0700

To echo what others have already said: redaction should go, for now. One
of my main objections to redaction, voiced on the ct-policy list, is the
complexity it introduces into the ecosystem. Removing redaction from
6962-bis means that clients don't have to take that complexity hit.'

A very good principle here is:

"No" is temporary; "Yes" is forever. If you're not sure about a new
feature, say no. You can change your mind later.
(https://github.com/docker/libcontainer/blob/master/PRINCIPLES.md#libcontainer-principles)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Jun 2016 18:24:32 +0000

> "No" is temporary; "Yes" is forever. If you're not sure about a new feature,
> say no. You can change your mind later.

That's a nice principle, but doesn't seem to hold in the IETF scale of things.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Jun 2016 10:36:37 -0800

> That's a nice principle, but doesn't seem to hold in the IETF scale of things.

If you're talking about overall process I don't think that's true.
If you're talking about the time and effort it takes to standardize
something, alas, yes, and it seems likely to me that any name
redaction work in the future is likely to be as heavily contested
as it is now.  That does not mean, however, that it's not appropriate
to defer a name redaction specification into another, later
document for any number of reasons (including trying to get 6962-bis
out sooner rather than later and trying to avoid being an example
of process sludge).  I think the core question here is whether
publishing 6962-bis without it will make it difficult to specify
name redaction in the future.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Jun 2016 18:38:06 +0000

>  I think the core question here is whether
> publishing 6962-bis without it will make it difficult to specify name redaction
> in the future.

If it's not in the initial core spec, it will not get picked up later by browsers.  My view.

---

From: Eran Messeri <[email-masked]>
Date: Thu, 16 Jun 2016 19:38:32 +0100

Would it alleviate concerns if we commit to making an experimental RFC
describing redaction separately of 6962-bis available relatively at the
same time as 6962-bis?

I think Rob's proposal of separating it to a different document (and taking
it out of the core 6962-bis specification) is the most sensible:
- The redaction mechanism is pretty much independent from the operation of
precertificates.
- (AFAICT) the discomfort with the redaction is its experimental / unknown
nature, so it seems fitting to have it as an experimental RFC.

Given the text is already written, it should be straightforward to separate
it out.

Eran

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 16 Jun 2016 18:42:12 +0000

> Would it alleviate concerns if we commit to making an experimental RFC describing redaction separately of 6962-bis available relatively at the same time as 6962-bis?

My reply would be the inverse of your answer to this one:  will Chrome do it?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2016 15:14:49 -0400

If we look at the mess that syntactically bad CA certs cause, it does 
suggest that Yes is forever ;-), and not just based on IETF standards.

Steve

---

From: Jeremy Rowley <[email-masked]>
Date: Fri, 17 Jun 2016 00:51:23 +0000

My view as well. If it's not part of this bis, you're basically saying
goodbye to name redaction

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Thursday, June 16, 2016 12:38 PM
To: Melinda Shore <[email-masked]>; Jacob Hoffman-Andrews
<[email-masked]>; [email-masked]
Subject: Re: [Trans] Name redaction - stay or go?

>  I think the core question here is whether publishing 6962-bis without 
> it will make it difficult to specify name redaction in the future.

If it's not in the initial core spec, it will not get picked up later by
browsers.  My view.

---

From: Matt Palmer <[email-masked]>
Date: Fri, 17 Jun 2016 10:54:40 +1000

> If it's not in the initial core spec, it will not get picked up later by browsers.  My view.

Even if it's in the initial core spec, browsers still won't necessarily pick
it up.  Especially if it's a scheme that's got some pretty serious concerns
against it.  Instead, if it gets split out into a separate spec, the current
6962-bis (sans redaction) can go forward, and the additional time needed to
get a broadly workable redaction mechanism standardised can be taken by
those who wish redaction to be existent.

- Matt

-- 
Yes, Java is so bulletproofed that to a C programmer it feels like being in
a straightjacket, but it's a really comfy and warm straightjacket, and the
world would be a safer place if everyone was straightjacketed most of the
time.		-- Mark 'Kamikaze' Hughes

---

From: Matt Palmer <[email-masked]>
Date: Fri, 17 Jun 2016 11:48:31 +1000

> goodbye to name redaction

How so?  Has the IETF said they won't accept any further RFC submissions on
redaction (or CT in general) after the publishing of 6962-bis?

- Matt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 16 Jun 2016 22:55:39 -0400

> redaction (or CT in general) after the publishing of 6962-bis?

Specifying it is the easy part.  Figuring out a deployment story would
be the hard part, especially if there are browsers (or other CT clients)
in the deployed base who don't know how to deal with it.

 * Deploying only a new, redacted SCT means that the deployed base will
   think that your cert has not been logged.

 * Deploying a redacted SCT side-by-side with a non-redacted SCT (for
   the older deployed base) gives you no privacy benefit, because the
   non-redacted SCT is still public.

As a result, servers have no strong incentive to deploy redacted SCTs,
so they probably won't deploy them.  And because no servers deploy
redacted SCTs, no clients will have an incentive to support them.

:(

   --dkg

---

From: Matt Palmer <[email-masked]>
Date: Fri, 17 Jun 2016 13:19:05 +1000

> in the deployed base who don't know how to deal with it.

That's the position we're in today, though, with 6962 not supporting
redaction, and the single widely-deployed CT client stating they won't be
recognising 6962-redacted SCTs as valid.  So, whether redaction is in 6962
or not, you're still going to have all the same deployment issues (which are
hardly unique to redaction; IPv6 anyone?) when redaction's kinks are worked
out.

- Matt

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Jun 2016 21:29:34 -0800

> those who wish redaction to be existent.

Well, that's the concern (one of them).  Leaving aside, for the
moment, the discussion of whether or not it's a good idea, is
there anybody who can say with authority that this is a feature
they want for their own implementation (either in a server or
browser)?

Thanks,

Melinda

---

From: Sanjay Modi <[email-masked]>
Date: Fri, 17 Jun 2016 11:01:15 -0700

Melinda,
We want to keep reaction feature. We have talked extensively with
customers who have validated the requirement for privacy. Since we rolled
out
redaction support several days ago, we have already had hundreds of
customers select this option for over 1500 certificates.

Thanks,
-Sanjay

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Jun 2016 14:28:38 -0800

On 6/17/16 10:01 AM, Sanjay Modi wrote:
> Melinda, We want to keep reaction feature. We have talked extensively
> with customers who have validated the requirement for privacy. Since
> we rolled out redaction support several days ago, we have already had
> hundreds of customers select this option for over 1500 certificates.

Okay, that's really good information to have.  By way of
follow-up, have you read Eran's proposal for an alternative
mechanism, and is that something that Symantec would be
interested in (acknowledging that you would not be speaking
for the entire company)?

Melinda

---

From: Sanjay Modi <[email-masked]>
Date: Mon, 20 Jun 2016 17:08:02 -0700

Melinda,
We are reviewing Eran's proposal and and followup posts on that. We are
also looking into how to address redacted CN. I will post follow up
shortly.

- Sanjay