crypto/x509: add Certificate.RawSignatureAlgorithm

[cjpatton]

Proposal Details

I'm working on an implementation of Merkle Tree Certificates, a new type of certificate that combines issuance with certificate transparency in a way that reduces the overall size of the certificate The spec involves a new type of signature algorithm, specifically for the issuer's signature.

crypto/X509.ParseCertificate() successfully parses the certificate, but sets SignatureAlgorithm to UnknownSignatureAlgorithm. Before attempting to validate the Signature, I would like to inspect the raw signature algorithm in order to ensure it is the OID we expect.

Options:

1. Expose the raw signature algorihm as a field in Certificate. Though I don't know enough about X.509 to say if this is a realistic option.
2. Add support for the MTC signature algorithm. Note, however, that the spec is in an experimental phase and the OID has not been finalized.

Related proposal: #75260

[davidben]

Adding support for the draft MTC sigalg feels a bit premature. Exposing the raw signature algorithm seems maybe a bit better?

That said, a signature algorithm is more than an OID. It's actually an OID and an optional ANY. (An AlgorithmIdentifier.) So it would either need to be some exposed representation of a lightly-parsed AlgorithmIdentifier, or perhaps just the raw bytes.

The raw bytes (RawSignatureAlgorithm) might be most straightforward? Matches some of the other fields. You can compare against the expected sigalg, or peel it apart with an ASN.1 like cryptobyte.

[gabyhelp]

Related Issues

• proposal: crypto/x509: add support for Relative OIDs #75260
• proposal: crypto/x509: add VerifyOptions.UnknownAlgorithmVerifier #74024
• proposal: crypto/x509: add ExtKeyUsage.OID #75325
• proposal: crypto/x509: expose hash algorithm for SignatureAlgorithm #33317 (closed)
• proposal: crypto/x509: support extracting X25519 public keys from certificates #70667
• proposal: crypto/x509: add Public Key Algorithms from RFC 4491 #21858 (closed)
• proposal: crypto/x509: ability to add custom curve when parsing X509 certificate #32874
• proposal: x/crypto/ssh: add a way to see pubkey signature algorithm #73847 (closed)
• proposal: crypto/x509: support extending list of algorithms #34844 (closed)
• crypto/x509: support OIDs for tcg-kp (2.23.133.8) #47620 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[FiloSottile]

I like the idea of Certificate.RawSignatureAlgorithm. We do have a pkix.AlgorithmIdentifier type, but it uses the old asn1.ObjectIdentifier type I would like to move on from.

Let's propose to add the following field to Certificate, CertificateRequest, and RevocationList

    RawSignatureAlgorithm []byte // DER encoded AlgorithmIdentifier

and it can be compared for equality with the expected MTC one.

[aarongable]

We should consider adding the same field to x509.RevocationList, since that ASN.1 structure has the same semantics around signature algorithms, even though we don't currently expect to be signing CRLs with MTC proofs.

[FiloSottile]

Good point, and also CertificateRequest. Added.

[aclements]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— aclements for the proposal review group

[aclements]

Based on the discussion above, this proposal seems like a likely accept.
— aclements for the proposal review group

The proposal is to add the following field to crypto/x509.Certificate, CertificateRequest, and RevocationList:

    RawSignatureAlgorithm []byte // DER encoded AlgorithmIdentifier

Currently, for any unrecognized signature algorithm, we set SignatureAlgorithm to UnknownSignatureAlgorithm. This field will allow callers that support other types of signature algorithms (e.g., MTC) to check the signature, and parallels existing, similar Raw* fields.