I'd prefer option 2 for simplicity and because I think the CT log should reflect the number of levels redacted. Do you gain much advantage if topsecret.secret.example.com is redacted as (PRIVATE).example.com v. ?.?.example.com. I think the second is more straight forward and gives more insight on what certs are out there.
-----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Rob Stradling Sent: Wednesday, January 28, 2015 4:20 PM To: Daniel Kahn Gillmor; [email protected] Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction Thanks for explaining that, DKG. Makes sense. Is there ever such a thing as a "sub-sub-zone" whose operators expect their parent and grandparent zones to be fully-enumerated? If so, that would suggest that option 1 is also insufficient, in which case we'd need to do option 2. Or if not, is there any reason to prefer option 1 over option 2, or vice versa? On 28/01/15 22:56, Daniel Kahn Gillmor wrote: > On Tue 2015-01-27 07:58:14 -0500, Rob Stradling wrote: >> On 27/01/15 10:51, Rob Stradling wrote: >>> On 21/01/15 18:49, Stephen Kent wrote: >>>> Rob, >>> >>> Hi Steve. >>> >>>>> That seems like a good idea. Did you have any particular DNS >>>>> experts in mind? >>>> >>>> I'd ask Joel Jaeggli <[email protected]> for suggestions. >>> >>> Thanks. I'll contact Joel. >> >> Actually, before I do that... >> >> We've already thought of two possible ways to express redacted >> label(s) in a Precertificate: >> 1. "(PRIVATE)." matching >=1 redacted labels. >> 2. "?." matching =1 redacted label. >> >> But it occurs to me that there's a third option: >> 3. "" matching >=0 redacted labels. >> >> Option 3 would hide the fact that redaction is even occurring. We >> wouldn't need to use "(PRIVATE)" or "?" or seek any alternative >> redaction label proposals from the DNS experts. :-) >> >> Would folks be happy with option 3? > > The proposal is that "foo.example.com" could be registered with the CA > as "example.com" -- this seems problematic for operators of a sub-zone > who expect their parent zone to be fully-enumerated. > > let's say the operator of example claims to be fully-publicly logged, > and lets me register dkg.example.net. i want to know that the > .example.net operators won't be able to masquerade as dkg.example.net > without issuing a certificate that i can find in the public logs, tied to my > name. > > If under proposal (2), i need to scan the logs for anything that ends > in dkg.example.net, or ?.example.net that i didn't request. if > something like that shows up, then i know something is fishy. > > But the .example.net operators may have a legitimate reason for > wanting to issue a certificate for "example.net" -- now they have a > way of impersonating me that CT doesn't help me to detect. > > I think option 3 defeats one of the main aims of CT. > > --dkg > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
