Re: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

A signed JAR file meets some of these requirements. Metadata and signatures are in extra files in the ZIP archive: META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA. Content is the other files in the archive. It is not JSON of course, and the signature & certs are packaged in ASN.1, but

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

>> Ideally, it [Let's Encrypt] would use the IP of the >> requester (of course only after it has verified that the IP is in the >> DNS) or allow the requester to specify a preferred IP. This is quite a sensible feature request from Jonas. It supports multiple servers for a domain while encouragi

Re: [Acme] Implicit vs. explicit keys (was Re: Unparallelizing roll-over)

On Sun, Aug 21, 2016 at 8:32 PM, Jacob Hoffman-Andrews mailto:j...@eff.org>> wrote: On 08/21/2016 04:31 PM, Richard Barnes wrote: > How about this as a compromise proposal: Have the JWS header contain > *both* the account URL and the account public key. That way you get > fast rejection based on

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

>> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_" “A” is %x41 (not %x40) -- James Manger ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

I’m confused about what is desired with draft-yusef-acme-3rd-party-device-attestation, but I think it may be quite different from what draft-ietf-acme-authority-token offers. Here’s my guess: draft-ietf-acme-authority-token is designed to issue certs for namespaces other than domain names, eg f

Re: [Acme] ACME subdomains

>> There’s a lot of mixing of example.org and >> example.com here, in ways I’m having trouble making >> sense of. I just wanted to confirm those were typos, since we have recently >> seen some confusion around this space. > I followed the patterns used in

Re: [Acme] Remove the hyphen from the acceptable character set for _acme-challenge TXT records.

An Acme CA may choose the dns-01 challenge token, but what goes in the DNS TXT record is base64url(SHA-256(f(token and account key))). So to avoid hyphens in that result the CA would need to: pick a random token; do the hash & base64url calculations; then repeat with a new random token if any hy