On 01/11/16 03:38, Ryan Sleevi wrote: > On Mon, Oct 31, 2016 at 7:45 PM, Stephen Farrell > <[email protected]> wrote: >> >> 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.) > > "Show me the certs with PII" is a somewhat problematic stance, isn't > it?
I guess it might sound like it yeah:-) But see my mail to
Peter, a count of those with likely-sensitive attributes
would be a good start.
> To what end will it help you or the community evaluate?
It'd help evaluate the seriousness of the potential privacy
issue with current logging. My sense going in was that this
(inclusion of PII in certs in logs) wasn't too big a deal,
but I could well be wrong.
> 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 am quite interested in discussing privacy issues if they
exist here. (I don't however accept that corporate secrecy
is a privacy issue.)
>
>>> - 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.
>>
>> 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.
Agreed.
>
>> 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.)
>
> 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.
No that was not my suggestion at all.
> 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?
That's a wild misinterpretation of what I said. If you can
point to where I "rejected even exploring" anything then I'd
be very happy to retract that.
>
>>> 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?
>>
>> 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.
>
> 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'm entirely fine with discussion of privacy as it relates
to CT, and would be glad to see that. My main point is that
privacy is entirely different from corporate secrecy, and
conflating the two would be an error.
> 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.
Every time you tell me what you feel I think, you go wrong.
Maybe concentrating on what I say will be more useful?
>
>>> It so, can you articulate what you view as the appropriate scope of
>>> 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.)
>
> Are the only certificates CT cares about TLS server certificates?
No. Those are the most important use-case for now though.
I do also think we need to be careful to not try to e.g.
re-design e2e secure interpersonal messaging based on CT. While
getting better e2e secure interpersonal messaging would be
a fine thing, there is much more to that than considering
CT.
So going beyond the well understood use-cases has a number
of risks.
>
> 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?
To reiterate: I'm very happy if we discuss privacy so long
as we do not conflate that with corporate secrecy. There are
requirements for both, but they are far from the same.
S.
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
