Subject: [lamps] Encoding errors in draft-ietf-lamps-samples-01

From: "David A. Cooper" <[email-masked]>
Date: Tue, 11 May 2021 10:35:48 -0400

I ran the ten sample certificates in draft-ietf-lamps-samples-01 through 
a certificate checker that I wrote several years ago and it highlighted 
a couple of issues with the sample certificates.

The first issue is that the keyUsage extensions in the certificates are 
not DER encoded. The keyUsage extensions in the certificates are all 
encoded in the form "03 03 07 XX 00."

It seems that the developer of the encoder mistakenly believed that the 
bit string should always be 9 bits long in order to correspond to the 
definition of keyUsage:

    KeyUsage ::= BIT STRING {
                digitalSignature        (0),
                nonRepudiation          (1), -- recent editions of X.509
    have
                                     -- renamed this bit to
    contentCommitment
                keyEncipherment         (2),
                dataEncipherment        (3),
                keyAgreement            (4),
                keyCertSign             (5),
                cRLSign                 (6),
                encipherOnly            (7),
                decipherOnly            (8) }

However, X.680 and X.690 specify that when encoding a named bit list, 
such as above, any trailing zeros must be removed. So, a keyUsage 
extension with just digitalSignature and nonRepudiation set would be 
encoded as a bit string that is only two bits long ('11') and a keyUsage 
extension with just keyAgreement set would be encoded as a bit string 
that is five bits long ('00001').

So, the correct encoding for the keyUsage extension would be:

  * "03 02 01 06" for the CA certificate
  * "03 02 06 C0" for the digital signature certificates
  * "03 02 05 20" for the encryption certificates
  * "03 02 03 08" for the key agreement certificates

The second issue the program highlighted is that the certificates in 
Sections 4.1, 4.3, 7.3, and 8.1 contain negative serial numbers. While 
this is permitted by X.509, Section 4.1.2.2 of RFC 5280 requires 
conforming CAs to use positive integers as serial numbers.

Thanks,

David Cooper

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 12 May 2021 19:27:21 -0400

Hi David--

Thanks for reviewing, and for catching these two issues!

It looks to me like these are issues with the certificate generation
tooling I'm using to generate the draft.  I've reported them upstream
here:

- mis-encoded KeyUsage:
  https://gitlab.com/gnutls/gnutls/-/issues/1236

- negative serial numbers:
  https://gitlab.com/gnutls/gnutls/-/issues/1237

I'm working on a new revision to the draft that should resolve both
problems.

I welcome more reviews like this that actually apply the sample
certificates to code!

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 12 May 2021 21:35:28 -0400

Hi David (and other LAMPS folks)--

> a couple of issues with the sample certificates.

Is that certificate checker something that is publicly available?  It
sounds like it would be a pretty useful thing to have!

I found the following X.509 certificate "linters" with a quick search, but
i haven't tried running them on the certs in the draft yet:

  https://github.com/zmap/zlint
  https://github.com/certlint/certlint
  https://github.com/globalsign/certlint

I'd be curious to hear any results from anyone working on them.

Are there any other linters that folks know of that are worth trying?

    --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 May 2021 01:45:05 +0000

>      https://github.com/certlint/certlint

These two are the dominant ones.  But  don't take my word for it, take Ryan's :)  https://twitter.com/sleevi_/status/1392120487749300226

---

From: Rob Stradling <[email-masked]>
Date: Thu, 13 May 2021 10:04:50 +0000

Hi DKG.  Here are some hopefully useful links...

ZLint: https://github.com/zmap/zlint
Certlint/CABlint: https://github.com/certlint/certlint   (formerly https://github.com/awslabs/certlint)
x509lint: https://github.com/kroeckx/x509lint

Censys can run ZLint over any certificate that it's already aware of.
Example: https://censys.io/certificates/7ba3f342894da292d7e20bb6a7c385e3cc6deb432d5ffa79a998a3d0eaa8dc30/zlint

https://crt.sh/ can run ZLint, CABlint and x509lint over any certificate that it's already aware of.
Example: https://crt.sh/?id=3162422298&opt=zlint,cablint,x509lint

https://crt.sh/lintcert can run ZLint, CABlint and x509lint over any user-supplied certificate.

I just ran a couple of the certs from draft-ietf-lamps-samples-01 through https://crt.sh/lintcert.  It looks like ZLint and Certlint/CABlint don't currently detect the non-minimal Key Usage encoding, whereas x509lint does.

________________________________
From: Spasm <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: 13 May 2021 02:45
To: Daniel Kahn Gillmor <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [lamps] X.509 certificate linting [was: Re: Encoding errors in draft-ietf-lamps-samples-01]

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.

