Re: [Acme] ACME subdomains

2020-09-02 Thread 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] ACME subdomains

2020-09-02 Thread Owen Friel (ofriel) 
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. I also replaced all the random values in the 
tokens and URIs so that duplicate random values (i.e. duplicate URIs or tokens) 
are not used within an option example, as this could have caused confusion too.



Both option 1. Your suggestion. I think we need new challenges types for the 
parent for each of the supported challenge types e.g. http-parent-01 and 
dns-parent-01.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://acmeserver.com/acme/chall/prV_B7yEyA4";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://acmeserver.com/acme/chall/NvGuSDAgel";,
 "type": "http-parent-01",
 "parent-identifier":"example.org",
 "status": "pending",
 "token": "4ri0VOyfYe",
   },
   {
 "url": "https://acmeserver.com/acme/chall/Nd0E0RmHYe";,
 "type": "dns-parent-01",
 "parent-identifier":"example.org",
 "status": "pending",
 "token": "S9nQjcWrSI",
   }
 ],
   }
~~~

Both option 2. The challenge for the parent domain is of a new type that 
contains a set of nested challenges of existing types.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://acmeserver.com/acme/chall/9eDK8EeM8R";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://acmeserver.com/acme/chall/PAniVnsZcis";,
 "type": related-identifier",
 "status": "pending",
  "related-identifier":"example.org",
  "challenges":[
   {
   "url": "https://acmeserver.com/acme/chall/NYV9zTtOBT";,
   "type": "http-01",
   "status": "pending",
   "token": "q1XCKRP2DX",
   },
   {
   "url": "https://acmeserver.com/acme/chall/25OE1ZoicK";,
   "type": "dns-01",
   "status": "pending",
   "token": "bLfEMqhoVp",
 },
 ]
   }
 ]
   }
~~~

Both option 3. A new challenge type that points to another new authorization 
object. This can be standard authorization obejct that includes http-01, dns-01 
challenges for the parent. It may make sense to also include the parent domain 
in this new challenge, even though it will be in the 2nd authorization.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://acmeserver.com/acme/chall/RW9UppaYs0";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://acmeserver.com/acme/chall/PAniVnsZcis";,
 "type": related-identifier",
 "related-identifier":"example.org",
 "related-authorization":" https://example.com/acme/authz/r4HqLzrSrpI";
 "status": "pending"
   }
 ],
   }
~~~

And for option 3, the related-authorization points to the authorization object 
for the parent domain e.g. POST-as-GET to the “related-authorization” 
https://example.com/acme/authz/r4HqLzrSrpI :

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": " example.org"
 },

 "challenges": [
   {
 "url": "https://acmeserver.com/acme/chall/prV_B7yEyA4";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://acmeserver.com/acme/chall/Nd0E0RmHYe";,
 "type": "dns-01",
 "status": "pending",
 "token": "S9nQjcWrSI",
   }
 ],
   }
~~~





Of all the above, option 3 arguably keeps the client implementation and logic 
as close to base ACME as possible.


From: Ryan Sleevi 
Sent: 02 September 2020 23:08
To: Owen Friel (ofriel) 
Cc: Felipe Gasper ; Jacob Hoffman-Andrews 
; acme@ietf.org
Subject: 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

Re: [Acme] ACME subdomains

2020-09-02 Thread Ryan Sleevi 
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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Review of draft-friel-acme-subdomains-02

2020-09-02 Thread Owen Friel (ofriel) 
Thanks Russ. I've addressed all these in github at: 
https://github.com/upros/acme-subdomains/blob/master/draft-friel-acme-subdomains.md.
 I have not pushed out draft-03 yet, lets see what Jacob and Felipe have to say 
on the related thread about challenge options, and I will incorporate then.


-Original Message-
From: Acme  On Behalf Of Russ Housley
Sent: 05 August 2020 06:44
To: IETF ACME 
Subject: [Acme] Review of draft-friel-acme-subdomains-02

Document: draft-friel-acme-subdomains-02
Reviewer: Russ Housley
Date: 2020-08-04

Major Concern:

The TODO markers regarding wildcard domain names, the 200 response code, and 
the security considerations should be filled in with strawman text before this 
I-D is adopted by the ACME WG.


Minor Concerns:

General: s/certificate authority/certification authority/ (many)

Abstract: s/certificate authority policy/certificate policy/

