On 01/11/16 03:34, Peter Bowen wrote: > On Mon, Oct 31, 2016 at 6:33 PM, Stephen Farrell > <[email protected]> wrote: >> On 01/11/16 01:04, Peter Bowen wrote: >>> On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell >>> <[email protected]> wrote: >>>> >>>> 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? >>> >>> 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. > > 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
Thanks. I'd be interested if there's a way to count how many logged certs have givenName, surname or similar attributes. Anyone with better log-foo know? > >>> certificates that have personal information (e.g. given >>> name, surname, and physical location) in the subject distinguished >>> 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.) > > 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. Again, do we have a count of how many of those (IV certs) are logged? > >>> 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). >> >> 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? :-) > > I'm not a lawyer, so I'm not going to make any legal conclusions. I wasn't making a legal point:-) > 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. > >>> We already see this with domains in many countries where the full >>> registrant details are not publicly available. >> >> 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. > >>> >>> Additionally, while 6962-bis does focus on certificates used for TLS >>> server authentication, there are other types of certificates that >>> 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. > > 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? It is entirely possible. Or it could be that those aren't being logged for other reasons. My main point is that it would be an error to conflate (a) requirements for privacy with (b) requirements for corporate secrecy. Those need to be discussed separately as the issues are quite different. And while it is perhaps possible that one technical approach might exist to address both sets of issues, that would surprise me, given that the requirements for (a) and (b) differ so much. S. > > Thanks, > Peter >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
