Re: [Acme] WGLC for ACME DTN Node ID

[Brian Sipos]

Yoav,
This draft has also received a DTN WG review, and I have a new revision in 
progress. This new revision will also address a difference in behavior from the 
email S/MIME document that was brought up by Ryan Sleevi and explained by Ben 
Kaduk. That change does affect the data content by adding the challenge-unique 
token into the bundles with an explanation about its use.

Once that new revision is posted I believe all comments to-date have been 
addressed.

Thanks to Russ Housley and Ryan Sleevi for the reviews. Thanks to the authors 
for the revised version.

This is not a great showing in terms of quantity of review, but the quality is 
sufficient. I will write the shepherd write-up and submit.

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

Re: [Acme] WGLC for ACME DTN Node ID

[Yoav Nir]

Thanks to Russ Housley and Ryan Sleevi for the reviews. Thanks to the authors 
for the revised version.

This is not a great showing in terms of quantity of review, but the quality is 
sufficient. I will write the shepherd write-up and submit.

Yoav


> On 31 Mar 2021, at 22:50, Yoav Nir  wrote:
> 
> Hi.
> 
> This starts a WGLC for the subject draft entitled “Automated Certificate 
> Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID 
> Validation Extension”. The call will end at EOD Monday, April 19th, 2001.
> 
> The document has been with the WG since last August, and has received too 
> little review. ACME participants are encouraged to read and review, so that 
> we can make changes if such are needed, and progress the document for 
> publication.
> 
> Linsk:
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ 
> 
> Plain text: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.txt 
> 
> HTML: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.html 
> 
> PDF: https://tools.ietf.org/pdf/draft-ietf-acme-dtnnodeid-01.pdf 
> 
> 
> Thanks in advance
> 
> Yoav

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

Re: [Acme] WGLC for ACME DTN Node ID

[Brian Sipos]

Ben,
Thank you for the feedback. Given that this document is earlier in the stream,
we still have opportunities to improve its encoded structure or properties.

> My recollection from the email+S/MIME document (which is to be published as
> an RFC imminently) is that the token-part2 was playing the role of a way to
> bind the authorization to the specific ACME order.  I also wanted to have a
> unique identifier that binds the challenge email to the ACME order, and
> that aspect changed a fair amount during the review process, but IIRC we
> ended up with a bit of a fudge where the ACME exchange includes the "From:"
> header field for the challenge email, and that could be unique to the order
> but isn't required to be.

Unfortunately in the case of bundles the source must be a fixed Node ID so we
don't have the option of a similar challenge-specific address. Is there any
value in having the ACME server use a unique-but-constant-per-order, and shown-
to-the-client,  value?
Currently the distinguishing characteristic of  is that it _only_
comes via bundle so knowing it means that you've seen the challenge bundle
(which an on-path attacker can do equally as well) but this avoids the
possibility of a response bundle being able to be produced before the challenge
bundle is even received.

Any value in a three-part nonce token (as recommended earlier, the names can be
changed to reflect the use) as defined here?
* Part 1 arrives only via challenge bundle, unique to that bundle (not just the
order).
* Part 2 arrives only via ACME HTTPS, unique to the order.
* Part 3 is indicated in both the ACME HTTPS and the challenge bundle and
provides a unique filter in the tuple of (Source Node ID, token-part3). This
would be similar to the randomized email address.

> That said, I have a (very vague, for which I apologize) recollection that
> earlier in the evolution of the TCPCLv4 document there was an option where
> certain TLS certificates would have an indication that the CA asserts that
> the holder of the private key is trusted to provide its Node ID in the
> TCPCL SESS_INIT even if the Node ID itself is not included in the
> certificate.  If that indication from the CA was the id-kp-bundleSecurity
> EKU, then requiring ACME to always include that EKU in the issued
> certificate would have surprising semantics.  That said, it looks like in
> at least the latest version of the TCPCLv4 draft, id-kp-bundleSecurity does
> not play that role, so there is no issue.  I'm only mentioning it now
> because the potential scope of consequences is so large, and I am sure that
> you will do the right thing (assuming I have been able to describe the
> situation I'm worried about clearly enough).

You are correct in your conclusion. The last recommended security policy (sent
to the RFC editor) is to require a proper Node ID SAN and ignore any other SANs
present. There is no recommended policy about implying the ownership/validity of
a Node ID.



smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WGLC for ACME DTN Node ID

[Benjamin Kaduk]

Hi Brian,

On Fri, Apr 16, 2021 at 09:28:14PM +, Brian Sipos wrote:
> Ryan,
> Thank you for the review comments. My responses are inline with prefix 
> "[BS1]".
> 
> > With admittedly very little context for this specific use case, a few
> > things stand out:
> 
> > Section 2 states "Any identifier of type "uri" in a newOrder request MUST
> > NOT have a wildcard ("*") character in its value." This seems to
> > unnecessarily constrain the character space. While I suspect the purpose
> > was to exclude wildcards from the authority-part of a generic URI/specific
> > to a particular scheme, it ends up defining the semantics for all URIs.
> > Given URI's well-known ambiguity in representation across implementations,
> > and the ability to do things like include pct-encoded characters in
> > reg-name (it's only a must requirement, not a MUST requirement), this both
> > seems unnecessarily restrictive and fails to achieve the goal, especially
> > since such decoding to prevent this scenario, at the ACME server, is SHALL
> > NOT'd by the same section.
> 
> > If the goal is to prevent wildcards that imply certain semantics for a
> > given scheme (e.g. "dtn:"), then that probably deserves a separate section
> > detailing the requirements for the extraction and validation of the Node ID
> > from the URI, and can define any restrictions on the character namespace.
> 
> > Alternatively, since identifier labels are cheap, making the identifier
> > type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
> > to impose requirements specific to DTN URIs without risk of overfitting for
> > other types of URIs.
> 
> [BS1] This was a copy-paste statement from ietf-acme-email-smime, and I agree
> that this imposes unnecessary restrictions on the "uri" type. I will add
> clarification that the URI must conform to any scheme-specific syntax.
> It is actually the case that both "dtn" and "ipn" URI specifications [1]
> restrict a Node ID to have a specific set of allowed characters (similar to
> restrictions on DNS names). So a Node ID is a more restricted form of a 
> generic
> "dtn" or "ipn" URI, and I will add clarifying statements outside of the "uri"
> type definition.
> 
> > Section 3 describes how this cribs from ietf-acme-email-smime, but provides
> > no clear explanation as to the _why_, only the _how_. For example, the
> > statement "requires that the ACME client have access to the results of each
> > channel to get both parts of the token" describes a result, but does not
> > describe the motivation that necessitates such a design. This seems like it
> > might be relevant for security considerations, but documenting the
> > rationale for this design seems relevant to successfully and securely
> > implementing/extending this spec. This becomes equally relevant when
> > attempting to understand why the choice of 128-bits of entropy within
> > Section 3.1, since it seems the choice in the size of the parts is equally
> > related to this undocumented threat.
> 
> [BS1] Yes, there is a missing "Threat: Bundle Replay" which applies to both
> Challenge and Response bundles in similar ways. The "token-part2" is the 
> unique
> value for the whole ACME challenge and the "token-part1" is the unique value 
> for
> each bundle exchange. Having -part1 proves recepton of the Challenge Bundle 
> (but
> on-path attackers will also see this) and having -part2 proves access as the
> ACME client (which will be hidden from OPAs).
> Thinking through the logic a bit, I don't know if there is much value in 
> -part2
> since:
>  1. It's not part of the challenge bundle itself, so can't be used for 
> on-path-
> attack filtering.
>  2. It's used for the Key Authorization value alongside the client key
> thumbprint, so there already is data binding the response to that ACME client.
>  3. The 
> Maybe Alexey (CC'd on this message) has some insight about the token splitting
> for a messaging challenge (i.e. not a HTTP/TLS/DNS request-response exchange).

My recollection from the email+S/MIME document (which is to be published as
an RFC imminently) is that the token-part2 was playing the role of a way to
bind the authorization to the specific ACME order.  I also wanted to have a
unique identifier that binds the challenge email to the ACME order, and
that aspect changed a fair amount during the review process, but IIRC we
ended up with a bit of a fudge where the ACME exchange includes the "From:"
header field for the challenge email, and that could be unique to the order
but isn't required to be.

> > In Section 3.1, I'm probably just not familiar enough with the underlying
> > specs, but as far as I could tell, it's not clear why Step 3 the ACME
> > client needs to indicate the  to the BP agent, versus just the
> > source. The source Node ID is clear, at least, but it seems like, at best,
> >  might just be serving as a "request ID" of sorts (judging by
> > 3.4)
> 
> > The reason I highlight this is because I think it diverges 

Re: [Acme] WGLC for ACME DTN Node ID

[Brian Sipos]

Ryan,
Thank you for the review comments. My responses are inline with prefix "[BS1]".

> With admittedly very little context for this specific use case, a few
> things stand out:

> Section 2 states "Any identifier of type "uri" in a newOrder request MUST
> NOT have a wildcard ("*") character in its value." This seems to
> unnecessarily constrain the character space. While I suspect the purpose
> was to exclude wildcards from the authority-part of a generic URI/specific
> to a particular scheme, it ends up defining the semantics for all URIs.
> Given URI's well-known ambiguity in representation across implementations,
> and the ability to do things like include pct-encoded characters in
> reg-name (it's only a must requirement, not a MUST requirement), this both
> seems unnecessarily restrictive and fails to achieve the goal, especially
> since such decoding to prevent this scenario, at the ACME server, is SHALL
> NOT'd by the same section.

> If the goal is to prevent wildcards that imply certain semantics for a
> given scheme (e.g. "dtn:"), then that probably deserves a separate section
> detailing the requirements for the extraction and validation of the Node ID
> from the URI, and can define any restrictions on the character namespace.

> Alternatively, since identifier labels are cheap, making the identifier
> type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
> to impose requirements specific to DTN URIs without risk of overfitting for
> other types of URIs.

[BS1] This was a copy-paste statement from ietf-acme-email-smime, and I agree
that this imposes unnecessary restrictions on the "uri" type. I will add
clarification that the URI must conform to any scheme-specific syntax.
It is actually the case that both "dtn" and "ipn" URI specifications [1]
restrict a Node ID to have a specific set of allowed characters (similar to
restrictions on DNS names). So a Node ID is a more restricted form of a generic
"dtn" or "ipn" URI, and I will add clarifying statements outside of the "uri"
type definition.

> Section 3 describes how this cribs from ietf-acme-email-smime, but provides
> no clear explanation as to the _why_, only the _how_. For example, the
> statement "requires that the ACME client have access to the results of each
> channel to get both parts of the token" describes a result, but does not
> describe the motivation that necessitates such a design. This seems like it
> might be relevant for security considerations, but documenting the
> rationale for this design seems relevant to successfully and securely
> implementing/extending this spec. This becomes equally relevant when
> attempting to understand why the choice of 128-bits of entropy within
> Section 3.1, since it seems the choice in the size of the parts is equally
> related to this undocumented threat.

[BS1] Yes, there is a missing "Threat: Bundle Replay" which applies to both
Challenge and Response bundles in similar ways. The "token-part2" is the unique
value for the whole ACME challenge and the "token-part1" is the unique value for
each bundle exchange. Having -part1 proves recepton of the Challenge Bundle (but
on-path attackers will also see this) and having -part2 proves access as the
ACME client (which will be hidden from OPAs).
Thinking through the logic a bit, I don't know if there is much value in -part2
since:
 1. It's not part of the challenge bundle itself, so can't be used for on-path-
attack filtering.
 2. It's used for the Key Authorization value alongside the client key
thumbprint, so there already is data binding the response to that ACME client.
 3. The 
Maybe Alexey (CC'd on this message) has some insight about the token splitting
for a messaging challenge (i.e. not a HTTP/TLS/DNS request-response exchange).

> In Section 3.1, I'm probably just not familiar enough with the underlying
> specs, but as far as I could tell, it's not clear why Step 3 the ACME
> client needs to indicate the  to the BP agent, versus just the
> source. The source Node ID is clear, at least, but it seems like, at best,
>  might just be serving as a "request ID" of sorts (judging by
> 3.4)

> The reason I highlight this is because I think it diverges from some of the
> classic assumptions about ACME and challenge design, because it seems to
> suggest that  may transit the network in the clear and/or be
> held by multiple parties, which is a very different model than the history
> of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
> Token (which not simply a random value, but uniquely bound to the original
> request and is single-use). I *think* this might just be a terminology
> issue here, but would it make sense to name these according to their
> structural purpose, rather than just "token-part1" / "token-part2"?

[BS1] I agree that more purposeful names could help; the current ones were chose
only to follow in the steps of ietf-acme-email-smime draft.
The purpose of "token-part2" is in fact to be 

Re: [Acme] WGLC for ACME DTN Node ID

[Russ Housley]

These changes resolve my concerns.

Russ

> On Apr 9, 2021, at 5:40 PM, Brian Sipos  wrote:
> 
> Russ,
> Thank you for the review comments. My responses are inline with prefix 
> "[BS1]".
> 
>> I think that this document is almost ready.  I have a few comments.
> 
>> MAJOR:
> 
>> Section 4 points to Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]; but that 
>> profile does not require the certificate to
> include an EKU of id-kp-bundleSecurity.  When this document is used to verify 
> control over the DTN Node ID, I think the
> issued certificate MUST include an EKU of id-kp-bundleSecurity.  If other 
> means are used to validate other identities,
> then other EKU values might be included as well.
> 
> [BS1] This seems reasonable to require. I suppose the "email-reply-00" 
> document [1] just leaves out any discussion of
> EKU because the preexisting S/MIME documents define a more concrete 
> certificate profile and there is a lot of momentum
> behind S/MIME implementation. I'm going to add statements about the EKU in 
> the CSR and the issued certificate.
> 
>> Section 4.2 is talking about S/MIME certificates.  I think there is a 
>> cut-and-paste error here.
> 
> [BS1] Yes, these statements should replace "S/MIME" with "bundle security".
> 
>> MINOR:
> 
>> Section 3.1 says:  "The only over-the-wire data required by ACME for a 
>> Challenge Bundle is a nonce token ...".  This
> is the first time that "nonce" appears in the document.  Please reword.
> 
> [BS1] I removed this statement and replaced it with a statement about the 
> token-part2 scope:
> The  value included in this object is fixed for the entire 
> challenge, and may correspond with multiple
> separate  values when multiple Challenge Bundles are sent for a 
> single validation.
> 
>> Section 3.3 and 3.4: in the beginning of the section, please add a pointer 
>> to the document that defines these
> parameters.  I think it is draft-ietf-dtn-bpbis.
> 
> [BS1] That is the correct reference. I am adding a statement at the top of 
> each section.
> 
>> Section 6.1: please provide a reference for "BPSEC key material", and please 
>> spell out "BCB".
> 
> [BS1] I removed this speculative text and replaced it with:
> It is possible for intermediate BP nodes to encapsulate-and-encrypt Challenge 
> and/or Response Bundles while they
> traverse untrusted networks, but that is a DTN configuration matter outside 
> of the scope of this document.
> 
>> NITS:
> 
>> Section 1: please spell out BP on first use.
>> Section 2: s/wildcard ("*") character/wildcard character ("*")/
>> Section 6.2:  please spell out "BIB".
> 
> [BS1] I am correcting all of these typos.
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-14
> 
> ___
> 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] WGLC for ACME DTN Node ID

[Brian Sipos]

Russ,
Thank you for the review comments. My responses are inline with prefix "[BS1]".

> I think that this document is almost ready.  I have a few comments.

> MAJOR:

> Section 4 points to Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]; but that profile 
> does not require the certificate to
include an EKU of id-kp-bundleSecurity.  When this document is used to verify 
control over the DTN Node ID, I think the
issued certificate MUST include an EKU of id-kp-bundleSecurity.  If other means 
are used to validate other identities,
then other EKU values might be included as well.

[BS1] This seems reasonable to require. I suppose the "email-reply-00" document 
[1] just leaves out any discussion of
EKU because the preexisting S/MIME documents define a more concrete certificate 
profile and there is a lot of momentum
behind S/MIME implementation. I'm going to add statements about the EKU in the 
CSR and the issued certificate.

> Section 4.2 is talking about S/MIME certificates.  I think there is a 
> cut-and-paste error here.

[BS1] Yes, these statements should replace "S/MIME" with "bundle security".

> MINOR:

> Section 3.1 says:  "The only over-the-wire data required by ACME for a 
> Challenge Bundle is a nonce token ...".  This
is the first time that "nonce" appears in the document.  Please reword.

[BS1] I removed this statement and replaced it with a statement about the 
token-part2 scope:
 The  value included in this object is fixed for the entire 
challenge, and may correspond with multiple
separate  values when multiple Challenge Bundles are sent for a 
single validation.

> Section 3.3 and 3.4: in the beginning of the section, please add a pointer to 
> the document that defines these
parameters.  I think it is draft-ietf-dtn-bpbis.

[BS1] That is the correct reference. I am adding a statement at the top of each 
section.

> Section 6.1: please provide a reference for "BPSEC key material", and please 
> spell out "BCB".

[BS1] I removed this speculative text and replaced it with:
It is possible for intermediate BP nodes to encapsulate-and-encrypt Challenge 
and/or Response Bundles while they
traverse untrusted networks, but that is a DTN configuration matter outside of 
the scope of this document.

> NITS:

> Section 1: please spell out BP on first use.
> Section 2: s/wildcard ("*") character/wildcard character ("*")/
> Section 6.2:  please spell out "BIB".

[BS1] I am correcting all of these typos.


[1] https://tools.ietf.org/html/draft-ietf-acme-email-smime-14



smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WGLC for ACME DTN Node ID

[Ryan Sleevi]

With admittedly very little context for this specific use case, a few
things stand out:

Section 2 states "Any identifier of type "uri" in a newOrder request MUST
NOT have a wildcard ("*") character in its value." This seems to
unnecessarily constrain the character space. While I suspect the purpose
was to exclude wildcards from the authority-part of a generic URI/specific
to a particular scheme, it ends up defining the semantics for all URIs.
Given URI's well-known ambiguity in representation across implementations,
and the ability to do things like include pct-encoded characters in
reg-name (it's only a must requirement, not a MUST requirement), this both
seems unnecessarily restrictive and fails to achieve the goal, especially
since such decoding to prevent this scenario, at the ACME server, is SHALL
NOT'd by the same section.

If the goal is to prevent wildcards that imply certain semantics for a
given scheme (e.g. "dtn:"), then that probably deserves a separate section
detailing the requirements for the extraction and validation of the Node ID
from the URI, and can define any restrictions on the character namespace.

Alternatively, since identifier labels are cheap, making the identifier
type a dtn-uri (rather than the acknowledge-generic URI) seems like a way
to impose requirements specific to DTN URIs without risk of overfitting for
other types of URIs.

Section 3 describes how this cribs from ietf-acme-email-smime, but provides
no clear explanation as to the _why_, only the _how_. For example, the
statement "requires that the ACME client have access to the results of each
channel to get both parts of the token" describes a result, but does not
describe the motivation that necessitates such a design. This seems like it
might be relevant for security considerations, but documenting the
rationale for this design seems relevant to successfully and securely
implementing/extending this spec. This becomes equally relevant when
attempting to understand why the choice of 128-bits of entropy within
Section 3.1, since it seems the choice in the size of the parts is equally
related to this undocumented threat.

In Section 3.1, I'm probably just not familiar enough with the underlying
specs, but as far as I could tell, it's not clear why Step 3 the ACME
client needs to indicate the  to the BP agent, versus just the
source. The source Node ID is clear, at least, but it seems like, at best,
 might just be serving as a "request ID" of sorts (judging by
3.4)

The reason I highlight this is because I think it diverges from some of the
classic assumptions about ACME and challenge design, because it seems to
suggest that  may transit the network in the clear and/or be
held by multiple parties, which is a very different model than the history
of ACME's DNS/TLS challenges being tied to the CA/Browser Forum's Request
Token (which not simply a random value, but uniquely bound to the original
request and is single-use). I *think* this might just be a terminology
issue here, but would it make sense to name these according to their
structural purpose, rather than just "token-part1" / "token-part2"?

In Section 3.3, it's stated "The ACME server SHOULD NOT perform URI
normalization on the Node ID given by the ACME client.". It seems like this
deserves its own section within Security Considerations, because as with
the above remarks, when, where, and how URI normalization is performed
seems like it has significant security impact. Even if this protocol uses
unnormalized URIs throughout the entire protocol, if implemented on top of
anything that performs normalization, or the certificates that are issued
are used by clients that perform normalization, you can end up with
ambiguities / confused deputies. Normally in a security protocol you would
want to validate and normalize your 'hostile' inputs as early as possible
in this flow, and that's one of the key roles of the ACME Server / CA, so
that it uses identifiers that are post-normalized/unambiguous. This seems
like a major oversight, but it could be that I'm misunderstanding something
specific to DTN.

Section 3.3 states "BP agents SHALL refuse to respond to a Challenge Bundle
which is signed by a known ACME server but has an invalid signature.". It
seems like this also deserves a note within the Security Considerations,
both in terms of how BP agents/ACME clients should determine whether an
ACME server is "known" and how they can successfully determine an invalid
signature (i.e. how to maintain the expected signing keys). This might
merely be a spec reference to DTN, but this normative language appears to
be trying to mitigate an undocumented security threat.

I agree with Russ' comments on Section 4 where the EKU MUST be included in
the issued certificate. Related, the profile from that Section 4.4.2 seems
problematic for implementation (around keyUsage), but alas, that's a whole
other issue for a whole other spec :)

Section 6.1 feels unnecessarily light for explaining why 

Re: [Acme] WGLC for ACME DTN Node ID

[Russ Housley]

I think that this document is almost ready.  I have a few comments.

MAJOR:

Section 4 points to Section 4.4.2 of [I-D.ietf-dtn-tcpclv4]; but that profile 
does not require the certificate to include an EKU of id-kp-bundleSecurity.  
When this document is used to verify control over the DTN Node ID, I think the 
issued certificate MUST include an EKU of id-kp-bundleSecurity.  If other means 
are used to validate other identities, then other EKU values might be included 
as well.

Section 4.2 is talking about S/MIME certificates.  I think there is a 
cut-and-paste error here.

MINOR:

Section 3.1 says:  "The only over-the-wire data required by ACME for a 
Challenge Bundle is a nonce token ...".  This is the first time that "nonce" 
appears in the document.  Please reword.

Section 3.3 and 3.4: in the beginning of the section, please add a pointer to 
the document that defines these parameters.  I think it is draft-ietf-dtn-bpbis.

Section 6.1: please provide a reference for "BPSEC key material", and please 
spell out "BCB".

NITS:

Section 1: please spell out BP on first use.

Section 2: s/wildcard ("*") character/wildcard character ("*")/

Section 6.2:  please spell out "BIB".

Russ


> On Mar 31, 2021, at 3:50 PM, Yoav Nir  wrote:
> 
> Hi.
> 
> This starts a WGLC for the subject draft entitled “Automated Certificate 
> Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID 
> Validation Extension”. The call will end at EOD Monday, April 19th, 2001.
> 
> The document has been with the WG since last August, and has received too 
> little review. ACME participants are encouraged to read and review, so that 
> we can make changes if such are needed, and progress the document for 
> publication.
> 
> Linsk:
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ 
> 
> Plain text: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.txt 
> 
> HTML: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.html 
> 
> PDF: https://tools.ietf.org/pdf/draft-ietf-acme-dtnnodeid-01.pdf 
> 
> 
> Thanks in advance
> 
> Yoav
> ___
> 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