Introduction: s/X.509 (PKIX)/X.509v3 (PKIX) [RFC5280]/

Terminology: Correct CA, please.  See above.

Terminology: Please add a definition of subdomain.


Nits:

Section 3: says:

   3.  client sends POST-as-GET requests to retrieve the
   "authorizations", with the downloaded "authorization" object(s)
   containing the "identifier" that the client must prove control of

s/client must prove control of/client must prove that they control/

There is something wrong with the table formatting in Section 6.2.

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

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

Re: [Acme] ACME subdomains

2020-09-02 Thread Owen Friel (ofriel) 
Thanks Felipe, Jacob, we had not really considered the use case where the 
server would offer challenges for both 
foo.bar.example.org and 
example.org and the client could choose which to fulfil.

We assumed (maybe naively) that the server would only offer the Base Domain 
Name challenge (using the CA/B Baseline defn. of the Base Domain Name), and 
also wanted to minimise changes to the protocol and JSON objects.

For flexibility, I guess if the client wants 
foo.bar.example.org the protocol should also allow 
server choice of offering challenges for (1) both 
foo.bar.example.org and  
example.com (2) only the requested identifier 
foo.bar.example.com or (3) only the parent domain 
example.com.

I was talking through this with Richard, and there are a few choices for how to 
enhance the authorizations object to allow this. If the server only wants to 
offer one challenge, then that’s straight forward. It includes whatever 
identifier it picks (subdomain or parent) in the authorization object. If it 
wants to include both, here are a few options:

Both option 1. Your suggestion. I think we need new challenges types for the 
parent for each of the supported challenge types e.g. http-parent-01 and 
dns-parent-01.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://example.com/acme/chall/prV_B7yEyA4";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://example.com/acme/chall/prV_B7yEyA4";,
 "type": "http-parent-01",
 "parent-identifier":"example.org",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://example.com/acme/chall/prV_B7yEyA4";,
 "type": "dns-parent-01",
 "parent-identifier":"example.org",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   }
 ],
   }
~~~

Both option 2. The challenge for the parent domain is of a new type that 
contains a set of nested challenges of existing types.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://example.com/acme/chall/prV_B7yEyA4";,
 "type": "http-01",
 "status": "pending",
 "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
 "url": "https://example.com/acme/chall/PAniVnsZcis";,
 "type": related-identifier",
 "status": "pending",
  "related-identifier":"example.org",
  "challenges":[
   {
   "url": "https://example.com/acme/chall/prV_B7yEyA4";,
   "type": "http-01",
   "status": "pending",
   "token": "DGyRejmCefe7v4NfDGDKfA",
   },
   {
   "url": "https://example.com/acme/chall/prV_B7yEyA4";,
   "type": "dns-01",
   "status": "pending",
   "token": "DGyRejmCefe7v4NfDGDKfA",
 },
 ]
   }
 ]
   }
~~~

Both option 3. A new challenge type that points to another new authorization 
object. This can be standard authorization obejct that includes http-01, dns-01 
challenges for the parent. It may make sense to also include the parent domain 
in this new challenge, even though it will be in the 2nd authorization.

~~~
   {
 "status": "pending",
 "expires": "2015-03-01T14:09:07.99Z",

 "identifier": {
   "type": "dns",
   "value": "foo.bar.example.org"
 },

 "challenges": [
   {
 "url": "https://example.com/acme/chall/prV_B7yEyA4";,
 "type": "http-01",
 "status": "valid",
 "token": "DGyRejmCefe7v4NfDGDKfA",
 "validated": "2014-12-01T12:05:58.16Z"
   },
   {
 "url": "https://example.com/acme/chall/PAniVnsZcis";,
 "type": related-identifier",
 "related-identifier":"example.org",
 "related-authorization":"uri"
 "status": "pending"
   }
 ],
   }
~~~

Of all the above, option 3 arguably keeps the client implementation and logic 
as close to base ACME as possible.



From: Acme  On Behalf Of Jacob Hoffman-Andrews
Sent: 05 August 2020 07:53
To: Felipe Gasper 
Cc: acme@ietf.org
Subject: Re: [Acme] ACME subdomains

I haven't followed the "ACME for subdomains" conversation closely, but the base 
semantics of ACME are designed such that they can express "all of" semantics 
AND "one of" semantics. For a given Order, a client has to fulfil all the 
Authorizations; for a given Authorization, a client h