On Mon, Aug 15, 2016 at 2:52 PM, Sanjay Modi <[email protected]> wrote:
> > A redacted pre-certificate contains 95% of the information in the > certificate, and fully demonstrates CA compliance to policies and > requirements. A redacted > pre-certificate contains 100% of the information needed for a harmed party > to take recourse (issuer, serial number, notBefore, owned domains in the > redacted > CN and DNS SANs). The recourse for a redacted pre-certificate is exactly > the > same as the recourse for an un-redacted pre-certificate: approach the CA, > within the > terms of its Relying Party Agreement, CP, and/or CPS and state a claim > that a > certificate has been issued in error and it encroaches on the rights and > property of > the complainant. The only action that can be taken by the issuer is to > revoke > the certificate. Whether a browser can or cannot consume certificate status > information in a timely manner is out of the scope of this RFC. > If whether browsers can consume certificate status information in a timely manner is out of the scope of this RFC, I would think that whether "approach the CA" is sufficient recourse for a misissued redacted pre-certificate would also be out of scope for this RFC. > > We favor the full redaction as originally proposed in earlier versions of > 6962-bis. Redaction blocks FQDN components that provide intelligence about > internal networks that was designed to be parsed and understood only by > employees and peer-to-peer systems privy to internal DNS. Redaction blocks > geographical data embedded in FQDNs; it blocks harvesting of high value > targets prior to attack. Some of our largest customers have had structured > naming conventions for many years; forcing them to use wildcards or > redesign their DNS hierarchy to preserve privacy in an eTLD+2 policy world > requires > massive network renaming far beyond the staffing levels of current day IT > organizations. > Two inconsistencies here: * "network renaming", massive or not, would only be required for redesigning their DNS hierarchy for eTLD+2, and would not be required for use of wildcards. * If redaction is for your "largest customers", enterprises that large should be far more likely to have the resources to rename their internal network names. -- Eric > > > > - Sanjay > > On 8/12/16, 5:17 PM, "Melinda Shore" <[email protected]> wrote: > > >Hi, all: > > > >Since there was no comment at all on the proposal to retain > >name redaction, we appear to have complete agreement that > >it should go. We'll go back into wglc when a new version > >is submitted. > > > >Melinda > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
