Linda,
To provide some clarification: a "delay-tolerant network" isn't just a
descriptive term, it is a specific type of overlay network operating with
the Bundle Protocol of RFC 9171 in accordance with the principals of RFC
4838. This proposed validation method is both conceptually and
All,
I'm reposting here to confirm that in a different thread I identified the
DTN draft which modifies the IANA registry [1] as a necessary companion to
the ACME document. The DTN document purely updates the IANA registry and
has no other substantial content.
[1]
e Management
> Environment WG of the IETF.
>
> Title : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author : Brian Sipos
> Filename: draft-ietf-acme-dtnnodeid-1
us know whether you think it is
> ready (or make comments). We are hoping to get this draft finished!
> >
> > Deb Cooley
> >
> > On Tue, May 24, 2022 at 5:29 PM Sipos, Brian J.
> wrote:
> > All,
> >
> > I haven’t seen any reviews of the last draft versio
gt; >> wrote:
> >>
> >>> All,
> >>>
> >>> I haven’t seen any reviews of the last draft version -09. I hope that
> the
> >>> closer alignment with RFC 8823 makes its understanding and analysis
> easier.
> >>>
> >
; This draft is a work item of the Automated Certificate Management
> Environment WG of the IETF.
>
> Title : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author : Brian Sipos
>
t;
> Title : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author : Brian Sipos
> Filename: draft-ietf-acme-dtnnodeid-08.txt
> Pages : 30
>
Linda,
The way that Roman has described this is correct.
There are however subtleties to the distinctions between Node ID,
Administrative Endpoint ID, and general Endpoint ID that are not explained
in this document that deserve at least an expansion in the Terminology
section and a paragraph in
on-line Internet-Drafts
> directories.
> This draft is a work item of the Automated Certificate Management
> Environment WG of the IETF.
>
> Title : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
going to the same destination).
If the "token-chal" is assumed to be globally unique, then the client
really doesn't need to know what ACME servers are making the challenges.
On Mon, Oct 4, 2021 at 3:05 PM Aaron Gable wrote:
> Brian,
>
> Fantastic, thank you for the responses!
d ignore that constraint and generate bundles with
> lifetimes far into the future and a strictly-implemented server would be
> obligated to accept them.
>
> BS1: I agree that ideally these would indicate the same end time, but the
ACME server should trust only its own originated data, i.e.
e IETF.
>
> Title : Automated Certificate Management Environment
> (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension
> Author : Brian Sipos
> Filename: draft-ietf-acme-dtnnodeid-05.txt
> Pages
m in.
>
> Russ
>
> On Aug 20, 2021, at 3:10 PM, Brian Sipos
> wrote:
>
> Rich, I see your point. I had made my own assumptions that tools would
> validate that the SAN URI contained a valid URI and nothing more. But
> because the RFC 5280 requires more about the authority par
Rich, I see your point. I had made my own assumptions that tools would
validate that the SAN URI contained a valid URI and nothing more. But
because the RFC 5280 requires more about the authority part some
tools/libraries are free to throw out URIs that have some other
(RFC-invalid) authority
All,
I understand more fully now that the RFC5280 definition for
uniformResourceIdentifier has a more specific purpose than as a general URI
container, and that existing tools likely have additional assumptions baked
in about what services the URIs are to be used for. I was really hoping
that the
Roman,
My replies regarding the other, editorial comments are below with the
prefix "BS:". I'll get back to the earlier topics in the other mail thread.
** Section 1. Editorial. The paragraph starting with "Once an ACME
server validates ..." jumps immediately into discussion a "uri"
without
Roman,
Thank you for this thorough review. I want to address the more
procedural/structural points first; the ones which have implications outside of
just this document.
> On the process side, this arrangement is rather unusual. No quarrels with the
substance of the update which will improve
Yoav,
Is there anything needed in the near term to make progress on this document? I
haven't seen any further comments since the WG last call has ended. Also, as an
FYI the current draft is the result of review comments from the DTN WG and
there are no outstanding issues from either WG.
I am
Richard,
>From my interpretation, the fact that the two token parts are base64url
>strings is immaterial to the text-string concatenation into the ACME "token"
>value. The Key Authorization calculation of RFC 8555 also does not care where
>the token text came from or whether it is a base64url
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
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
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
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
All,
Recently both the DTN drafts related to BPv7 (over which the Node ID validation
is performed) and the ACME draft for email validation (from which the Node ID
validation takes its workflow) have progressed to the RFC Editor's queue, which
is great!
I am updating the DTN Node ID validation
Rich,
I plan on submitting a slightly updated draft, including the WG name prefix,
today.
Thanks for the uptake and sorry for the delay in posting.
From: Salz, Rich
Sent: Friday, August 21, 2020 10:05
To: acme@ietf.org ; Brian Sipos
Subject: Adopting the DTN
Nielsen
Sent: Friday, June 19, 2020 13:25
To: Brian Sipos; acme@ietf.org
Cc: alexey.melni...@isode.com
Subject: SV: [Acme] ACME email validation
The reason is to prevent email spoofing.
In the case of .well-known or DNS validation, or ALPN, you publish a record
where ACME fetches. That can’t
All,
In a recent draft I created for using ACME for non-web-PKI verification [1] I
see that there are many similarities with an earlier draft for email
verification [2]. In that email protocol, the challenge token is split into two
parts which arrive at the email validation agent through two
27 matches
Mail list logo
