Open job opened 1 year ago
The json is not fully standardised is it? The ski field feels redundant.
Wish there was a better spec for this. Might make sheets on it. Mostly because there also is a nice way to get multiple rtr servers in sync for the same session if the session and serial-within-that-session are in the json.
I'm not a huge fan of the idea of validating ASN.1 payloads inside a RTR demon, In terms of scope creep on a RTR demon, and the scope for bugs as a result of dealing directly with ASN.1 payloads
Message ID: @.***>
The JSON format indeed does not follow a standard. For BGPsec Router Keys I attempted to mimic the layout of the RTR PDUs to make Ben’s life easier.
Although the
SKI
field in BGPSec Router Keys appears to be redundant, its presence can perhaps be used to detect data corruption in the pipeline.Given the following example:
The SKI can be confirmed by calculating the SHA-1 hash of the BIT STRING present in the base64-encoded DER-encoded SPKI.
Perhaps it is robust behavior to log a warning and ignore the Router Key entry if there is a mismatch between the calculated SKI and the listed SKI?