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

[Deb Cooley]

Sounds like a good path forward.

Deb Cooley
deco...@nsa.gov

On Fri, Dec 10, 2021 at 9:04 AM Daniel Migault  wrote:

> I also prefer 8499 terminology.
> Yours,
> Daniel
>
> On Fri, Dec 10, 2021 at 4:40 AM Owen Friel (ofriel)  40cisco@dmarc.ietf.org> wrote:
>
>> 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
>>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> 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 RFC8499 vs. CA/B terminology

[Daniel Migault]

I also prefer 8499 terminology.
Yours,
Daniel

On Fri, Dec 10, 2021 at 4:40 AM Owen Friel (ofriel)  wrote:

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


-- 
Daniel Migault
Ericsson
___
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] acme subdomains open items

[Michael Richardson]

Owen Friel (ofriel)  wrote:
> The draft as is does not preclude http-01 challenges, but I agree that
> the dns-01 challenge is more applicable.

I'm gonna pick on this part only.

An http-01 challenge shows that the client controls the web resource that is 
named.
It does nothing at all about control of the DNS.   We don't know anything
about the client's control over the DNS, about any other names in the DNS.

When we do a dns-01 challenge for a specific name, we mostly prove exactly
the same thing: that the client can direct traffic to that name to a place
that it could potentially control.
{Well, the presence of CNAMEs (and DNAMEs) blurs this a bit}

If we do a dns-01 challenge for foo.example, then there is an assumption
in the challenge that we control the DNS for foo.example, and therefore
could put any.thing.foo.example into the DNS and control that.

Really, it doesn't quite prove that, it proves that we can update
_acme-challenge.foo.example, and that could be the only thing we
can actually control.

We might want to think about whether the authorization phase for
a subdomain challenge might need to show control over more bits than just that.
For instance, we could demand proof of 
_acme-challenge.ran.dom.token.foo.example.
Perhaps even that we can insert A or  records at that spot too.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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,

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Tue, Dec 8, 2020 at 8:14 PM Michael Richardson  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, followed by an order for
> 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" / "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-acme-subdomains-03#section-5.4 ,
example 1.


> > In the pre-auth flow, the client affirmatively requests
> "lex.example" (In
> > the illustration here, "example.org"), in order to authorize
> > "so.me.comp.lex.example" (in the illustration here, "sub.example.org
> ").
> > That is, the client explicitly declares their naming scope.
>
> > However, in the pre-auth flow, you have to know that the client will
> want
> > to be able to /newOrder for "sub.example.org" (as Step 2 in the
> > illustration), since you shouldn't return http-01 authorizations in
> Step 1
> > for this case.
>
> how are http-01 authorizations involved?
> The client asks for dns-01 authorizations.


Can you point me to the text in the draft you're using to support this
statement? As far as I can tell, there's nothing in the draft to indicate
that the client asks for dns-01 authorizations. Further, there's nothing as
far as I can tell that prohibits, restricts, or even allows a CA to
indicate that an http-01 authorization would not be allowed.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Michael Richardson]

Ryan Sleevi  wrote:
>> Ryan Sleevi  wrote:
>> >> The client has control over lex.example, but and can prove it with
>> dns-01
>> >> TXT
>> >> record placed at _acme-challenge.lex.example.  Why does it matter
>> whether
>> >> it
>> >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
>> >> or an.other.comp.lex.example??
>>
>>
>> > The mistake you’ve made here is assuming the client has control over
>> > lex.example, and thus all subdomains. The point of all of this is
>> that is
>> > an unrealistic assumption: the client may only have control over the
>> DNS
>> > zone at so.me.comp.lex.example or they might have control at the
>> > me.comp.lex.example, but no control at comp.lex.example.
>>
>> I don't understand.
>> If the client doesn't control lex.example, then why would it expect to 
get
>> any kind of control of that?
>> Same as without subdomains.
>>

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

>> 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, followed by an order for 
sub.example.com

> In the pre-auth flow, the client affirmatively requests "lex.example" (In
> the illustration here, "example.org"), in order to authorize
> "so.me.comp.lex.example" (in the illustration here, "sub.example.org").
> That is, the client explicitly declares their naming scope.

> However, in the pre-auth flow, you have to know that the client will want
> to be able to /newOrder for "sub.example.org" (as Step 2 in the
> illustration), since you shouldn't return http-01 authorizations in Step 1
> for this case.

how are http-01 authorizations involved?
The client asks for dns-01 authorizations.

> The significant majority of CAs, for the majority of certificates issued 
by
> these CAs, totally rely upon authorizing "lex.example" in order to issue
> certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or
> other). So I'm not sure what you mean by "does not demonstrate
> control".

I think that I have typoed above! :-)

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



signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Tue, Dec 8, 2020 at 4:33 PM Michael Richardson 
wrote:

