Re: [Acme] [Technical Errata Reported] RFC8555 (5861)

[Owen Friel (ofriel)]

That's fair. The text should probably state something along the lines of

"If the server has an existing authorization for the identifier, depending on 
server policy, the server may return a 200 (OK) response with the existing 
authorization URL in the Location header field and the existing JSON 
authorization object in the body."

It currently reads as not allowing reuse of existing authorization objects, and 
always creating a new pending object and returning 201.



From: Jacob Hoffman-Andrews 
Sent: Wednesday, January 3, 2024 8:29 PM
To: Deb Cooley ; r...@ipv.sx; jdkas...@umich.edu; 
c...@letsencrypt.org; Owen Friel (ofriel) 
Cc: r...@cert.org; ynir.i...@gmail.com; acme@ietf.org; rfc-edi...@rfc-editor.org
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (5861)

This overspecifies things. When someone requests to create a new authorization 
object (or requests to create a new order object that would necessitate 
creation of new authorization objects), it is up to server policy whether to 
reuse an existing authorization or not. For instance a server might have a 
policy of never reusing authorization objects (that is, doing validation from 
scratch every time), or it might have a policy of reusing only pending 
authorization objects, or only ones created in the last N hours or days.

So I think we should not accept this errata as it stands.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Dnsdir last call review of draft-ietf-acme-integrations-15

[Owen Friel (ofriel)]

FYI, draft -16 was published on 13th June that (i) removes the confusing 
terminology and delegates completely to RFC8499 and (ii) addresses John's 2 
outstanding nits.
Thanks,
Owen

-Original Message-
From: Michael Richardson  
Sent: Friday, June 9, 2023 2:58 PM
To: Ted Lemon ; Warren Kumari 
Cc: dns...@ietf.org; acme@ietf.org; draft-ietf-acme-integrations@ietf.org; 
last-c...@ietf.org
Subject: Re: Dnsdir last call review of draft-ietf-acme-integrations-15


WARREN:

Ted Lemon via Datatracker  wrote:
> Frustratingly, the -15 update makes the document worse as a result of
> my initial comments, not better. I think the authors didn't understand
> why I made the comments, and hence are just trying to get rid of the
> text that I commented on rather than fixing it. I actually suggested a
> better way to write the text, in the initial review, which may have
> gotten lost:

Hi, I appreciate your frustation.
You complained gently about text that wasn't ours.  It was copied from RFC8499.
We quoted the definitions to save you a trip to RFC8499 and back.

That's an entire RFC *JUST* for DNS Terminology.  Were you aware of this?
Was WARREN aware when he asked us to look at your nit, aware of that?

If using RFC8499 definitions is wrong in a document that deals a lot about DNS, 
then we really really have a problem.  Especially for a DNS Directorate REVIEW.

Editing the definitions would just lead to confusion as people wondered why we 
changed things.  Abridging things to omit the words you found unhelpful at 
least makes it clear we aren't trying to change things.
My co-author suggested we just rip all our text out.

>> I'm not seriously proposing that you make this change, but if you
>> don't, I think you should delete the sentence about graph theory,
>> because it's just confusingly broad if you don't then actually
>> describe the subset of graph theory you're talking about.

> So, as an example, I did not suggest removing the text about
> fully-qualified domains, which was fine, and is now not fine, in the
> sense that the reader will have no idea why they are being mentioned.

We shortened it to what we thought was essential, but maybe we cut too much.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



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

Re: [Acme] John Scudder's No Objection on draft-ietf-acme-integrations-15: (with COMMENT)

[Owen Friel (ofriel)]

Oops missed those, will get a draft-16 out to address those nits.

-Original Message-
From: John Scudder via Datatracker  
Sent: Thursday, June 8, 2023 5:33 PM
To: The IESG 
Cc: draft-ietf-acme-integrati...@ietf.org; acme-cha...@ietf.org; acme@ietf.org; 
deco...@radium.ncsc.mil; deco...@radium.ncsc.mil
Subject: John Scudder's No Objection on draft-ietf-acme-integrations-15: (with 
COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-acme-integrations-15: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/



--
COMMENT:
--

Thanks for addressing my DISCUSS.

## NITS

"Roots CAs" -> "Root CAs"?

"The EST Registration Authority (RA) is configured with the DNS domain which it
will issue certificates." That should be "for which", right?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments



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

Re: [Acme] Dnsdir last call review of draft-ietf-acme-integrations-15

[Owen Friel (ofriel)]

As Michael says, in -14 and earlier, we were verbatim without change copying 
text from RFC8499.

And the latest -15 abridges the text to remove quoting of the offending text 
from RFC8499.

If neither of the above are acceptable, how about this text:

"The terms Label, Domain Name, Subdomain and FQDN are used throughout this 
document. Please refer to [RFC8499] for a definition of these terms."

-Original Message-
From: Michael Richardson  
Sent: Friday, June 9, 2023 2:58 PM
To: Ted Lemon ; Warren Kumari 
Cc: dns...@ietf.org; acme@ietf.org; draft-ietf-acme-integrations@ietf.org; 
last-c...@ietf.org
Subject: Re: Dnsdir last call review of draft-ietf-acme-integrations-15


WARREN:

Ted Lemon via Datatracker  wrote:
> Frustratingly, the -15 update makes the document worse as a result of
> my initial comments, not better. I think the authors didn't understand
> why I made the comments, and hence are just trying to get rid of the
> text that I commented on rather than fixing it. I actually suggested a
> better way to write the text, in the initial review, which may have
> gotten lost:

Hi, I appreciate your frustation.
You complained gently about text that wasn't ours.  It was copied from RFC8499.
We quoted the definitions to save you a trip to RFC8499 and back.

That's an entire RFC *JUST* for DNS Terminology.  Were you aware of this?
Was WARREN aware when he asked us to look at your nit, aware of that?

If using RFC8499 definitions is wrong in a document that deals a lot about DNS, 
then we really really have a problem.  Especially for a DNS Directorate REVIEW.

Editing the definitions would just lead to confusion as people wondered why we 
changed things.  Abridging things to omit the words you found unhelpful at 
least makes it clear we aren't trying to change things.
My co-author suggested we just rip all our text out.

>> I'm not seriously proposing that you make this change, but if you
>> don't, I think you should delete the sentence about graph theory,
>> because it's just confusingly broad if you don't then actually
>> describe the subset of graph theory you're talking about.

> So, as an example, I did not suggest removing the text about
> fully-qualified domains, which was fine, and is now not fine, in the
> sense that the reader will have no idea why they are being mentioned.

We shortened it to what we thought was essential, but maybe we cut too much.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



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

Re: [Acme] I-D Action: draft-ietf-acme-subdomains-07.txt

[Owen Friel (ofriel)]

The authors feel this update addresses all recent review comments.

All comments were tracked with individual github issues, and corresponding 
commits, if that makes it easier to fine the respective updates:

https://github.com/upros/acme-subdomains/issues?q=is%3Aissue+is%3Aclosed

Owen

-Original Message-
From: Acme  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, March 1, 2023 9:38 PM
To: i-d-annou...@ietf.org
Cc: acme@ietf.org
Subject: [Acme] I-D Action: draft-ietf-acme-subdomains-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Automated Certificate Management 
Environment WG of the IETF.

Title   : Automated Certificate Management Environment (ACME) 
for Subdomains
Authors : Owen Friel
  Richard Barnes
  Tim Hollebeek
  Michael Richardson
  Filename: draft-ietf-acme-subdomains-07.txt
  Pages   : 22
  Date: 2023-03-01

Abstract:
   This document specifies how Automated Certificate Management
   Environment (ACME) can be used by a client to obtain a certificate
   for a subdomain identifier from a certification authority.  This
   document specifies how a client can fulfill a challenge against an
   ancestor domain but may not need to fulfill a challenge against the
   explicit subdomain if certification authority policy allows issuance
   of the subdomain certificate without explicit subdomain ownership
   proof.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-subdomains-07

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-subdomains-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] 答复: Comment on draft-ietf-acme-subdomains-06: How about using wildcard certificates for subdomains?

[Owen Friel (ofriel)]

We will add clarifying text in draft-07 to clarify this.
Thanks,
Owen

From: Acme  On Behalf Of Yanlei(Ray)
Sent: Friday, February 10, 2023 3:47 AM
To: Deb Cooley ; acme@ietf.org
Subject: [Acme] 答复: Comment on draft-ietf-acme-subdomains-06: How about using 
wildcard certificates for subdomains?

> RFC8555 already addresses wildcards, no?
Yes, wildcards are suppoted in RFC8555.
Meanwhile, there are no mentions of wildcards in draft-ietf-acme-subdomains-06.
It seems that wildcard certificates are not suitable for the subdomain scenario.
However, I think the wildcard certificate is another candidate for subdomain 
manegement.
Thus, I am wondering the reason why no wildcard certificates are mentioned in 
the draft.
Are there some reasons for wildcard certificates cannot be used in subdomain 
scenarios?

Regards,

Lei YAN

发件人: Acme mailto:acme-boun...@ietf.org>> 代表 Deb Cooley
发送时间: 2023年2月4日 21:32
收件人: Yanlei(Ray) 
mailto:ray.yanlei=40huawei@dmarc.ietf.org>>;
 acme@ietf.org
抄送: Dorothy E Cooley mailto:deco...@radium.ncsc.mil>>
主题: Re: [Acme] Comment on draft-ietf-acme-subdomains-06: How about using 
wildcard certificates for subdomains?

RFC8555 already addresses wildcards, no?

Deb Cooley
ACME chair
deco...@radium.ncsc.mil


On Tue, Jan 31, 2023 at 7:11 AM Yanlei(Ray) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:

Hi，



I'm new to this group and sorry for the late comment. I just saw this draft and 
have an idea after reading. I'd like to know from you experts whether it's 
reasonable.



The illustration in Section 5 uses Subject Alternative Name (SAN) to list every 
subdomain name in a certificate.

I wonder if this mechanism can be replaced by using a wildcard certificate?

Compared with using the Subject Alternative Name (SAN), a wildcard certificate 
can simplify the complexity and reduce the costs for securing a number of 
subdomains.

As the sub-domain name changes, the client with SAN has to re-apply its 
certificate, but the client with wildcard certificate does not need to change 
its certificate.

I think wildcard certificates have been commonly used in subdomains management.

As illustrated in Section 5:

  ++  +--+ +-+

  | Client |  | ACME | | DNS |

  +---++  +---+--+ +--+--+

  |||

STEP 1: Pre-Authorization of ancestor domain

  |   .||

  |   .||

  |   .||

STEP 2: Place order for sub1.example.org

  |   .||

  |   .||

  |   .||

STEP 3: Place order for sub2.example.org.

  |   .||

  |   .||

  |   .||



If there are multiple subdomains, the client has to place an order multiple 
times for every subdomain.

If using a wildcard certificate, the client only needs to place an order once 
for the wildcard certificate.

Then the client can configure its subdomain servers with the same wildcard 
certificate.

  ++  +--+ +-+

  | Client |  | ACME | | DNS |

  +---++  +---+--+ +--+--+

  |||

STEP 1: Pre-Authorization of ancestor domain

  |   .||

  |   .||

  |   .||

STEP 2: Place order for *.example.org|

  |||





This is just a preliminary idea, and please correct me if I'm thinking wrongly.



Regards,

Lei YAN
___
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] Paul Wouters' Discuss on draft-ietf-acme-subdomains-06: (with DISCUSS and COMMENT)

[Owen Friel (ofriel)]

Thanks Paul.

The authors have been back and forth on these issues for the past month. See 
inline for summary.

-Original Message-
From: Paul Wouters via Datatracker  
Sent: Thursday, January 19, 2023 2:47 AM
To: The IESG 
Cc: draft-ietf-acme-subdoma...@ietf.org; acme-cha...@ietf.org; acme@ietf.org; 
debcool...@gmail.com; debcool...@gmail.com
Subject: Paul Wouters' Discuss on draft-ietf-acme-subdomains-06: (with DISCUSS 
and COMMENT)


--
DISCUSS:
--

# Sec AD review of draft-ietf-acme-subdomains-06

CC @paulwouters

Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

This review uses the format specified in https://github.com/mnot/ietf-comments/
which allows automated tools to process items (eg to produce github issues)

## DISCUSS

### Zone bondary implications
```
   the ACME client need only fulfill an
   ownership challenge against an ancestor domain identifier.
```

This document seems to have a "Public Suffix List" issue and no Security
Considerations to cover this. PSL is mentioned in RFC 8555, but limited to
the context of wildcards.

The draft hints at the server being able to allow or not allow subdomain
issuance but provides little guidance.  I think at minimum, advise should be
given not to allow issuance where it crosses a label that is present in
the Public Suffix List (PSL). Additionally, it could say this should not
be allowed for the root one or TLD zones, and that care should be taken
with Empty Non Terminals (ENS), eg "co.uk".

Currently, for a TLD to obtain a rogue certificate, it has to take over
a child zone by issuing new NS records or issue a (DNSSEC signed) A or
 record directly into the child domain abusively crossing the zone cut.
These are auditable or rejectable as these DNSSEC keys are not used fo
subdomains in normal deployment. With this document, they just need to
issue a TXT record into their own zone, which is indistinguishable from
a normal operation of a DNSSEC zone key signing its own zone content.

So I believe some security guidance here would be useful.

[ofriel] Agreed. We will add some commentary similar to that in 
https://www.rfc-editor.org/rfc/rfc8555#section-10.5


### Post compromise security

This document allows an authorization object to be used in the future
for additional sub/super domain ACME certificates. This does seem
like a new security concern without a matching security consideration.
While without this document, abuse could happen for an individual domain,
this can now be extended to all domains under or one or more levels
above it. An attacker could copy this object and use it at a much later
date to issue fraudulent certificates for many subdomains.

Related: Is there a way to indicate with ACME that this object should be
de-authorized, to gain some post compromise security? I did not see anything
listed in the security considerations of RFC8555.

I did not see any recommendations for the expire: field in RFC 8555's Security
Considerations Section.

[ofriel] The authz object is the servers internal state that represents the 
specific client account authorization for a given identifier. Its not really 
the authz object that gets compromised, it’s the client account that gets 
compromised and allows the attacker to do whatever they want with that client 
account. We can clarify this in the security section and reference back to 
https://www.rfc-editor.org/rfc/rfc8555#section-7.3.6, which describes how a 
client can deactivate their account if account keys are compromised.

### Wildcards?

It is unclear to me how DNS wildcards, eg "*.nohats.ca" should be handled?
Do they fall within the permissions granted by "subdomainAuthAllowed"?

[ofriel] We will add clarifying text that if server policy allows issuance of 
wildcard certs under a given ancestor domain, then it SHOULD include the 
"wildcard": true field in the authz object. 
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-integrations-13.txt

[Owen Friel (ofriel)]

Hi all,
This addresses all issues raised on the mailers. The issues and associated 
fixes can all be seen at: 
https://github.com/upros/acme-integrations/issues?q=is%3Aissue+

The authors noticed one issues related to Joe Salowey's feedback on tls-unique 
channel binding:

An update for TEAP is underway that can be used to address channel binding in 
TLS1.3 using RFC9266.

However, there is no currently planned update for EST RFC7030 to specify how to 
use RFC9266. EST only references tls-unique. How should we proceed here?

Thanks,
Owen

-Original Message-
From: Acme  On Behalf Of internet-dra...@ietf.org
Sent: Friday 10 February 2023 19:49
To: i-d-annou...@ietf.org
Cc: acme@ietf.org
Subject: [Acme] I-D Action: draft-ietf-acme-integrations-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME Integrations for Device Certificate Enrollment
Authors : Owen Friel
  Richard Barnes
  Rifaat Shekh-Yusef
  Michael Richardson
  Filename: draft-ietf-acme-integrations-13.txt
  Pages   : 24
  Date: 2023-02-10

Abstract:
   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  The use cases include ACME
   integration with EST, BRSKI and TEAP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-integrations-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] Artart last call review of draft-ietf-acme-subdomains-04

[Owen Friel (ofriel)]

Thank you Carsten for the review and comments.

I created individual github issues for these comments and all other review 
comments of acme-subdomains at https://github.com/upros/acme-subdomains/issues

I have committed fixes and closed the associated issues for 6 of these 10 
comments.

Michael is working on an update to address the security considerations comment: 
https://github.com/upros/acme-subdomains/issues/27

For the remaining three comments, please see inline below. I have proposed 
changes on github branches for these three, have raised PRs, but have not 
merged these onto master yet.

Thank you for https://github.com/upros/acme-subdomains/pull/14, this has now 
been merged onto master.

Regards,
Owen

-Original Message-
From: Carsten Bormann via Datatracker  
Sent: Wednesday 23 November 2022 10:50
To: a...@ietf.org
Cc: acme@ietf.org; draft-ietf-acme-subdomains@ietf.org; last-c...@ietf.org
Subject: Artart last call review of draft-ietf-acme-subdomains-04

Reviewer: Carsten Bormann
Review result: Ready with Issues

Thank you for an easy-to-read document that is accessible even to readers who 
are not ACME experts.

# Minor technical

## "default value"

subdomainAuthAllowed is said to have a default value (value assumed if not 
included) of false, i.e., absence of the field implies the value to be false 
(except in metadata, which is a separate inconsistency that might surprise 
implementers).

However, in several places, the text seems to instruct the server to 
specifically include subdomainAuthAllowed with a value of false in certain 
cases, apparently turning this into a three-valued field (true, false, absent).

Which one is it?

(This could easily become an interoperability problem.)

[ofriel] I have attempted to remove the ambiguity. I have used the patterns and 
guidelines associated RFC8555 wildcard usage to influence my choice of text 
here. I have also removed the default subdomainAuthAllowed inconsistency 
between authorization object (assume false if absent) and directory metadata 
(changed from no default to assume false if absent).

https://github.com/upros/acme-subdomains/commit/91ea76cd5fce242ea389506ba02267051386c054

# Major editorial

## terminology

### parent

