Signatures / MACs: AAD generation missing?

[chrysn]

Looking to fix the big TODO around _verify_signature (which currently returns successfully for all cases), I'm lacking the AAD context to verify these hashes.

What's the plan around that function? Is the expectation that it has enough context to build the relevant plaintext/AAD itself, or should it grow an argument and have the callers provide that?

[chrysn]

Having worked a bit on an actual implementation (with which I can verify the MAC in message3), I found that while of peers there's always full information (ID_CRED_mine, CRED_mine, my private key), of the peer there's only ID_CRED_peer and the public key of the peer, but not the consensus encoding of the CRED_peer (which typically takes the form {1: 1, -1: 4, -2: key, "subject name": something}). Are there any plans where that should be transported yet?

CC @TimothyClaeys as I'm not sure you're subscribed here.

[chrysn]

Hm, seems ther is a distincguished place for those (_peer_cred, _remote_authkey), just that there's some paths through _parse_credentials that make them identical.

On the plus side, this is getting into a PR'able shape slowly, maybe we can talk more precisely when reviewing that.

[chrysn]

I do now have working signature_or_mac_3 verification (both versions); PR probably makes most sense after #9 is processed and my stuff is rebased onto there.

[TimothyClaeys]

Okay, I think you can PR your changes. in the meantime I'll add some additional test vectors from test-vectors-05.