Lint Coverage of SMIME BRs version 1.0.0

[robplee]

• SMIME certificates SHALL have cRLDistributionPoints (7.1.2.3.b)(Lint for CABF SMIME 7.1.2.3b - cRLDistributionPoints SHALL be present #742 )
• Strict and Multipurpose SMIME certificates SHALL have the cRLDistributionPoints URI scheme as HTTP others are not permitted (7.1.2.3.b)
• Strict and Multipurpose SMIME certificate AIA fields: OCSP Responder "When provided, every accessMethod SHALL have the URI scheme HTTP." (7.1.2.3.c.1) (refactor of SMIME aia contains #777)
• Strict and Multipurpose SMIME certificate AIA fields: caIssuers "When provided, every accessMethod SHALL have the URI scheme HTTP." (7.1.2.3.c.1) (refactor of SMIME aia contains #777)
• Key usage, RSA certs, strict policies: prevent all key usages other than digitalSignature, nonRepudiation, keyEncipherment (7.1.2.3.e) (CABF SMIME BR 7.1.2.3.e - KeyUsages #757 )
• Key usage, RSA certs, multipurpose/legacy policies: prevent all key usages other than digitalSignature, nonRepudiation, keyEncipherment and dataEncipherment (7.1.2.3.e) (CABF SMIME BR 7.1.2.3.e - KeyUsages #757 )
• Key usage, EC certs, all: prevent all key usages other than digitalSignature, nonRepudiation, keyAgreement, encipherOnly, decipherOnly (7.1.2.3.e) (CABF SMIME BR 7.1.2.3.e - KeyUsages #757 )
• Key usage, EC certs, all: encipherOnly/decipherOnly are permitted only when keyAgreement is set (7.1.2.3.e) (CABF SMIME BR 7.1.2.3.e - KeyUsages #757 )
• Key usage, Edwards certs, keys defined on curve 25519: Bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation. (CABF SMIME BR 7.1.2.3.e - KeyUsages #757 )
• Key usage, Edwards certs, keys defined on curve 448: Bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation. Blocked due to lack of support for curve 448 in zcrypto
• Extended key usage, strict: emailProtection SHALL be present. Other values SHALL NOT BE PRESENT (7.1.2.3.f)(Lints for CABF SMIME BRs 7.1.2.3.f - EKUs #747)
• Extended key usage, multipurpose/legacy: emailProtection SHALL be present. Other values MAY be present (7.1.2.3.f)(Lints for CABF SMIME BRs 7.1.2.3.f - EKUs #747 )
• Extended key usage, all: serverAuth, codeSigning, timeStamping, anyExtendedKeyUsage SHALL NOT BE PRESENT (7.1.2.3.f)
• authorityKeyIdentifier, all: SHALL be present, SHALL NOT be critical. keyIdentifier SHALL be present, authorityCertIssuer and authorityCertSerialNumber SHALL NOT be present (7.1.2.3.g)
• subjectAlternativeName, all: SHALL be present (7.1.2.3.h)(Lint for CABF SMIME 7.1.2.3.h - subjectAlternativeName, all: SHALL be present (7.1.2.3.h) #744)
• subjectAlternativeName, all: SHOULD NOT be marked critical unless subject field is empty (7.1.2.3.h)(Lint for CABF SMIME 7.1.2.3.h - subjectAlternativeName SHOULD NOT be marked critical unless the subject field is an empty sequence #746)
• subjectDirectoryAttributes, strict/multipurpose: field is Prohibited (7.1.2.3.j)
• subjectDirectoryAttributes, legacy: if present, field must not be marked Critical (7.1.2.3.j)
• qcStatements, all: if present, field must not be marked Critical (7.1.2.3.k)
• Legal Entity Identifier, mailbox-validated/individual-validated, all generations: is Prohibited (7.1.2.3.l)
• Legal Entity Identifier, organization-validated, all generations: LEI (1.3.6.1.4.1.52266.1) MAY be present and SHALL NOT be marked critical (7.1.2.3.l)
• Legal Entity Identifier, sponsor-validated, all generations: LEI (1.3.6.1.4.1.52266.1) or for role (1.3.6.1.4.1.52266.2) MAY be present and SHALL NOT be marked critical (7.1.2.3.l)
• Adobe Extensions, strict: is Prohibited (7.1.2.3.m) (CABF SMIME BR 7.1.2.3.m - Adobe Extensions #763)
• extensions:subjectAltName all validations, all generations: SHALL be present, SHALL contain at least one GeneralName entry of the following types: Rfc822Name, otherName of type id-on-SmtpUTF8Mailbox (7.1.4.2.1)
• subject:commonName, mailbox-validated: if present, this attribute SHALL contain... [a] Mailbox Address (7.1.4.2.2.a)
• subject:commonName, organization-validated: if present, this attribute SHALL contain... subject:organizationName or [a] Mailbox Address (7.1.4.2.2.a)
• subject:commonName, sponsor-validated/individual-validated: if present, this attribute SHALL contain... Personal Name, subject:pseudonym, or [a] Mailbox Address. PersonalName SHOULD be presented as subject:givenName and/or subject:surname (7.1.4.2.2.a)
• subject:commonName, all: if present, the Mailbox Address SHALL contain a rfc822Name or otherName value of type id-on-smtpUTF8Mailbox from extensions:subjectAltName (7.1.4.2.2.a)
• subject:givenName, subject:surname, subject:pseudonym: The subject:givenName and/or subject:surname SHALL NOT be present if the subject:pseudonym is present. (7.1.4.2.2.e/f)
• subject:emailAddress, all: if present, the subject:emailAddress SHALL contain a single Mailbox Address. (7.1.4.2.2.h)(CABF SMIME 7.1.4.2.h If present, the subject:emailAddress SHALL contain a single Mailbox Address #752 )
• subject:countryName, all: SHALL contain the two letter ISO country code or 'XX' if no ISO 3166-1 code has been assigned (7.1.4.2.2.n)
• subject DN attributes for mailbox-validated profile (7.1.4.2.3)(Add lint enforcing the restrictions on subject DN fields for mailbox validated SMIME certificates #713 )
• subject DN attributes for organization-validated profile - Legacy (7.1.4.2.4)
• subject DN attributes for organization-validated profile - Multipurpose (7.1.4.2.4)
• subject DN attributes for organization-validated profile - Strict (7.1.4.2.4)
• subject DN attributes for sponsor-validated profile - Legacy (7.1.4.2.5)
• subject DN attributes for sponsor-validated profile - Multipurpose (7.1.4.2.5)
• subject DN attributes for sponsor-validated profile - Strict (7.1.4.2.5)
• subject DN attributes for sponsor-validated profile - Multipurpose/Strict: profiles SHALL include either subject:givenName and/or subject:surname, or the subject:pseudonym (7.1.4.2.5)
• subject DN attributes for individual-validated profile - Legacy (7.1.4.2.6)
• subject DN attributes for individual-validated profile - Multipurpose (7.1.4.2.6)
• subject DN attributes for individual-validated profile - Strict (7.1.4.2.6)

[bitlux]

Hello,

I'd like to help implement some of these lints. Would you be open to my contributions? I'm working on launching S/MIME certificates at my organization, and we'd like to be able to use zlint to lint S/MIME certificates, as we do with TLS.

I've already sent a PR (#779) for one of the lints on the list.

[bitlux]

I think

Extended key usage, all: serverAuth, codeSigning, timeStamping, anyExtendedKeyUsage SHALL NOT BE PRESENT (7.1.2.3.f)

was handled by #747. https://github.com/robplee/zlint/blob/1018dcd6368fbbc65846bc3b721aa83092aeb863/v3/lints/cabf_smime_br/smime_legacy_multipurpose_eku_check.go#L66 compares the EKU against the list of forbidden EKUs.