Hi Michael, My comments are inline.
> -----Original Message----- > From: Anima <[email protected]> On Behalf Of Michael Richardson > Sent: Freitag, 26. April 2019 00:16 > To: [email protected] > Subject: [Anima] evaluation of pinned-domain-cert equality in BRSKI > > > Due to a design concern my MASA looks up domain registrars by public key > rather than certificate(DN). I think that I did this because of > constrained voucher concerns. > A test registrar resigned the certificate used for pinning, and used that as > part of the BRSKI protocol. The private key was not > replaced, so it had the same public key inside the certificate. > > The resulting voucher was pinned to the original certificate, rather than the > certificate that was present. This was then rejected by the > pledge because the certificate pinned was not the same as the registrar that > was proximal. > > Before I fix the bug in the MASA such that it always pins with the > certificate provided, I thought I'd ask some questions. It could be > that my pledge was wrong instead. > > 1) how should a pledge compare pinned-domain-cert to TLS Server Certificate. > a) compare Issuer + DN+subjectAltName. > b) compare subjectPublicKeyInfo > c) byte-wise comparison of DER encoded form. > > [I am doing c] In case a) a nonceless voucher would need to be renewed if the issuing CA for the registrars TLS certificate has been updated or changed. Update could be handled by a compare to the rootCA instead of the issuing CA, but this would lead to the point you stated below. Also, it would require the rootCA to be part of the voucher Case b) seems similar to c) but the nonceless voucher needs to be updated after renewal of the registrar certificate assumed the key pair is renewed and not only a re-certification of the existing public key is done. In case c) this would mean that you need to renew any nonceless voucher, which the registrar already possessed after update of the registrars TLS server certificate. > > 2) how should a MASA audit a voucher-request that comes from a JRC that has > the same public key, but a different certificate? > > a) it is the same owner, if the old certificate is still valid, then > keep it. > b) it is the same owner, keep the new certificate on file, replacing the > previous certificate > c) it is the same owner, keep whichever certificate has a later notAfter. > d) it is the same owner, only if the issuer+DN are the same. In which > case keep the one with ... > i) a newer PKIX serial number (no, ramdomized serial numbers) > ii) latest notAfter > iii) ??? If the same public key is used, I would propose d) II under the assumption that DN is the subject name including the domain name. In addition, the SAN may also be included if a TLS server certificate is intended to represent multiple domains (for the high availability use case mentioned below). > I note that a high-availability multi-node JRC might have: > a) different certificates with the same DN, and different public keys > b) different certificates with the same DN, and the same public keys, > because rewewal times were skewed. (They will become the same at the > next sync) > c) different certificates with different DNs b) may not be wanted as the it requires to share the private key on different instances. c) may not be beneficial in high availability scenarios if the subject DN changes. Here it may be possible to utilize multiple SANs to address the usage of the certificate for multiple domains, keeping the same DN to support load balancing > > {I note that doing Issuer+DN comparisons is difficult to get right if the > Issuer public key is not easily obtained from a trusted store} > > Now, you might say that the pledge should never expect the TLS Server > Certificate to ever differ, byte-for-byte from the pinned- > domain-cert, and that would be reasonable for a completely online situation. agree > But in the case of offline vouchers, it's entirely reasonable that the JRC > has rolled it's certificate. In such a situation, either one needs > (1a) or > (1b) above. If we are doing (1a), then we get back to something we thought > we got away from, which was pinning the CA+DN. We > have underspecified this. > > If we go with (1b), then there are some crypto-hygiene operational > considerations to consider, but I think they are probably > acceptable given that vouchers can be re-issued easily. I think for both cases the re-issuing of vouchers depending on changes of the LRC certificate would be necessary Best regards Steffen > > -- > Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 > IoT consulting =- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
