> The Registrar MUST use a certificate that chains to the pinned- > domain-cert as its TLS server certificate.
I wonder if it should say: + The Registrar MUST use a certificate that chains from the pinned- + domain-cert as its TLS server certificate. Or maybe we want "descends"? Perhaps "server certificate" should be ServerCertificate, which is the name of the actual payload. next paragraph: > The Pledge's PKIX path validation of a Registrar certificate's > validity period information is as described in Section 2.4. > Once the > PKIX path validation is successful the TLS connection is no longer > provisional. Is there some way we can call the the last sentence out louder? UPPERCASE it all? I dunno. I think people might really need to be hit over the head here. section 3.5, I changed: - <t>To indicate Pledge status regarding the Voucher the client + <t>To indicate Pledge status regarding the Voucher, the pledge I think this is clear. I'm not certain about the comma :-) section 3.6: > The registrar MUST HTTP POSTs the same Voucher Request as when > requesting a Voucher. It is posted to the /requestauditlog URI > instead. The "idevid-issuer" and "serial-number" informs the MASA It seems to me that a Registrar should also be able to post any voucher. Even an expired one. So not just a voucher request. (The distinction being who signed it). While generally a Registrar is going to consult the audit log before asking for a voucher, it could well do so afterwards. I think this has value in the Pledge is offline case: a Registrar on the Internet side of the air-gap firewall (with the USB drive...) could take responsability to consult the audit log periodically. [StatsCanada's airgap firewall used UUCP via 9-track tapes to move email cross their airgap firewall] I think section 3.7 should be 3.6.1, as it's the reply to 3.6. (I'm gonna do that in the XML) Section 3.7 needs to say what to do if version!=1. Could we remove the version from the response and change the URL to /requestauditlog/v1 ? (I read to the end of the diffs, and found nothing else that stirred me) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
