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

[Manger, James]

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 hyphens are present. It will only take 2 tries on average ; - )

--
James Manger

-Original Message-
From: Acme  On Behalf Of Michael Richardson
Sent: Thursday, 26 November 2020 9:37 AM
To: Mark Tomlin ; acme@ietf.org
Subject: Re: [Acme] Remove the hyphen from the acceptable character set for 
_acme-challenge TXT records.

[External Email] This email was sent from outside the organisation – be 
cautious, particularly with links and attachments.

Mark Tomlin  wrote:
> I have a bit of a feature request for you all. It's actually to remove
> the hyphen from the TXT records to make it easier to copy and paste into a
> DNS server record. Here's my scenario. I ran the following command on my
> server (Ubuntu 20.04) that as you can see has cerbot on it and a large
> number of domains to cover.

It is annoying, and I've run into the same problem as well.
The challenge is a base64url encoded (RFC4648) nonce.  It is preferred by web 
programmers because it does not use + or /, which are special in URLs.
The base64 alphabet doesn't use -, but does use + and /, but which would copy 
and paste better.

The format and contents of the nonce are not mandated by RFC8555, so 
LetsEncrypt change this in many different ways.
It would be a unilateral decision on the ACME server only.

I actually think that BASE32 encoding would probably better: you could probably 
write a pull-request to the letencrypt code base to do this.
I don't know how they would feel about this, but it would be worth learning.

> Please deploy a DNS TXT record under the name
> _acme-challenge.mimocad.io with the following value:

> 6-K6v7VjtVpGhJk4d6Zx8qxsg6JFUZbGnnr-bDpKpSc

What annoyed me here when renewing a system with 10 different aliases is that I 
don't know when I've gotten to the last one.  I should be shown all
10 at the same time, so that I can put them all in place, and then reload the 
zone.  Instead, I count (badly), reload the zone too late or too soon...
Even better if they add the entire DNS presentation lines so that I could 
copy&paste the entire set.
But, again, this is a client code issue, and not a protocol issue.

I have since bit the bullet and gotten nsupdate to do the right thing, and it 
now autorenews on it's own, as Ghod intended.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Manger, James]

>> 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 RFC8555 which consistently uses example.com 
> as the ACME server base domain and example.org as the client certificate 
> identifier base domain, but yes Ryan I did find this a source of confusion 
> too when reading ACME.
>
> For clarity, I replaced all example.com with acmeserver.com, and left all the 
> client identifiers as example.org.

https://tools.ietf.org/html/draft-friel-acme-subdomains-02 and 
https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md
 don’t seem to follow RFC 8555’s convention at all, which could be the 
confusion.

Trampling on another arbitrary domain name – acmeserver.com – is worse; unless 
you can think of an additional domain name to reserve with an update to RFC 
6761 Special-Use Domain Names.

Stick with the RFC 8555 ACME convention. Maybe tweak it to be, say, 
site.example.org and ca.example.com if that is clearer.
Plus a sentence stating the convention used would help.

--
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

[Manger, James]

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 for phone numbers. The CA trusts another authority to 
vouch for that namespace.

draft-yusef-acme-3rd-party-device-attestation is designed to issue certs for a 
domain name (as per normal Acme). The cert will be for a specific device whose 
serial number (eg MAC address) the domain-owner knows. The device manufacturer 
can vouch for device keys associated with that serial number.
Curiously, the protocol flow in draft-yusef-acme-3rd-party-device-attestation 
doesn’t seem to involve the device at all – only the domain-owner (client), 
manufacturer, and CA. But surely the device needs to provide the CSR?

It sounds like the client (domain-owner) should be able to confirm the correct 
device is involved (by talking to the device and manufacturer) before sending a 
normal ACME request. That way the ACME CA doesn’t need to know anything about 
the device attestation.

--
James Manger
+61 4 1754 1870
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Manger, James]

>> 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] Implicit vs. explicit keys (was Re: Unparallelizing roll-over)

[Manger, James]

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 crypto failures, and you also get protection
> against any issues related to relying on public keys alone.
This doesn't achieve the goal of making sure that ACME servers are
validating based on account data they already have, rather than
validating based on a key provided in the request.

>What do you mean by "validating"?
>There are two types of validation to do here:
>1. Validating that the signature on the message is good
>2. Validating that the key belongs to a the right account for this request
>
>You can do the first of these without any knowledge of the account status of a 
>key.  Doesn't require any database lookup if you provide the key in >the 
>header.  There's no harm to doing this validation without knowing whether the 
>key is good, and there's benefit in rejecting bad signatures quickly.


