Subject: [Acme] CSR in JSON

From: Anders Rundgren <[email-masked]>
Date: Tue, 16 Dec 2014 11:54:20 +0100

Hi List,
I don't see an absolute necessity continuing with PKCS #10 in a JSON-world:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse

I was able to integrate this (with ease) in EJBCA which is the most widely used Open Source CA.

Anders

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Dec 2014 08:09:07 -0500

Since we are going to be generating X.509 certificates, ASN.1 is
inescapable.

There is a lot of machinery that depends on generating CSRs. So support for
CSRs is essential. Duplicating that functionality in JSON does not seem
like a priority to me.

Now if we were getting rid of the ASN.1 in the certs as well I could see a
point. But that is not a 1.0 thing.

On Tue, Dec 16, 2014 at 5:54 AM, Anders Rundgren <
[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 16 Dec 2014 10:47:40 -0500

> Since we are going to be generating X.509 certificates, ASN.1 is inescapable.

Yes, but not necessarily for anyting other than the certs.

>There is a lot of machinery that depends on generating CSRs. So support for CSRs is essential. Duplicating that functionality in JSON does not seem like a priority to me.

Agree with first sentence, disagree with the second, and have an open mind on the third.

There are many certificate enrollment protcols and data formats already out there.  I don't believe ACME needs to be tied to interop with any of them. After all, if they were as wildly successful as initially expected, there wouldn't be need for yet another.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Dec 2014 11:23:26 -0500

On Tue, Dec 16, 2014 at 10:47 AM, Salz, Rich <[email-masked]> wrote:
> >There is a lot of machinery that depends on generating CSRs. So support
> for CSRs is essential. Duplicating that functionality in JSON does not seem
> like a priority to me.
>
> There are many certificate enrollment protcols and data formats already
> out there.  I don't believe ACME needs to be tied to interop with any of
> them. After all, if they were as wildly successful as initially expected,
> there wouldn't be need for yet another.
>

I'm in sort of the same place as PHB here.  No, we don't necessarily have
to interop with legacy stuff (though it wouldn't hurt).  But we do need a
language to talk about X.509 certs, and CSRs have that.  If we invented
something new, we would have to re-do a bunch of stuff that CSRs already
have.

Of course, if we get extensibility right, we can add a non-CSR option in
the future, if people really think they need it.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Dec 2014 11:24:06 -0500

> there wouldn't be need for yet another.

CSR is widely successful, it is used for pretty much 100% of the public
certs issued.

I am pretty sure there is no actual 'need' for yet another enrollment
protocol. We could almost certainly implement automated enrollment by
extending one of the existing schemes.

The reason it is preferable to move to a new protocol rather than extend
the existing ones is that the only part of the protocol that is strongly
coupled to the PKIX part is CSR and the cost of making any change to the
protocol is almost entirely the cost of QA. So reuse of legacy code isn't
much of an issue.

Most of the code and hardware out there has been written based on a CSR
though.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Dec 2014 11:33:41 -0500

> the future, if people really think they need it.
+1

I want to have as little to do with PKIX as possible. It is a Jenga
specification at this point.

But there is an issue as to what level of abstraction we want ACME to work
at. In the PKIX days it was assumed that the end entity would know what
sort of cert it wants and ask for it. These days, I am not sure.

Lets say we have a site with twenty hosts, some of which process payments,
some do ordinary web stuff, some do email. We are likely to have different
certificates in use for the different purposes. Should we be expected to
configure the end host to know what flavor of cert to install or is that
something that we would want to control centrally?

If the objective is encrypt by default, we are going to end up with a lot
more hosts with certs and a bigger management issue.

I see two approaches possible:

1) The end host specifies the type of cert it needs
2) The end hosts specifies what it wants to do with the cert (i.e. domain
name and protocol) and lets the issuer sort out what to do

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 10:47:45 -0600

> https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample.KeyCreationResponse

