Subject: [Acme] (Re)Design sketch

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Dec 2014 15:31:50 -0500

Comodo has an existing API for certificate issue. It is functional and
works but it isn't ideal because:

1) It isn't JSON and we have customers that demand JSON.

2) It is proprietary which means we have to support plug ins for a large
number of servers which is costly and reduces the utility to larger
installations.

3) It is rather crusty as features have been added gradually over the years
by a variety of authors in a variety of styles.

If we follow the path of only addressing the problems considered important
by one CA that has yet to issue a cert then the result is only going to
address the first two problems. We will end up with another PKIX situation
where the stack is ridiculously complicated BECAUSE of the attempts to
'keep it simple'.

Lowballing requirements results in redundancy and unnecessary complexity.

A better way to address the problem is to architect the system recognizing
that in some circumstances functions will be split across different actors
at subscriber site at the start rather than trying to retrofit this
capability as an afterthought.

It isn't just enterprise firewalls that present corner cases. Managing
credentials on a Web service in the cloud presents similar issues.

*Architectural Constraints:*

* Use the existing CSR format for proof of possession of the private key
for X.509v3 issue.
* Use JSON encoding for all new structures and protocol messages.
* Assume HTTP binding, do not rely on HTTPS for security properties.
* Use SRV and CAA records in DNS to enable automation.

*Actors:*

Subject: The party whose identity is validated
Issuer: The party that issues the certificate
Host: The machine on which the private key and certificate are installed

Recognizing that the Host is not the same as the Subject is important as
without that distinction it becomes impossible to talk about failures or
attacks in a meaningful way.

Note that as far as the protocol interactions are concerned, the Issuer
need not be a CA. A CA is a party that is subject to audit and insurance
and has actual custody of the signing key. It is not actually necessary for
the Subject to have a direct interaction with their CA.

In the ideal situation any party with more than a dozen certs is going to
channel cert requests through a local issuer which forwards them to a CA
(possibly through another intermediary).

*Processes:*

Validation: Determining that a purported subject meets a set of criteria
specified by a certificate policy and in particular has the right to use a
specified identity.

Key Generation: Generating a public/private key pair

Certificate Issue: Signing a Certificate

While each process must occur at least once for a certificate to be issued,
these are three separate processes.

In particular, Validation is an interaction with the certificate subject,
Certificate Issue is to the Host holding the corresponding private key. In
any deployment that has more than one host it is going to be desirable to
amortize a validation process across the multiple hosts.

Today Key Generation and Validation might occur once every three years and
Certificate Issue once a year. One of the reasons I am interested in
automating Cert Management is to change these parameters.

My ideal situation would be to perform Key Generation and Certificate Issue
every 24 hours with overlapping 72 hour validity intervals of which 24
hours is backdated. I certainly don't want to have to perform OV or EV
validation every 24 hours.

I am not averse to performing the DV component of validation every 24 hours
as well but the most appropriate response to single validation failure
after a long stream of successful validations is probably to notify the
system admin rather than force their site offline.

A somewhat more complicated question is how to deal with the problem of
multiple ports, multiple protocols and multiple applications on the same
host.

We should not limit the use of HTTP validation to certificates that will be
used with HTTP.

While the requirements appear complicated, it is actually fairly
straightforward to support them all if we recognize the distinction between
the Subject and the Host. Since there is a relationship between the subject
and the issuer that potentially persists across multiple certificate issue
transactions, this implies some form of account/credential. Since we are
doing PKI we can insist that the credential used to authenticate
transactions be a public key.

For a free cert provider with a zero touch model, the account identifier
might well be simply the public key or a fingerprint thereof. If the
account identifier is never seen by a user, it does not need to be
particularly human readable.

Thoughts? Comments?

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 03 Dec 2014 19:40:47 -0800

See inline

From: Acme [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, December 03, 2014 12:32 PM
To: [email-masked]
Subject: [Acme] (Re)Design sketch

Comodo has an existing API for certificate issue. It is functional and works but it isn't ideal because:

2) It is proprietary which means we have to support plug ins for a large number of servers which is costly and reduces the utility to larger installations.

