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
