Subject: [lamps] multiple EKU extensions in a certificate -- an observation

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Nov 2021 14:32:11 -0500

Due to a limitation in the ruby-openssl interface, I wound up creating server
certificates that had multiple Extended Key Usage (EKU) extensions, rather than a
single EKU that contained multiple OIDs.
I am investigating how to fix this.

I discovered this when I set the certificate as the OpenSSL (D)TLS server
certificate, and then deep in x509v3_cache_extensions(), when it sees
multiple EKUs, it bails, marking the certificate as invalid.  It continues on
anyway (not having rejected the certificate), but since it has no
certificates and DTLS is 1.2 based, it says that it has no matching cipher,
sending a "no shared cipher" Alert.
(It was really difficult to figure this out: IoT is involved and thus the
CCM-8 cipher, which is not enabled by default... so I was barking up the
wrong tree on and off since 2018, I think)

I just reviewed:
  https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.1.12

That section says nothing about multiple extensions, but additional reading
found that section 4.2 does say:
   A certificate MUST NOT include more than one instance of a particular extension.

The OpenSSL's X509_get_ext_d2i() function seems setup to be able to process
multiple extensions of the same kind, so I wonder if there are any exception to
that rule.

Anyway, I'm just posting this here as a breadcrumb.
I have another long email the openssl-users, and I need to open a few bug reports.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Nov 2021 14:40:26 -0500

Indeed, RFC 5280 says:

   A certificate MUST NOT include more
   than one instance of a particular extension.

I cannot think of any reason why any extension would appear more than once.  I can think of many ways that they could be inconsistent if that were to happen.

Russ

> On Nov 22, 2021, at 2:32 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 22 Nov 2021 15:12:39 -0500

Yes, the APIs for OpenSSL (and several other PKI toolkits) will happily
allow you to create invalid certificates if you so desire and direct, where
"invalid" is Not Conforming to RFC 5280 (and/or ITU-T X.509, for those who
believe the distinction valuable).

This was the cause for many issues in existing PKIs, such as the Web PKI,
and why a variety of linting tools have been developed to ensure that the
necessary degree of technical interoperability is met.

The pre-eminent tools for this are https://github.com/certlint/certlint ,
which incorporates https://github.com/vlm/asn1c via Ruby to compile the
ASN.1 module and to enforce syntactic schema constraints, and
https://github.com/zmap/zlint , which is written in Go, and works to
enforce the semantic and prosaic constraints. Anyone attempting to create
certificates by hand are strongly encouraged to use both tools to evaluate
against the relevant RFCs, thus avoiding many common forms of
interoperability risk.

On Mon, Nov 22, 2021 at 2:32 PM Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>