The point is that if you: take an account id from message → lookup account → 
use public key from account to verify signature; then it is hard to see how an 
implementer can get #2 wrong. But you have to do the DB lookup before the 
crypto verification.

Richard’s alternative approach takes a public key from a message and tries to 
match that to a public key in an account. That should work, but it is less 
clear that there are not easy implementer traps. Matching keys is less obvious. 
How to do it isn’t specified. You could calculate JWK Thumbprints [RFC7638] and 
match those strings. Thumbprints ignore optional fields; hopefully that’s okay. 
Thumbprints can’t be relied on to be unique (eg shouldn’t be used in a 
blacklist); hopefully Acme implementations only need them to be unambiguous, 
not unique, for security. I hope an implementation doesn’t assume a “kid” 
(key-id) provided by a client is a thumbprint.

Having both (public key and account-id) in a message raises the risk that a 
sloppy implementation verifies with the former, does the lookup with the 
latter, then fails to properly link the two.

--
James Manger
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Manger, James]

>> 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 encouraging keys that are tied to a single piece of 
hardware, without adding extra coordination requirements. It doesn't feel too 
onerous for CAs to implement.

> There's a fairly good solution available with the current protocol, which is 
> to serve a (long lived) redirect from /.well-known/acme-challenge/ on all of 
> the servers to a different URL that is always answered by the machine you run 
> an ACME client on.

This redirect-based workaround feels far from ideal. It assumes 1 server does 
all the ACME bits, which discourages per-hardware keys. It requires more 
coordination between servers (1 is different; others need its IP; need some 
extra mechanism to distribute key+cert once issued). Section 9.2 "Integrity of 
Authorizations" [draft-ietf-acme-acme-01] warns that an ACME CA following 
redirects can be risky as a web site might have a catch-all redirect rule. Even 
worse, the spec hints that CAs might not (or must not?) follow redirects at all 
due to the risk when it says: "suppose an ACME server follows HTTP redirects in 
Simple HTTP validation…".

App-level redirects might be necessary to cope with some load balancing 
schemes, but specifying that an ACME server must prefer the requester's IP or a 
specified IP from the A/ records DNS returns would still be useful.

--
James Manger


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Pendleton
Sent: Friday, 4 December 2015 8:53 PM

Personally, I think that's a more appropriate approach.

Even if a protocol change was made that allowed an ACME client to pin the 
challenge to a certain IP address, the requested IP may not always be returned 
by the authoritative DNS server. Any type of latency, geo or weighted routing 
algorithm could potentially get in the way.


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Peter Eckersley
Sent: Friday, 4 December 2015 7:46 PM
To: Jonas Wielicki 
Cc: acme@ietf.org
Subject: Re: [Acme] Support for domains with redundant but not immediately 
synchronized servers

There's a fairly good solution available with the current protocol, which is to 
serve a (long lived) redirect from /.well-known/acme-challenge/ on all of the 
servers to a different URL that is always answered by the machine you run an 
ACME client on.

Are there any cases where that is sufficiently unworkable to warrant a protocol 
change?


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Jacob Hoffman-Andrews
Sent: Friday, 4 December 2015 10:27 AM

I think there are a few possible approaches to domain validation for hostnames 
that resolve to multiple IP addresses:

1) It is sufficient to deploy a challenge response on any IP address.
2) The challenge response must be deployed on all IP addresses.
3) The server tries one deterministic IP address and succeeds or fails based on 
whether the challenge is deployed there.

Let's Encrypt currently does (3), but it's probably the worst of both worlds 
and we should fix it.

Arguably (2) is the most secure, since a single-machine compromise isn't 
sufficient to issue a certificate.

And (1) is the easiest and most user-friendly. I think it's also similar to 
existing practice in the wild.

Jonas, security-wise your proposal is equivalent to (1). Rather than adding a 
preferred IP address to the spec, why not specif that ACME servers SHOULD 
implement (1)? Alternately we could state in the spec that the choice of IP is 
a policy choice of the CA, and lay out the two most reasonable options (1 and 
2).

