Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add lints for DirectoryString encoding as Printable or UTF8 #368

Open
jsha opened this issue Jan 22, 2020 · 0 comments
Open

Add lints for DirectoryString encoding as Printable or UTF8 #368

jsha opened this issue Jan 22, 2020 · 0 comments

Comments

@jsha
Copy link
Contributor

jsha commented Jan 22, 2020

https://tools.ietf.org/html/rfc5280#page-24

When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:

  (a)  When the subject of the certificate is a CA, the subject
       field MUST be encoded in the same way as it is encoded in the
       issuer field (Section 4.1.2.4) in all certificates issued by
       the subject CA.  Thus, if the subject CA encodes attributes
       in the issuer fields of certificates that it issues using the
       TeletexString, BMPString, or UniversalString encodings, then
       the subject field of certificates issued to that CA MUST use
       the same encoding.

  (b)  When the subject of the certificate is a CRL issuer, the
       subject field MUST be encoded in the same way as it is
       encoded in the issuer field (Section 5.1.2.3) in all CRLs
       issued by the subject CRL issuer.

  (c)  TeletexString, BMPString, and UniversalString are included
       for backward compatibility, and SHOULD NOT be used for
       certificates for new subjects.  However, these types MAY be
       used in certificates where the name was previously
       established, including cases in which a new certificate is
       being issued to an existing subject or a certificate is being
       issued to a new subject where the attributes being encoded
       have been previously established in certificates issued to
       other subjects.  Certificate users SHOULD be prepared to
       receive certificates with these types.

Clause (c) makes it hard to make this an error or warning, since we can't know if a name had previously been established. Perhaps this could be a notice-level lint?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants