Re: [Acme] Acme Digest, Vol 13, Issue 3

[Ron Aitchison]

This a follow-on email with more specific comments on 
draft-ietf-acme-acme-01.txt:
Couple of terminology points first. I note the use of the term TLS 
certificates throughout the draft. TLS also supports DTCP certificates 
(RFC 7562) is this format supported? If not, I suggest use of X.509 
certificate throughout or invent another term and define it under 
Terminology. I note the use of the terms domain (user domain apex, zone 
may be more appropriate but the term is not widely used outside the DNS 
world) and domain name (a name under the user domain apex), sometimes 
used synonymously, sometimes not. As I read the spec both are 
appropriate in certain contexts. Both terms should be defined precisely 
under Terminology and used consistently.

Section 2.
It was not until I read para 2 of Terminology that the Deployment Model 
became clearer. Certainly this clarifies that the ACME server is CA 
operated and (one assumes) communication between them uses JSON over 
HTTPS - but this is surely part of the deployment model and should be in 
this section. Further, it is still not clear who 
could/would/should/might provision the client: a CA independent third 
party, an RA, a licensed agent of a CA or RA, a CA - all of the above? 
Certainly bullets 2 and 3 of the subsequent Operator Experience are 
client functions that lie outside the scope of the draft and would 
absolutely not be present if a CA provides a ACME client as a customer 
service. (these bullet points could be added as a note the illustrate 
the kinds of functionality that could be provided by an ACME client if 
required). Depending on who offers the ACME client there may be payment 
models involved which, while being outside the scope of the draft, may 
be a deployment limiting factor. In spite of the general discussion 
about DV vs OV and EV certificates it was still not clear what type of 
cert this draft was addressing (only kinda clarified in the last para of 
section 4 as a DV with necessary limitations). Surely it should be made 
explicit in section 2.

Section 4.
Each distinct step should have a subsection reference e.g. 4.1 
Registration, da da etc. (makes commenting easier and forces logical 
step separation) The sentence beginning 'The "add a domain" function...' 
is completely out of place and indeed as far as I can tell the term 
'"add a domain" function' is never used again in the entire draft. I 
assume it references the section immediately following registration, so 
this could be 4.2 Add a Domain (?? see my previous email also for other 
implications), then 4.3 Certificate Issue. 4.4 Revokation Procedures or 
whatever.


Regards

--
Ron Aitchison  www.zytrax.com
ZYTRAX r...@zytrax.com

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

Re: [Acme] Acme Digest, Vol 13, Issue 3

[Ron Aitchison]

I have just joined this mailing list, read the group charter, the 
messages over the last week or so (including the meeting report) and the 
WG draft-ietf-acme-acme-01.txt. I have not read the archives since I 
assume from the draft date that it reflects current thinking. My 
comments at this stage are almost all related to the document scope 
since the methodology (and therefore the required message sets, 
challenges etc.) should flow from the intended scope not the other way 
around. Let me start from the position that I would like to see this 
initiative succeed for a lot of different reasons. All my comments must 
be read in that context.
Section 2 Para 1. This is offered as guiding use case which may have 
placed unnecessary restrictions, in my opinion, on the ACME scope. I 
further think that by staying too close to the current CA model an 
opportunity may been missed to simplify the client/server interactions. 
As I read the draft it addresses two user case scenarios:
Case 1. Where the registered ACME client user wishes to add a domain 
(user domain apex for want of a better term at this stage, zone may be 
more appropriate but is not a widely used term outside the DNS world) 
that they own and control. As a by-product of the domain registration 
process this user must have control of their DNS and therefore the DNS 
TXT RR based signed challenge is the only appropriate one as proof of 
domain ownership. Once this challenge has been verified then subsequent 
certificate requests for any domain name under the domain (user domain 
apex) can be granted as long as a) the signed DNS TXT RR is still in 
place b) the users registration has not been revoked by the CA of 
record. Whether the domain name requested is a web service, mail 
service, ldap service, ftp service or even exists is irrelevant. 
Perhaps, once initial verification is complete the TXT RR could be 
replaced with a domain cert in a TLSA RR but this may unduly complicate 
things and I'm not sure it add to security.
Case 2. Where a registered user wishes to generate/manipulate 
certificates for an operational entity where they do not control the 
domain (the user domain apex) but do control the domain name (the name 
under the user domain apex). This registered user may have operation 
control covering multiple domains names (names under multiple user 
domain apices). There are two sub cases here one where the entity has a 
web presence (e.g. virtual web hosting) and others where it does not 
e.g. multi-host mail services or LDAP services etc.. The latter case is 
not currently supported by the draft, the former can only be handled by 
a signed file at URL type challenge (a DNS challenge is not appropriate 
in this case) and is fully handled by the current draft.
Case 1 means that for a sub-class of users (domain owners) all the 
restrictions referenced in the final para of section 4 of the draft are 
removed. Case 2 stays the same as the current draft, except that non-web 
services operators could have the various domain owners register as Case 
1 and send the domain name certificate and its private key to them 
(perhaps using ACME client functionality outside the scope of the draft).
Whatever user case scenarios are agreed, in whatever form, should appear 
in the document.

A second email follows with some detail comments.
--
Ron Aitchison  www.zytrax.com
ZYTRAX r...@zytrax.com

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