[Acme] Two pull requests from me waiting.

[Sebastian Robin Nielsen <[e-mail]>]

https://github.com/ietf-wg-acme/draft-ietf-acme-dns-persist/pulls

First one:

This is to change the language in the document. issuer-domain-name is a
opaque value from client's point of view.

That means, the client does not make a request, verify or otherwise make any
connection to the value in the field "issuer-domain-name".

 

it could be a random hash like "adf6a97f6a95f85fda5f9d59a98fda59fa6". It
would work perfectly still.

 

That means, protecting the "issuer-domain-name" does not give any security
advantage from the clients point of view.

A compromise of "issuer-domain-name" would also not give any security
degradation.

The "issuer-domain-name" may even be a domain the CA no longer owns (for
example a legacy domain they no longer renew, but still keep in their CPS to
keep old dns-persist-01 records working indefinitely).

 

Tthe above pull request changes it to "ACME Directory URL" - which is the
sensitive resource the CA owns in the ACME world.

 

Max Hearnden suggested that a ACME Directory may emit cross-domain URLs in
its directory - for example a newAccount URL that does not reside at the
same domain as the Directory.

This newAccount URL could then be independently compromised.

 

However, in my opinion, its the CAs responsibility - if they host parts of
their ACME infrastructure on different domains - to at least perform some
basic health checking of their sub-resources and shut down the Directory URL
if any sub-resource is found to be comrpomised. Thus, the important thing to
keep secure (with DNSSEC and other things) is the ACME Directory URL. Thats
a URL that is the "root of trust" for the ACME client, and failing to secure
that would mean complete takeover of the ACME client.

 

 

Second one:

Its a variation of my "pubkey:" idea, but instead of a SPKI hash of the
pubkey, I chose a JWK thumbprint. In this way, functionality to verify it
already exist server-side and functionality to generate it, exist
client-side (in the same functions which generate a JWK thumbprint for use
in HTTP-01 challenges).

To avoid a CA going foul of the CAB forum rules, I chose to make a rule that
a CA must invalidate any authorizations that have been validated using a
pubkey: record, IF a keyChange is made on the account, so if said key would
be moved to a second account, a pubkey: record doesn't accidentially
validate 2 account to issue certificates simultaniously for the same record
(which is prohibited by the CAB forum since each dns-persist-01 record may
only link to ONE account).

Client functionality that a client must reject a pubkey: URL emitted from a
ACME server (as discussed) - I choose to omit, since a pubkey: record is
SUPPOSED to be generated completely offline.

Clients implementing support for pubkey: records will thus already do the
calculations offline.

 

 

 

Hope you like the pull requests, and it would be nice if someone in the ACME
group could take a look on them and see if there is any problems.

the first one should not really be a problem to merge.

 

 

Best regards, Sebastian Nielsen