Subject: [Acme] Issuing a cert with a superset of requested identifiers

From: Mike Danese <[email-masked]>
Date: Wed, 16 Aug 2017 18:24:23 -0700

Hello,

It's unclear to me whether an ACME CA is allowed to issue a cert with
a superset of identifiers that were requested in the order. I see the
language:

> The server MUST return an error if it cannot fulfill the request as
> specified, and MUST NOT issue a certificate with contents other than
> those requested. If the server requires the request to be modified in
> a certain way, it should indicate the required changes using an
> appropriate error type and description.

https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-7.4

Due to this statement, I suspect the answer is no but the meaning of
"fulfill the request as specified" is pretty ambiguous w.r.t. changes
that are purely additive.

Thanks for clarity,
Mike Danese

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Aug 2017 13:54:16 +0000

language:
    
    > those requested.

The “and MUST NOT” clause means that both parts are required to be true.  So if you ask for A B and you are given A B C then the server was not compliant.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Aug 2017 11:05:02 -0400

Yeah, I agree that the intent here is for the CSR to match the certificate
in all material respects.

This does require the client to know what it wants, so it knows what to put
in the CSR.  Do you have a use case where that's not the case?

On Thu, Aug 17, 2017 at 9:54 AM, Salz, Rich <[email-masked]> wrote:

> The “and MUST NOT” clause means that both parts are required to be true.
> So if you ask for A B and you are given A B C then the server was not
> compliant.
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Oliver Weyhmüller <[email-masked]>
Date: Thu, 17 Aug 2017 17:21:38 +0000

Hello,

I work at a "legacy CA" and there it is quite common to substitute all
components of the certificate subject except the CN when a DV certificate
is issued. Also OV and EV certificates normally include information in the
subject, that are not part of the requesting CSR.

We think about implementing ACME, and see some potential use cases for
that. For example, a customer's order could only specify a CN in the
subject to get a free DV certificate just like LE does. In parallel the
organisation or extended validation process takes place and the customer
gets the external-account-binding mac and kid if this process completes
successfully. After configuring mac and kid at the ACME client, a renewal
could seamlessly upgrade the DV certificate to an OV or even EV one. Vice
versa a OV or EV certificate could be downgraded to a free DV certificate
if the customer cancels his contract or updated validation documents are
not provided in time, preventing the usage of an expired certificate.

Of course, the CN and the  SANs MUST NOT be altered by the CA.

Regards,
Oliver Weyhmüller

On Thu, Aug 17, 2017 at 5:05 PM Richard Barnes <[email-masked]> wrote:

> This does require the client to know what it wants, so it knows what to
> put in the CSR.  Do you have a use case where that's not the case?
>
> --
Oliver Weyhmüller
Hauptstr. 17/1
73098 Rechberghausen
Germany

Tel +49 7161 9866330
Fax +49 7161 9866332
Mobile +49 160 1560508
E-Mail [email-masked]
Web: https://www.weyhmueller.de

---

From: Clint Wilson <[email-masked]>
Date: Thu, 17 Aug 2017 18:11:41 +0000

Oliver's use-case is very similar to our own, as well. Looking exclusively
at OV, for example, it's difficult to rely upon exactly what is in the CSR
for issuance. While a requester knows the specific dNSName value(s) they
need, they often don't know the specific legally registered entity name.

As I'm interpreting the word and intent correctly, then if a request has A,
B, and O, but the provided O value in the request is not reflective of the
legal entity to be represented in the certificate's O value, the CA is
unable to issue the cert because they cannot assert O, but they also cannot
change O to O'. Or if the request includes the Organization name and
Country, but not the Locality, the CA is unable to issue the cert through
ACME.

On Thu, Aug 17, 2017 at 11:25 AM Oliver Weyhmüller <[email-masked]>
wrote:

>> Yeah, I agree that the intent here is for the CSR to match the
>> certificate in all material respects.
>>
>>> The “and MUST NOT” clause means that both parts are required to be
>>> true.  So if you ask for A B and you are given A B C then the server was
>>> not compliant.
>>
>> --
> Oliver Weyhmüller
> Hauptstr. 17/1
> 73098 Rechberghausen
> Germany
>
> Tel +49 7161 9866330 <+49%207161%209866330>
> Fax +49 7161 9866332 <+49%207161%209866332>
> Mobile +49 160 1560508 <+49%20160%201560508>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Aug 2017 18:26:42 +0000

There’s compliant and there’s compliant. ☺  The IETF has no protocol police, and you will not get a ticket for issuing a cert “wrongly.”  Will anyone complain if you change the CSR to say “S.A.” or “Pty” instead of “Inc” or “Ltd”?  Of course not.

Will people be upset if you add other random SAN fields they didn’t want or ask for?  Yes.  This is the internet, someone is bound to be upset. ☺

It’s great to see commercial interest.  If there are real roadblocks we can issue errata, updates, new challenges, or whatever it takes.

                /r$

---

From: Mike Danese <[email-masked]>
Date: Thu, 17 Aug 2017 13:15:02 -0700

*Resending after joining the list.*

Thanks for clarifying that for me. It's the answer I expected.

I have a very different use case which I believe has gotten somewhat
less attention than the public CA use case. I am studying large
orchestration systems (some internal and some external like
Kubernetes) that have very similar APIs to ACME. In these systems, the
CAs are not publicly trusted. All communication secured by these CAs
is internal.

