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 <token-part2> value included in this object is fixed for the entire 
challenge, and may correspond with multiple
separate <token-part1> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to