The term "parent" is usually reserved for the direct ancestor (single edge in 
the graph).  What is defined here really is an "ancestor domain".  (Given the 
definition of subdomain that explicitly includes self, each domain also is its 
own parent domain; I'm not clear whether this is intended here.)

Unfortunately, this unusual terminology is now hard-coded in the names of 
fields added by this specification, so it is not a purely editorial decision to 
adjust the terminology to common usage.

[ofriel] This is blindingly obvious now that you have pointed this out. I have 
changed to use your recommended "ancestor domain" rather than "parent domain" 
terminology. I do not think its that huge an issue having to change the 
parentDomain field in the newOrder identifers payload to ancestorDomain, and 
have already started to code this up in my acmez client and pebble server 
golang implementations.

https://github.com/upros/acme-subdomains/pull/37/commits/96e2f14521f8356a1207714ffa80b9cc7cfa

### subdomain

The definition of subdomain (of a domain given) appears to include the domain 
given.  This fine point might be lost on the reader; it can be surprising 
(subalpine definitely does not include alpine).
Several pieces of text sound like setting subdomainAuthAllowed to true only 
allows subdomains, which actually does not make a difference due to the 
subtlety of the meaning of subdomain.

[ofriel] Indeed, the definition of subdomain lifted from RFC8499 does appear to 
allow this interpretation. I think the key sentence in the definition is " A 
domain is a subdomain of another domain if it is contained within that domain. 
". If the reader/implementor interprets *another* domain as implicitly meaning 
a *different* domain then a domain cannot be a subdomain of itself.

As a stop gap, I have proposed a clarifying explanation in acme-subdomains that 
does not change the RFC8499 definition, but states that for the purposes of 
this document a domain cannot be a subdomain of itself.

Otherwise we could end up in a paradoxical situation where a server creates an 
authorization object for an identifier and sets "subdomainAuthAllowed"=false, 
but if a domain is allowed be a subdomain of itself, does this mean that the 
authorization is in fact not valid for itself??

https://github.com/upros/acme-subdomains/commit/50f29bd8c617efad0ba4bd56341624d67681b9a2

Does the RFC8499 definition need to be updated? What is ISEG guidance here?

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

Re: [Acme] Genart last call review of draft-ietf-acme-subdomains-04

[Owen Friel (ofriel)]

Thank you Reese for the review and comments.

I created individual github issues for these comments and all other review 
comments of acme-subdomains at https://github.com/upros/acme-subdomains/issues

I have committed fixes and closed all bar one of the issues raised below. I 
will comment on that one inline below.

Regards,
Owen

-Original Message-
From: Reese Enghardt via Datatracker  
Sent: Thursday 17 November 2022 01:24
To: gen-...@ietf.org
Cc: acme@ietf.org; draft-ietf-acme-subdomains@ietf.org; last-c...@ietf.org
Subject: Genart last call review of draft-ietf-acme-subdomains-04

Reviewer: Reese Enghardt
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

Section 2:

" Fully-Qualified Domain Name (FQDN): This is often just a clear way
  of saying the same thing as "domain name of a node", as outlined
  above.  However, the term is ambiguous."

These two sentences appear to contradict each other - Is the term clear or 
ambiguous? I suggest removing the word "clear" to simply state how the term is 
commonly used, and then point out the ambiguity.

[ofriel] The section starts with stating:

" The following terms are defined in DNS Terminology [RFC8499] and are
   reproduced here" 

The definition is an exact quote from RFC8499. Do we need to get the definition 
in RFC8499 updated? I am unsure if I should change the definition of FQDN in 
this ACME document and would prefer to change the definition in the common 
source of these DNS terms. What does IESG recommend?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Opsdir last call review of draft-ietf-acme-subdomains-04

[Owen Friel (ofriel)]

Thank you Bo for the review and comments.

I created individual github issues for these comments and all other review 
comments of acme-subdomains at https://github.com/upros/acme-subdomains/issues

I have committed fixes and addressed all of the below comments, and closed all 
the associated issues.

Regards,
Owen

-Original Message-
From: Bo Wu via Datatracker  
Sent: Sunday 20 November 2022 12:21
To: ops-...@ietf.org
Cc: acme@ietf.org; draft-ietf-acme-subdomains@ietf.org; last-c...@ietf.org
Subject: Opsdir last call review of draft-ietf-acme-subdomains-04

Reviewer: Bo Wu
Review result: Has Nits

Reviewer: Bo Wu
Review result: Has Nits

I am the assigned Ops reviewer for this draft.

Document: draft-ietf-acme-subdomains-04

Summary:

This document (with intended status Standards Track) extends ACME [RFC8555] to 
support issuing certificates for subdomains. This is a well-written document.

Major issues: None.

Minor issues: None.

Nits/editorial comments:

1- Question: Section 4.3, Would it better to replace "a given identifier FQDN"
with "a given subdomain"?
   Clients need a mechanism to optionally indicate to servers whether or
   not they are authorized to fulfill challenges against parent domains
   for a given identifier FQDN.

2- Question: Section 5, it seems that the text below the call flow figure is 
not consistent with the figure. It would be better to describe the differences 
between the steps in the figure and the steps in the text below.

3- Inconsistent words: Section 5, pre-authorised -> pre-authorized

4- Question: Section 8, Is RFC 8555 a normal reference as this document is an 
enhancement to this RFC?

Thanks,
Bo Wu



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

Re: [Acme] AD review of draft-ietf-acme-subdomains-04

[Owen Friel (ofriel)]

Thank you Roman for the review and comments.

I created individual github issues for these and all other reviews of 
acme-subdomains at https://github.com/upros/acme-subdomains/issues

I have committed fixes and closed all bar one of the issues raised below. I 
will comment on that one inline below.

Regards,
Owen

-Original Message-
From: Acme  On Behalf Of Roman Danyliw
Sent: Saturday 29 October 2022 22:58
To: acme@ietf.org
Subject: [Acme] AD review of draft-ietf-acme-subdomains-04

Hi!

I performed an AD review of draft-ietf-acme-subdomains-04.  Thanks for this 
work to extend ACME capability.  I have a few comments below, but they aren't 
significant enough to hold the document.  Please address them concurrently with 
IETF LC.


** Section 2.  Editorial. This section takes direct quotes out of RFC8499 but 
does not put quotation marks around them.  However, when text is taken from 
RFC1034 it has quotes.  Recommend consistency.

[ofriel] Similar to my feedback on acme-integrations: The quotes or lack of 
quotes is itself taken directly from the definitions in RFC8499. If you look at 
RFC8499, the definition of Label is not in quotes; however, the definition of 
Subdomain starts with a quote as it is pulling in text from RFC1034 into 
RFC8499. The text in acme-integrations aligns to the character with what is in 
RFC8499. Does this make sense?

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

Re: [Acme] AD Review of draft-ietf-acme-integrations-10

[Owen Friel (ofriel)]

Thank you Roman for the review and comments.

I created individual github issues for these comments and have committed fixes 
for most of them and closed the issues:  
https://github.com/upros/acme-integrations/issues

There are three outstanding issues and I will comment on these inline below.

Regards,
Owen

-Original Message-
From: Acme  On Behalf Of Roman Danyliw
Sent: Saturday 29 October 2022 03:34
To: acme@ietf.org
Subject: [Acme] AD Review of draft-ietf-acme-integrations-10


Hi!
I performed an AD review of draft-ietf-acme-integrations-10.  Thanks for this 
information document to should the broad applicability of ACME.  My feedback is 
as follows:


** Section 2.  Editorial.  The definition of subdomain uses explicit quotes 
around text from RFC1034.  However, label comes verbatim of RFC8499, why not 
quotes around it?

[ofriel] The quotes or lack of quotes is itself taken directly from the 
definitions in RFC8499. If you look at RFC8499, the definition of Label is not 
in quotes; however, the definition of Subdomain starts with a quote as it is 
pulling in text from RFC1034 into RFC8499. The text in acme-integrations aligns 
to the character with what is in RFC8499. Does this make sense?


** Section 6.  I don't have the full history on draft-ietf-eap-teap-brski.  
However, it seems unusual to be effectively specifying an applicability 
statement for an expired, unadopted draft.  Is there significant usage of this 
draft in the field?  What's the motivation?

[ofriel] We / cisco are actively working on elements of 
draft-lear-eap-teap-brski, we just didn't get to updating at IETF115. It might 
make sense to remove the reference for now, but see next comment.

** Section 6.  Diagram

Step 2 is "Establish Outer Tunnel".  Isn't the last step of it the follow 
(i.e., the client responding back with the Result TLV= Success.

   |  EAP-Response/  |  |   |
   |   Type=TEAP,|  |   |
   |   {Crypto-Binding TLV,  |  |   |
   |   Result TLV=Success}   |  |   |
   |>|  

However, the following is being shown as the last step:

   |  EAP-Request/   |  |   |
   |   Type=TEAP,|  |   |
   |   {Request-Action TLV:  |  |   |
   | Status=Failure, |  |   |
   | Action=Process-TLV, |  |   |
   | TLV=CSR-Attributes, |  |   |
   | TLV=PKCS#10}|  |   |
   |<|  

[ofriel] The reason this happens is yes, the client has successfully completed 
TLS handshake, but the server is explicitly instructing the client to do a CSR 
Attributes followed by a PKCS#10 cert enrol so that the client will enrol to 
get a cert that will allow it to access. E.g. the client may start the TEAP 
transaction with an IDevID, or with an about-to-expire LDevID, thus the server 
is telling it to get a new cert before it will grant access.

This behavoiur is not too clearly specified in RFC7170, but is clearer in 
draft-lear-eap-teap-brski. We could possibly drop draft-lear-eap-teap-brski 
reference and add further clarification in this document over and above what is 
in RFC7170.


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

Re: [Acme] I-D Action: draft-ietf-acme-integrations-08.txt

[Owen Friel (ofriel)]

This addresses all comments raised against draft-07 bar one:

-
Section 7.2 says:

   EST [RFC7030] is not clear on how the CSR Attributes response should
   be structured, and in particular is not clear on how a server can
   instruct a client to include specific attribute values in its CSR.
   [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
   use CSR Attributes response to specify specific values for attributes
   that the client should include in its CSR.

   Servers MUST use this mechanism to tell the client what identifiers
   to include in CSR request. ...

This is a MUST, but is is not really nailed down.  Can we get to a simple MUST 
statement here?  If not, can we at least narrow the possibilities?
-

Michael is working on updates to richardson-lamps-rfc7030-csrattrs which should 
clarify this, and we felt that best to leave the text hear as is, as 
richardson-lamps-rfc7030-csrattrs will be clarified shortly.

Owen


-Original Message-
From: Acme  On Behalf Of internet-dra...@ietf.org
Sent: Monday 4 July 2022 15:31
To: i-d-annou...@ietf.org
Cc: acme@ietf.org
Subject: [Acme] I-D Action: draft-ietf-acme-integrations-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME Integrations
Authors : Owen Friel
  Richard Barnes
  Rifaat Shekh-Yusef
  Michael Richardson
  Filename: draft-ietf-acme-integrations-08.txt
  Pages   : 23
  Date: 2022-07-04

Abstract:
   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  The use cases include ACME
   integration with EST, BRSKI and TEAP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-integrations-08


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] WG Last Call for draft-ietf-acme-integrations-07

[Owen Friel (ofriel)]

Hi,
There were 12 individual comments/issues raised. I tracked them all as separate 
github issues. 10 have been addressed and fixes checked into 
https://github.com/upros/acme-integrations.
There are only two outstanding issues, and we are noodling over the correct 
text.
Expect an update in the next couple of days and draft-ietf-acme-integrations-08 
to be pushed.
Thanks for the detailed comments.
Owen

From: Acme  On Behalf Of Deb Cooley
Sent: Thursday 16 June 2022 18:36
To: IETF ACME 
Cc: Dorothy E Cooley 
Subject: Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07

Thanks for the two reviews w/ comments.  When the authors have addressed the 
comments, we can issue a short WGLC.

For the ACME chairs,
Deb Cooley

On Fri, May 27, 2022 at 9:44 AM Carl Wallace 
mailto:c...@redhoundsoftware.com>> wrote:
I’ll reply here to add one comment. The introduction of the potential for 
errors due to domains the RA is authorized for and those may be requested is 
not called out to any extent. It is likely something that is mostly addressed 
by authentication to the RA and could be noted as such in section 7.1.  Section 
7.5 gets at the issue with the mapping for badIdentity, but it could be called 
out as something that occurs upon submission of request to the RA (vs mapping 
an ACME error back to the protocol of interest after failed interaction with 
the ACME server).

From: Acme mailto:acme-boun...@ietf.org>> on behalf of 
Russ Housley mailto:hous...@vigilsec.com>>
Date: Thursday, May 26, 2022 at 10:25 AM
To: Deb Cooley mailto:debcool...@gmail.com>>, Dorothy E 
Cooley mailto:deco...@radium.ncsc.mil>>
Cc: IETF ACME mailto:acme@ietf.org>>
Subject: Re: [Acme] WG Last Call for draft-ietf-acme-integrations-07

I have a few comments.  Only one of them will be difficult to sort out.

Section 1, para 1: Please add a cite to [RFC5280] after "X.509 (PKIX) 
certificate".

Section 1, last para: Please reword.  Something like:

   Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
   useful optimization when ACME is used to issue certificates for large
   numbers of devices; it reduces the domain ownership proof traffic as
   well as the ACME traffic overhead.  This is accomplished by completing
   a challenge against the parent domain instead of a challenge against
   each explicit subdomain. Use of ACME for subdomains is not a
   necessary requirement.

Section 2: Please add a reference for CSR.  Consider [RFC2986].

Section 2: Please add a reference for RA.  Consider [RFC5280].

Section 2: Please add a reference for TLV.  Consider [RFC7170].

Section 4: Please fix the markdown typo: Refer to section {csr-attributes} for 
more details.

Section 7.2 says:

   EST [RFC7030] is not clear on how the CSR Attributes response should
   be structured, and in particular is not clear on how a server can
   instruct a client to include specific attribute values in its CSR.
   [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
   use CSR Attributes response to specify specific values for attributes
   that the client should include in its CSR.

   Servers MUST use this mechanism to tell the client what identifiers
   to include in CSR request. ...

This is a MUST, but is is not really nailed down.  Can we get to a simple MUST 
statement here?  If not, can we at least narrow the possibilities?

Section 7.2: s/The identifier must/The identifier MUST/

Section 7.3: s/certificate MAY be omitted from the chain/certificate SHOULD be 
omitted from the chain/

Section 7.3.2: Please provide references for PKCS#7 and PKCS#10.

Section 7.4: s/id-kp-cmcRA extended key usage bit/id-kp-cmcRA extended key 
usage OID/ (multiple places)

Russ


On May 26, 2022, at 6:58 AM, Deb Cooley 
mailto:debcool...@gmail.com>> wrote:

Title:  ACME Integrations

Authors: O.Friel, R.Barnes, R. Shekh-Yusef, M.Richardson

Datatracker: 
https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/

This document outlines multiple advanced use cases and integrations that ACME 
facilitates without any modifications or
enhancements required to the base ACME specification.  The use cases include 
ACMEintegration with EST, BRSKI and TEAP.

Please respond to this WG last Call by 9 June 2022.

For the ACME WG Chairs,
Deb
___
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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WG Last Call for draft-ietf-acme-subdomains-03

[Owen Friel (ofriel)]

Hey all,
I’ve addressed the nits and just published draft-ietf-acme-subdomains-04.
Owen

From: Acme  On Behalf Of Deb Cooley
Sent: Thursday 16 June 2022 18:33
To: IETF ACME 
Cc: Cooley, Dorothy E 
Subject: Re: [Acme] WG Last Call for draft-ietf-acme-subdomains-03

We've seen two responses to the WGLC (one with nits).  Can we get a few more 
reviews?  From people that are not authors?

For the ACME WG chairs,
Deb Cooley

On Mon, Jun 6, 2022 at 12:36 PM Deb Cooley 
mailto:debcool...@gmail.com>> wrote:
A couple of more days for this WGLC and crickets

For the ACME WG chairs,
DebCooley

On Thu, May 26, 2022 at 7:03 AM Deb Cooley 
mailto:debcool...@gmail.com>> wrote:
Title:  ACME for Subdomains

Authors: O.Friel, R.Barnes, T.Hollebeek, M.Richardson

Datatracker:  https://datatracker.ietf.org/doc/draft-ietf-acme-subdomains/

This document outlines how ACME can be used by a client to obtain a certificate 
for a subdomain identifier
from a certification authority.

Please respond to this WG last Call by 9 June 2022.

For the ACME WG Chairs,
Deb
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 113 agenda items

[Owen Friel (ofriel)]

Hi Deb,

I will not be there in person, but Michael and Rifaat will, so they will 
present.

Michael will present acme-subdomains.

Rifaat will present acme-integrations.

They will both only need ~5 minutes each, primarily only editorial updates.


-Original Message-
From: Acme  On Behalf Of Michael Richardson
Sent: Wednesday 2 March 2022 23:11
To: Deb Cooley ; acme@ietf.org; acme-cha...@ietf.org
Subject: Re: [Acme] IETF 113 agenda items


Deb Cooley  wrote:
> We have a meeting time scheduled for Monday, 21 March 2022, 1300-1400

> Please send in your agenda topics along with how much time you think you
> will need to: acme-cha...@ietf.org by 14 March 2022.

I expect that Owen will speak to status of acme-integrations, and 
acme-subdomains.
I think that acme-integrations needs a shepherd writeup.

It now depends upon RFC7030 CSR clarifications (over in LAMPS), which has not 
received the attention it needs.

> We will likely have one chair in person (unless things go sideways) and 
one
> remote.  Should be fun.

I will also be there in person.

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

[Acme] acme-subdomains RFC8499 vs. CA/B terminology

[Owen Friel (ofriel)]

I mentioned it at IETF 112 that we needed to decide on use of RFC8499 vs. CA/B 
forum terminology in the document.

As this document is not specific to Web PKI use cases, I prefer RFC8499 
terminology.

Martin expressed that preference too: 
https://mailarchive.ietf.org/arch/msg/acme/Yh1YbtqZy9rwOmInU1KyJdADTE4/

For acme-integrations, Deb also preferred RFC8499: 
https://mailarchive.ietf.org/arch/msg/acme/Hj1PwYuO0zWdXG4HOPGOs8cVNw4/

So unless I hear otherwise, I will publish a draft-01 with updated RFC8499 
terminology, that also addresses Daniels comments 
https://mailarchive.ietf.org/arch/msg/acme/Px0d5MG5_fC490PmEUSRAcsCAF0/ , 
before the holiday break.

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

Re: [Acme] question regarding -subdomains-00 section 5

[Owen Friel (ofriel)]

Thanks for the review Daniel.

I created a github issue to track: 
https://github.com/upros/acme-subdomains/issues/2




From: Acme  On Behalf Of Daniel Migault
Sent: 09 December 2021 06:26
To: acme@ietf.org
Subject: [Acme] question regarding -subdomains-00 section 5

Briefly looking at the flows of section 5 I do have the following 
questions/comments.

   | POST /challenge|   |
   |--->|   |
   || Verify|
   ||-->|
   | 200 status=valid   |   |
   |<---|   |


I believe the 200 response is the response to the POST / Challenge 
extrapolating the POST-as-GET to the order resource.
[ofriel] Correct.

My understanding is that the purpose of the POST is to indicate the challenge 
can be checked by the ACME server. It has a challenge url as well as an empty 
JSON payload {}.
The POST-as-GET purpose would be to check the status of the authorization 
resource. It has an new-order url and a void payload.
If the 200 status=valid is a response to a POST /challenge, I am wondering if 
that is a common practice for ACME server to delay the response of a POST 
/challenge and to have the client inferring the 200 status=valid will be 
reflected in the authorization and later in the order with a status=ready or 
valid.- assuming the the order requires a single authorization. When multiple 
authorizations are involved, the ACME client would need to keep track of those. 
I might also have missed this in 8555.

[ofriel] https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1 states:

“Usually, the validation process will take some time, so the client
   will need to poll the authorization resource to see when it is
   finalized”

So you are correct, the usual flow is an immediate response to the  client with 
a status=processing, and then the client polls until it gets a response with 
status=valid. I guess the operative word in the acme-subdomains doc is 
*Illustrative* call flow, but I could add a processing response and a client to 
server poll to the call flow to make it clearer and align with the ‘usual’ flow 
if there is consensus that that will make things clearer.

The ACME spec is pretty flexible and not proscriptive here. And yes, if the 
client has multiple pending authorizations, then yes it will have to track 
these different pending objects.


I do have a similar question regarding the finalize order exchange.


Beginning of page 12, given the text on page 11, and the introduction to step 
2, it seems maybe clearer to set the status of the authorization object to 
"valid".
[ofriel] Maybe it becomes clearer if I split the paragraph. I can put the 
second sentence “Once the client completes the  challenge, the server will 
transition the authorization object and  associated challenge object status to 
"valid". “ after the example STEP 1 JSON.


STEP 2:

"""
 As an authorization object already exists for the parent ADN of the
   Domain Namespace, the server replies with an order object with a
   status of "valid" that includes a link to the existing "valid"
   authorization object.
"""

I have the impression an order has its status set to valid once the certificate 
has been issued. In STEP 2, my understanding is that authorization has been 
validated and the order has not been finalized, so I would have expected a 
status set to ready.

I have the same issue in STEP 3.
[ofriel] Correct for both steps, will update to “ready”.
Yours,
Daniel

--
Daniel Migault
Ericsson
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] comments on: draft-ietf-acme-integrations-05

[Owen Friel (ofriel)]

Hi Deb,
I have raised github issues for all these items:

https://github.com/upros/acme-integrations/issues

I will get these addressed later this week.
Thanks for the review.
Owen


From: Acme  On Behalf Of Deb Cooley
Sent: 27 November 2021 19:43
To: acme@ietf.org
Cc: Cooley, Dorothy E 
Subject: [Acme] comments on: draft-ietf-acme-integrations-05

No hats (oh that was fun!).

Most of these are very minor.  In full disclosure, I don't have a ton of 
experience on either ACME message exchanges or TEAP:

Section 2:  I like the DNS terminology (I can’t say if they are correct).  For 
me, they are clear and easy to understand.
Section 2:  CMS – spell this out the first time.
Section 3:  This might be picky, but sometimes it is difficult to distinguish 
between ACME the protocol and ACME the CA.  For example, the call flow chart 
has a node ‘ACME’, this is the CA, correct?  If you wanted to clarify this, I 
think it would be as easy to change the node to ‘ACME CA’.  Again, I will 
freely admit this might be picky…
Section 4, para 1:   Spell out MASA somewhere.  Maybe in the terms in Section 
2.  I know MASA is defined in BRSKI, but this would at least give the reader a 
hint.
Section 6:
TLV?  (This means tag length value, but clearly that is wrong).
I know nothing about TEAP, but does the server initiate normally? (I’m used to 
seeing client-initiated exchanges)
And this is not for this document, per se, but does TEAP use TLS1.2 (it doesn’t 
look like TLS 1.3 – change cipher spec, for example)?

Deb Cooley
deco...@nsa.gov

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

Re: [Acme] 2nd working group call for adoption

[Owen Friel (ofriel)]

-Original Message-
From: Martin Thomson  
Sent: 18 October 2021 09:46
To: Owen Friel (ofriel) ; acme@ietf.org
Subject: Re: [Acme] 2nd working group call for adoption

On Fri, Oct 15, 2021, at 18:00, Owen Friel (ofriel) wrote:
> Not sure why "domainNamespace" is used as the field when "subdomains" 
> is shorter and easier to understand.
>
>
> [ofriel] there was early discussion on the mailer about what exactly a 
> 'subdomain' meant. So we quoted the CA/B Browser baseline definitions 
> and used that terminology instead.  Note that the draft is not 
> restricted to web use cases, so basing terminology on CA/B is not by 
> any means mandatory. I have no strong preference on what we call the 
> field at all -  subdomains and namespaces are both used in the draft, 
> so happy to change to whatever is clearest.

RFC 8499:

   Subdomain:  "A domain is a subdomain of another domain if it is
  contained within that domain.

I found "namespaces" confusing.  I don't think we need to borrow CA/BF 
obfuscations.

[ofriel] As section 
https://datatracker.ietf.org/doc/html/draft-friel-acme-subdomains-05#section-7.1
 already explicitly states that this draft is not restricted to Web PKI use 
cases and CA/B policy, and is equally applicable to e.g. IoT use cases or 
Private CA use cases, it makes sense to stick to generic IETF RFC 8499 
terminology, and use that to define subdomain. 

And even though the appendix explicitly references version 1.7.1 of the CA/B 
reqs, its probably worth deleting that appendix completely, as its already out 
of date.

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

Re: [Acme] 2nd working group call for adoption

[Owen Friel (ofriel)]

Not sure why "domainNamespace" is used as the field when "subdomains" is 
shorter and easier to understand.


[ofriel] there was early discussion on the mailer about what exactly a 
'subdomain' meant. So we quoted the CA/B Browser baseline definitions and used 
that terminology instead.  Note that the draft is not restricted to web use 
cases, so basing terminology on CA/B is not by any means mandatory. I have no 
strong preference on what we call the field at all -  subdomains and namespaces 
are both used in the draft, so happy to change to whatever is clearest.

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

Re: [Acme] working group call for adoption

[Owen Friel (ofriel)]

From: Aaron Gable 
Sent: 14 September 2021 00:02
To: Owen Friel (ofriel) 
Cc: Michael Richardson ; Ryan Sleevi 
; Deb Cooley ; acme@ietf.org
Subject: Re: [Acme] working group call for adoption

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) 
mailto:ofr...@cisco.com>> wrote:

Consider an RA that wants to get device certs for thousands of devices e.g. 
foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org> and 
bar.type-b-sensors.example.org<http://bar.type-b-sensors.example.org>, The RA 
would likely do a preAuthz for the domains it owns (e.g. 
example.org<http://example.org>) rather than wait for a device to send an enrol 
request for a specific identifier (e.g. 
foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>) and the 
RA then send a newOrder containing “identifiers”: [ {“value”: 
“foo.type-a-sensors.example.org<http://foo.type-a-sensors.example.org>”, 
“domainNamespace”:“example.org<http://example.org>”} ].

The point of much of my original message is that this flow is already possible 
today (modulo server policy). Instead of doing a preAuthz for 
example.org<http://example.org>, the subscriber would do a newOrder for 
*.example.org<http://example.org>. The rest of the process would be identical.

[ofriel] It did come up at the last face-to-face meet IETF106 that the ACME 
server and authorization objects should explicitly differentiation between 
authorization for wildcard certs vs. authorization for the full domain 
namespace.

It was EKR that made that point and asked for this ‘special indicator’: 
https://datatracker.ietf.org/meeting/106/materials/minutes-106-acme-00. This 
was the genesis for adding the “domainNamespace” boolean to the authz object 
(which was called “basedomain” in draft-01).


Again, I'm new here and so I'm not sure what criteria we look for when 
considering new standards. Maybe a standard that provides a clear, intuitive 
alternative to something already possible but kinda hacky is a good thing; 
maybe it isn't. That's where my knowledge ends. I'm just trying to make sure we 
understand that this behavior is technically possible today.

[ofriel] In general, its better to have the standard clear and explicit and not 
have implementers having to scratch their heads and jump through hoops to force 
the behaviour they want.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) 
mailto:ofr...@cisco.com>> wrote:

CA/B guidelines states the following in “3.2.2.4 Validation of Domain 
Authorization or Control” for multiple methods (including DNS)...

I'm not totally sure which part of my message this is responding to. Just in 
case this was responding to my very last bullet point: yes, the BRs allow 
multiple methods (including DNS validation) to be used for subdomains. But they 
no longer allow Agreed-Upon Change To Website to be used for subdomains, which 
means Appendix A needs to be updated.

[ofriel] The point I was attempting to make here, along with the assumption in 
my email that there is “value in explicitly distinguishing between an 
authorization for a wildcard vs. an authorization for an entire domain 
namespace” is that while CA/B policy allows that proof of domain control to be 
used for issuance of both wildcard and certs with subordinate identifiers in 
the namespace, this draft defines how an ACME servers can disambiguate between 
the two. This was the EKR ask at IETF106.

On Sun, Sep 12, 2021 at 11:24 PM Owen Friel (ofriel) 
mailto:ofr...@cisco.com>> wrote:

An RFC8555 wildcard authorization for example.org<http://example.org> only 
allows the *.example.org<http://example.org> cert to be issued.

I don't think this is true. The relevant pieces of languages are, as far as I 
can tell:

Section 7.1.4:
"This field MUST be present and true for authorizations created as a result of 
a newOrder request containing a DNS identifier with a value that was a wildcard 
domain name.  For other authorizations, it MUST be absent."
"Wildcard domain names (with "*" as the first label) MUST NOT be included in 
authorization objects.  If an authorization object conveys authorization for 
the base domain of a newOrder DNS identifier containing a wildcard domain name, 
then the optional authorizations "wildcard" field MUST be present with a value 
of true."

So an Authorization object can only have the "wildcard" field set if it was 
created as the result of a newOrder request for a wildcard domain name, and the 
"wildcard" field must be set if the Authorization object conveys authorization 
for the base domain of a wildcard domain name.

This says nothing about whether or not that Authorization object also conveys 
authorization for other things (such as all subdomains of that base domain), 
and says nothing about whether or not that Authorization object can be re-used 
for orders other than the one 

Re: [Acme] working group call for adoption

[Owen Friel (ofriel)]

From: Acme  On Behalf Of Aaron Gable
Sent: 02 September 2021 08:31
To: Michael Richardson 
Cc: Ryan Sleevi ; Deb Cooley ; 
acme@ietf.org
Subject: Re: [Acme] working group call for adoption

On Wed, Sep 1, 2021 at 5:28 PM Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:
Yes, but not necessarily across TLS connections.

One connects, gets a challenge, sets it up (DNS or HTTP/S), waits for the
authorization check to complete, and sends an order.

I don't know what letsencrypt does, but my understanding is that I could do
all of this on the same connection, and afterward, aside from the certificate
that I append to a database, there is no other moving parts.

I do not believe this is an accurate description of the ACME protocol, and 
certainly not of any implementation of it that I'm aware of (but I may be 
wrong!).

It is true that one could imagine an ACME server which never performs 
authorization re-use. It would not support pre-authorization, as it always 
creates new authorizations for every name in each new order. Such a server 
would be able to support the extensions to the newOrder endpoint proposed by 
this draft, but would not be able to support the extensions to newAuthz 
proposed by this draft or proposed by my message above.

That said, even such a server is required to keep state about its 
authorizations for arbitrarily long periods of time: the authorizations are 
created (including the `wildcard` boolean) when the client requests a newOrder; 
they are served when the client requests details about the authorizations for 
the order; they are updated when the client fulfills challenges; and they must 
be examined by the server when the client requests to finalize the order. Each 
of these requests is a separate HTTP/TLS connection from the client to the 
server, and they may be seconds, hours, or even days apart, depending on the 
`expires` timestamp that the server populates in the order object.

Aaron
[ofriel] Thanks for the all the comments Aaron.

In my mind, the newAuthz proposal in this draft is the more useful and most 
likely to be implemented approach vs. the extension to newOrder. Consider an RA 
that wants to get device certs for thousands of devices e.g. 
foo.type-a-sensors.example.org and bar.type-b-sensors.example.org, The RA would 
likely do a preAuthz for the domains it owns (e.g. example.org) rather than 
wait for a device to send an enrol request for a specific identifier (e.g. 
foo.type-a-sensors.example.org) and the RA then send a newOrder containing 
“identifiers”: [ {“value”: “foo.type-a-sensors.example.org”, 
“domainNamespace”:“example.org”} ]. I think this would also make the RA code 
simpler.

So on balance, I do not think having the “domainNamespace”: “” extension 
to the newOrder would likely be used much, and am fine with dropping that. This 
use case did come up in discussions no the mailer over the past year, but 
simplifying this and removing that newOrder extension is OK. It would also 
avoid adding this complexity to both RA and ACME server code.

CA/B guidelines states the following in “3.2.2.4 Validation of Domain 
Authorization or Control” for multiple methods (including DNS):

“Note: Once the FQDN has been validated using this method, the CA MAY also issue
Certificates for other FQDNs that end with all the Domain Labels of the 
validated FQDN.
This method is suitable for validating Wildcard Domain Names.”

meaning that this covers both the wildcard cert and any subdomain certs in the 
full domain namespace under that FQDN.

Is there any value in explicitly distinguishing between an authorization for a 
wildcard vs. an authorization for an entire domain namespace? An RFC8555 
wildcard authorization for example.org only allows the *.example.org cert to be 
issued. Whereas, what we have proposed is that a domainNamespace authorization 
for example.org enables a cert with any identifier in the entire subordinate 
domain namespace to be issued. e.g. foo.type-a-sensors.example.org and 
bar.type-b-sensors.example.org. For sure, for the device cert enrolment and RA 
use cases we have in mind, the device and RA most definitely do not want a 
wildcard cert, they want a unique cert per device.

Assuming there is value in this, then the proposed changes to the APIs and 
objects are actually pretty minimal:

domainNamespace bool in authz object
domainNamespace bool in newAuthz request
domainNamespace bool in directory metadata to advertise the server supports this
domainNamespace string (an FQDN) in newOrder request (which I think we don’t 
really need, the pre-authorization workflow seems the really useful one here)

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

Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

[Owen Friel (ofriel)]

Deb in your govt PKI world then, would the flow be something like:


There is no CSR Attributes exchange that allows the RA to tell the Pledge to 
use a particular CN/SAN.

Pledge sends CSR with, say, SAN=serialnumberx

RA sends newOrder with identifier= serialnumberx

ACME CA decides that the identity should be 
“serialnumberx.devices.some-gov-dept.example.org” (e.g. based on the RA 
identity)

ACME returns an authorization challenge for “serialnumberx.devices. 
some-gov-dept.example.org” to the RA.

The RA must then prove ownership of that DNS domain before the ACME CA will 
issue the cert.




This is how we envisaged the enterprise/civilian workflow:

RA owns the domain e.g. devices.ra.example.org

Pledge connects to RA using its IDevID and sends CSR Attributes request

RA extracts serial#=abc123 (or whatever) from IDevID and appends domain to it

RA tells pledge in CSR Attributes response to include e.g. 
SAN=abc123.devices.ra.example.org in CSR

Pledge sends CSR with SAN= abc123.devices.ra.example.org

RA sends newOrder with identifier= abc123.devices.ra.example.org

ACME returns an authorization challenge for abc123.devices.ra.example.org

RA proves ownership of abc123.devices.ra.example.org and ACME issues cert.

(or using acme-subdomains, proves ownership of devices.ra.example.org)




From: Deb Cooley 
Sent: 10 June 2021 17:52
To: Michael Richardson 
Cc: Owen Friel (ofriel) ; acme@ietf.org; Cooley, Dorothy E 

Subject: Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

Michael,

In my world (government PKI systems), the RA doesn't get to do that.  Either 
the CSR is accepted or it is rejected.  The CA has a profile it follows, if the 
CSR is missing things, the CA adds them before the certificate is signed.  The 
RA can do none of that.  In our case, most RAs are actually people, so there 
can be a back channel to the requestor which can be used to sort it all out.

How this all happens in the case of 'little things', I don't know.  We do have 
a 'portal' for devices, but it would probably be quite 'heavy' for your use 
cases.




On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson 
mailto:mcr%2bi...@sandelman.ca>> wrote:

Owen Friel \(ofriel\) 
mailto:40cisco@dmarc.ietf.org>> wrote:
deb> Again architecture:  If the EST Server sits in front of a large
deb> organization, then domain validation is more interesting, and the
deb> Get /csrattrs may or may not be able to recommend a SAN, right?  I
deb> can see that policy oids could be provided, if that is a thing in
deb> these systems.  [we use policy oids in US DOD, but that is possibly
deb> uncommon elsewhere.]

ofriel> That is also a fair point, for complex deployments its not clear
ofriel> what policy the EST server may want to apply before assigning a
ofriel> SAN. The text in section 3 currently states:

“EST servers could use this mechanism to tell the client  what fields to
include in the CSR Subject and Subject Alternative  Name fields”

ofriel> We could beef up that statement and explicitly state that the
ofriel> policy by which the EST determines the SAN to specify is
ofriel> explicitly out of scope. And also note that policy OIDs could be
ofriel> provided.

I would love to hear from operators and designers of CAs about how a
RA can communicate to the CA about things it doesn't like, or wishes to add,
to a certificate request.

The CSR is immutable, being signed by the EE requesting.
ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct
me if I'm wrong here!)...  Max and I talked a lot about this when design 
RFC8995,
and we had to conclude that it was simply non-standard.

In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR may
contain anything the Pledge wants to put in, it will get an otherName
containing the encoded ACP IPv6 ULA.

In implementing, I also realized that the GET /csrattrs is pseudo-idempotent.
When first called, it needs to allocate an IPv6 ULA for that node, and it
needs to store it, such that whenever the same IDevID does the GET, it gets
the same answer.  It's uncomfortable having to change database state on a
GET, but at least the result is cachable!

In the ACME integrations, we haven't said how the RA will decide what dNSName
SAN will be returned, but the same property will apply.  The RA needs to
collect a CSR that it can pass along up ACME, and for which is can do dns-01
challenges.

--
Michael Richardson mailto:mcr%2bi...@sandelman.ca>>   . 
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] comments on: draft-ietf-acme-integrations-03.txt

[Owen Friel (ofriel)]

Yes Deb, it did get lost in the shuffle.

See inline.


From: Acme  On Behalf Of Deb Cooley
Sent: 19 March 2021 18:46
To: acme@ietf.org
Cc: Cooley, Dorothy E 
Subject: [Acme] comments on: draft-ietf-acme-integrations-03.txt

I thought this draft was pretty easy to follow, and I just have a few minor 
comments.  Note:  I am probably reviewing this from the point of view of an 
integrator (maybe?) definitely not as a device developer, and not as a CA 
developer.
Section 1, sentence after bullets and Section 4, paragraph 1:  Section 1 used 
“enrolment” while Section 4 used “enrollment”.  Pick one.  Use it everywhere.
[ofriel] Sure, will fixup.
Section 3, 4 and 5 call flow:  both cases show the ACME CA returning a PEM, 
while the EST RA returns a PKCS#7 to the device.  Is this intentional?  Are you 
expecting the EST Server to convert the certificate from PEM to PKCS 7, and is 
the PKCS7 a .p7b or .p7c.  [note:  these are trivial conversions, but they are 
also very confusing to most people]
[ofriel] That’s a fair point. We could reference 
https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state that EST 
server may request ACME certs using "application/pkcs7-mime" and that would 
avoid a transcoding operation when the EST downloads the cert from ACME.
From an architecture point of view, do you expect the EST Server to be run by 
the requesting organization?  Or by the CA owner – or is this not even 
possible?  [from a ‘domain control’ point of view]
[ofriel] We think this should be run by the organization that owns the domain, 
and then the EST RA can request certs from the ACME CA which could be run by a 
different org.
Again architecture:  If the EST Server sits in front of a large organization, 
then domain validation is more interesting, and the Get /csrattrs may or may 
not be able to recommend a SAN, right?  I can see that policy oids could be 
provided, if that is a thing in these systems.  [we use policy oids in US DOD, 
but that is possibly uncommon elsewhere.]
[ofriel] That is also a fair point, for complex deployments its not clear what 
policy the EST server may want to apply before assigning a SAN. The text in 
section 3 currently states:
“EST servers could use this mechanism to tell the client  what fields to 
include in the CSR Subject and Subject Alternative  Name fields”
We could beef up that statement and explicitly state that the policy by which 
the EST determines the SAN to specify is explicitly out of scope. And also note 
that policy OIDs could be provided.

Section 8.1, para 3:  What does ‘The cache should be keyed by the complete 
contents of the CSR’ mean?  The word ‘keyed’, I think, is the problem.  Maybe 
‘indexed’?  Unless the cache is encrypted?
[ofriel] Yes “indexed” is better and less confusing.

Deb Cooley, NSA
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: New Version Notification for draft-friel-acme-subdomains-03.txt

[Owen Friel (ofriel)]

Hi Rich,

Based on the discussions on the mailer last December and the preferences 
indicated, I will make these initial recommendations, and yes, a slot to 
discuss at IETF110 would be great. I will prepare a few slides to outline the 
recommendations, and summarise the reasons why as given on the mailer late last 
year.


The open items are quoted exactly as is from 
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4

Open item 1: “Does the client need a mechanism to indicate that they want to
   authorize a parent domain and not the explicit subdomain
   identifier?  Or a mechanism to indicate that they are happy to
   authorize against a choice of identifiers?  E.g. for
   foo1.foo2.bar.example.com, should the client be able to specify
   anywhere from 1 to 4 identifiers they are willing to fulfil
   challenges for?”

Recommendation 1: YES. Clients may advertise the parent ADNs that they are 
authorised to fulfil challenges against when they want a cert for an FQDN, the 
server picks from one of those challenges.

Open item 2: “Does the server need a mechanism to provide a choice of
   identifiers to the client and let the client chose which
   challenge to fulfil?  E.g. for foo1.foo2.bar.example.com, should
   the server be able to specify anywhere from 1 to 4 identifiers
   that the client can pick from to fulfil?”

Recommendation 2: NO. Servers do not need a mechanism to advertise multiple 
potential challenges to the client and let the client pick one.

Open item 3: Should acme-subdomains be restricted to dns-01 challenges and not 
allowed for http-01 challenges?

Recommendation 3: YES. Restrict acme-subdomains to dns-01 challenges. 
Fulfilment of a http-01 challenge must be carried out against the explicit 
FQDN, and not a parent ADN. Servers must not offer a client the option of 
fulfilling a http-01 challenge against a parent ADN. If server policy allows, 
then a client may fulfil a dns-01 challenge against a parent ADN in order to 
complete an order against a child FQDN.

Point of Confusion: acme-subdomains works for both the pre-authorization flows, 
and the standard flow where the client POSTs the newOrder before authorization 
takes place.


-Original Message-
From: Salz, Rich  
Sent: 03 February 2021 05:42
To: Salz, Rich ; Owen Friel (ofriel) ; IETF 
ACME 
Subject: Re: [Acme] FW: New Version Notification for 
draft-friel-acme-subdomains-03.txt

Do we have any views on these open issues?

Do we want to discuss at the virtual IETF next month?

On 1/12/21, 1:52 PM, "Salz, Rich"  wrote:

Reposting this to see if we can close the two open issues.


On 10/12/20, 4:25 AM, "Owen Friel (ofriel)" 
 wrote:

This new draft addresses the comments that were raised back in August 
by Russ.

It also explicitly lists in the Open Items 
https://tools.ietf.org/html/draft-friel-acme-subdomains-03*section-4  the two 
main open items that have been raised by Felipe and Ryan:

1. Does the client need a mechanism to indicate that they want to authz 
a parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authz against a choice of identifiers? 

2. Does the server need a mechanism to provide a choice of identifiers 
to the client and let the client chose which to fulfil?

Both would require some JSON definition work. If we can't reach 
consensus on the mailer, we could discuss at IETF 109 Online.

Cheers,
Owen


-Original Message-
From: internet-dra...@ietf.org  
Sent: 09 October 2020 18:35
To: Richard Barnes ; Tim Hollebeek 
; Owen Friel (ofriel) ; Michael 
Richardson 
Subject: New Version Notification for draft-friel-acme-subdomains-03.txt


A new version of I-D, draft-friel-acme-subdomains-03.txt
has been successfully submitted by Owen Friel and posted to the IETF 
repository.

Name:   draft-friel-acme-subdomains
Revision:   03
Title:  ACME for Subdomains
Document date:  2020-10-09
Group:  Individual Submission
Pages:  13
URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dfriel-2Dacme-2Dsubdomains-2D03.txt=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU=BU6Y6_X7HUffuxdnapklOZeMRtGd0KkNPaAvb49LYKA=
 
Status: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfriel-2Dacme-2Dsubdomains_=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=TvT7TDlUQ5gKnK6wZ-OXEwDofAYq7LINGqq4Q-XaRKU=nVKzeNyyg4s-D5rg2gvxxaqf3bhTy0szmVOHFSVe3pQ=
 
Htmlized:   
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dfriel-2Dacme-2Dsubdomains=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI

Re: [Acme] acme subdomains open items

[Owen Friel (ofriel)]

Ryan, Michael, I think you are both actually in agreement and both arguing for 
exactly the same thing.

I think I agree that it makes more sense if the client advertises its 
authorized set of ADNs. e.g. if a client needs a cert or pre-authz for 
foo1.foo2.bar.example.com, it can offer anything from 1 to 4 different ADNs 
that it is capable of fulfilling.

The draft as is does not preclude http-01 challenges, but I agree that the 
dns-01 challenge is  more applicable.

Does it make sense for the client to also be able to advertise the types of 
challenges it can fulfil? e.g. only advertise support for dns-01 but not 
http-01; or advertise support for both. RFC 8555 does not support this, nor 
does version -03 of this draft.

If a client is advertising multiple ADNs it can authorize, should the supported 
challenge type be per ADN? e.g. dns-01 and http-01 for 
foo1.foo2.bar.example.com but only dns-01 for example.com? Is this flexibility 
in any way useful, or just likely to lead to confusion and implementation bugs?

For sure, the way the draft is currently written, if a client places an order 
for a subdomain, and the server issues a single challenge for a parent ADN 
(which could be the BDN/Base Domain Name), then this will result in frequent 
failures as the client is not authorized to control the parent ADN/BDN.



From: Ryan Sleevi 
Sent: 10 December 2020 03:51
To: Michael Richardson 
Cc: Ryan Sleevi ; Owen Friel (ofriel) ; 
Felipe Gasper ; acme@ietf.org
Subject: Re: [Acme] acme subdomains open items



On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson 
mailto:m...@sandelman.ca>> wrote:
> Alas, I'm equally at a loss to understand what you're asking here, as I
> can't make much sense of your question?

dns-01 challenges for bar.bar.foo.example do not have to show control over 
foo.example.
Yet, you seem to think that they do.

Thanks for being clear!

To respond: No, I don't.

I'm highlighting that for a requested identifier of "baz.bar.foo.example", the 
CA is permitted to challenge for "bar.foo.example" or "foo.example". Indeed, 
some CAs, by default, will only challenge for "foo.example", despite that being 
a parent of the requested domain, because they want to reduce the effort 
involved to issue other certificates to that user.

Now, I never said a CA "has" to, but it's certainly true that a number of CAs 
do, in fact, require this as their standard operating procedure, and my 
understanding is that this proposal was specifically about enabling such cases 
within ACME. That is, more generally, making a clear and well-lit path where 
the domain used in the authorization does not match the domain in the 
certificate.

Is that an unreasonable understanding? It seems directly supported in the text 
of the draft, Section 5.4, 
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.4 , 
example 1.


>> The client does not demonstrate control over lex.example using dns-01 
when
>> it
>> asks for so.me.comp.lex.example.

> Is that not literally what this draft is proposing (e.g.
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-5.2 ) ?

It demonstrates control (during the authorization) for lex.example, which
allows it to fullfil orders for so.me.comp.lex.example.

Your line of questioning implies you think the reverse.
5.2 clearly shows authorization for example.org<http://example.org>, followed 
by an order for sub.example.com<http://sub.example.com>

I am again at a loss for what you mean here / what you are attributing to me. 
Equally, I'm hoping that the "example.org<http://example.org>" / 
"sub.example.com<http://sub.example.com>", as I cannot make any sense of what 
you said otherwise.

As to your statement about me thinking the reverse, I'm hoping you can perhaps 
rephrase the following paragraph in Section 5.1:

   It may make sense to use the ACME pre-authorization flow for the
   subdomain use case, **however, that is an operator implementation and
   deployment decision.**  With the ACME pre-authorization flow, the
   client could pre-authorize for the parent domain once, and then issue
   multiple newOrder requests for certificates for multiple subdomains.

With the section in emphasis (**), it seems clear that this draft is not 
prescriptive as to whether the example in Section 5.2 (the "pre-authorization 
flow") needs to be required.

To try to be clearer, since it seems you and I may be talking past each other 
and have been for some time, I'm considering the following flow:

- POST /newOrder "so.me.comp.lex.example"

Where the server needs to determine the appropriate set of authorizations to 
return for this case and the set of challenges within those authorizations. 
Again, this seems directly supported by Section 5.4 of the draft, 
https://tools.ietf.org/html/draft-friel-acm

Re: [Acme] acme subdomains open items

[Owen Friel (ofriel)]

From: Ryan Sleevi 
Sent: 05 December 2020 03:27
To: Owen Friel (ofriel) 
Cc: Felipe Gasper ; acme@ietf.org
Subject: Re: [Acme] acme subdomains open items

Thanks for bringing it to the list, Owen.

This is something we're trying to lock down in the CA/B Forum, at least with 
respect to the 'http-01' method, by making it clear that, like tls-alpn-01, it 
cannot be used as an Authorization Domain Name (i.e. a domain and all of its 
descendents), only as an FQDN.

So this method primarily is for the 'dns-01' method, which seems to suggest 
that, at a minimum, the ACME server needs to indicate to the ACME client what 
modifications it will accept, since the ACME client will need to actually 
modify the DNS record at the appropriate label. If the server only chooses a 
single label, then it seems both likely and possible that the server may choose 
a dns-01 challenge that the client cannot fulfill (e.g. the client can only 
modify subdomain.example.com<http://subdomain.example.com> and descendents, but 
the server/CA chooses to challenge against example.com<http://example.com>)

So I *think* it would benefit from having the server be able to issue 
challenges against several identifiers, and communicate that to the client, 
which seems to argue "Yes" for your question #2.

[ofriel] Are there any benefits or security advantages in #1 (client giving 
server options) vs. #2 (server giving client options)? With #2, the client does 
not have to explicitly divulge any information about its level of domain 
control. The server gives the client a set of options, and the client decides 
what to do. Obviously, if it fulfils the challenge against a parent Authorized 
Domain Name, then it has implicitly indicated control over that domain.

Equally in this scenario, I think you're asking whether or not the client 
should be able to indicate its capabilities to the ACME server, for selecting 
appropriate challenges. If a client is using dns-01 and can only modify 
subdomain.example.com<http://subdomain.example.com>, it doesn't benefit the 
client at all if the server chooses to also allow 
example.com<http://example.com>. The question is whether there's a security 
risk in doing so; that is, should the client be able to affirmatively restrict 
the server or does it not matter.

[ofriel] Yes, that is exactly what I am getting at. Perhaps the question #1 
should be phrased more accurately something like: Does the client need a 
mechanism to indicate to the server that it is capable of and authorized to 
fulfil challenges against the requested subdomain FQDN, as well as some or all 
of the parent Authorized Domain Names (potentially up to and including the Base 
Domain Name).

TBH I have no thought about the security risk of a client indicating to the 
server that it has control over parent domains, potentially including the Base 
Domain Name. What does the CA/B currently think about this?

Does that accurately capture things?

[ofriel] Exactly the questions I am asking.

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel) 
mailto:40cisco@dmarc.ietf.org>> wrote:
That is what is currently documented – the server simply picks the one domain 
that it wants the client to fulfil the challenge against.

That was presented as the current documented approach. And I also presented the 
open questions if we needed to build flexibility in client request and/or 
server response. There were no concrete opinions as far as I recall (waiting on 
the exact minutes) and Rich said to bring the qs to the mailer for further 
discussion.

Cheers,
Owen


From: Acme mailto:acme-boun...@ietf.org>> On Behalf Of 
Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) 
mailto:40cisco@dmarc.ietf.org>>
Cc: acme@ietf.org<mailto:acme@ietf.org>
Subject: Re: [Acme] acme subdomains open items

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to 
choose whether it tries authz against parent domains without the client’s 
requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us 
well.

-F

On Dec 4, 2020, at 02:23, Owen Friel (ofriel) 
mailto:ofriel=40cisco@dmarc.ietf.org>> 
wrote:

Hi all,

As recommended by the chairs at IETF109, bring the two open items to the list 
for discussion. These were raised by Felipe and Ryan previously.

1: Does the client need a mechanism to indicate that they want to authorize a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authorize against a choice of identifiers?

E.g. for foo1.foo2.bar.example.com<http://foo1.foo2.bar.example.com>, should 
the client be able to specify anywhere from 1 to 4 identifiers they are willing 
to fulfil challenges for?

2: Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which challenge to fulfil?

E.g. for foo1.foo2

Re: [Acme] acme subdomains open items

[Owen Friel (ofriel)]

That is what is currently documented – the server simply picks the one domain 
that it wants the client to fulfil the challenge against.

That was presented as the current documented approach. And I also presented the 
open questions if we needed to build flexibility in client request and/or 
server response. There were no concrete opinions as far as I recall (waiting on 
the exact minutes) and Rich said to bring the qs to the mailer for further 
discussion.

Cheers,
Owen


From: Acme  On Behalf Of Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) 
Cc: acme@ietf.org
Subject: Re: [Acme] acme subdomains open items

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to 
choose whether it tries authz against parent domains without the client’s 
requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us 
well.

-F


On Dec 4, 2020, at 02:23, Owen Friel (ofriel) 
mailto:ofriel=40cisco@dmarc.ietf.org>> 
wrote:

Hi all,

As recommended by the chairs at IETF109, bring the two open items to the list 
for discussion. These were raised by Felipe and Ryan previously.

1: Does the client need a mechanism to indicate that they want to authorize a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authorize against a choice of identifiers?

E.g. for foo1.foo2.bar.example.com, should the client be able to specify 
anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?

2: Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which challenge to fulfil?

E.g. for foo1.foo2.bar.example.com, should the server be able to specify 
anywhere from 1 to 4 identifiers that the client can pick from to fulfil?

Both 1 and 2 require JSON object definition changes. Currently, the document 
only defines how a client can submit a newOrder / newAuthz for a subdomain, and 
the server can chose any one parent identifier that it requires a challenge 
fulfilment on

Owen

https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01

https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4

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

[Acme] acme subdomains open items

[Owen Friel (ofriel)]

Hi all,

As recommended by the chairs at IETF109, bring the two open items to the list 
for discussion. These were raised by Felipe and Ryan previously.

1: Does the client need a mechanism to indicate that they want to authorize a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authorize against a choice of identifiers?

E.g. for foo1.foo2.bar.example.com, should the client be able to specify 
anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?

