Hi all,
I’d like to propose that the redaction I-D allow for redacting labels above
the 2nd level domain, as determined by the public suffix used, of
SAN:dNSName values. For example, redaction of “secret.example.com” would
result in “{redacted}.example.com” while “secret.example.co.uk” would
result in “{redacted}.example.co.uk”. The I-D should also allow for
redaction of some subject DN values, especially commonName (the unfortunate
reality is this field is still used… frequently).
To (hopefully) address some of the concerns redaction has encountered in
the past, we’d like to propose the addition of a “redaction signal”. This
is essentially the domain owner publicly signaling that they have opted-in
to redaction of their certificates. While this does not solve the issue of
a client being unable to authoritatively determine that the host name being
observed during certificate verification is the one intended in the
redacted precertificate, it does introduce a mechanism for the entity that
CT is intended to protect to assert their acceptance of this tradeoff.
We haven’t identified the precise mechanism via which this redaction signal
would be communicated, but two options we want to throw out are CAA records
and HTTP header (such as the proposed Expect-CT header).
We also have not identified who/what should verify the redaction signal and
when. A CA should check for the presence of the redaction signal before
submitting a redacted precert, but if that were the only entity checking,
we would need to determine a way to publicly audit this check. A Log
Operator might check for the presence of a redaction signal before
accepting a redacted precert, but this introduces a new requirement for
logs to make some form of connection to the domain(s) in the precert. A
relying party might check for the presence of the redaction signal when
verifying the SCTs, but the lack of a redaction signal at the time of
connection does not necessarily represent the state of redaction signal at
the time of precert submission. A log monitor might check for a redaction
signal when a precert is discovered for a domain of interest, in order to
help determine whether a discovered precert might represent misissuance.
Cheers!
On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler <[email protected]>
wrote:
I’m glad to hear it, and looking forward to it.
I’d like to ask about the two things that seem really necessary to me;
sometimes a technical RFC lacks within it the rationale for why we do
things. I’ve been creating essentially a white paper at the same time as
writing comments and some prescriptive thoughts on privacy.
There’s a fundamental disagreement here over why we would want privacy and
transparency on a variable slider, and ultimately, it comes down to the
motivations of the entities involved. Some of us want to sell a product
that provides privacy, and some of us want to sell a product that is only
possible with transparency. Let’s not pretend that we’re not all faced with
differing incentives.
I’ve been on this list for a while, and very quiet because in general, it
seems like a fool’s game to try to argue people out of acting in their best
interests. It wasn’t until now that I had a solid idea of what would be
useful to this process.
There are some very smart people in information security. There are those
with strong inclinations towards advocating privacy at multiple levels of
organizational size from a individual to a YUUUUUUGE company (sorry,
couldn’t resist, and we all need to laugh a bit now and then). There are
those who see full transparency as a virtue and I can certainly understand
why, both on an ideological and a financial level.
I’ve watched this situation be cautiously talked around for months now, and
I’d be interested to hear people’s thoughts on asking some unassailably
corporate-neutral experts on both sides of this debate to provide guidance.
Whose opinion are you interested in hearing on whether or not permitting
certificate privacy and accepting it as a browser standard is a good idea?
I’m putting myself and Symantec out there in a vulnerable way; I and we
might not always hear what we want to hear, but every one of us wants to
make the internet better in the way we believe will work best.
Respectfully,
Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
[email protected]
From: Eran Messeri <[email protected]>
Date: Tuesday, November 15, 2016 at 6:17 PM
To: Tarah Wheeler <[email protected]>
Cc: Rob Stradling <[email protected]>, "[email protected]" <
[email protected]>
Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00
AIUI
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
