Unintended test: DSSE bundle tests appear to be lacking old X.509v3 extensions

[woodruffw]

It looks like d.txt.good.sigstore's leaf certificate has an extension for 1.3.6.1.4.1.57264.1.8 (i.e. OIDC Issuer V2) but not 1.3.6.1.4.1.57264.1.1 (i.e. the original OIDC Issuer extension).

This puts it out of sync with the current PGI instance, which still produces certificates with both extensions for compatibility reasons. The legacy extension is deprecated, but some clients (like sigstore-python, unfortunately) haven't been able to move off of it because the new ones use a wrapper DER encoding that doesn't have straightforward API support yet :slightly_frowning_face:

Full dump:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 286793732 (0x11182004)
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: CN = sigstore, O = sigstore.mock
        Validity
            Not Before: Feb  1 00:00:00 2023 GMT
            Not After : Feb  1 00:10:00 2023 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:90:33:67:89:3d:ee:68:06:30:c6:ee:14:ec:3d:
                    c4:41:70:a8:51:ae:38:02:f7:33:16:27:64:53:4a:
                    67:f3:10:12:3c:4f:5b:d3:17:82:f3:e8:a3:fa:a7:
                    28:31:76:b9:82:1c:75:ba:49:7a:89:18:69:a0:07:
                    3a:35:a2:4f:56
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Code Signing
            X509v3 Subject Alternative Name: critical
                URI:https://github.com/sigstore-conformance/extremely-dangerous-public-oidc-beacon/.github/workflows/extremely-dangerous-oidc-beacon.yml@refs/heads/main
            X509v3 Subject Key Identifier:
                59:83:06:1B:57:DD:FF:E6:A2:13:75:B9:93:A8:87:46:D2:FF:1B:D0
            X509v3 Authority Key Identifier:
                3F:14:5C:64:EC:55:31:B7:FA:04:F2:50:D9:10:5D:2C:EE:46:AC:B8
            1.3.6.1.4.1.57264.1.8:
                .+https://token.actions.githubusercontent.com
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : F7:26:CA:A3:41:17:BA:91:65:44:AF:37:34:E9:20:CD:
                                4C:49:2E:F7:5C:E6:22:8F:DC:04:EE:FF:2F:3F:27:DD
                    Timestamp : Feb  1 00:00:00.000 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:59:EE:58:15:45:62:03:17:E0:7D:D9:44:
                                23:02:D4:8F:80:4D:BB:F1:6C:BE:AC:79:08:D0:CC:27:
                                20:FF:91:9A:02:20:37:65:AA:20:6C:7C:DD:77:98:A8:
                                80:62:00:1F:88:9E:DF:BE:41:1E:85:87:67:95:0B:84:
                                19:C7:8F:28:81:9E
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:45:02:21:00:a7:35:8b:d0:e6:4f:ba:bb:fd:fc:06:69:d4:
        cb:ea:e9:20:c5:59:1d:f2:c0:b9:c6:70:24:fc:ff:b6:9a:7b:
        45:02:20:30:fa:bd:47:71:a1:fb:89:04:98:2f:8f:f4:09:a3:
        e9:ec:62:0f:b0:ef:c0:9a:98:bf:b6:c4:03:ba:54:ff:d2

CC @bdehamer @steiza: do you think we could re-generate these testcases, but with the legacy extension enabled as well? Or do you think that would be too painful? If the latter, this may be a sufficient kick in the ass for sigstore-python to finally get with the program and move over to the new extensions :slightly_smiling_face:

h/t @segiddins for noticing this :slightly_smiling_face:

[loosebazooka]

Oh yeah huh. I'm not sure we use the new extensions either

[haydentherapper]

Cosign only uses the old extensions too, though we should move over to the new ones to support CI identity verification for more than just GHA.

Fulcio wont remove the extensions until a V2 API, so for now, generating a certificate where the deprecated extensions are present would be reflective of what we are doing in prod.

[woodruffw]

Fulcio wont remove the extensions until a V2 API, so for now, generating a certificate where the deprecated extensions are present would be reflective of what we are doing in prod.

Makes sense to me. Yeah, in that case I think this case needs to be re-generated even if clients move towards the new extensions :slightly_smiling_face:

[bdehamer]

Lemme work on regenerating this case with the legacy extensions in place.