Paul Wouters has entered the following ballot position for draft-ietf-acme-dtnnodeid-18: Abstain
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am filing a ballot of Abstain, as I can't fully comprehend the security model of ACME issuing endpoint certificates through an insecure Bundle Protocol based network which is not end-to-end secure. The ACME protocol security is bootstrapped by any ACME client being able to know that its content is only readable by the ACME server, and visa versa. But that is not the case here. 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. Defining the lack of this core ACME requirement as out-of-scope kind of confuses me as to what security guarantees ACME issued certificates offer. Any Intermediate BP node can get ACME certs issued for Node IDs behind it. So what does an ACME Node ID certificate really mean from a security point of view? _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