These APIs are used to provide credentials to processes running in the
system. Processes use these credentials to establish (essentially)
mutual TLS authentication with other processes. In these systems,
there is a very loose coupling between the process and the TCP
loadbalancers that might front the process. A process exposes a
secured network endpoint and doesn't know or care where connections
are coming from. A process only knows it's own identifier.

This poses a problem when trying to talk to a process through a named
loadbalancer. Standard TLS validation will fail if a client talks
through a named loadbancer to a process that presents a certificate
with a DN of the process's identifier and without a SAN of the
loadbalancer identifier. Possible solutions I can think of are:

1. Have the CA add SANs to the process's CSR for the loadbalancer
identifiers the process backs. This is out of ACME spec, but we aren't
going to get a ticket :)
2. Have the process fetch which loadbalancer identifiers it will back
before building and sending a CSR to ACME. This has some performance
implications. We like processes to start rapidly. This has some
architecture implications. The loose coupling is quite handy.
3. Terminate/re-establish TLS in the loadbalancers. This has some
performance and security implications.
4. Relax TLS and have processes consult a central, trusted map of
loadbalancer identifiers to process identifiers to validate server
authentication. This solves the problem and has some other nice
properties but is (fairly radically) out of TLS spec.

One of these solutions is less bad than the others and we can figure
out how to workaround if we decide ACME satisfies this use case.

On Thu, Aug 17, 2017 at 11:26 AM, Salz, Rich <[email-masked]> wrote:
> There’s compliant and there’s compliant. J  The IETF has no protocol police,
> and you will not get a ticket for issuing a cert “wrongly.”  Will anyone
> complain if you change the CSR to say “S.A.” or “Pty” instead of “Inc” or
> “Ltd”?  Of course not.
>
>
>
> Will people be upset if you add other random SAN fields they didn’t want or
> ask for?  Yes.  This is the internet, someone is bound to be upset. J
>
>
>
> It’s great to see commercial interest.  If there are real roadblocks we can
> issue errata, updates, new challenges, or whatever it takes.
>
>
>
>                 /r$
>
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Aug 2017 20:21:41 +0000

Use #1 – add the loadbalancer to the SAN name – and use ACME ☺

---

From: Alan Doherty <[email-masked]>
Date: Fri, 18 Aug 2017 05:29:18 +0100

surely

public <ssl> loadbalancer with acme SAN

loadbalancer <internal ssl> process with its own internal cert

thus 2 separate connections
same as would be used if internal process was http without ssl
(aka 3)

or if as you imply internal ssl is unvalidated (process names are not known to callers thus CA trusted but individual identity unvalidated) 
then simply obtain SAN from LE (via loadbalancer)

have each process(that can be externally reached) only use a copy of this SAN+private-key
have all internal callers trust this SAN (via trusting its CA as well as the internal) as it will be equally unvalidated for internal callers
but will match all public names for external (validating) callers (web browsers)

At 21:15 17/08/2017  Thursday, Mike Danese wrote:
>*Resending after joining the list.* Thanks for clarifying that for me. It's the answer I expected. I have a very different use case which I believe has gotten somewhat less attention than the public CA use case. I am studying large orchestration systems (some internal and some external like Kubernetes) that have very similar APIs to ACME. In these systems, the CAs are not publicly trusted. All communication secured by these CAs is internal. These APIs are used to provide credentials to processes running in the system. Processes use these credentials to establish (essentially) mutual TLS authentication with other processes. In these systems, there is a very loose coupling between the process and the TCP loadbalancers that might front the process. A process exposes a secured network endpoint and doesn't know or care where connections are coming from. A process only knows it's own identifier. This poses a problem when trying to talk to a process through a named loadbalancer. Standar
d TLS validation will fail if a client talks through a named loadbancer to a process that presents a certificate with a DN of the process's identifier and without a SAN of the loadbalancer identifier. Possible solutions I can think of are: 1. Have the CA add SANs to the process's CSR for the loadbalancer identifiers the process backs. This is out of ACME spec, but we aren't going to get a ticket :) 2. Have the process fetch which loadbalancer identifiers it will back before building and sending a CSR to ACME. This has some performance implications. We like processes to start rapidly. This has some architecture implications. The loose coupling is quite handy. 3. Terminate/re-establish TLS in the loadbalancers. This has some performance and security implications. 4. Relax TLS and have processes consult a central, trusted map of loadbalancer identifiers to process identifiers to validate server authentication. This solves the problem and has some other nice properties but is (fairly 
radically) out of TLS spec. One of these solutions is less bad than the others and we can figure out how to workaround if we decide ACME satisfies this use case. On Thu, Aug 17, 2017 at 11:26 AM, Salz, Rich <[email-masked]> wrote: > There’s compliant and there’s compliant. J  The IETF has no protocol police, > and you will not get a ticket for issuing a cert “wrongly.”  Will anyone > complain if you change the CSR to say “S.A.” or “Pty” instead of “Inc” or > “Ltd”?  Of course not. > > > > Will people be upset if you add other random SAN fields they didn’t want or > ask for?  Yes.  This is the internet, someone is bound to be upset. J > > > > It’s great to see commercial interest.  If there are real roadblocks we can > issue errata, updates, new challenges, or whatever it takes. > > > >                 /r$ > > > > _______________________________________________ Acme mailing list [email-masked] https://www.ietf.org/mailman/listinfo/acme