On Thu, Feb 2, 2017 at 3:59 PM, Jakob Bohm <[email protected]> wrote:
> On 02/02/2017 00:46, Kathleen Wilson wrote: > >> All, >> >> I've added another Potentially Problematic Practice, as follows. >> >> https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL >> The encoding of the Issuer field in the CRL should be byte-for-byte >> equivalent with the encoding of the Issuer in the certificate; that is, >> using the exact same string types and field contents. The specs (RFC 2459, >> RFC 3280, RFC 5280) permit them to mismatch, but that causes compatibility >> issues with various clients -- in such cases client software might not find >> the entry for the revoked certificate in the CRL. >> >> As always, I will appreciate your thoughtful and constructive feedback. >> >> We ran into this situation several times while adding entries to OneCRL >> for revoked intermediate certificates, because our script pulled the data >> from the CAs' CRLs where possible. >> >> We have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1330968 to >> update the OneCRL client to be encoding agnostic when doing the Issuer >> comparisons. >> >> > What should a CA do if they have used different encodings of the same > issuer DN in different certs that point to the same CRL location? > > Wouldn't a more proper set of rules be: > > 1. The encoding of the Issuer field in the CRL must be the same as in > the SubjectDN in the issuing certificate. > > 2. The IssuerDN in all future issued certificates must the same as in > the SubjectDN in the issuing certificate. > > 3. If any previously issued certificates did not follow rule 2, the CA > must publish a list of the exact IssuerDN encodings used in such > certificates. > What value does 3 provide? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
