Nor do I think we want a ?.mil or ?.pvt.k12.ma.us logged. The former is technically valid, as mil is not a public suffix, rather it is a registered name and the latter has the longest public suffix I've seen.
On Fri, Jan 30, 2015 at 6:01 PM, Jeremy Rowley <[email protected]> wrote: > Yeah - good points. We definitely don't want to see a ?.com cert logged. > > -----Original Message----- > From: Peter Bowen [mailto:[email protected]] > Sent: Friday, January 30, 2015 6:59 PM > To: Jeremy Rowley > Cc: Daniel Kahn Gillmor; trans > Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction > > On Fri, Jan 30, 2015 at 2:16 PM, Jeremy Rowley <[email protected]> > wrote: >> My idea isn't fully formed yet, but... >> >> Wildcard certs are more risky than normal certs since the CA doesn't know >> exactly what they are securing. All they know is the secured base level >> domain. Therefore, I think the public has a strong interest in knowing when >> a wildcard cert was issued v. a standard FQDN cert. However, I'm not sure >> there's much more risk to end certificate requester - they still know >> everything that's been issued for their domain. It certainly doesn't make >> life easier for the CT operator or CA, but it gives important information to >> the relying parties looking at certs. If they look up a cert in the CT log, >> they'll be able to easily identify if the entire domain is secured by the >> same, logged cert. > > I was thinking similarly. I propose that labels containing a "*" may not be > redacted, as the "*" effectively is redaction. Additionally, if the left > most label is exactly "*", then it is considered redacted for the purposes of > determining if the label to the right may be redacted. That would allow > *.?.?.example.com to be an allowable redaction. > > I would also recommend that the right most two labels AND any labels making > up a "public suffix" not be allowed to be redacted. I'm not sure if this > should go into 6962bis or the policy of clients, auditors, and monitors, but > the redacting these effectively nullifies the reason for CT as far as I'm > concerned. > > Thanks, > Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