2: Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which challenge to fulfil?

E.g. for foo1.foo2.bar.example.com, should the server be able to specify 
anywhere from 1 to 4 identifiers that the client can pick from to fulfil?

Both 1 and 2 require JSON object definition changes. Currently, the document 
only defines how a client can submit a newOrder / newAuthz for a subdomain, and 
the server can chose any one parent identifier that it requires a challenge 
fulfilment on

Owen

https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01

https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4

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

[Acme] FW: New Version Notification for draft-friel-acme-subdomains-03.txt

[Owen Friel (ofriel)]

This new draft addresses the comments that were raised back in August by Russ.

It also explicitly lists in the Open Items section 
https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4 the two 
main open items that have been raised by Felipe and Ryan:

1. Does the client need a mechanism to indicate that they want to authz a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authz against a choice of identifiers? 

2. Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which to fulfil?

Both would require some JSON definition work. If we can't reach consensus on 
the mailer, we could discuss at IETF 109 Online.

Cheers,
Owen


-Original Message-
From: internet-dra...@ietf.org  
Sent: 09 October 2020 18:35
To: Richard Barnes ; Tim Hollebeek ; 
Owen Friel (ofriel) ; Michael Richardson 

Subject: New Version Notification for draft-friel-acme-subdomains-03.txt


A new version of I-D, draft-friel-acme-subdomains-03.txt
has been successfully submitted by Owen Friel and posted to the IETF repository.

