Confirm, administrator
5,526
edits
Changes
Drafting initial text regarding Issuer Encoding in CRL
Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.
== Issuer Encoding in CRL ==
'''DRAFT: This section is in DRAFT, and being discussed in mozilla.dev.security.policy.'''<br />
The encoding of the Issuer in the CRL should match the encoding of the Issuer in the certificate. The specs permits them to mismatch, but that causes compatibility issues with various clients, so CAs are discouraged from this, just as there should not be mismatches of encoding between cert-issuer and issuer-subject.
* [https://www.ietf.org/rfc/rfc2459.txt RFC 2459] - Implementations allowed to assume different types = different strings (see page 20 of , search for "(a) attribute values encoded"). Section 5.1.2.3 of RFC 2459 covers the Issuer Name for CRLs, and while it follows the same encoding rules, there's no rule that states it must be byte for byte equivalent (that is, however, implied).
* [https://www.ietf.org/rfc/rfc3280.txt RFC 3280] - Implementations allowed to assume different types = different strings (still page 20)
* [https://tools.ietf.org/html/rfc5280#section-7 RFC 5280] - Implementations allowed to assume different types = different strings, but MUST be prepared to handle IDNs
However, in all three versions, implementations were allowed (but not required) to use the X.500 name matching rules to compare characters (not encoded forms). Or, put differently, to map between UTF8String and PrintableString for purposes of comparison. Even though the specs permit the Issuer encoding in the CRL to mismatch the Issuer encoding in the certificate, this causes compatability issues with various clients, so CAs should ensure that the encoding of the Issuer in the CRL matches the encoding of the Issuer in the certificate.