On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi list,
> 
> I have asked this in the IRC and was pointed to this mailing list. I 
> tried to get a certificate for klausurschokola.de via Let’s Encrypt 
> during the currently running limited beta (we have the domain 
> whitelisted). The name has the following address records:
> 
> 1800  IN  A   176.9.101.187
> 1800  IN  A   217.115.12.71
> 
> (in addition, there is one  record for each of the machines 
> addressed by the A records)
> 
> As you can see, two different machines are addressed. Those are 
> physically separated machines with different main administrators.
> Both are pulling their web content from the same source, but it is not 
> supposed to be dynamic, so there is no "fast" (order of seconds) way 
> to mirror the content.
> 
> Our wish would be to be able to use different private keys and 
> certificates for both hosts, and renew these independently from the 
> other host. We thought that this would be possible using Let’s Encrypt.
> 
> The problem is that curre

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

[Manger, James]

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 
it is a useful comparison. It avoids BASE64 on the content; can adds 
signatures, digests, and other metadata; can transport content and metadata as 
a regular blob (*.jar file); can sign complete code distributions.

--
James Manger

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, 29 January 2015 5:15 AM
To: JSON WG; acme@ietf.org
Subject: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

All,

I would like to propose a spec similar to the JSON log file spec but with the 
purpose of being a container for JSON signatures. The immediate application for 
this might be for ACME or other JSON/Rest Web services.

The elevator pitch for the idea is that a JSON Container would be a JSON 
Metadata blob with the content being described appended to the end in a way 
that makes the separation between content and metadata simple and unambiguous.

 [Separator] 

Advantages:

* Can read the metadata for a file etc with a plain ASCII editor or command 
line tools like cat, more, etc.

* Avoids the need to BASE64 armor the content. So if the content is JSON or 
other ASCII/Unicode text it remains readable in an ASCII/Unicode editor.

* Can add signatures, digests and other metadata items to content in a simple 
regular fashion.

* Content and metadata can be transported as a simple regular blob that is 
fully abstracted from and independent of the transport and without the need for 
canonicalization, XPath or other complications.


Right now, the IETF spec for describing content metadata is based on RFC822. 
And by 'based on', I mean that it is a find the needle in the RFC haystack 
approach. RFC822 style content headers as currently used have several 
disadvantages:

* It is a flat structure, headers can have attributes but trying to add more 
structure is painful.

* It is a historical artifact and content metadata headers are mixed in with 
protocol metadata headers without rhyme or reason.

* It is not JSON and JSON is the spec we are now converging on for this type of 
work. It has all the expressive capabilities of XML and ASM.1 without the 
insanities and stupid. It is as easy to read and write as RFC822 but without 
the limitations.


The spec itself would be simple, its basically draft-ietf-json-text-sequence 
applied to a sequence of one json object and one content blob.

JSON sequence specifies that "A JSON text sequence consists of any number of 
JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator 
(0x1E), and each ending with an ASCII Line Feed character (0x1A)"

This is not ideal for JSON Container. We would prefer that the character which 
is illegal in a JSON document be the one that is the separator between the 
header and content.

All indexes used in the metadata header are calculated from the Record 
Separator byte, the first byte following being byte 0 and so on.


Applying this in a Web Service is very simple, our messages now have the form:

POST / HTTP/1.1
Host: example.com
Content-Type: application/json-container
Content-Length: 666

{ "Signature" : "wefwkjefkljwehfjklwhejkflh" }

<0x1E>{ "Service-Type" : "acme.ws",
   "Transaction-ID" : "2h23roih23oih23orh",
   "Register" : {  ... } }

Where <0x1E> is the record separator character.

The scope of the signature is the content, the whole content, AND NOTHING BUT 
THE CONTENT. Signing headers is a mugs game. Put all the information that 
matters into one blob and sign the blob. Do not present developers with an IKEA 
self-assembly job.

So to prevent protocol substitution attacks, the service identifier and the 
method name wrap the method parameters. In a response, the service identifier, 
response code and transaction ID wrap the response data for the same reason.


Applying the scheme to stored data in a file system is a little different. 
First we have to develop a file extension convention:

file.jpg  becomes file.jpg.jsonc

Many jsonc aware applications will have to share data with applications that 
are not aware. So we need the option of storing metadata in a separate file 
when that is convenient:

The metadata for file.jpg is stored in file.jsonm

In some circumstances we might want to keep the metadata for all the files in a 
directory or tree in one file, a metadata container. This could be 
jsonmc.jsonmc appearing in either the directory a file is in or one of the 
directories above it.

A metadata container would be a JSON container and begin with the usual 
metadata header for that file followed by a JSON sequence of entries per file. 
If this contains a signature, the file entries can just be digests.


Notice