>
> Ryan Sleevi  wrote:
> >> The client has control over lex.example, but and can prove it with
> dns-01
> >> TXT
> >> record placed at _acme-challenge.lex.example.  Why does it matter
> whether
> >> it
> >> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
> >> or an.other.comp.lex.example??
>
>
> > The mistake you’ve made here is assuming the client has control over
> > lex.example, and thus all subdomains. The point of all of this is
> that is
> > an unrealistic assumption: the client may only have control over the
> DNS
> > zone at so.me.comp.lex.example or they might have control at the
> > me.comp.lex.example, but no control at comp.lex.example.
>
> I don't understand.
> If the client doesn't control lex.example, then why would it expect to get
> any kind of control of that?
> Same as without subdomains.
>

Alas, I'm equally at a loss to understand what you're asking here, as I
can't make much sense of your question?


> > The existing approach with ACME assumes and expects that validation
> will be
> > done at the FQDN (this is an oversimplification, but the nuance here
> isn’t
> > as important).
>
> Yes, the FULLY-QUALIFIED.  Not the public name.
> dns-01 works just fine today for so.me.comp.lex.example.
>
> 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 ) ?

In the pre-auth flow, the client affirmatively requests "lex.example" (In
the illustration here, "example.org"), in order to authorize
"so.me.comp.lex.example" (in the illustration here, "sub.example.org").
That is, the client explicitly declares their naming scope.

However, in the pre-auth flow, you have to know that the client will want
to be able to /newOrder for "sub.example.org" (as Step 2 in the
illustration), since you shouldn't return http-01 authorizations in Step 1
for this case.

For authorizations created in response to a request (i.e. the non-preauth
flow, which this draft explicitly states is allowed in 5.1), the CA has to
make a determination about what authorizations to issue, and the state to
track all of those pending authorizations created, which gets us back to
the discussion.

The significant majority of CAs, for the majority of certificates issued by
these CAs, totally rely upon authorizing "lex.example" in order to issue
certificates for "so.me.comp.lex.example" (whether using DNS-01, email, or
other). So I'm not sure what you mean by "does not demonstrate control".

Hopefully, this reply helps clarify, but if you still aren't sure, I'm
hoping you could be clearer on the uncertainty and I'll do my best to
rephrase.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Michael Richardson]

Ryan Sleevi  wrote:
>> The client has control over lex.example, but and can prove it with dns-01
>> TXT
>> record placed at _acme-challenge.lex.example.  Why does it matter whether
>> it
>> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
>> or an.other.comp.lex.example??


> The mistake you’ve made here is assuming the client has control over
> lex.example, and thus all subdomains. The point of all of this is that is
> an unrealistic assumption: the client may only have control over the DNS
> zone at so.me.comp.lex.example or they might have control at the
> me.comp.lex.example, but no control at comp.lex.example.

I don't understand.
If the client doesn't control lex.example, then why would it expect to get
any kind of control of that?
Same as without subdomains.

> The existing approach with ACME assumes and expects that validation will 
be
> done at the FQDN (this is an oversimplification, but the nuance here isn’t
> as important).

Yes, the FULLY-QUALIFIED.  Not the public name.
dns-01 works just fine today for so.me.comp.lex.example.

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Mon, Dec 7, 2020 at 8:30 AM Michael Richardson 
wrote:

>
> Ryan, I'm not really following this conversation.
> Probably my mental model of dns-01 challenges is lacking.
> The word "window" does not appear in RFC8555 or acme-subdomains, so that's
> your word, I think.
>
> Ryan Sleevi  wrote:
> > Further, if we assume that say there are ten domain labels, but the
> server
> > is only willing to maintain state for five (as a window), then it’s
> not
> > clear how the client can request the server sends the first five
> rather
> > than the last five. Having the client advertise its capabilities
> let’s the
> > client choose the window, and if the server rejects all of them, the
> client
> > at least can try again with a different window (e.g. the last five
> > labels).
>
> I don't really understand this at all.
> I think that we are discussing so.me.comp.lex.example.
>
> The client has control over lex.example, but and can prove it with dns-01
> TXT
> record placed at _acme-challenge.lex.example.  Why does it matter whether
> it
> is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
> or an.other.comp.lex.example??


The mistake you’ve made here is assuming the client has control over
lex.example, and thus all subdomains. The point of all of this is that is
an unrealistic assumption: the client may only have control over the DNS
zone at so.me.comp.lex.example or they might have control at the
me.comp.lex.example, but no control at comp.lex.example.

The existing approach with ACME assumes and expects that validation will be
done at the FQDN (this is an oversimplification, but the nuance here isn’t
as important). The point is that if the server decides to challenge
lex.example or comp.lex.example, it will fail for this client, so that’s
why we need some form of either/or or both/and of multiple challenges and a
client indicated set of capabilities.

The window is simply which labels you select: the example you chose has
five labels, so whether we select the “first” two domains (“so” and “me”
working from most to least specific) or the “middle” two (“comp” and “lex”)
matters. Similarly, it’s valid to issue a challenge for “example” in all of
its glory: this comes up with ICANN Spec-9/Spec-13 gTLDs, and so it’s
useful to allow the client to say “no, really, validate the *entire*
namespace”. So even if the server challenged “lex.example” that could be
the wrong level.

One thing that just occured to me is whether or not there is any value in
> the
> dns-01 challenge remaining in the DNS after the authorization.
> What I'm thinking is that the CA could offload some of it's state for the
> client to store for it.


I don’t think it’s reasonable at all to make changes like that. It would
either limit issuance of multiple independent certificates within a time
period (collision on _acme-validation) or would encourage the use of random
values in the labels.


>
> > That’s why my slight preference was to have the client advertise.
> > Processing after validation seemed preferable to processing prior to
> > validation, and it also seemed useful to let the client advertise
> > capabilities directly to let the server reduce any stored state.
>
> > However, I
> > can equally imagine an asinine implementation of client-advertise
> that
> > requests a cert for “www.example.com” but let’s the client set the
> ADN as “
> > example.net” and, post-validation of example.net, fails to check
> that “
> > example.net” matches “example.com”. Or does something equally silly
> like
> > allowing “prefix.example” to authorize
> “not-actually-a-prefix.example”.
>
> I can't see how any of these things are anything other than serious bugs.


I didn’t say they weren’t. But just like C is a fundamentally insecure
language that no one ethically responsible or security conscious should
choose as a first choice for new code, the ergonomics of the decisions here
are worth pointing out. There are Top 10 CAs that are misissuing
certificates because they found it “confusing” to locate requirements [1]
or manually implement the CAA lookup algorithm by hand for every request
[2]. My intent in pointing these out is to acknowledge that we have to
contemplate the worst possible implementations, and view the risks through
that lens, when thinking about risks or tradeoff. We simply can’t assume a
competent implementation, unfortunately.

[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=1662807
[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1651026#c12

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

Re: [Acme] acme subdomains open items

[Michael Richardson]

Ryan, I'm not really following this conversation.
Probably my mental model of dns-01 challenges is lacking.
The word "window" does not appear in RFC8555 or acme-subdomains, so that's
your word, I think.

Ryan Sleevi  wrote:
> Further, if we assume that say there are ten domain labels, but the server
> is only willing to maintain state for five (as a window), then it’s not
> clear how the client can request the server sends the first five rather
> than the last five. Having the client advertise its capabilities let’s the
> client choose the window, and if the server rejects all of them, the 
client
> at least can try again with a different window (e.g. the last five
> labels).

I don't really understand this at all.
I think that we are discussing so.me.comp.lex.example.

The client has control over lex.example, but and can prove it with dns-01 TXT
record placed at _acme-challenge.lex.example.  Why does it matter whether it
is so.me.comp.lex.example or ve.ry.so.me.comp.lex.example.
or an.other.comp.lex.example??

One thing that just occured to me is whether or not there is any value in the
dns-01 challenge remaining in the DNS after the authorization.
What I'm thinking is that the CA could offload some of it's state for the
client to store for it.

> That’s why my slight preference was to have the client advertise.
> Processing after validation seemed preferable to processing prior to
> validation, and it also seemed useful to let the client advertise
> capabilities directly to let the server reduce any stored state.

> However, I
> can equally imagine an asinine implementation of client-advertise that
> requests a cert for “www.example.com” but let’s the client set the ADN as 
“
> example.net” and, post-validation of example.net, fails to check that “
> example.net” matches “example.com”. Or does something equally silly like
> allowing “prefix.example” to authorize “not-actually-a-prefix.example”.

I can't see how any of these things are anything other than serious bugs.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

On Sun, Dec 6, 2020 at 9:32 PM Owen Friel (ofriel)  wrote:

> [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.
>
🤷‍♂️

If there is a limit to the number of challenges, it seems it benefits from
the client choosing/advertising. Until the challenge is complete, the
server has to maintain state for (effectively) an unauthorized user, while
in the client-advertise scenario, there’s no server state other than what
the server chooses to use.

Further, if we assume that say there are ten domain labels, but the server
is only willing to maintain state for five (as a window), then it’s not
clear how the client can request the server sends the first five rather
than the last five. Having the client advertise its capabilities let’s the
client choose the window, and if the server rejects all of them, the client
at least can try again with a different window (e.g. the last five labels).

I don’t know how compelling this is, but my assumption here is that because
we’re discussing effectively DNS-01 challenges, the client is limited in
its abilities, and so the client should indicate it’s capabilities, and
minimize server state.

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, it doesn't benefit the client at all if the
> server chooses to also allow 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?
>
I mean, right now there’s no rules on which party selects the Authorization
Domain Name, when an ADN is allowed. The CA still has to validate the ADN
against the rules.

Having the client indicate minimizes CA processing before validation; each
of the advertised ADNs can really be treated as independent FQDNs (that is,
largely opaquely), and only after validation of the challenge does the CA
do any processing on the domain label, to ensure it’s an ADN for the
(originally requested) FQDN.

That’s why my slight preference was to have the client advertise.
Processing after validation seemed preferable to processing prior to
validation, and it also seemed useful to let the client advertise
capabilities directly to let the server reduce any stored state. However, I
can equally imagine an asinine implementation of client-advertise that
requests a cert for “www.example.com” but let’s the client set the ADN as “
example.net” and, post-validation of example.net, fails to check that “
example.net” matches “example.com”. Or does something equally silly like
allowing “prefix.example” to authorize “not-actually-a-prefix.example”.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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 cha

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

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 and descendents, but the
server/CA chooses to challenge against 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.

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, it doesn't benefit the client at all if the
server chooses to also allow 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.

Does that accurately capture things?

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel)  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  *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) <
> 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
> 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] 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