Name:   draft-friel-acme-subdomains
Revision:   03
Title:  ACME for Subdomains
Document date:  2020-10-09
Group:  Individual Submission
Pages:  13
URL:https://www.ietf.org/id/draft-friel-acme-subdomains-03.txt
Status: https://datatracker.ietf.org/doc/draft-friel-acme-subdomains/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-friel-acme-subdomains
Htmlized:   https://tools.ietf.org/html/draft-friel-acme-subdomains-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-friel-acme-subdomains-03

Abstract:
   This document outlines how ACME can be used by a client to obtain a
   certificate for a subdomain identifier from a certification
   authority.  The client has fulfilled a challenge against a parent
   domain but does not need to fulfil a challenge against the explicit
   subdomain as certificate policy allows issuance of the subdomain
   certificate without explicit subdomain ownership proof.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

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

[Owen Friel (ofriel)]

Hi Felipe, all,

> What if … there’s no need for a standard for this? Or at least, the standard 
> would require no significant changes to the protocol?

The current draft-02 attempted to minimize the changes to the standard e.g. 
there are no significant changes proposed to any of the objects, merely 
addition of one new field to the authorization object, and one new field to the 
directory metadata.

The core idea of what -02 does is allow a client to submit a newOrder / 
newAuthz for one identifier (e.g. sub.example.com), and the server to choose 
the parent identifier (e.g. example.com) that it requires challenge fulfilment 
on and specify that in the authorization object.

That could of course be generalised so that a client could submit a newOrder / 
newAuthz for e.g. foo1.foo2.bar.example.com and the server could chose the 
exact identifier or any of the parents for authorization and challenge 
fulfilment: 

- foo1.foo2.bar.example.com OR
- foo2.bar.example.com OR
- bar.example.com OR
- example.com

With the current RFC8555 specification and structure of order and authorization 
objects, the server can only choose one of those identifiers to return in the 
authorization object, it cannot choose multiple identifiers and give  the 
client the option of which identifier challenge to fulfil. The current 
subdomains-02 draft outlines how that could work.

The two big design / requirements questions to ask are:

1. Does the client need a mechanism to indicate that they want to authz a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authz against a choice of identifiers? E.g. for 
foo1.foo2.bar.example.com, should the client be able to specify anywhere from 1 
to 4 identifiers they are willing to fulfil?

2. Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which to fulfil? E.g. for 
foo1.foo2.bar.example.com, should the server be able to specify anywhere from 1 
to 4 identifiers that the client can pick from to fulfil?

Both 1 and 2 would require changes to the JSON object definitions. For 1, each 
identifier in the newOrder or newAuthz requests would need a child array of 
alternative identifiers the client is willing to fulfil.

For 2, the current order object contains a set of authorizations that must all 
be completed, the authorization object contains a single identifier that all 
challenges are against, so therefore its not possible for the server to give 
the client a choice of identifiers to pick from. The examples I gave previously 
in the non-RFC6761-compliant email thread were a few options for addressing 2 
by enhancing the JSON objects.

I also noticed this text in https://tools.ietf.org/html/rfc8555#section-7.1.3:

authorizations (required, array of string): ...The authorizations
  required are dictated by server policy; there may not be a 1:1
  relationship between the order identifiers and the authorizations
  required.

Which is another indication that it appears valid for a client to send an order 
for a subdomain, and the server to pick any of the parent domains up to and 
including the base domain for authz fulfilment.

I think the key thing is whether 1 and/or 2 are required. Based on that, I can 
provide example JSONs that enable 1 and/or 2 and make them RFC6717 compliant 
and align with RFC8555 examples.

