Subject: [Trans] Topicality

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Oct 2016 20:37:55 -0800

Hi, all:

You may have seen the recent announcement from the Chrome
team that as of October 2017 certificates will need to comply
with Chrome's CT policy in order to be trusted.  There was
also an invitation to discuss that on the trans mailing list.
This is a reminder that mailing list discussions need to
remain focused on the specifications being produced by the
working group - that is to say, policies related to
individual implementations are out of scope for the working
group except to the extent that they bear on decisions related
to our working group drafts.

Many thanks,

Paul and Melinda

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Oct 2016 07:53:12 -0700

> to our working group drafts.
Apologies for that - in every message but the one posted here, I encouraged
people to discuss the policies on [email-masked], but that any use
cases or concerns with the technical means should be brought to IETF.

To that end, there was some discussion in person during the CA/Browser
Forum's F2F (scheduled before we made the announcement) that attempted to
explore various use cases for forms of redaction within
certificates; information that CAs and site operators felt that
transparency would be harmful, rather than helpful. As soon as the minutes
become public, my hope is that further conversation about use cases for
redaction will be channeled here, so that it may be used to assist in the
production and work on a redaction draft that tries to capture these, as
well as explore possible technical solutions. In the event the WG cannot
find consensus on technical solutions, or for which the tradeoffs are seen
as too large, or too specific to the Web PKI, then I think it is something
to explore addressing via policy solutions, and the conversation migrates
to either via [email-masked] if they're specific to Chrome's plans,
or [email-masked] if there are specific solutions to explore.

I mention all of this to echo support for avoiding a discussion of browser
policy, or CA policy, on this list, except to the extent it affects the
technical discussions being noted here.

---

From: Peter Bowen <[email-masked]>
Date: Mon, 31 Oct 2016 12:01:34 -0700

> to our working group drafts.

Paul and Melinda,

Do you consider discussion of use cases for privacy to be in-scope for
this group or do you consider only the technical implementation of
privacy (e.g. section 4 of 6962-bis and the redaction draft) to be
in-scope?

Thanks,
Peter

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 31 Oct 2016 22:02:50 +0000

Peter,

> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be

(Wearing no IETF hat, but perhaps the hat of someone interested
in privacy...)

I do not believe that it makes sense for us to talk as if
privacy was a concept that applies to corporate entities.

I do believe that your text above conflates privacy (a human
concept) with corporate secrecy (a useful but different thing)
in ways that are in the end damaging to both. (I further and
even moreso believe that such conflation would be damaging
to the IETF were we to slip into the bad practice of not
calling out that terminological sloppiness.)

I totally get that redaction has utility for folks who need
corporate secrecy on a temporary basis. I absolutely do not
accept that that has any privacy aspect.

Can you call out the privacy aspect that applies to humans
and that is a real part of the question related to support for
redaction in CT?

Thanks,
S.

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

---

From: Peter Bowen <[email-masked]>
Date: Mon, 31 Oct 2016 18:04:29 -0700

> and that is a real part of the question related to support for

There are certificates that have personal information (e.g. given
name, surname, and physical location) in the subject distinguished
name or the subject alternative names.  It is very possible that there
may be a desire to redact this information (in fact it could even be
required in some jurisdictions as CT could be considered a database).
We already see this with domains in many countries where the full
registrant details are not publicly available.

Additionally, while 6962-bis does focus on certificates used for TLS
server authentication, there are other types of certificates that
could be logged.  For example a certificate that is used with email
and contains both the email address and given/surname.  It might be
that the owner of the certificate only wishes to disclose this binding
to people receiving email from them rather than publicly disclosing
it.  We have also seen requests for certificates that cover phone
numbers.  A similar situation would apply -- having an "unlisted"
number should be possible, where the subject details (other than phone
number) are only known to a group of people who communicate with the
number.

So I think there is a privacy aspect here in addition to any corporate
secrecy aspect.

Thanks,
Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 01:33:10 +0000

Hiya,

On 01/11/16 01:04, Peter Bowen wrote:
> There are 

"Are" or "could be"?

Serious question. The (non)existence of those in 6962 logs
seems to me to be a) highly pertinent and b) demonstrable.

> certificates that have personal information (e.g. given
> name or the subject alternative names. 

I can well imagine certs for web servers with some PII
embedded for no good reason. "Don't do that by accident"
would be as good a bit of advice as we could offer in
CT I think as it's really much more an issue for acme
in terms of current IETF work. (Or at least arguably.)

> It is very possible that there

The above has "possible," "may be a desire," "could even
be" and "could be considered" all in one sentence. That
is not a template for a winning argument is it? :-)

> registrant details are not publicly available.

DNS registration policies are not in scope here though.

> could be logged. 

How many have been logged? Serious question. If there is a
real problem here, I'm interested. If there is not, then I,
for one, am not. Finding the evidence either way should not
be hard.

> For example a certificate that is used with email

