Writeing a acme extension for onion address

This will be almost scribble like, so it may hard to read.
add onion identifier -
chllenges ::
http/tls-alpn (both over tor network)
dns challenge can’t be used
new csr based challenge (LE want to use it because it doesn’t need tor daemon running on VA), but are we send json payload to VA backend from WFE.
from pebble wte updateChallenge function.
// In strict mode we reject any challenge POST with a body other than {}.
// This matches RFC 8555 Section 7.5.1 and the ACME challenge types that
// Pebble has implemented. Per ACME errata 5729[0] it may not be true for
// extensions to ACME that add new challenge types.
Boulder will need a new column for this csr data saved at challange object: will it able to work on production without massive downtime?

signing would be same as before (except the need to set SNI as dns, not maked up onion identifier obviously

Is there any reason to store the CSR?

We could just send the CSR directly to the RA, that will check with the VA that it contains the signed keyAuthz, update the challenge status, and then just discard the CSR.

Are you working on a Pebble version of this?

Yeap, and pebble don’t have ra so I forgot about it.

hit a wall: tor onionv3 address is a hash of ed25519 key, while golang x509 package doesn’t support csr signed with ed25519

Are you sure?


I realize that the example is for signing, but since it calls x509.ParseCertificateRequest on the DER-form of the CSR, we know it can handle reading and validating it also.

$ openssl req -in a.pem -noout -text
Certificate Request:
        Version: 1 (0x0)
        Subject: CN = foobar
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
        Requested Extensions:
            X509v3 Subject Alternative Name:
    Signature Algorithm: ED25519
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.