On Wed, Feb 26, 2025 at 4:49 PM Aaron Gable <[email protected]> wrote:
> Hi Paul, > > Apologies for the delay, I had a very busy beginning of the year. I'm now > getting to these in preparation for IETF 122. I have incorporated these > comments into the working copy > <https://github.com/aarongable/draft-acme-ari/pull/94> (from which I will > publish a new version soon), and have responded inline below. > Thanks for your discussion and explaining the various operational issues I wasnt fully aware of. I will update my ballot to Yes. Just one note I wanted to explain: > >> The keyIdentifier field of the certificate's AKI extension has the >> hexadecimal bytes >> 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 as its >> ASN.1 Octet String value. The base64url encoding of those bytes is >> aYhba4dGQEHhs3uEe6CuLN4ByNQ= >> >> There seems to be an endian swap in here? Perhaps this text should be >> clarified? >> The same for the the certificate's Serial Number field in the next >> paragraph. >> > > Could you be more specific? Do you mean that you believe there's an > endianness swap between the hex bytes and the base64 string? Or between the > values in the Appendix A certificate and the hex bytes here? Multiple > active implementations (including simply `openssl x509 -noout -text -in > appendix_a.pem | grep -A1 "Authority Key Identifier" | tail -n 1 | xxd -r > -p | base64`) agree on the value aYhba4dGQEHhs3uEe6CuLN4ByNQ= being the > correct base64-encoding for the Appendix A keyIdentifier. > paul@thinkpad:/tmp$ echo aYhba4dGQEHhs3uEe6CuLN4ByNQ= | base64 -d | hexdump 0000000 8869 6b5b 4687 4140 b3e1 847b a07b 2cae 0000010 01de d4c8 0000014 Note my output has 88:69:6B:5B[....] and you have [69:88:5B:6B][...] I assume it is a network vs host order issue. I just wanted to make sure there is no confusion here for people. Paul
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
