Thoughts from starting to play with ARI

[petercooperjr]

Multiple CertIDs work for the same certificate

Continuing the discussion from another thread, Implementing ARI / POST issue:

@Nummer378

The example from draft-ietf-acme-ari-01 uses this payload:

MFswCwYJYIZIAWUDBAIBBCCeWLRusNLb++vmWOkxm34qDjTMWkc3utIhOMoMwKDqbgQg2iiKWySZrD+6c88HMZ6vhIHZPamChLlzGHeZ7pTS8jYCCD6jRWhlRB8c

which decodes to:

  0  91: SEQUENCE {
  2  11:   SEQUENCE {
  4   9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
       :     }
 15  32:   OCTET STRING
       :     9E 58 B4 6E B0 D2 DB FB EB E6 58 E9 31 9B 7E 2A
       :     0E 34 CC 5A 47 37 BA D2 21 38 CA 0C C0 A0 EA 6E
 49  32:   OCTET STRING
       :     DA 28 8A 5B 24 99 AC 3F BA 73 CF 07 31 9E AF 84
       :     81 D9 3D A9 82 84 B9 73 18 77 99 EE 94 D2 F2 36
 83   8:   INTEGER 3E A3 45 68 65 44 1F 1C
       :   }

Your payload

MGgwDQYJYIZIAWUDBAIBBQAEIOpkIqHI/Ls/OhlCdhE04lJbuQeWAJOnNXYBVVd5McY8BCDSVL7W2ZsvDB2XvGCxFyqANyOEGpzMnWghk6IzVt0J4QITAPq2fJCRPuOPeIQPmgxgZpHUYw==

decodes to:

  0 104: SEQUENCE {
  2  13:   SEQUENCE {
  4   9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
 15   0:     NULL
       :     }
 17  32:   OCTET STRING
       :     EA 64 22 A1 C8 FC BB 3F 3A 19 42 76 11 34 E2 52
       :     5B B9 07 96 00 93 A7 35 76 01 55 57 79 31 C6 3C
 51  32:   OCTET STRING
       :     D2 54 BE D6 D9 9B 2F 0C 1D 97 BC 60 B1 17 2A 80
       :     37 23 84 1A 9C CC 9D 68 21 93 A2 33 56 DD 09 E1
 85  19:   INTEGER 00 FA B6 7C 90 91 3E E3 8F 78 84 0F 9A 0C 60 66 91 D4 63
       :   }

Which looks like there's an extra null byte there.

So, I don't know what's an issue with the spec vs. an issue with Boulder's implementation of it, but I've confirmed that Boulder (staging at least) replies the same regardless of whether the AlgorithmIdentifier has the parameters left out entirely, if it is a null value, or even if some other random data is in there. I feel like in order for CAs to be able to cache responses appropriately, and for clients to be sure of interoperability with CAs, there should exactly one clear representation for the certificate that is used. If some clients put in the null and others leave it out, then there will be twice as many possible URLs that need to be dealt with. (There's some discussion of the history of whether to need to add a NULL parameters for the algorithm for PKCS1 in this Stack Exchange post I found, but I have no idea what RFCs/etc. to chase down in order to figure out if it belongs there or not for OCSP CertID.)

Even more bizarre, Boulder doesn't seem to care what gets put in the issuerNameHash and issuerKeyHash at all! If I leave them as empty octet strings I still get the same response since all Boulder cares about is the serial number. (Like, it even makes sure that SHA-256 is specified, but then doesn't care what the actual hashed data is.) So only testing against Boulder doesn't tell me whether my implementation is actually hashing the right data or not, or if it would work with any other CA. Plus again, each client could be making its own different URL to test which would make it harder for caching and such to work. (Plus I'm curious if it's possible to inject tons of data or otherwise confuse something by putting stuff in those fields that doesn't belong.)

So, if this OCSP CertId is going to be what's used, I think that it needs to be very clearly and explicitly specified the steps to map a certificate to the value, server implementations should make sure that they check for and only allow the one canonical representation, and there should be a bunch of test cases for clients to use to check their work beyond just the one in Appendix A.