Again, please show us evidence from the public logs. That'd
be compelling where speculation is not. But please note that
redaction in CT is not the only possible mitigation - it may
be better to say to CAs: "Hey, don't issue certs with PII
unless the EE wants that really" since after all certs that
end up in logs are mostly TLS server certs and hence will be
picked up via zmap anyway if they are on the public Internet.
(And those that are not on the public Internet because of
corporate secrecy requirements are not relevant for privacy.)

> So I think there is a privacy aspect here in addition to any corporate

And you also agree that separating those concepts is important?
I hope so. If not, please do argue that. If so, let's see if
there are really any important privacy cases here or if the only
interesting ones relate to corporate secrecy. (Which, again is
IMO a totally valid concept in many, but not all, guises.)

Actually, my meta-suggestion is to start a new thread that does
not have the failing of fatally mixing corporate secrecy and
privacy. (Or even two threads if you think both concepts need
discussion for CT.)

S.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 31 Oct 2016 19:18:06 -0700

> seems to me to be a) highly pertinent and b) demonstrable.

Isn't that an element of log policies - and what clients are logging? These
certs definitely exist - but the combination of client behavior and log
policies have, so far, prevented them from being logged, and only
incidentally so.

> in terms of current IETF work. (Or at least arguably.)
I fail to see how ACME relates. This is a question of PKI: does TRANS exist
solely for elements of browser-mediated Web PKI, or is it for more? In
either case, they extend beyond issuance via ACME, and speak to policy, so
I don't feel we can be so easily dismissive.

> is not a template for a winning argument is it? :-)

Are you suggesting these cases are not valid? Because Peter is far from the
only one to bring them forward, as we've heard it in the past in relation
to ETSI profiles and the EU Trust List from a number of CAs. Are you
suggesting this isn't the venue to discuss technical solutions, as it
relates to CT, to those problems?

> DNS registration policies are not in scope here though.

Are you suggesting that CT does not need to be aware of what is possible,
either through other WGs actions (such as NSEC/NSEC3) or through other
bodies, such as IANA/ICANN?

It so, can you articulate what you view as the appropriate scope of
function and discussion here? I mean that as an honest question.

> Again, please show us evidence from the public logs.

I am sorry, but I find this argument going against the seeming IETF
principles of not favoring a particular vendors policies.

What is a public log, in your view? What policies do you believe logs must
have for acceptance? How do you respond, given that some CAs and log
operators have explicitly stated they want to log email and code signing
certificates? Concretely, WoSign is such an example of a CA doing that.

It seems the core of your objections are simply "Chromium policies have
prevented this" - but as the person responsible for those policies, I don't
find that argument particularly compelling or convincing, and certainly not
in line with the feedback we've received at Google, nor necessarily how I
think Chrome would like to see CT grow.

Perhaps it's easier to just ask - do you view CT as only valid for a
limited subset of Internet-facing, "publicly trusted," id-kp-serverAuth EKU
bearing certificates? If so, could we see if there's consensus with that
view? Because at present, the tech neither requires nor states that, and
perhaps that's core to determining whether your dichotomy of privacy and
confidentiality is accurate and reflected in both the tech and the running
code.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 02:45:50 +0000

On 01/11/16 02:18, Ryan Sleevi wrote:
> Isn't that an element of log policies 

No, that's an empirical question, to rephrase it: Show me the
certs:-)

Really, it is a serious question when considering the difference
between corporate secrecy and privacy. I totally accept that there
are issues with the former (e.g. with <newproduct>.example.com)
but I'd like to see evidence if someone claims that the latter
is an issue. ("The latter" being the privacy of humans, not the
secrecy of organisations.)

> - and what clients are logging? These

I don't follow that, can you elaborate?

> solely for elements of browser-mediated Web PKI, or is it for more? 

The WG charter calls out web site cert misissuance as thing#1
and http/tls as the same (in the deliverable bit).

Acme relates as follows: if there are certs containing PII,
instead of trying to handle those via redaction during the
act of CT logging, one could recommend not including the PII
in the certs. (It is arguable that that is a sufficient
answer, but nonetheless it could be argued to be one, in the
context of the IETF.)

> In

I was not dismissive. I asked for evidence. I did not
use the word policy at all.

> Are you suggesting these cases are not valid? 

No. I'm claiming that his argument is unconvincing. I'm
very very happy to continue to pick at that one sentence
if it helps the overall argument, but I doubt that it
will;-)

I said more than once in my mail that corporate secrecy
can be a valid requirement to posit. Feel free to ignore
that as often as you wish.

> Because Peter is far from the

That last is not great rhetoric. Do you really expect me
to say "yes, this is not the place to talk technical
solutions"? Hrmpf;-)

ETSI profiles and EU trust lists are all fine and good
things (in theory at least). I do regard a lot of argument
about those are purely theoretic having seen 20+ years of
such theory not resolving into reality.

And again I did more than once ack that corporate secrecy
is a valid requirement to posit in some forms.

> bodies, such as IANA/ICANN?

I've no clue what the above means, sorry.

Guessing though, as to what might constitute an answer: I do
not think that CT needs to try to address problematic things
like ICANN registrar policies that call for PII to be generally
visible. To the extent one has a problem with that, (and I do
as it happens) the trans WG is the wrong venue, was my point.

> function and discussion here? I mean that as an honest question.

As with the above, I'm too confused to answer. (And figure
there's some underlying miscommunication going on here.)

> principles of not favoring a particular vendors policies.

Huh? Asking for evidence of the existence of a claimed problem
goes against what? I'm very confused tbh.

> prevented this" - 

Eh, no. That's entirely and utterly incorrect to the point
where I wonder if you got mixed up by the indenting in the
mail thread or something. (Or perhaps you are reading between
the lines and finding things that are not really there, at
least between the lines as I write 'em;-)

> but as the person responsible for those policies, I don't

I remain as confused as I was a minute ago;-)

S.

---

From: Peter Bowen <[email-masked]>
Date: Mon, 31 Oct 2016 20:34:57 -0700

On Mon, Oct 31, 2016 at 6:33 PM, Stephen Farrell
<[email-masked]> wrote:
>> On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell <[email-masked]> wrote:
>>>

I'm not sure how you get that these don't exist.  Using the given name
and surname attribute types as indications of PII, and removing one
issuer's apparently confusion between surname and serial number, I see
thousands.  A few examples:

https://crt.sh/?id=9031476
https://crt.sh/?id=8997821
https://crt.sh/?id=45107003
https://crt.sh/?id=31130948

> in terms of current IETF work. (Or at least arguably.)

I wouldn't call this by accident.  Microsoft's root program
requirements (http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx)
explicitly call out Individual Validation (IV) is section 4(a)(15).
IV, by definition, puts Personal Information in the subject of the
certificate.

> is not a template for a winning argument is it? :-)

I'm not a lawyer, so I'm not going to make any legal conclusions.  So
I'm going to continue to qualify anything related to legislation that
may exist in certain jurisdictions in which CT logs may exist.  Yes,
that is heavily caveated again, so feel free to ignore, but it is a
real concern.

> DNS registration policies are not in scope here though.

I wasn't suggesting that they were.  I was using it to demonstrate a
related case where it was judged that restriction of information was
beneficial.

> for one, am not. Finding the evidence either way should not

Why does it matter how many have currently been logged?  Isn't the
point of this WG to create tech spec for a certificate log that can
log any kind of certificate?  Is it possible emailProtection certs
aren't being logged because of privacy concerns?

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 31 Oct 2016 20:38:31 -0700

> secrecy of organisations.)

"Show me the certs with PII" is a somewhat problematic stance, isn't
it? To what end will it help you or the community evaluate? I'm not
sure I accept at all your line of questioning, so perhaps, before
needlessly dropping PII, you can suggest how that would change your
response, if at all.

> I don't follow that, can you elaborate?

The extant logs all generally have policies that restrict the roots
from which they log, or even more narrowly, restrict the purposes for
certs which they log.

Similarly, the majority of log clients - those submitting to logs -
restrict what they log to a subset of what they see. Similarly, these
log clients only see particular types of certs, rather than the
broader corpus out there.

For concrete example: It's certainly be technically possible that
Google could decide to log every S/MIME certificate it saw. But would
it be wise? Of course not.

> answer, but nonetheless it could be argued to be one, in the

Of course, that doesn't address the issue pointed out earlier by Peter
- that certificates are in use for more than just TLS, and issued by
means more than ACME.

It sounds like your suggestion is only certs issued by ACME should be
logged via CT. Naturally, I reject that conclusion.

You're directly proposing policy solutions, right now ("Don't log"),
and rejecting even exploring or entertaining the technical discussion.
Is that intentional, or simply a misunderstanding?

> as it happens) the trans WG is the wrong venue, was my point.

I'm suggesting that CT needs to at least be aware of other privacy
preserving efforts - such as NSEC3 or DPRIVE - and as such, cannot
unconditionally say "Don't do that", when other IETF technologies
support "do that" - at least, not without a reasonable discussion of
why. I don't believe you've posed why, other than you don't like it,
or don't feel the use case exists, but if that's the level of
discussion, then I fear we will make no progress, especially given
that even the original message contained such evidence. My hope was
that here in the IETF we could try to find solutions for problems, and
only punt them when we believe they are better served elsewhere - but
I feel like your line of reasoning is to try to punt anything you
don't like.

> there's some underlying miscommunication going on here.)

Are the only certificates CT cares about TLS server certificates?

If not, then you already have ample evidence in the form of S/MIME
certificates, or in digital signature certificates, that privacy is an
aspect of the discussion.
If you don't agree with that, let's find out why.
If you do, then can we accept there's a privacy argument, and not just
a corporate secrecy requirement, and move on to the technological
discussion?