3) It is rather crusty as features have been added gradually over the years by a variety of authors in a variety of styles.

If we follow the path of only addressing the problems considered important by one CA that has yet to issue a cert then the result is only going to address the first two problems. We will end up with another PKIX situation where the stack is ridiculously complicated BECAUSE of the attempts to 'keep it simple'.

 

A better way to address the problem is to architect the system recognizing that in some circumstances functions will be split across different actors at subscriber site at the start rather than trying to retrofit this capability as an afterthought.

It isn't just enterprise firewalls that present corner cases. Managing credentials on a Web service in the cloud presents similar issues.

Architectural Constraints:

* Use the existing CSR format for proof of possession of the private key for X.509v3 issue.

[TF] Seems reasonable. There is a lot of code on many platforms to do this. 

[TF] Seems reasonable if we are defining something new. 

[TF] Why would we need HTTP? 

[TF] These seem niece to have ret than must haves. You can provide better load bailing and floe via NLB rather than SRV records. 

Actors:

[TF] There is also the DVRA

Recognizing that the Host is not the same as the Subject is important as without that distinction it becomes impossible to talk about failures or attacks in a meaningful way.

Note that as far as the protocol interactions are concerned, the Issuer need not be a CA. A CA is a party that is subject to audit and insurance and has actual custody of the signing key. It is not actually necessary for the Subject to have a direct interaction with their CA.

[TF] You will have to elaborate on the Asser <> CA part because I have always takes the issuer to be by definition a CA. The ACME server is a front end to a CA.

In the ideal situation any party with more than a dozen certs is going to channel cert requests through a local issuer which forwards them to a CA (possibly through another intermediary).

[TF] Do you mean ACME server chaining where one ACME server sends request to another ACE server?

Processes:

Validation: Determining that a purported subject meets a set of criteria specified by a certificate policy and in particular has the right to use a specified identity.

[TF] Determining that a request meets a set criteria as determined by a certificate policy. The policy will establish a LoA for the binding to the subject name.

 

While each process must occur at least once for a certificate to be issued, these are three separate processes. 

In particular, Validation is an interaction with the certificate subject, Certificate Issue is to the Host holding the corresponding private key. In any deployment that has more than one host it is going to be desirable to amortize a validation process across the multiple hosts.

[TF] Validation does not require interaction with the entity making the request. An administrator may have proven control of the domain thereby authorizing the issuance of certificates in the domain namespace and the subject making the request it technically their delegate. 

Today Key Generation and Validation might occur once every three years and Certificate Issue once a year. One of the reasons I am interested in automating Cert Management is to change these parameters.

My ideal situation would be to perform Key Generation and Certificate Issue every 24 hours with overlapping 72 hour validity intervals of which 24 hours is backdated. I certainly don't want to have to perform OV or EV validation every 24 hours.

[TF] Ironic in that this is the model proposed by Barb Fox many moons ago… I get the frequent cert issuance but frequent key generation seems a bit ott given the move to pfs. Reissuing a certificate with the same key is a safer process.

I am not averse to performing the DV component of validation every 24 hours as well but the most appropriate response to single validation failure after a long stream of successful validations is probably to notify the system admin rather than force their site offline.

[TF] We need to look at the threat model for the actual proofs. You could generate false negative due to operational procedures on the part of the domain. 

A somewhat more complicated question is how to deal with the problem of multiple ports, multiple protocols and multiple applications on the same host.

[TF] Why should you care what the cert gets used for?

We should not limit the use of HTTP validation to certificates that will be used with HTTP.

[TF] Don’t you mean HTTPS validation?

While the requirements appear complicated, it is actually fairly straightforward to support them all if we recognize the distinction between the Subject and the Host. Since there is a relationship between the subject and the issuer that potentially persists across multiple certificate issue transactions, this implies some form of account/credential. Since we are doing PKI we can insist that the credential used to authenticate transactions be a public key.

For a free cert provider with a zero touch model, the account identifier might well be simply the public key or a fingerprint thereof. If the account identifier is never seen by a user, it does not need to be particularly human readable.

Thoughts? Comments?