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

[Ron Aitchison <[e-mail]>]

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                             [e-mail]