On 03/18/2014 08:02 AM, Phillip Hallam-Baker wrote: > Unfortunately it is focused mostly on fixing cookies which is trying to fix > stupid which is never going to produce a sensible result. But there is > already a zone prefix list used for issue of wildcard certs. > > The problem of <private>.<domain>.foo.com looks to me to be the same as the > problem of *.<domain>.foo.com. > > *.uk would be a bad thing...
the CABForum guidelines split "registry-controlled" zones from the next level of labels using http://publicsuffix.org/, though they acknowledge that this is not a scalable long-term solution and something else needs to be done eventually (see section 11.1.3): https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf This idea of a "natural split" between public registries and private zones is appealing, because of the tradeoffs between auditability and resistance to zone enumeration. The entities closer to the root of the hierarchy need to be audited, since they have power over the leaves; the entities nearer to the leaves have less power, little or no responsibility delegated to them from third-parties, and possibly more legitimate need for hiding individual zone entries or avoiding enumeration. So how would this work in CT? if i'm an admin for the example.com zone, i'd want to monitor the logs for any entries matching: a) <PRIVATE>.com b) example.com c) *.example.com d) <PRIVATE>.example.com if any of b, c, or d are observed which were not issued from within my authority, i now have proof of misissuance, and can take the issuing CA to task. But if (a) is observed from monitoring the log, what can the site operator do? Do we declare that (a) is indication of log misbehavior? if so, then we need to also consider that CT-aware TLS clients need to be able to identify SCTs of the (a) form and report them publicly somehow, so that log misbehavior is known. presumably, this would be the same mechanism used to report an SCT that didn't show up within the MMD, right? is there a reporting mechanism defined? --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
