FR4NK-W
commented
2 years ago Thanks for your comments @matzf
From your comments, it seems like we want to do more checks than we can easily do with the scion-pki tool:
- we no longer can treat the payload as a blob we authenticate
- we want to verify that the content of the topology file (in particular the AS id we are getting) matches the signer identity.
This puts us in a similar case as with a detached signature, where we also need to infer the signer.
About the EKU (Extended Key Usage), crypto/x509 Verify insists on verifying the EKU from the signer, to the issuer through to the root (which in production only has EKU Time Stamping and an internal EKU 1.3.6.1.4.1.55324.1.3.3), so we have to ignore EKUs anyway since there is no valid EKU.
Not sure that restricting the EKU on the root certificates is intentional.
Unless the insecure flag is set, download a TRC, a signed topology file and verify the signature. Verifies the certificate chain of the included certificate against the TRC. Crypto operations are only done using the tools scion-pki and openssl.