On Tue, Oct 24, 2017 at 05:17:32PM +0300, Ilari Liusvaara wrote: > On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > > > The ACME protocol should permit CAs to implement policy as far as is > > reasonably practicable with regard to the workflows around which the > > protocol is organised. Providing the CSR up-front allows the CA to > > predicate order processing on aspects of that CSR, both with regard to > > the present protocol and any future extensions, both now and in the > > future in ways that we can and cannot foresee. I don't think it's > > appropriate to defer giving critical information to the CA until the > > last minute due to a resource utilisation concern which LE has already > > proven capable of dealing with, especially when the whole point of the > > order flow in the first place was to provide more flexibility for CAs to > > institute policy. > > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI > key). Implementing that without knowing the public key at validation > time is annoying. > > As to why one would want something like that, it would allow limiting > trust on certficiate management system without deploying something as > dangerous as HPKP. >
Specifically, this would be a top-level CAA property that is satisfied by certificate request having SubjectPublicKeyInfo matching at least one of the listed hashes. The contents of property consist of one or more hash=hasval pairs, where hash is a hash function (unknown ones are ignored) and hashval is base64-encoded hash of the SPKI. There is no max-age, as the restriction is not sticky and thus can be replaced quickly if needed. It can be signed using DNSSEC as usual. Example: foo.example.net IN CAA 128 pin "sha256=AIPH49+A9F1e650YMzRPJG9OkBA0F24Mwa5ru5ZmsCo=,sha256=FmbTUrJD2lBK8H501MKenwkFg+639r/x6eZp22qUd/I=" This property is satisfied only by requests containing SubjectPublicKeyInfo key with either SHA-256 hash of 0083c7e3df80f45d5eeb9d1833344f246f4e901034176e0cc1ae6bbb9666b02a or 1666d352b243da504af07e74d4c29e9f090583eeb7f6bff1e9e669db6a9477f2. The usecase is as follows: Suppose certificate management system runs with the least authority. If it gets compromised, the attacker can not aquire the private keys. However, he can abuse its authority to solve challenges for his own keypairs. The end result is attacker getting maliscous certificates he controls the private key for. The account keypair does not help, since it can be abused too. However, if the public keys one can get certificates are restricted, the attacker can not aquire useful certificates, as he can not specify his own keypairs for the certifciate, nor get the private key for any of the whitelisted keypairs. Similar attacks could be also mounted on some other least-authority components of the whole system, components that could be at even higher risk of compromise. The current solution to this usecase is the HPKP. However, HPKP is known to be difficult to deploy, quite of a footgun and worst of all is being deprecated. Expect-CT will not even begin to solve it. A partial solution would be to use CAA to restrict issuance to CAs that either do not support automation, or support "vanity CAAs" with corresponding restrictions. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
