So a real world situation has been brought forward that requires CT to care about visibility of subdomains when ownership of name property is granted from ICANN at the level of the visible content in a redacted name?
On Tue, Jun 21, 2016, 9:16 AM Eran Messeri <[email protected]> wrote: > FYI proposed text for this change (unreviewed) is in > https://github.com/google/certificate-transparency-rfcs/pull/175 > > On Tue, Jun 21, 2016 at 4:56 PM, Steve <[email protected]> wrote: > >> If a client can un-redact, what's the point of redaction? >> > A monitor of the log which observes a certificate with redacted dNSName > fields and has a list of subdomains for that domain (for example, because > it is operated by the legitimate domain owner who knows about all the > subdomains registered under this domain) can distinguish between a redacted > cert for one of the known subdomains and a redacted cert for an unknown > subdomain. > TLS clients have to receive the un-redacted certificate, but having the > redacted dNSNames alongside the unredacted ones allows clients to apply a > policy for determining whether the redaction is acceptable or not. > >> Kind regards, >> Steve >> >> On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer <[email protected]> wrote: >> >>> Hi Rob, >>> >>> On Mon, 20 Jun 2016 14:39:00 +0100 >>> Rob Stradling <[email protected]> wrote: >>> >>> > 1. When redacting a LABEL in the "redacted SAN" extension, the issuer >>> > replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of >>> > just "?". >>> > >>> > 2. If the client desires stronger SCT matching, it checks that each >>> > redacted label in the redacted SAN extension matches the >>> > corresponding label in the SAN extension, by computing HASH >>> > (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of >>> > the certificate. >>> >>> I'm a little uneasy about using the serial number, because of >>> the ways that serial numbers can be, and are, incorrectly encoded (e.g. >>> not minimally encoded, or a "positive" integer with the MSB set). I >>> think it's simpler and more robust for the client to take the salt out >>> of an extension, so it can be treated as an opaque blob and therefore >>> be unaffected by the vagaries of parsers. >>> >> Per this feedback, the proposed text requires the use of all bytes used > to encode the serial number, including the tag and length bytes. > >> >>> > - Provides a (partial) technical solution to 'un'redaction (which is >>> > something that needs to be addressed before Chrome will ever support >>> > redaction [1]): If a domain owner's certificate team observes an >>> > unexpected precertificate, they can calculate HASH(SERIAL_NUMBER|| >>> > LABEL) for all of the LABELs they manage. >>> >>> Another way to support "un-redaction" is to just leave the salt >>> extension in the pre-certificate instead of removing it. I'd prefer >>> that approach if this style of un-redaction is desired. >>> >> The reason I'm uneasy with the salt as a separate extension is it adds > some complications (another extension to remove, another thing to get right > when matching the redacted labels with unredacted ones). As far as I can > tell, the serial number could serve the same purpose. > >> >>> Regards, >>> Andrew >>> >>> _______________________________________________ >>> Trans mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/trans >>> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> >>
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