Re: [Acme] acme subdomains open items

[Felipe Gasper]

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

Re: [Acme] ACME subdomains

[Ryan Sleevi]

On Thu, Sep 3, 2020 at 9:47 AM Salz, Rich  wrote:

>
>- 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.
>
>
>
> Thanks for the changes.  I am also confused by example.com and example.org.
> Someone want to grab acmeserver.org and donate it?
>

That still seems problematic; registrations are fixed lifetimes.

Just use RFC 6761 https://tools.ietf.org/html/rfc6761#section-6.5

Specifically, acmeserver.example

As James points out, the use isn't really consistent with RFC 8555 in the
examples provided, and that's why it bears clarifying. However, my specific
concern was this statement:

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

Which is the problematic area. I believe this is "trying" to say that the
options are:

foo.bar.example.org
bar.example.org
example.org

And all permutations/combinations of those.

Whether those go to acmeserver.com or acmeserver.example is irrelevant; the
point of clarification is what challenges can be used for the identifier.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Salz, Rich]

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

Thanks for the changes.  I am also confused by example.com and example.org.  
Someone want to grab acmeserver.org and donate it?
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Manger, James]

>> There’s a lot of mixing of example.org and 
>> example.com here, in ways I’m having trouble making 
>> sense of. I just wanted to confirm those were typos, since we have recently 
>> seen some confusion around this space.

> I followed the patterns used in RFC8555 which consistently uses example.com 
> as the ACME server base domain and example.org as the client certificate 
> identifier base domain, but yes Ryan I did find this a source of confusion 
> too when reading ACME.
>
> For clarity, I replaced all example.com with acmeserver.com, and left all the 
> client identifiers as example.org.

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

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

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

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

Re: [Acme] 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://exa

Re: [Acme] ACME subdomains

[Ryan Sleevi]

There’s a lot of mixing of example.org and example.com here, in ways I’m
having trouble making sense of. I just wanted to confirm those were typos,
since we have recently seen some confusion around this space.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] 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<http://foo.bar.example.com> and 
example.org<http://example.com> 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<http://foo.bar.example.com> the protocol should also allow 
server choice of offering challenges for (1) both 
foo.bar.example.org<http://foo.bar.example.com> and  
example.com<http://example.com> (2) only the requested identifier 
foo.bar.example.com<http://foo.bar.example.com> or (3) only the parent domain 
example.com<http://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

Re: [Acme] ACME subdomains

[Jacob Hoffman-Andrews]

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
fulfil *one
of* the Challenges.

To take advantage of this, you would need to define a new challenge type
that expresses validating a parent domain. For instance "dns-parent-01." It
would contain the name of the parent domain as a field.

If a server has the policy that validating control of either
foo.bar.example.com or example.com is sufficient to issue for
foo.bar.example.com, it would respond to newOrder requests for
foo.bar.example.com by creating an Order with one Authorization (for
foo.bar.example.com), and that Order would have two Challenges: "dns-01"
and "dns-parent-01" (with a parent domain of "example.com"). The client
could then choose which challenge to attempt.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME subdomains

[Felipe Gasper]

As regards https://tools.ietf.org/html/draft-friel-acme-subdomains-02 ...

Is the idea that the client will, if requesting authz on sub.example.com, 
*only* be able to do authz against the parent domain (example.com)?

It would seem advantageous—from the client’s perspective, anyway—to allow a 
workflow where the client can do authz against one or the other. For longer 
subdomains, e.g., foo.bar.example.com, likewise, ideally the domain itself or 
either parent domain would work.

Was this considered and deemed infeasible?

Thank you!

-Felipe Gasper___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme