Subject: [lamps] Fwd: X.509 certificate linting

From: "David A. Cooper" <[email-masked]>
Date: Fri, 14 May 2021 08:28:07 -0400

I uploaded the program that I've been using to 
https://github.com/dcooper16/cert_check. I haven't looked at the code 
much since I wrote it several years ago, so I'm not planning to actively 
maintain it, but it still might be useful for some purposes.

Looking at the source code for https://github.com/kroeckx/x509lint, I 
can see that there are a number of checks for conformance to the 
CABForum requirements. For any certificates that are not CA 
certificates, it checks against the CABForum's requirements for 
subscriber certificates. The CABForum baseline requirements "only 
address Certificates intended to be used for authenticating servers 
accessible through the Internet," so it should be expected that many 
issues raised by x509lint don't apply to S/MIME certificates.

I don't think it's necessary for the sample certificates to include a 
certificatePolicies extension. However, if you want, NIST has defined a 
set of OIDs that say that the certificates were "issued for testing and 
evaluation ONLY": 
https://csrc.nist.gov/CSRC/media/Projects/Computer-Security-Objects-Register/documents/test_policy.pdf.

As for the CommonName issue, the baseline requirements say that if the 
commonName field is present in a subscriber certificate it MUST contain 
an IP address or FQDN. However, certificates should now only include 
that information in the subjectAltName extension, so inclusion of a 
commonName is deprecated. On the other hand, the baseline requirements 
indicate that CA certificates MUST include a commonName. So, this is 
just noting that information such as IP address and FQDN shouldn't be 
encoded in the subject field, not that commonName is bad in general.

draft-ietf-trans-rfc6962-bis indicates that CT is limited to TLS server 
certificates, and I don't believe that there is any discussion about 
extending it to email certificates.

On 5/13/21 9:10pm, Daniel Kahn Gillmor wrote:

> > x509lint	ERROR	No policy extension
> > x509lint	INFO	Unknown validation policy
>
> the INFO line comes from x509lint's verification:
>
> 	if (type == SubscriberCertificate && !DomainValidated && !OrganizationValidated
> 		&& !IndividualValidated && !EVValidated)
>
> The two mentions here appear to be based on CABForum requirements for
> the certificatePolicies extension -- but even if we added the extension,
> we wouldn't be able to legitimately include (for example) policy
> 2.23.140.1.2.1 (which claims alignment with the domain-validated
> standards for the CABForum BR), so unless there is some OID for a "these
> certificates are used for examples and test cases" policy that someone
> thinks we should point to, i'm inclined to ignore it.
>
> > x509lint	INFO	Subject has a deprecated CommonName
>
> Perhaps we should use surName and givenName instead of commonName for
> the end-entity certificates?
>
> > zlint	NOTICE	Check if certificate has enough embedded SCTs to meet Apple CT Policy
>
> I don't expect to embed these certificates in the CT logs, so we aren't
> going to get SCTs.  If the certificates aren't in CT, does that make
> them less useful?  should we be trying to apply cert transparency to
> them somehow?
>
>       --dkg

---

From: Rob Stradling <[email-masked]>
Date: Fri, 14 May 2021 13:45:24 +0000

Daniel, David,

Sorry, I should have mentioned up front what you've both observed - that the development of these linters has so far been focused primarily on the WebPKI.

However, it's worth noting that https://github.com/certlint provides two applications: certlint and cablint.  The former is intended to lint against IETF standards (notably RFC5280), whereas the latter is intended to lint against both IETF and CABForum requirements.  (https://crt.sh/lintcert runs cablint rather than certlint, because crt.sh (and CT) aren't particularly interested in non-WebPKI certificates).

Also, there's been talk recently of adding a "linting profile" concept to ZLint - see https://github.com/zmap/zlint/issues/583 and https://github.com/zmap/zlint/issues/594.

________________________________
From: Spasm <[email-masked]> on behalf of David A. Cooper <david.cooper=[email-masked]>
Sent: 14 May 2021 13:28
To: Daniel Kahn Gillmor <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [lamps] Fwd: X.509 certificate linting

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I uploaded the program that I've been using to https://github.com/dcooper16/cert_check<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdcooper16%2Fcert_check&data=04%7C01%7C%7Caf2dae9abdce466ed47508d916d3c5cd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565921679738633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=UjaddeRK1GjoMGXR%2F2Tjsr7iNHyZ93dzf3fyGCQ%2FlFE%3D&reserved=0>. I haven't looked at the code much since I wrote it several years ago, so I'm not planning to actively maintain it, but it still might be useful for some purposes.

Looking at the source code for https://github.com/kroeckx/x509lint<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkroeckx%2Fx509lint&data=04%7C01%7C%7Caf2dae9abdce466ed47508d916d3c5cd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565921679738633%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=TqZVvhy%2FvFg53Cyaoobt3uK35BVMKXh0XFiOu1LbIcQ%3D&reserved=0>, I can see that there are a number of checks for conformance to the CABForum requirements. For any certificates that are not CA certificates, it checks against the CABForum's requirements for subscriber certificates. The CABForum baseline requirements "only address Certificates intended to be used for authenticating servers accessible through the Internet," so it should be expected that many issues raised by x509lint don't apply to S/MIME certificates.

I don't think it's necessary for the sample certificates to include a certificatePolicies extension. However, if you want, NIST has defined a set of OIDs that say that the certificates were "issued for testing and evaluation ONLY": https://csrc.nist.gov/CSRC/media/Projects/Computer-Security-Objects-Register/documents/test_policy.pdf<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcsrc.nist.gov%2FCSRC%2Fmedia%2FProjects%2FComputer-Security-Objects-Register%2Fdocuments%2Ftest_policy.pdf&data=04%7C01%7C%7Caf2dae9abdce466ed47508d916d3c5cd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565921679748589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FMaGQZvHFk80pmzmYNkCm584A1na7Cqdb0gKfRwkpQE%3D&reserved=0>.

As for the CommonName issue, the baseline requirements say that if the commonName field is present in a subscriber certificate it MUST contain an IP address or FQDN. However, certificates should now only include that information in the subjectAltName extension, so inclusion of a commonName is deprecated. On the other hand, the baseline requirements indicate that CA certificates MUST include a commonName. So, this is just noting that information such as IP address and FQDN shouldn't be encoded in the subject field, not that commonName is bad in general.

draft-ietf-trans-rfc6962-bis indicates that CT is limited to TLS server certificates, and I don't believe that there is any discussion about extending it to email certificates.

     --dkg

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 May 2021 11:32:11 -0400

Thanks David!

There have been many GeneralName otherName forms defined in RFCs since this was written.  PermanentIdentifier (RFC 4043), HardwareModuleName (RFC 4108), SIM (RFC 4683), SRVName (RFC 4985), XMPP address (RFC 6102), NAI Realm (RFC 7585), EAI (RFC 8398), and so on.  I have see that these are not always encoded as the specified type.  For example, UTF8String is used when PrintableString is specified.

Maybe as a community we can add the additional otherName forms to this code.

Russ

> On May 14, 2021, at 8:28 AM, David A. Cooper <david.cooper=[email-masked]> wrote:
> 
> I uploaded the program that I've been using to https://github.com/dcooper16/cert_check <https://github.com/dcooper16/cert_check>. I haven't looked at the code much since I wrote it several years ago, so I'm not planning to actively maintain it, but it still might be useful for some purposes.
> Looking at the source code for https://github.com/kroeckx/x509lint <https://github.com/kroeckx/x509lint>, I can see that there are a number of checks for conformance to the CABForum requirements. For any certificates that are not CA certificates, it checks against the CABForum's requirements for subscriber certificates. The CABForum baseline requirements "only address Certificates intended to be used for authenticating servers accessible through the Internet," so it should be expected that many issues raised by x509lint don't apply to S/MIME certificates.
> 
> I don't think it's necessary for the sample certificates to include a certificatePolicies extension. However, if you want, NIST has defined a set of OIDs that say that the certificates were "issued for testing and evaluation ONLY": https://csrc.nist.gov/CSRC/media/Projects/Computer-Security-Objects-Register/documents/test_policy.pdf <https://csrc.nist.gov/CSRC/media/Projects/Computer-Security-Objects-Register/documents/test_policy.pdf>.
>