Hiya, On 01/11/16 11:21, Ryan Sleevi wrote: > On Tuesday, November 1, 2016, Stephen Farrell <[email protected]> > wrote: > >> >> I am quite interested in discussing privacy issues if they >> exist here. (I don't however accept that corporate secrecy >> is a privacy issue.) > > > I don't see how, within a certificate, you can draw that line.
That's a fair question. I'm not sure I can draw a clean distinction, but then again the same is true e.g. wrt source IP addresses sometimes being (considered by some courts as) PII and sometimes not. We can however distinguish the <newproduct>.example.com use-case for corporate secrecy - in that case, there is mostly a need for secrecy only until the web site is launched. And that does differ from inclusion of non-changing PII (such as givenName) in DNs. To the extent there are any privacy issues with including a givenName, those issues don't go away in a few weeks. I'm less clear myself on the real need for keeping some hostnames secret forever but yet have the certs for those publicly logged. It may be that the better approach to that is to make clear that semantically meaningful hostnames in certs inevitably exposes those semantics, leading to a "dr. dr. it hurts when I do this" answer. > We know people are deploying DNS names with PII (the U.K. tax offices > naming scheme, for example, uses tax identifiers as subdomains). I'd say that's a fairly clear example of a not-great design, once CT (or passive DNS) is considered. I don't have a strong position as to what the WG ought do about that, if anything. > We know > CAs are deploying subject naming information in certificates, and these are > issued to natural persons. givenName and Surname are an example, but as > Peter points out, CAs are issuing certificates for individuals (IV), and > these are permitted to put the PII in the O field. Are those all used for TLS client auth or in applications above TCP or TLS? It sounds like it'd be a fine thing if someone was motivated to describe the cases like that that have been seen in current logs, as well as cases where the inclusion of such information in certs is known but those are not ending up in logs. Absent that description, I'm not sure we can see what changes or additions the WG might develop. (Note: I'm not asking that such descriptive material be in an I-D or RFC.) I'd also comment that it may be the case that some CA practices that seemed ok before CT, might no longer seem like such a good idea now. And that's ok - I think that's just showing some evolution towards a better PKI. We do of course need to try not break things as we go but I don't think that just because one of the O(100) CAs in the world has been doing X necessarily means that X has to be catered for via changes to CT. > > I appreciate the "data needed" viewpoint, but I don't agree with using the > extant logs to justify that viewpoint, especially when you consider what > the extant logs are presently logging, and what's desired to be logged. I don't understand the above. > > I can appreciate you see a difference between corporate secrecy vs personal > privacy - but perhaps you could articulate how that codifies into > certificates being issued, or its technical relevance. I can understand > that playing into discussions about which to punt on, but I don't feel > you've done a good job articulating why you feel this distinction is > relevant, or what end it serves, given the context of certificates. The distinction is relevant in that methods to protect corporate secrecy might or might not assist with personal privacy. > 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. > > > Can you suggest a meaningful distinction between these two, as expressed in > certificates? I think the distinction is that privacy relates to people, whereas corporate secrecy does not, one is trying to protect some corporate asset. As I said above I don't claim to have a crisp way to distinguish those "as expressed in X.509." That might emerge though from discussion, not sure. > > So going beyond the well understood use-cases has a number >> of risks. > > > Can you expand on what you see as well-understood? I thought both IV certs > and QCP certs were well understood, at least within the context of the Web > PKI. I don't get the question sorry. What I'm saying is that we need to be careful e.g. when discussing how CT might relate to better interpersonal messaging. That doesn't mean that we shouldn't discuss such things, but we ought not think that changes to CT will somehow make better e2e email happen - that'd be a cart before the horse kind of thing. >> 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. >> > > Can we infer that you're happy to discuss corporate secrecy as well? Of course. > Could > you expand on why you see these requirements as different? See above wrt the duration for which protection is needed issue for one well known use case for corporate secrecy. In terms of privacy, I think there's a difference in that the use of certs that might contain PII may be such that equivalent (but not necessarily bitwise identical) PII is inevitably exposed (say in mail header fields) to the point where there's no good reason to try hide the version of that information that's visible in a CT log. I think it is also the case that there will be cases where the best way to protect PII is to say "putting that in a cert is not best practice as it'll show up in CT logs." That may well conflict with some existing CA practices, which is something that warrants discussion. Note I'm not saying that "omit PII" is "the one true answer" but it might be the best we can do in some cases. There is also a danger if we allow redaction to be posed as a solution for long-term exposure of PII - the danger being that that might allow forms of mississuance to re-emerge whilst not actually protecting privacy. (If redaction is posed as a privacy protection, then in principle one has to be able to redact nearly any field in X.509, which is a danger for the effectiveness of CT I think.) I think that danger is itself a sufficient reason to distinguish carefully between privacy and corporate secrecy in CT discussions. S. > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
