Having recently started work on code to reconstruct a precert TBSCertificate given a name-redacted certificate, I agree that the following is a concern:
On Wed, 15 Jun 2016 13:47:18 +0100 Eran Messeri <[email protected]> wrote: > * If the original, redacted precert had encoding violations it will > be very hard for the client to re-encode it correctly (I'll point out > that logs MAY accept cert chains that are "not fully valid according > to RFC 5280 verification rules in order to accommodate quirks of CA > certificate-issuing software"). A concrete example is a cert with trailing garbage at the end of the subjectAltName, such as this one: https://crt.sh/?q=cf144cad0599775dc273d02205f1fccfd042a43dbf382695950e82fa0b601ec7 When reconstructing a redacted pre-cert TBSCertificate, it is necessary to parse the subjectAltName and then re-encode it. Should implementations be expected to remember the trailing garbage and include it in the reconstructed TBSCertificate? I think that would be an unreasonable requirement due to the complexity. However, if a popular implementation decides to do that, and then the ecosystem gets flooded with certs exhibiting this encoding error, it will become a de facto requirement for other implementations, driving up the complexity cost of supporting redaction. Another challenge is non-ASCII characters in DNS SANs or IA5String common names. A client might normally ignore improperly-encoded identifiers so the certificate can still work with the other identifiers. However, with redaction, for the certificate to work for any identifier, the client needs to be able to decode all of them and then re-encode the incorrectly-encoded ones with the same encoding violation as the original certificate. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
