Subject: [Acme] CSR CN contents for multiple identifiers -- from a recent implementor/integrator

From: Michael Richardson <[email-masked]>
Date: Sun, 17 Mar 2019 00:35:59 -0400

It's too bad RFC8555's section 7.4 elides the CSR in
the  POST /acme/order/TOlocE8rfgo/finalize HTTP/1.1
on page 47, or I could just decode it and see what's in it to answer my
questions :-)

(I rather wish that all RFCs that include content that is the result of
cryptographic operations included the full examples (including private
keys used) in an appendix... but)
{And I'm sorry that I didn't know I should ask this question six months ago.}

Looking through the LetsEncrypt community, at least one system
requests multiple DNS names (WRONGLY) by doing:
         /CN=name1;name2

As getting subjectAltName extensions into CSRs can be painful,
I would have thought that the correct answer was:
         /CN=name1/CN=name2

but that seems to rejected as well.  The rfc2985 reference for CSRs does not
help at all.  I think maybe it should be rfc2986?  In any case, 2986
does not help either.

rfc8555:  Identifiers of type "dns" MUST appear either in the commonName

I'm not actually sure I know what this sentence means.
Many commercial CAs actually have you specify multiple names during the
web interface part.  I think that the "dns" part applies to the SAN
only, and not the CN part.

Reading the source code to boulder it's clear that you can only get
multiple names by including multiple subjectAltName extensions.
The above sentence seems to imply they could be in CN or SAN.
If that's intended, then there is a bug in boulder.
If that's not intended, then the text needs a tweak.
   ..does this warrant an errata?

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

---

From: Jörn Heissler <[email-masked]>
Date: Sun, 17 Mar 2019 09:06:45 +0100

> help at all.  I think maybe it should be rfc2986?  In any case, 2986

2985 is correct:

   Attribute types that are useful especially in PKCS #10 certification
   requests are the challenge password and the extension-request
   attribute.  The attributes would be used in the attributes field of a
   CertificationRequestInfo value.

> only, and not the CN part.

The section in rfc8555 is indeed misleading. We all missed this bug because
everyone (but you, else you would have missed that too) knows that
multiple domain names go into the extension, not the subject.

> multiple names by including multiple subjectAltName extensions.

You need exactly one extension, with multiple names inside. Not sure if
multiple extensions would or should work.

Example how to create a working request:

$ cat > san.cnf <<EOF
[req]
req_extensions = ext
utf = yes
prompt = no
distinguished_name = dn
default_md = sha256

[dn]
commonName = example.net

[ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.net
DNS.2 = ietf.org
DNS.3 = *.ietf.org
EOF

$ openssl req -config san.cnf -new -newkey ed25519 -nodes
Generating a ED25519 private key
writing new private key to stdout
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIC+1PEmlW9iIJPB0J02qQzqjBL5Lt8vBaNC/Huavkh4Y
-----END PRIVATE KEY-----
-----
-----BEGIN CERTIFICATE REQUEST-----
MIHVMIGIAgEAMBYxFDASBgNVBAMMC2V4YW1wbGUubmV0MCowBQYDK2VwAyEAg9zI
pMZW4ftJbRyFmg84aw0vTlsqIX5QSh/y0dZvJxmgPzA9BgkqhkiG9w0BCQ4xMDAu
MCwGA1UdEQQlMCOCC2V4YW1wbGUubmV0gghpZXRmLm9yZ4IKKi5pZXRmLm9yZzAF
BgMrZXADQQCwe/6G5L2855of3/HGF4F9en7+TnRnIv202z32WSGnjtVdPpjD7eCx
zAE6KvvjeV4LlswpiRjVQG8p2I110yIM
-----END CERTIFICATE REQUEST-----

(ed25519 only used for the brevity, not sure if it's supported
anywhere yet! Use RSA or ECC!)

base64-decode the request into example.csr
Dumped it looks like this:

$ dumpasn1 -ad example.csr
  0 213: SEQUENCE {
  3 136: . SEQUENCE {
  6   1: . . INTEGER 0
  9  22: . . SEQUENCE {
 11  20: . . . SET {
 13  18: . . . . SEQUENCE {
 15   3: . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
 20  11: . . . . . UTF8String 'example.net'
       : . . . . . }
       : . . . . }
       : . . . }
 33  42: . . SEQUENCE {
 35   5: . . . SEQUENCE {
 37   3: . . . . OBJECT IDENTIFIER curveEd25519 (1 3 101 112)
       : . . . . }
 42  33: . . . BIT STRING
       : . . . . 83 DC C8 A4 C6 56 E1 FB 49 6D 1C 85 9A 0F 38 6B
       : . . . . 0D 2F 4E 5B 2A 21 7E 50 4A 1F F2 D1 D6 6F 27 19
       : . . . }
 77  63: . . [0] {
 79  61: . . . SEQUENCE {
 81   9: . . . . OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
 92  48: . . . . SET {
 94  46: . . . . . SEQUENCE {
 96  44: . . . . . . SEQUENCE {
 98   3: . . . . . . . OBJECT IDENTIFIER subjectAltName (2 5 29 17)
103  37: . . . . . . . OCTET STRING, encapsulates {
105  35: . . . . . . . . SEQUENCE {
107  11: . . . . . . . . . [2] 'example.net'
120   8: . . . . . . . . . [2] 'ietf.org'
130  10: . . . . . . . . . [2] '*.ietf.org'
       : . . . . . . . . . }
       : . . . . . . . . }
       : . . . . . . . }
       : . . . . . . }
       : . . . . . }
       : . . . . }
       : . . . }
       : . . }
142   5: . SEQUENCE {
144   3: . . OBJECT IDENTIFIER curveEd25519 (1 3 101 112)
       : . . }
149  65: . BIT STRING
       : . . B0 7B FE 86 E4 BD BC E7 9A 1F DF F1 C6 17 81 7D
       : . . 7A 7E FE 4E 74 67 22 FD B4 DB 3D F6 59 21 A7 8E
       : . . D5 5D 3E 98 C3 ED E0 B1 CC 01 3A 2A FB E3 79 5E
       : . . 0B 96 CC 29 89 18 D5 40 6F 29 D8 8D 75 D3 22 0C
       : . }

>    ..does this warrant an errata?

Yes, this does warrant an errata. "Identifiers" is plural,
but multiple dns identifiers just cannot go into the subject.
At least nobody does this.

Does "either" in the sentence mean "exactly one" or "at least one"?
It usually works to put one identifier into the subject, and all of them
into the extension.