Melinda, We have provided feedback on redaction earlier on this forum and also on some other public forums. We've heard loud and clear from customers in many product segments that they need redaction for publicly-trusted certificates because they value privacy. We don't think redaction as currently specified in RFC 6962-BIS makes much sense; it's too complicated and doesn't protect the privacy of domain owners. If un-redaction is possible by just throwing some cycles at it, then nothing has really been redacted.
To summarize the position we've already stated: we feel that the issuing CA must be approached by the domain owner to achieve disclosure of the full contents of a redacted pre-certificate. Policies and procedures should be crafted to standardize that, but they shouldn't be tied to a discussion on redaction because they are needed even when a pre-certificate is not redacted. 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. 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. The type of very large organization that has a long and vastly deployed legacy of intelligent naming and needs redaction also has strict IT policies that require certificates to be signed by public audited CAs. If redaction is completely removed from 6962-bis, we believe that it should be moved to another RFC so that work can proceed. - 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