As long as there's no ambiguity between the thing to be signed as a CSR
(in whatever encoding, and of whatever form) and other things to be
signed with the same key, a different format than PKCS#10 should be
fine.

Nico
--

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Dec 2014 12:05:01 -0500

> signed with the same key, a different format than PKCS#10 should be

The challenge is making sure there's no ambiguity.  That has pretty much
been worked out with PKCS#10.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 11:12:01 -0600

> been worked out with PKCS#10.

I didn't say it would be easy.  I just stated a constraint on the
alternatives.

I think this is a strong incentive to stick to PKCS#10, though it's not
a foregone conclusion that we must.

Nico
--

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 16 Dec 2014 18:12:29 +0100

On 2014-12-16 18:05, Richard Barnes wrote:
> On Tue, Dec 16, 2014 at 11:47 AM, Nico Williams <[email-masked] <mailto:[email-masked]>> wrote:
>
> The challenge is making sure there's no ambiguity.  That has pretty much been worked out with PKCS#10.

As I understand quite a lot of CAs out there do not use anything but the public key + proof
of a CSR and take the "information" from other sources.  If this applies to ACME I don't know
since I haven't fully digested the process model yet.

FWIW, the the FIDO/Google folks didn't reuse anything but X.509 in their JSON-based U2F stuff.

I found it trivial creating the CSR for SKS/KeyGen2.

Anders