Cheers,
Owen


-Original Message-
From: Felipe Gasper  
Sent: 03 September 2020 21:14
To: Owen Friel (ofriel) 
Cc: Russ Housley ; IETF ACME 
Subject: Re: [Acme] Review of draft-friel-acme-subdomains-02

Hi all,

What if … there’s no need for a standard for this? Or at least, the 
standard would require no significant changes to the protocol?

The application that I help manage integrates alternately with Sectigo 
and with Let’s Encrypt. Sectigo, when they verify domain control, always checks 
parent domains along with the domain(s) given in the certificate order. If any 
of those checks succeeds, the authz is valid. Perhaps the standard could be 
defined merely in those terms, such that CAs who so choose could simply 
indicate in the authz objects that parent/ancestor domains suffice for the 
verification?

This would also allow CAs to mandate that such liberty apply only to 
DNS-based authz, while still requiring HTTP-based authz to be against the 
literal identifier.

A bit of context: our application runs on shared-hosting servers that 
we don’t administer, subject to firewall rules that neither we nor the admin 
may control. The admins run the gamut of competence, from highly-skilled on 
down. The domains are end-user-controlled, not necessarily registered with the 
same organization that administers the server. We’ve seen all kinds of crazy 
setups that complicate SSL issuance, as a result of which our 
certificate-provision logic attempts to accommodate potential 
misconfigurations. Sectigo’s acce

Re: [Acme] ACME subdomains

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

~~~
   {
 "s

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

[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

[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 has to 

Re: [Acme] IETF 107; agenda

[Owen Friel (ofriel)]

-Original Message-
From: Acme  On Behalf Of Michael Richardson
Sent: 10 March 2020 05:47
To: Salz, Rich 
Cc: Alexey Melnikov ; acme@ietf.org; Mary Barnes 

Subject: Re: [Acme] IETF 107; agenda

> draft-ietf-acme-integrations-00, ACME Integrations
> Michael Richardson can present.

I was given some slides (wasn't I Owen? Or did you just say that you'd send 
some), and the major item was to clarify the changes that were made based
comments.   I think that there isn't much to say.   I have running code that
integrates ACME with a BRSKI Registrar.

[ofriel] you *will be* given some slides :)


> draft-friel-acme-subdomains-02
> Michael Richardson can present; this is a topic for WG adoption

At first, I think that we thought that this work required no standard action, 
because it was within the server's policy to do this or not.
However, the client may not know the server's policy, and so section 5 adds the 
basedomain and implicitSubdomainAuthorization boolean.  If it comes back false 
(or missing), then the client knows it has to perform authorizations for every 
request (which is what my code above does).

I think that the WG previously expressed interest in adopting it, pending some 
changes, and those changes are made.  It may not need actual WG time, except 
that having it on a schedule sometimes gets a document read :-)

 [ofriel] Similarly, you *will be* given some slides :)


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

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-friel-acme-subdomains)

[Owen Friel (ofriel)]

I just published draft-02 
https://www.ietf.org/id/draft-friel-acme-subdomains-02.txt which hopefully 
addresses the pre-authorization and policy discussions below.


-Original Message-
From: Acme  On Behalf Of Owen Friel (ofriel)
Sent: 29 January 2020 05:51
To: Felipe Gasper 
Cc: IETF ACME 
Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call 
for adoption draft-frield-acme-subdomains)



> -Original Message-
> From: Felipe Gasper 
> Sent: 21 January 2020 14:01
> To: Owen Friel (ofriel) 
> Cc: IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was 
> RE: Call for adoption draft-frield-acme-subdomains)
> 
> 
> > On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> >
> >>
> >> Will this document eventually also describe subdomain authz via the 
> >> standard ACME workflow?
> >>
> >> 
> >
> > [ofriel] That’s the exact workflow that the document is attempting 
> > to
> describe, so maybe it needs to be clarified.
> > The example section 
> > https://tools.ietf.org/html/draft-friel-acme-subdomains-
> 01#section-4.2 (and I realise now looking at it that I messed up the 
> numbered steps - they are all '1') outlines a client authorizing for 
> "example.com" and getting certs for "sub0.example.com", 
> "sub1.example.com" and "sub2.example.com". If its not clear, I can try reword 
> in an update.
> 
> Your document seems to confine itself to the pre-authorization 
> workflow, though (as per section 4’s 2nd paragraph, anyhow); I’m 
> thinking applicability to 8555’s default/standard/order-then-authz workflow.

[ofriel] Confining to pre-authorization certainly isn’t the intention, and I 
can clarify this.

https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.1 states:

" If a server has such a policy and a client is not authorized for the
   parent domain then:
...
   o  If the client submits a newOrder request for a subdomain: The
  server MUST return a status 201 (Created) response.  The response
  body is an order object with status set to "pending" and links to
  newly created authorizations objects against the parent domain." 

So some of the text explicitly allows this. I will refactor.

> 
> -FG
___
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 wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

> -Original Message-
> From: Felipe Gasper 
> Sent: 21 January 2020 14:15
> To: Ryan Sleevi 
> Cc: Owen Friel (ofriel) ; IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> 
> > On Jan 21, 2020, at 8:04 AM, Ryan Sleevi  wrote:
> >
> > On Tue, Jan 21, 2020 at 7:14 AM Owen Friel (ofriel)  
> > wrote:
> > > Also, the linked document states:
> > >
> > >The call flow illustrates the DNS-based proof of ownership mechanism,
> > >but the subdomain workflow is equally valid for HTTP based proof of
> > >ownership.
> > >
> > > Can’t I have HTTP access to a base domain’s website without having
> > > access to a subdomain’s, though? I thought that was the reason why
> > > ACME limits wildcard authz to DNS.
> >
> > [ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME
> limitation.
> >
> > Although the CA/Browser Forum / Browser Stores have repeatedly
> > discussed forbidding it. That is, allowing the HTTP and TLS methods of
> > validation to only be scoped for the host in question (and potentially
> > the service in question, if we can work out the safe SRVName
> > transition, due to the interaction of nameConstraints and policy)
> >
> > Would it be simpler to remove the statement from the draft, rather than try 
> > to
> clarify equally valid refers to the technology without commenting on the 
> policy?
> 
> For what my opinion is worth, that seems reasonable--though perhaps the best
> might be to defer explicitly to the CA/B guidelines, e.g., “whatever 
> validation
> methods CA/B allows for subdomains/wildcards, this also allows.”

[ofriel] this suggestion makes sense. I will clarify what RFC8555 allows, and 
then refer to CA/B guidelines too. This could be for a private CA, or an IoT 
root CA (as per the long thread on lamps), so CA/B may not even be applicable 
depending on the use case.

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

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

> -Original Message-
> From: Felipe Gasper 
> Sent: 21 January 2020 14:01
> To: Owen Friel (ofriel) 
> Cc: IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> 
> > On Jan 21, 2020, at 7:13 AM, Owen Friel (ofriel)  wrote:
> >
> >>
> >> Will this document eventually also describe subdomain authz via the
> >> standard ACME workflow?
> >>
> >> 
> >
> > [ofriel] That’s the exact workflow that the document is attempting to
> describe, so maybe it needs to be clarified.
> > The example section https://tools.ietf.org/html/draft-friel-acme-subdomains-
> 01#section-4.2 (and I realise now looking at it that I messed up the numbered
> steps - they are all '1') outlines a client authorizing for "example.com" and
> getting certs for "sub0.example.com", "sub1.example.com" and
> "sub2.example.com". If its not clear, I can try reword in an update.
> 
> Your document seems to confine itself to the pre-authorization workflow,
> though (as per section 4’s 2nd paragraph, anyhow); I’m thinking applicability 
> to
> 8555’s default/standard/order-then-authz workflow.

[ofriel] Confining to pre-authorization certainly isn’t the intention, and I 
can clarify this.

https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.1 states:

" If a server has such a policy and a client is not authorized for the
   parent domain then:
...
   o  If the client submits a newOrder request for a subdomain: The
  server MUST return a status 201 (Created) response.  The response
  body is an order object with status set to "pending" and links to
  newly created authorizations objects against the parent domain." 

So some of the text explicitly allows this. I will refactor.

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

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

> -Original Message-
> From: Acme  On Behalf Of Felipe Gasper
> Sent: 20 January 2020 12:32
> To: IETF ACME 
> Subject: Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call
> for adoption draft-frield-acme-subdomains)
> 
> Will this document eventually also describe subdomain authz via the standard
> ACME workflow?
> 
> Examples:
> 
> 1) Client wants a certificate for example.com & www.example.com. Ideally, if
> the client authzs example.com, then authz for www.example.com shouldn’t be
> necessary.
> 
> 2) Now client also wants a separate certificate for sub.example.com and
> www.sub.example.com. Since example.com was already authorized, this
> certificate order should not require any additional authz.
> 
> It seems like the above workflow should “just work”, but since it’s closely
> related to what your document describes I wonder if there’s benefit to
> mentioning it?
> 

[ofriel] That’s the exact workflow that the document is attempting to describe, 
so maybe it needs to be clarified.
The example section 
https://tools.ietf.org/html/draft-friel-acme-subdomains-01#section-4.2 (and I 
realise now looking at it that I messed up the numbered steps - they are all 
'1') outlines a client authorizing for "example.com" and getting certs for 
"sub0.example.com", "sub1.example.com" and "sub2.example.com". If its not 
clear, I can try reword in an update.

> Also, the linked document states:
> 
>The call flow illustrates the DNS-based proof of ownership mechanism,
>but the subdomain workflow is equally valid for HTTP based proof of
>ownership.
> 
> Can’t I have HTTP access to a base domain’s website without having access to a
> subdomain’s, though? I thought that was the reason why ACME limits wildcard
> authz to DNS.

[ofriel] Daniel has clarified this already. Its a Lets Encrypt, not an ACME 
limitation.

> 
> 
> cheers,
> -Felipe Gasper
> 
> 
> > On Jan 20, 2020, at 6:48 AM, Owen Friel (ofriel)  wrote:
> >
> > FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents
> the proposed new authorization object field "basedomain"
> >
> >
> >> -Original Message-
> >> From: Acme  On Behalf Of Owen Friel (ofriel)
> >> Sent: 06 December 2019 15:41
> >> To: Salz, Rich ; acme@ietf.org
> >> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE:
> >> Call for adoption draft-frield-acme-subdomains)
> >>
> >> Any comments on this email on how to explicitly distinguish between
> >> wildcard and subdomain authorizations, which hopefully addresses ekr's mic
> comments.
> >>
> >>
> >>> -Original Message-
> >>> From: Acme  On Behalf Of Owen Friel (ofriel)
> >>> Sent: 26 November 2019 22:51
> >>> To: Salz, Rich ; acme@ietf.org
> >>> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> >>>
> >>> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to
> >>> the IANA Considerations section):
> >>>
> >>> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:
> >>>
> >>>   Any identifier of type "dns" in a newOrder request MAY have a
> >>>   wildcard domain name as its value.  A wildcard domain name consists
> >>>   of a single asterisk character followed by a single full stop
> >>>   character ("*.") followed by a domain name as defined for use in the
> >>>   Subject Alternate Name Extension by [RFC5280].  An authorization
> >>>   returned by the server for a wildcard domain name identifier MUST NOT
> >>>   include the asterisk and full stop ("*.") prefix in the authorization
> >>>   identifier value.  The returned authorization MUST include the
> >>>   optional "wildcard" field, with a value of true.
> >>>
> >>> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization 
> >>> Objects:
> >>>
> >>>   If an
> >>>   authorization object conveys authorization for the base domain of a
> >>>   newOrder DNS identifier containing a wildcard domain name, then the
> >>>   optional authorizations "wildcard" field MUST be present with a value
> >>>   of true.
> >>>
> >>> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1
> >>> Pre-authorization
> >>>
> >>>   Note that because the identifier in a pre-authorization request is
> >>>   the exact i

Re: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

FYI, https://tools.ietf.org/html/draft-friel-acme-subdomains-01 documents the 
proposed new authorization object field "basedomain"


