I have read draft-aaron-acme-ari. I support adoption of the document. The problem statement is well founded, but I'm surprised at the solution.
I am surprised that it's not something that is inside the certificate.
An in-certificate hint would be useful in RFC7030 situations for IoT
networks, particularly when a CA rollover is expected soon.
I am also not thrilled about the online assumptions about this process.
I guess the point is that the ACME server does not need to commit to a
particular schedule. I am also concerned about privacy implications here.
dns-01 challenges for instance, don't have to reveal the location of the end
server, but I suppose any indirection for obtaining certificates can also do
the polling of this renew directly.
One bit that confused me:
> Conforming servers MUST provide the renewalInfo resource via POST-as-GET;
> they SHOULD provide it via unauthenticated GET as well. Conforming clients
> SHOULD use unauthenticated GET to request renewalInfo resources.
Generally, if you write SHOULD, then there are some exceptions that are
possible, even if unlikely. What are they?
If conforming clients are supposed to use unathenticated GET, why is support
for that only SHOULD? I guess clients MUST also support POST-as-GET, at
which point, why wouldn't clients just get code for that choice?
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
