Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-39: Discuss
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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updates leading to the -39; I believe we're almost there! Unfortunately, it seems that the "pinned-domain-cert" in the issued voucher is the registrar's cert, not the CA cert. (Given that the documented workflow is to extract this CA cert from the registrar-voucher-request CMS object, and the registrar-voucher-request in our examples does include both the registrar cert and the CA cert, I wonder if this reflects a bug in the code itself used to generate the examples, in that it picks the wrong cert?) My understanding is that the protocol requires this field to be populated by a CA cert, and the registrar's cert is not a CA cert. I am very hopeful that we can just regenerate the voucher without having to redo the rest of the examples, since we have all the keys and certificate enshrined in the document already, and my apologies for not noticing whether this issue was present in previous revisions as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would make this a Discuss point but I think I already had my chance at the text and missed it: Section C.1.5 says that "The public key is used by the registrar to find the MASA", but it's really the certificate (via the "MASA URL" extension) and not the public key that is so used. I would suggest noting in C.2 that the asn1parse output is truncated at $number columns, and specifically calling out that this makes it hard to differentiate between organizationally related name components, specifically "highway-test.example.com CA" and "highway-test.example.com MASA". (The full asn1parse output from the live openssl CLI is much clearer about the distinction.) _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