>      https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint&amp;data=04%7C01%7C%7C6327dfa0b5ea4b9f069108d915b0c536%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637564671245631710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IQHSr%2FtQDzhtS51Ots2rcs9PvNRMMRIl8CPI67tCbr8%3D&amp;reserved=0
>      https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcertlint%2Fcertlint&amp;data=04%7C01%7C%7C6327dfa0b5ea4b9f069108d915b0c536%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637564671245631710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zeMe5FMhHKFrgGqw%2FhYIHkPPaY7LZSCDPnpi7GehuII%3D&amp;reserved=0

These two are the dominant ones.  But  don't take my word for it, take Ryan's :)  https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fsleevi_%2Fstatus%2F1392120487749300226&amp;data=04%7C01%7C%7C6327dfa0b5ea4b9f069108d915b0c536%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637564671245631710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=EOdKR%2BNuXMXjDhVSvk%2BYoXoYCrOd9s5HNzIgvXkFmAc%3D&amp;reserved=0

_______________________________________________
Spasm mailing list
[email-masked]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7C%7C6327dfa0b5ea4b9f069108d915b0c536%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637564671245631710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uqGOOrFmW3ldsbWhUvy%2BBOH5i8%2B0WHZ1G2HikwFTNjQ%3D&amp;reserved=0

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 13 May 2021 21:10:15 -0400

> Hi DKG.  Here are some hopefully useful links...

Thanks very much for this overview of X.509 linters!

> x509lint: https://github.com/kroeckx/x509lint

I played around a bit with certlint, and found that it appears to choke
on the "new" CFRG curves.  I wasn't able to patch it in easily because i
ran into some problems with a dependency (asn1c) choking on RFC 5912.  I
reported this upstream:

   https://github.com/certlint/certlint/issues/7

> https://crt.sh/lintcert can run ZLint, CABlint and x509lint over any user-supplied certificate.

After revising the drafted certificates to account for issues raised on
list, i used https://crt.sh/lintcert to produce this output for dana.sign.25519.crt:

cablint	ERROR	ED25519 is not allowed for signing certificates
cablint	ERROR	Subject key must be RSA, DSA, or EC
cablint	WARNING	Certificate signature algorithm type is unknown: 1.3.101.112
cablint	WARNING	Unknown public key type
cablint	INFO	Key usages not checked for OpenSSL::PKey::PKey
cablint	INFO	No certificate type identified
x509lint	ERROR	Issuer without countryName
x509lint	ERROR	Issuer without organizationName
x509lint	ERROR	no authorityInformationAccess extension
x509lint	ERROR	No OCSP over HTTP
x509lint	ERROR	No policy extension
x509lint	ERROR	The certificate is valid for longer than 60 months
x509lint	WARNING	No HTTP URL for issuing certificate
x509lint	INFO	Checking as leaf certificate
x509lint	INFO	Subject has a deprecated CommonName
x509lint	INFO	Unknown validation policy
zlint	NOTICE	Check if certificate has enough embedded SCTs to meet Apple CT Policy

It looks like at least some of these reflect CABForm policies which
might not be applicable either in the S/MIME context or to sample
certificates.

What do other LAMPS folks think?

Going through the list (regrouping a bit to handle related warnings
together:

> cablint	ERROR	ED25519 is not allowed for signing certificates
> cablint	ERROR	Subject key must be RSA, DSA, or EC
> cablint	WARNING	Certificate signature algorithm type is unknown: 1.3.101.112
> cablint	WARNING	Unknown public key type
> cablint	INFO	Key usages not checked for OpenSSL::PKey::PKey

These all seem related to the fact that certlint/cablint can't handle CFRG
curves, as noted above.  And, perhaps they reflect some conservative
CABForum policy on choices of algorithm.  I think that means that they
aren't relevant for the goal of this draft.

> cablint	INFO	No certificate type identified

I'm not sure what this is supposed to mean, other than that
certlint/cablint are confused about the certificate itself due to not
handling the algorithms in question.

> x509lint	ERROR	Issuer without countryName
> x509lint	ERROR	Issuer without organizationName

We can easily fix these constraints by making up an org name (maybe
"O=IETF/OU=LAMPS WG"?) and choosing a country (is there an example
country code, analogous to the .example TLD?).  Do folks think that
would be worth including?

> x509lint	ERROR	no authorityInformationAccess extension
> x509lint	ERROR	No OCSP over HTTP
> x509lint	WARNING	No HTTP URL for issuing certificate

The CABForum's Baseline Requirements suggest that AIA has a MUST for
including the issuing CA's OCSP responder endpoint and a SHOULD for a
URL where one can find the issuing CA's certificate.

I don't think anyone plans to run an OCSP responder for the sample CAs,
and i don't think anyone has a plan to host a permanent OCSP responder
for the certification authorities here.  To my knowledge, despite being
able to mark an <artwork> element in an I-D's XML with an explicit file
name, the IETF doesn't automatically publish the constituent components
of an RFC in any distinct location.

So, my inclination is to ignore these warnings.

> 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	ERROR	The certificate is valid for longer than 60 months

I think the draft already has a good justification for violating this
constraint; i don't think there's anything to do here.

> 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