Paul Wouters has entered the following ballot position for draft-ietf-acme-ari-07: 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/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-ari/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. It can be a useful extension but I do have some issues I would like to discuss / clarify Query the renewalInfo resource to get a suggested renewal window. Select a uniform random time within the suggested window. If the selected time is in the past, attempt renewal immediately. This seems to skew to "now" which would only cause the ACME server more load than without this extension (one GET and one actual renewal). Why not let the client select a uniform random time between "now" and "end" if "now" > "start" ? it indicates both the earliest time and a target time. It is really not the "earliest time" because an ACME server isn't going to refuse it? I would rewrite this to just say "it indicates the desired target time". This does bring up a point of concern. Clients who do not implement this have an advantage on an overloaded server compared to clients who do implement this. For example, let's say some new industry certification license says "certifiates MUST always be valid for at least two more weeks". Wouldn't it make more sense for the server to check the "urgency" of the client request and when (too) busy, start rejecting to renew those with plenty of lifetime left? I am also not sure about the argument of revocation for timing. Either the owner of the cert to be revoked knows this and is already in the process of replacing the cert/private key, and it wants to get a new cert issued "now", or it is completely unaware, and most likely whatever caused the leak of the current cert/private key, would also leak this renewed one. I don't think an ACME server can help with either cases by issuing shorter calls to renew. These would also be certificate specific and I understood this unauthenticated extension to be generic and based on load, and not on specific individual certificate issues. Clients SHOULD set reasonable limits on the their checking interval. For example, values under one minute could be treated as if they were one minute, and values over one day could be treated as if they were one day. This really does violate the "compliant clients MUST" clause :) Security Considerations: This document specifies that renewalInfo resources MUST be exposed and accessed via unauthenticated GET requests, a departure from RFC8555's requirement Where does it specify this, other then right here? This specification should be outside the Security Considerations section. What I can find is: To request the suggested renewal information for a certificate, the client sends a GET request to a path under the server's renewalInfo URL. Maybe a sentence can be added there that this GET request is unauthenticated, so that an implementer does not accidentally send credentials of any kind? Maybe even say that a server MUST reject any attempted authorized connections for renewalInfo to ensure such badly implemented clients cannot prosper ? Perhaps also a clarifying sentence can be added along the lines of: If an on-path attacker would force ACME clients to postpone renewal indefinately, a properly implemented client would ignore these when the lifetime of its certificate becomes critically low (eg 7 days ?). I also feel this belongs more in Section 4.3.2 with some concrete advise to implementers. As for the last paragraph in the Security Considerations, it seems to specify specific server behaviour that belongs in the formal specification instead of as security example. If we look at the protocol requirement of the server to tell the client "renew now", why not define this by either using a timestamp of unix time 0 (eg 1970) or by introducing a third keyword along the "start" and "end" in the suggestedWindow property, eg "fetch-now": "recommended" ? Using some kind of fake time seems like a poor hack for a protocol, as the text in the security considerations already admits to (but then tries to band-aid the client) Again, I feel this belongs in the base document specification and not in the Security Consideration section. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Conforming clients MUST attempt renewal I find this a bit weasel wording. How about: Clients SHOULD attempet renewal Clearly, a client can have some overriding local policy concern that trumps the ACME servers The keyIdentifier field of the certificate's AKI extension has the hexadecimal bytes 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 as its ASN.1 Octet String value. The base64url encoding of those bytes is aYhba4dGQEHhs3uEe6CuLN4ByNQ= There seems to be an endian swap in here? Perhaps this text should be clarified? The same for the the certificate's Serial Number field in the next paragraph. Maybe instead of: GET https://example.com/.... Use: GET https://acme-server.example.com/..... Similar for the explanationURL value. Clients MUST stop checking RenewalInfo after a certificate is expired. I would stay "MUST skip checking RenewalInfo after a certificate is expired and immediately request a renewal." Clients MUST stop checking RenewalInfo after they consider a certificate to be replaced (for instance, after a new certificate for the same identifiers has been received and configured). I would also avoid the "MUST stop" construct here. Perhaps: RenewalInfo MUST NOT be attempted for any certificate that has been replaced (for instance, after a new certificate for the same identifiers has been received and configured) _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