> -Original Message-
> From: Acme  On Behalf Of Owen Friel (ofriel)
> Sent: 06 December 2019 15:41
> To: Salz, Rich ; acme@ietf.org
> Subject: [Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for
> adoption draft-frield-acme-subdomains)
> 
> Any comments on this email on how to explicitly distinguish between wildcard
> and subdomain authorizations, which hopefully addresses ekr's mic comments.
> 
> 
> > -Original Message-
> > From: Acme  On Behalf Of Owen Friel (ofriel)
> > Sent: 26 November 2019 22:51
> > To: Salz, Rich ; acme@ietf.org
> > Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> >
> > DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to
> > the IANA Considerations section):
> >
> > 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:
> >
> >Any identifier of type "dns" in a newOrder request MAY have a
> >wildcard domain name as its value.  A wildcard domain name consists
> >of a single asterisk character followed by a single full stop
> >character ("*.") followed by a domain name as defined for use in the
> >Subject Alternate Name Extension by [RFC5280].  An authorization
> >returned by the server for a wildcard domain name identifier MUST NOT
> >include the asterisk and full stop ("*.") prefix in the authorization
> >identifier value.  The returned authorization MUST include the
> >optional "wildcard" field, with a value of true.
> >
> > 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization Objects:
> >
> >If an
> >authorization object conveys authorization for the base domain of a
> >newOrder DNS identifier containing a wildcard domain name, then the
> >optional authorizations "wildcard" field MUST be present with a value
> >of true.
> >
> > 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 Pre-authorization
> >
> >Note that because the identifier in a pre-authorization request is
> >the exact identifier to be included in the authorization object, pre-
> >authorization cannot be used to authorize issuance of certificates
> >containing wildcard domain names.
> >
> > For the subdomains use case, it looks as if it makes sense to define a
> > "parentdomain" boolean flag (or "basedomainname" or similar) to be
> > included in the authorization object for a domain that authorizes
> > subdomain certs. The relevant CAB guidelines are quoted in
> > https://tools.ietf.org/html/draft-friel-
> > acme-subdomains-00#appendix-A.
> >
> > The authorization object would then explicitly indicate that this is a
> > base domain authorization and thus subdomain certs may be issued off
> > this. This is conceptually similar to the current "wildcard" flag
> > which indicates that a wildcard cert may be issued off the identifier
> > in the object, and would definitively differentiate wildcard vs. base
> > domain vs. explicit domain authorizations.
> >
> > Item #3 from section 7.4.1 Pre-authorization is already called out as
> > a substantive change from RFC8555: i.e. the identifier in the
> > authorization object may be different from the identifier in the newAuthz
> object.
> >
> > > -Original Message-
> > > From: Acme  On Behalf Of Salz, Rich
> > > Sent: 26 November 2019 21:53
> > > To: acme@ietf.org
> > > Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> > >
> > > WRONG.  My mistake.
> > >
> > > Please discuss this, especially the subdomains/wildcard issues.
> > > This is *NOT* a call for adoption.  We will take this up in Vancouver, 
> > > IETF
> 107.
> > >
> > > From: Rich Salz <mailto:rs...@akamai.com>
> > > Date: Tuesday, November 26, 2019 at 4:51 PM
> > > To: "mailto:acme@ietf.org; <mailto:acme@ietf.org>
> > > Subject: [Acme] Call for adoption draft-frield-acme-subdomains
> > >
> > > This email starts a ten-day call for adoption. There was consensus
> > > in the room at IETF 106 to adopt this as a working group document.
> > > If you disagree with that, or have any other strong feelings, please
> > > post to the list before the end of next week.
> > > Also discussed was the need for some additional clarity around
> > > subdomains and the existing wildcard challenges.
> > >
> > > Thank you.
> > >
> > ___
> > 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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME wildcards vs. subdomain authorizations (was RE: Call for adoption draft-frield-acme-subdomains)

[Owen Friel (ofriel)]

Any comments on this email on how to explicitly distinguish between wildcard 
and subdomain authorizations, which hopefully addresses ekr's mic comments.


> -Original Message-
> From: Acme  On Behalf Of Owen Friel (ofriel)
> Sent: 26 November 2019 22:51
> To: Salz, Rich ; acme@ietf.org
> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> 
> DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to the IANA
> Considerations section):
> 
> 1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:
> 
>Any identifier of type "dns" in a newOrder request MAY have a
>wildcard domain name as its value.  A wildcard domain name consists
>of a single asterisk character followed by a single full stop
>character ("*.") followed by a domain name as defined for use in the
>Subject Alternate Name Extension by [RFC5280].  An authorization
>returned by the server for a wildcard domain name identifier MUST NOT
>include the asterisk and full stop ("*.") prefix in the authorization
>identifier value.  The returned authorization MUST include the
>optional "wildcard" field, with a value of true.
> 
> 2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization Objects:
> 
>If an
>authorization object conveys authorization for the base domain of a
>newOrder DNS identifier containing a wildcard domain name, then the
>optional authorizations "wildcard" field MUST be present with a value
>of true.
> 
> 3. https://tools.ietf.org/html/rfc8555#section-7.4.1 Pre-authorization
> 
>Note that because the identifier in a pre-authorization request is
>the exact identifier to be included in the authorization object, pre-
>authorization cannot be used to authorize issuance of certificates
>containing wildcard domain names.
> 
> For the subdomains use case, it looks as if it makes sense to define a
> "parentdomain" boolean flag (or "basedomainname" or similar) to be included in
> the authorization object for a domain that authorizes subdomain certs. The
> relevant CAB guidelines are quoted in https://tools.ietf.org/html/draft-friel-
> acme-subdomains-00#appendix-A.
> 
> The authorization object would then explicitly indicate that this is a base 
> domain
> authorization and thus subdomain certs may be issued off this. This is
> conceptually similar to the current "wildcard" flag which indicates that a
> wildcard cert may be issued off the identifier in the object, and would
> definitively differentiate wildcard vs. base domain vs. explicit domain
> authorizations.
> 
> Item #3 from section 7.4.1 Pre-authorization is already called out as a
> substantive change from RFC8555: i.e. the identifier in the authorization 
> object
> may be different from the identifier in the newAuthz object.
> 
> > -Original Message-
> > From: Acme  On Behalf Of Salz, Rich
> > Sent: 26 November 2019 21:53
> > To: acme@ietf.org
> > Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> >
> > WRONG.  My mistake.
> >
> > Please discuss this, especially the subdomains/wildcard issues.  This
> > is *NOT* a call for adoption.  We will take this up in Vancouver, IETF 107.
> >
> > From: Rich Salz <mailto:rs...@akamai.com>
> > Date: Tuesday, November 26, 2019 at 4:51 PM
> > To: "mailto:acme@ietf.org; <mailto:acme@ietf.org>
> > Subject: [Acme] Call for adoption draft-frield-acme-subdomains
> >
> > This email starts a ten-day call for adoption. There was consensus in
> > the room at IETF 106 to adopt this as a working group document. If you
> > disagree with that, or have any other strong feelings, please post to
> > the list before the end of next week.
> > Also discussed was the need for some additional clarity around
> > subdomains and the existing wildcard challenges.
> >
> > Thank you.
> >
> ___
> 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] Call for adoption draft-frield-acme-subdomains

[Owen Friel (ofriel)]

DNS wildcards are mentioned in 3 sections in RFC8555 (in addition to the IANA 
Considerations section):

1. https://tools.ietf.org/html/rfc8555#section-7.1.3 Order Objects:

   Any identifier of type "dns" in a newOrder request MAY have a
   wildcard domain name as its value.  A wildcard domain name consists
   of a single asterisk character followed by a single full stop
   character ("*.") followed by a domain name as defined for use in the
   Subject Alternate Name Extension by [RFC5280].  An authorization
   returned by the server for a wildcard domain name identifier MUST NOT
   include the asterisk and full stop ("*.") prefix in the authorization
   identifier value.  The returned authorization MUST include the
   optional "wildcard" field, with a value of true.

2. https://tools.ietf.org/html/rfc8555#section-7.1.4 Authorization Objects:
 
   If an
   authorization object conveys authorization for the base domain of a
   newOrder DNS identifier containing a wildcard domain name, then the
   optional authorizations "wildcard" field MUST be present with a value
   of true.   

3. https://tools.ietf.org/html/rfc8555#section-7.4.1 Pre-authorization

   Note that because the identifier in a pre-authorization request is
   the exact identifier to be included in the authorization object, pre-
   authorization cannot be used to authorize issuance of certificates
   containing wildcard domain names.

For the subdomains use case, it looks as if it makes sense to define a 
"parentdomain" boolean flag (or "basedomainname" or similar) to be included in 
the authorization object for a domain that authorizes subdomain certs. The 
relevant CAB guidelines are quoted in 
https://tools.ietf.org/html/draft-friel-acme-subdomains-00#appendix-A.

The authorization object would then explicitly indicate that this is a base 
domain authorization and thus subdomain certs may be issued off this. This is 
conceptually similar to the current "wildcard" flag which indicates that a 
wildcard cert may be issued off the identifier in the object, and would 
definitively differentiate wildcard vs. base domain vs. explicit domain 
authorizations.

Item #3 from section 7.4.1 Pre-authorization is already called out as a 
substantive change from RFC8555: i.e. the identifier in the authorization 
object may be different from the identifier in the newAuthz object.

> -Original Message-
> From: Acme  On Behalf Of Salz, Rich
> Sent: 26 November 2019 21:53
> To: acme@ietf.org
> Subject: Re: [Acme] Call for adoption draft-frield-acme-subdomains
> 
> WRONG.  My mistake.
> 
> Please discuss this, especially the subdomains/wildcard issues.  This is 
> *NOT* a
> call for adoption.  We will take this up in Vancouver, IETF 107.
> 
> From: Rich Salz 
> Date: Tuesday, November 26, 2019 at 4:51 PM
> To: "mailto:acme@ietf.org; 
> Subject: [Acme] Call for adoption draft-frield-acme-subdomains
> 
> This email starts a ten-day call for adoption. There was consensus in the 
> room at
> IETF 106 to adopt this as a working group document. If you disagree with that,
> or have any other strong feelings, please post to the list before the end of 
> next
> week.
> Also discussed was the need for some additional clarity around subdomains and
> the existing wildcard challenges.
> 
> Thank you.
> 
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME at IETF 106

[Owen Friel (ofriel)]

Rich,
10 minutes total on these two please:

https://tools.ietf.org/html/draft-friel-acme-subdomains-00
https://tools.ietf.org/html/draft-friel-acme-integrations-02

Cheers,
Owen

-Original Message-
From: Acme  On Behalf Of Salz, Rich
Sent: 25 October 2019 14:02
To: acme@ietf.org
Subject: [Acme] ACME at IETF 106

ACME is meeting at IETF 106 in Singapore next month.

If you want time on the agenda, please post.

We want to finish up some work items, so volunteers might be “solicited.”

We need to figure out next steps, too.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Use cases / trust model for device certs

[Owen Friel (ofriel)]

Hi Rifaat,
Inline.

From: Rifaat Shekh-Yusef 
Sent: 17 April 2019 20:37
To: Richard Barnes 
Cc: IETF ACME ; Owen Friel (ofriel) 
Subject: Re: Use cases / trust model for device certs

Hi Richard,

I was not aware of the ANIMA work before the meeting in Prague, so I will 
definitely look into that in details.

One use case that I have in mind is a way to make sure that a specific device 
can only be used by a specific party.
If you rely on RP to request identities for the device, then any party that has 
a valid ACME account can use any device.
[ofriel] This is one of the use cases that BRSKI enables. Read the sections 
relating to Ownership Tracker.

For example, if party A purchased a device from the vendor, and party B gets a 
hold of that device, then there
is nothing that prevents party B from getting a valid ACME certificate for that 
device.
[ofriel] With strict ownership tracking, BRSKI is flexible enough to prevent 
devices from bootstrapping against a network without proof of ownership.

If instead you reply on a token from the Device Authority, then the CA will 
only issue a certificate to a specific party and specific device.
[ofriel] The Device Authority appears to perform a similar function to the MASA 
audit log function. The Client (i.e. customer.com) can claim devices from the 
DA (via some sales channel/integration API), the DA issues JWTs indicating that 
the device is claimed by a specific Client, and ACME checks that the requesting 
Client matches that in the JWT which the DA has logged. The BRSKI MASA service 
audit logs every single domain that a device has registered against, and does 
not preclude Registrars claiming devices/proving ownership via some sales 
channel integration/API. It appears that this proposal is trying to address 
similar issues as BRSKI.

Regards,
 Rifaat


On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes 
mailto:r...@ipv.sx>> wrote:
Hey Rifaat,

Owen and I were chatting about ACME and device certs this morning, and it 
seemed like it might be useful to rekindle discussion on the topic here on the 
ACME list.

I'd like to push a little more on the trust model here.  Just to establish some 
terminology:

- Device: Uses certificates to authenticate identifiers
- Vendor: Makes the device that will get the end certificate
- Customer: Buys the device from the vendor and operates it
- CA: Validates identifiers and issues certificates
- Relying Party: Uses certificates to verify authentication for identifiers
- Device Identity: MAC address or similar

In the flows Owen and I have been discussing (more based on ANIMA/BRSKI), the 
model is basically broken in two, with the customer in the middle:

1. The customer validates devices' device identity as part of the ANIMA flow, 
based on the customer trusting the vendor, and assigns the device a domain name
2. The customer uses ACME to issue domain name certificates (the CA is unaware 
of the device identity)

That all pretty much just works with BRSKI and ACME as they are today.  But it 
presumes that the RP is authenticating the device by domain name, as is 
prevalent in most uses of TLS today.

In contrast, it seems like your draft presumes that the RP needs to know the 
device identity; it's not satisfied by a domain name alone.  Can you elaborate 
a bit more on what scenarios you have in mind for this?  If all you care about 
is the customer tracking things, then the model above is sufficient; the 
customer can simply assign domain names that encode the device identity however 
it likes.

Thanks,
--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme