Thank you Roman for the review and comments. I created individual github issues for these comments and have committed fixes for most of them and closed the issues: https://github.com/upros/acme-integrations/issues
There are three outstanding issues and I will comment on these inline below. Regards, Owen -----Original Message----- From: Acme <[email protected]> On Behalf Of Roman Danyliw Sent: Saturday 29 October 2022 03:34 To: [email protected] Subject: [Acme] AD Review of draft-ietf-acme-integrations-10 Hi! I performed an AD review of draft-ietf-acme-integrations-10. Thanks for this information document to should the broad applicability of ACME. My feedback is as follows: ** Section 2. Editorial. The definition of subdomain uses explicit quotes around text from RFC1034. However, label comes verbatim of RFC8499, why not quotes around it? [ofriel] The quotes or lack of quotes is itself taken directly from the definitions in RFC8499. If you look at RFC8499, the definition of Label is not in quotes; however, the definition of Subdomain starts with a quote as it is pulling in text from RFC1034 into RFC8499. The text in acme-integrations aligns to the character with what is in RFC8499. Does this make sense? ** Section 6. I don't have the full history on draft-ietf-eap-teap-brski. However, it seems unusual to be effectively specifying an applicability statement for an expired, unadopted draft. Is there significant usage of this draft in the field? What's the motivation? [ofriel] We / cisco are actively working on elements of draft-lear-eap-teap-brski, we just didn't get to updating at IETF115. It might make sense to remove the reference for now, but see next comment. ** Section 6. Diagram Step 2 is "Establish Outer Tunnel". Isn't the last step of it the follow (i.e., the client responding back with the Result TLV= Success. | EAP-Response/ | | | | Type=TEAP, | | | | {Crypto-Binding TLV, | | | | Result TLV=Success} | | | |------------------------>| However, the following is being shown as the last step: | EAP-Request/ | | | | Type=TEAP, | | | | {Request-Action TLV: | | | | Status=Failure, | | | | Action=Process-TLV, | | | | TLV=CSR-Attributes, | | | | TLV=PKCS#10} | | | |<------------------------| [ofriel] The reason this happens is yes, the client has successfully completed TLS handshake, but the server is explicitly instructing the client to do a CSR Attributes followed by a PKCS#10 cert enrol so that the client will enrol to get a cert that will allow it to access. E.g. the client may start the TEAP transaction with an IDevID, or with an about-to-expire LDevID, thus the server is telling it to get a new cert before it will grant access. This behavoiur is not too clearly specified in RFC7170, but is clearer in draft-lear-eap-teap-brski. We could possibly drop draft-lear-eap-teap-brski reference and add further clarification in this document over and above what is in RFC7170. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
