[Anima] evaluation of pinned-domain-cert equality in BRSKI

[Michael Richardson <[e-mail]>]

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]

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) ???

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

{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.

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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-