>     [email-masked] <mailto:[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Dec 2014 10:39:53 -0800

> The challenge is making sure there's no ambiguity.  That has pretty much been worked out with PKCS#10.

No, no it hasn't. There is little agreement about which fields in a CSR should appear in the issued cert, which fields in the issued cert that the CA can add, and which fields from the CSR that the CA can change in the cert. Enrollment protocols that use CSRs handwave.

They also don't negotiate the above. If your CSR has two identities and three key usages in it, and you can show proof of possession for both identities at all three usages, but the CA issues a cert with just one of each, should you have to pay for that cert? It would have been nice if the CA could say "Given that CSR, I'm going to issue this cert, do you agree?".

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Dec 2014 13:48:51 -0500

On Tue, Dec 16, 2014 at 1:39 PM, Paul Hoffman <[email-masked]> wrote:

> No, no it hasn't. There is little agreement about which fields in a CSR
> should appear in the issued cert, which fields in the issued cert that the
> CA can add, and which fields from the CSR that the CA can change in the
> cert. Enrollment protocols that use CSRs handwave.
>
> They also don't negotiate the above. If your CSR has two identities and
> three key usages in it, and you can show proof of possession for both
> identities at all three usages, but the CA issues a cert with just one of
> each, should you have to pay for that cert? It would have been nice if the
> CA could say "Given that CSR, I'm going to issue this cert, do you agree?".
>

Fair enough. It seems pretty doubtful that you're ever going to get much
resolution on this negotiation, since ultimately, the CA gets to do what it
wants*.   At least CSR has a clear syntax for talking about these things.

Trying to build a full negotiation protocol seems like an infinite well of
complexity.  In the context of ACME, which is oriented around name
validation, it seems like you could solve it partially.  For example, you
could say that the CA is expected to issue a certificate that contains SANs
for all names from the CSR for which the client has proved possession.  And
probably draw some boxes around subject/issuer/validity with regard to
which ones the CA needs to respect and which the client should assume the
CA will change.

It only really gets fiddly when you start talking about key usages and
other extensions, which are secondary to the authentication function of the
cert, and honestly probably inappropriate for most ACME contexts.  If my
only relationship to you is that you proved possession of example.com, how
should I decide what uses I grant you over that domain?  Seems very
CA-specific.

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Dec 2014 11:12:11 -0800

On Dec 16, 2014, at 10:48 AM, Richard Barnes <[email-masked]> wrote:
> Fair enough. It seems pretty doubtful that you're ever going to get much resolution on this negotiation, since ultimately, the CA gets to do what it wants*.

Disagree. It wants to be paid and it wants your repeat business. If our enrollment protocol doesn't build that, you'll have a bunch of pissed-off customers.

>   At least CSR has a clear syntax for talking about these things.  

No, it really doesn't. In today's CSR, there is no way to say "I would like a cert for this set of things, but I won't accept one that doesn't at least have this set of things". It also does not have a clear way of indicating wildcards in identities: that is done by vague mutual agreement.

I understand the desire not to do the hard work here. It's fine to say "we can live with CSRs", but not fine to say that the do things well that we know they don't.

> Trying to build a full negotiation protocol seems like an infinite well of complexity.

Not to some of us.

>  In the context of ACME, which is oriented around name validation, it seems like you could solve it partially.  For example, you could say that the CA is expected to issue a certificate that contains SANs for all names from the CSR for which the client has proved possession.  

That seems fine as long as a response with no cert can also say "I didn't issue the cert because I could not validate name X which you asked for" and "I didn't issue the cert because you asked for too many names".

> And probably draw some boxes around subject/issuer/validity with regard to which ones the CA needs to respect and which the client should assume the CA will change.

That is good, but not enough. Expectations about key usage turns out to be a huge problem. The location of the subject in the cert (subject vs. subjectAltName) is a huge issue. The format of some of the subjects (FQDN vs. DC for domain names) is a a huge issue.

> It only really gets fiddly when you start talking about key usages and other extensions, which are secondary to the authentication function of the cert, and honestly probably inappropriate for most ACME contexts.  

Fully disagree: they are not "secondary" at all, certainly not for PKIX. 

> If my only relationship to you is that you proved possession of example.com, how should I decide what uses I grant you over that domain?  Seems very CA-specific.

That would be fine in a protocol that was not trying to include payment, but I thought ACME was going to try that (and I think it should). 

Please don't undershoot here. The sooner we start to deal with all the issues CSRs have, and enrollment has, the sooner we can be sure which bits we don't want to do. Assuming from the beginning that we are going to do some under-specified minimum is not a good way to design a protocol that we hope will have a huge impact on the security of the web.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Dec 2014 14:48:50 -0500

Please do not get hung up on payment.  ACME should support certificate
issuance where payment is involved, but that does not have an architectural
impact on the protocol.  Payment is by nature out of band (since there's no
standard for it), and most of the things you're asserting are necessary due
to payment are really just, "the client should be able to know what the CA
is going to issue".  Happy to discuss on those technical grounds.

As for undershooting: We should also not overshoot, by biting off more
complexity than the baseline requires.  The phrase Minimum Viable Product
comes to mind.  Let's start simple, with hooks to get more complex as
needed.

If we really want some sort of negotiation system, I would propose
something like the following:
0. It is assumed that an ACME-enabled CA will issue certificates for names
validated with ACME.
1. Spec defines the semantic of a CSR in the context of ACME:
  * Body of the certificate partly up to CA
  * SAN contains only identifiers authorized with CA
  * Other extensions in CSR must be directly copied to cert
2. If CSR is unacceptable with those rules, CA rejects request
3. CA rejection message can carry a description of what extensions is
willing to issue for this cert body (~= set of identifiers)

That way, you can build very basic CAs that do no negotiation (e.g., allow
whatever CSR requests, allow a specific profile), or the CA can choose to
negotiate.  From a spec perspective, we can start with the basic, "reject
if you don't like it" version, with a basic "i don't like it because"
syntax, then elaborate more on the "what i would like" format later.

--Richard

On Tue, Dec 16, 2014 at 2:12 PM, Paul Hoffman <[email-masked]> wrote:
> wants*.
> Disagree. It wants to be paid and it wants your repeat business. If our
> enrollment protocol doesn't build that, you'll have a bunch of pissed-off
> customers.
>
> No, it really doesn't. In today's CSR, there is no way to say "I would
> like a cert for this set of things, but I won't accept one that doesn't at
> least have this set of things". It also does not have a clear way of
> indicating wildcards in identities: that is done by vague mutual agreement.
>
> I understand the desire not to do the hard work here. It's fine to say "we
> can live with CSRs", but not fine to say that the do things well that we
> know they don't.
>
> >  In the context of ACME, which is oriented around name validation, it
> seems like you could solve it partially.  For example, you could say that
> the CA is expected to issue a certificate that contains SANs for all names
> from the CSR for which the client has proved possession.
>
> That seems fine as long as a response with no cert can also say "I didn't
> issue the cert because I could not validate name X which you asked for" and
> "I didn't issue the cert because you asked for too many names".
>
> > And probably draw some boxes around subject/issuer/validity with regard
> to which ones the CA needs to respect and which the client should assume
> the CA will change.
>
> That is good, but not enough. Expectations about key usage turns out to be
> a huge problem. The location of the subject in the cert (subject vs.
> subjectAltName) is a huge issue. The format of some of the subjects (FQDN
> vs. DC for domain names) is a a huge issue.
>
> cert, and honestly probably inappropriate for most ACME contexts.
>
> > If my only relationship to you is that you proved possession of
> example.com, how should I decide what uses I grant you over that domain?
> Seems very CA-specific.
>
> That would be fine in a protocol that was not trying to include payment,
> but I thought ACME was going to try that (and I think it should).
>
> Please don't undershoot here. The sooner we start to deal with all the
> issues CSRs have, and enrollment has, the sooner we can be sure which bits
> we don't want to do. Assuming from the beginning that we are going to do
> some under-specified minimum is not a good way to design a protocol that we
> hope will have a huge impact on the security of the web.
>
> --Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 14:04:30 -0600

On Tue, Dec 16, 2014 at 11:12:11AM -0800, Paul Hoffman wrote:
> like a cert for this set of things, but I won't accept one that
> doesn't at least have this set of things". It also does not have a
> clear way of indicating wildcards in identities: that is done by vague
> mutual agreement.

Well now, more attributes can be defined to convey such semantics.  It's
not easy to deal with though.

> > Trying to build a full negotiation protocol seems like an infinite

We do need to negotiate a variety of things here.

> >  In the context of ACME, which is oriented around name validation,
> >  it seems like you could solve it partially.  For example, you could
> >  say that the CA is expected to issue a certificate that contains
> >  SANs for all names from the CSR for which the client has proved
> >  possession.  
> 
> That seems fine as long as a response with no cert can also say "I
> didn't issue the cert because I could not validate name X which you
> asked for" and "I didn't issue the cert because you asked for too many
> names".

Yes, nice error codes (and strings) would be... nice.

> > It only really gets fiddly when you start talking about key usages
> > and other extensions, which are secondary to the authentication
> > function of the cert, and honestly probably inappropriate for most
> > ACME contexts.  
> 

Well, some of this could be profiled.  It depends on how general this
protocol needs to be.  Ideally I'd like both, a general protocol that
has reasonable profiles that make implementation easier for common
uses.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 16 Dec 2014 16:14:41 -0500

> enrollment protocol doesn't build that, you'll have a bunch of pissed-off

Well that is not necessarily the wrong outcome :)

Its not really the customer asking most times, it is the software. And that
is not always configured to do what the customer wants.

Being able to encode what the customer wants is important but if they try
sometimes, they get what they need.

The ambiguity in the binding here is the reason I consider it a can of
worms I doth not want to partake of thank you very much. Since the only
reason to change the syntax in phase 1 is to make life easier, I suggest we
leave it for later on.

> indicating wildcards in identities: that is done by vague mutual agreement.

It is really binding the proof of possession to that statement.

> > Trying to build a full negotiation protocol seems like an infinite well

Me neither, we have been over this ground several times. We have working
APIs to use as templates. This is a cleanup and consistency job on
something that already exists.

+1

+1

The key uses you ask for will affect the validation regime in many
instances.

+1

This is JSON so I don't see that doing the job right needs to conflict with
support for a very minimal subset.