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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 17 March 2019 04:36 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2201310E5 for <acme@ietfa.amsl.com>; Sat, 16 Mar 2019 21:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76bi1Y36EpTc for <acme@ietfa.amsl.com>; Sat, 16 Mar 2019 21:36:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C35124408 for <acme@ietf.org>; Sat, 16 Mar 2019 21:36:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 165C03826B for <acme@ietf.org>; Sun, 17 Mar 2019 00:35:37 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9E8DBB9A; Sun, 17 Mar 2019 00:35:59 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9C2825D0 for <acme@ietf.org>; Sun, 17 Mar 2019 00:35:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: acme@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 17 Mar 2019 00:35:59 -0400
Message-ID: <29180.1552797359@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/Fw8AYOH2ONXb5lKZFqjpJznz2ss>
Subject: [Acme] CSR CN contents for multiple identifiers -- from a recent implementor/integrator
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Mar 2019 04:36:05 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-