Proposal for dns-02


#1
  1. Take the Publickey of the Account and build the SHA-1 of if. (Mable later SHA-256)
  2. Create an Textrecord sha1-dns-02-acme-challenge for domain with the Base64 content of the hash.
    sha1-dns-02-acme-challenge.example.com. 300 IN TXT “gfj9Xq…Rg85nM”

Improvements above dns-01:
a) It allow Wildcard entries so that the user does not need to change the dns for each fqdn.
b) As long as the account key is the same the approval is the same.

This is analog to placing an html page containing an authorization token into the webserver like google use is for webmaster info access. We do not need the random factor to prevent replay. As long as we bind the authorization to the account key.


#2

There’s no reason to use SHA1 now and SHA256 later. Better use SHA256 now.


#3

why not just take SHA512, that’s even more secure.


#4

IIRC they’re in the same family and if one is broken the other is probably, too. But the challenge is currently missing a random token which is a MUST by the CA/B Forum rules.


#5

hm, but the question is why? I mean account binding seems to be enough for me. and what happens at renewal? is it okay when it is checked whether the record is still in place or is a new one needed?


#6

@kelunik There is the random mention ?
I did not found it under https://cabforum.org/about-the-baseline-requirements/ or https://cabforum.org/documents/#Baseline-Requirements.

Even if required the token could be signed with the authorized key from the record. and send back via API call


#7

Can’t find it either, just read it here: https://mailarchive.ietf.org/arch/msg/acme/YNye8Y264O63yh7R4FnxUb9pUOQ

@jsha Where’s that requirement listed?


#8

With the system i described above the challenge that fulfill the random request is:

The certificate requester must prove that he own the private key for the public key that he anounced in the DNS record.
To prove this the CA send an random 128bit token to the requester that is send back as jwk signed witht the matching private key for the DNS record containing the token from the challenge.


#9

But things like this should go to the mailing list at acme@ietf.org.


#10

Lets see last time the post to the mailing list did not show any response.
But i give the list an second chance.


#11

It’s rather hard to find: It’s part of the in-progress guidelines being discussed by the Domain Validation Working Group of the CA/B Forum. I’d recommend looking up the CA/B Forum Public mailing list and looking through the archives for “domain validation” and “ballot”.


#12

but the CABF seriously needs help. who in their right mind would lock out private people of HTTPS .onion (I think most of the prople using TOR are oribably normal people) certs?
ya know tthose things have EV as requirements and individuals cannot get EV certs, so well…

and it’s similar tohis random thing. the question is how is this thing handled exactly? is it re-useable like in “make it once and get your certs as long as it stays active” or would you actually have to make a new one everytime?


#13

@jsha I have to say that it is very thin for an CA to say that their policy requirements are based on one mail in an mail list.
And not based on the official documents that stand behind the mailing list. I checked

https://wiki.mozilla.org/CA:Recommended_Practices

  • Verifying Domain Name Ownership
  • Baseline Requirements
  • 3.2.2.4 Authorization by Domain Name Registrant

And no place mention the random 128bit token. Instead all places mention that it is legal to validate based on public announced contact. Like mail in whois and i think an public announced public key would be equivalent.


#14

In my eyes there are an order of trust.
a) Without DNS-SEC

  1. Data from Whois Record
  2. DNS-Entry
  3. Port < 1024 of A or AAAA Record
    b) With DNS-SEC
  4. Whois Record (If DNS-SEC secured) , DNS-Entry
  5. Port < 1024 of A or AAAA Record
    So requesting approval via mail based on whois is ok according to CAB.
    Data published on FQDN on demand of CA is ok.
    So signed request based on DNS should be ok to.
    Maybe someone could ask this in the cab forum.

#15

This is the challenge I’d like to see implemented, dns-01 ist just not usable for us.


#16

and HTTP-01 gets painful when a lot of SANs are involved.


#17

TBH I’m a bit surprised this wasn’t implemented for dns-01, just seems to much easier and useful for everyone without the limitations of the current implementation (separate dns entries for each domain, dns provider with api for automation, auth for dns api on every server to be able to use real automation (this especially is a showstopper))


#18

also it should propagate to subdomains.


#19

I also think that this is the perfect solution for many potential issues with the http-01 challenge…

As I assume that Let’s Encrypt is a known player at the cabforum it would probably be best if
they could introduce this request in this committee…


#20

Per @kelunik’s note from a couple of years ago (!), this would be better directed to the ACME working group at IETF. This forum isn’t actively used for protocol standardization discussions.