On Tue, Mar 7, 2017 at 9:13 PM, Ryan Sleevi <[email protected]> wrote: > > > On Tue, Mar 7, 2017 at 10:36 PM, Peter Bowen <[email protected]> wrote: >> >> I think I might have phrased it poorly. It was not meant to be a >> policy principal, rather a technical one. What I was trying to say is >> that I don't think having an encrypted blob in the precertificate >> (i.e. publicly escrowed) that has unredacted names is a good path. >> >> I am not intending to rule out a policy that says the holder of the >> full certificate (i.e. the CA) must provide it to X upon Y. My focus >> was on the "reversibility" of the precertificate in cases where the >> precertificate does not contain all the data in the final certificate. > > > I think the question of whether or not a precertificate should be able to > produce a full certificate is, in some ways, related to the policy > discussions. That is, a technical solution is a means to circumvent the > policy discussion, and a policy discussion is a means to circumvent a > technical solution. I don't know that I can agree a priori that we should > rule this out, if only because it implies a policy solution is viable, but > we don't know that. > > As far as statements go, while there's an intuitive appeal about the first > statement, it does seem to conflict with some degree of RFC 7719 - namely, > it seems to introduce additional terms that may conflict with or overlap > with the terminology there. In particular, the claim that the > existence/non-existence of a registered domain as public information sits > within that space of uncertainty as to whether you're describing something > akin/similar to "public suffix", or something akin to the > registry/registrant relationship. > > I highlight this because I think Statement 1 is similar to Statement 8. If > we're describing the technical capabilities, and ignoring any policy > concerns, then I think 7719 and Statement 1 are in some degree of conflict. > If we're describing possible and/or desired outcomes, then I think Statement > 1 is a reasonable statement. Put differently, I'm unclear if Statement 1 is > "This is a thing that currently exists" or whether it's "This is a thing > that (for policy reasons related to CT and its deployment in common browser > clients for purposes of the WebPKI) should exist". If the former, it's hard > to support. If the latter, I agree that it represents at least a minimum, > both of goal and of what is, as you note, effectively practiced at the TLD > zone level. But it's a policy statement :)
OK, rephrasing in RFC 7719 terms and focusing on the reality: For all TLDs which consist of three or more letters, except for mil, gov, and int, and for certain two letter TLDs, the existence of a domain name consisting of the label immediately below plus the label that is the TLD is public information. This is ICANN policy as it exists today. It is a fact independent of browsers or CT. Additionally certain two letter TLDs, such as us and se, have the same policy. I'm just asking for stipulation that due to the policies enforced by ICANN, it is not valid to say "the existence of companycorporationpromocode.com. is not public information". _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
