X509.Certificate.self_signed.new() fails on an RDNSequence struct but doesn't fail when that RDNSequence is cast to string

[daidoji]

What happened:
When I called X509.Certificate.self_signed(ca_sk_struct, rdn, template: :root_ca) with an RDNSequence struct type I get a weird MatchError that I couldn't quite figure out. When I called the same function but with that RDNSequence cast to string via its to_string() function on that module, a valid certificate was produced. (ie: X509.Certificate.self_signed(ca_sk_struct, rdn |> X509.RDNSequence.to_string(), template: :root_ca) )

What I expected to happen:
Both calls should work if one works or both should fail if one fails.

The original code that caused this error:

{uncompressed_pk, sk} = :crypto.generate_key(:ecdh, :secp256r1)
ca_sk_struct = {:ECPrivateKey, 1, sk, {:namedCurve, {1, 2, 840, 10045, 3, 1, 7}}, uncompressed_pk, :asn1_NOVALUE}
rdn = X509.RDNSequence.new([countryName: "US", stateOrProvinceName: "NC", localityName: "Mooresville", organizationName: "vLEIDA", commonName: "Kerilixir ACME-like Root CA"])
iex(139)> X509.Certificate.self_signed(ca_sk_struct, rdn, template: :root_ca)

The error:
** (MatchError) no match of right hand side value: {:error, {:asn1, {:badarg, [{:erlang, :element, [1, <<12, 2, 78, 67>>], [error_info: %{module: :erl_erts_errors}]}, {:"OTP-PUB-KEY", :enc_X520StateOrProvinceName, 2, [file: ~c"../src/OTP-PUB-KEY.erl", line: 16173]}, {:"OTP-PUB-KEY", :encode, 2, [file: ~c"../src/OTP-PUB-KEY.erl", line: 1225]}, {:pubkey_cert_records, :transform, 2, [file: ~c"pubkey_cert_records.erl", line: 81]}, {:lists, :map, 2, [file: ~c"lists.erl", line: 2077]}, {:lists, :map_1, 2, [file: ~c"lists.erl", line: 2082]}, {:lists, :map, 2, [file: ~c"lists.erl", line: 2077]}, {:pubkey_cert_records, :transform, 2, [file: ~c"pubkey_cert_records.erl", line: 93]}, {:pubkey_cert_records, :encode_tbs, 1, [file: ~c"pubkey_cert_records.erl", line: 320]}, {:public_key, :pkix_encode, 3, [file: ~c"public_key.erl", line: 813]}, {:public_key, :pkix_sign, 2, [file: ~c"public_key.erl", line: 1362]}, {X509.Certificate, :self_signed, 3, [file: ~c"lib/x509/certificate.ex", line: 138]}, {:elixir, :eval_external_handler, 3, [file: ~c"src/elixir.erl", line: 386]}, {:erl_eval, :do_apply, 7, [file: ~c"erl_eval.erl", line: 919]}, {:elixir, :eval_forms, 4, [file: ~c"src/elixir.erl", line: 364]}, {Module.ParallelChecker, :verify, 1, [file: ~c"lib/module/parallel_checker.ex", line: 120]}, {IEx.Evaluator, :eval_and_inspect, 3, [file: ~c"lib/iex/evaluator.ex", line: 336]}, {IEx.Evaluator, :eval_and_inspect_parsed, 3, [file: ~c"lib/iex/evaluator.ex", line: 310]}, {IEx.Evaluator, :parse_eval_inspect, 4, [file: ~c"lib/iex/evaluator.ex", line: 299]}, {IEx.Evaluator, :loop, 1, [file: ~c"lib/iex/evaluator.ex", line: 189]}]}}} (public_key 1.17.1) pubkey_cert_records.erl:61: :pubkey_cert_records.transform/2 (stdlib 6.2.2) lists.erl:2077: :lists.map/2 (stdlib 6.2.2) lists.erl:2082: :lists.map_1/2 (stdlib 6.2.2) lists.erl:2077: :lists.map/2 (public_key 1.17.1) pubkey_cert_records.erl:93: :pubkey_cert_records.transform/2 (public_key 1.17.1) pubkey_cert_records.erl:320: :pubkey_cert_records.encode_tbs/1 (public_key 1.17.1) public_key.erl:813: :public_key.pkix_encode/3 (public_key 1.17.1) public_key.erl:1362: :public_key.pkix_sign/2 (x509 0.8.10) lib/x509/certificate.ex:138: X509.Certificate.self_signed/3 iex:139: (file)

The fixed code that produces the certificate as expected:
X509.Certificate.self_signed(ca_sk_struct, rdn |> x509.RDNSequence.to_string(), template: :root_ca)

The results of running the fixed call in the same iex session:

{:OTPCertificate,
 {:OTPTBSCertificate, :v3, 12297407839812733269,                                                                                                      {:SignatureAlgorithm, {1, 2, 840, 10045, 4, 3, 2}, :asn1_NOVALUE},
  {:rdnSequence,
   [
     [{:AttributeTypeAndValue, {2, 5, 4, 6}, ~c"US"}],                                                                                                   [{:AttributeTypeAndValue, {2, 5, 4, 8}, {:utf8String, "NC"}}],
     [{:AttributeTypeAndValue, {2, 5, 4, 7}, {:utf8String, "Mooresville"}}],
     [{:AttributeTypeAndValue, {2, 5, 4, 10}, {:utf8String, "vLEIDA"}}],                                                                                 [                                                                                                                                                     {:AttributeTypeAndValue, {2, 5, 4, 3},
        {:utf8String, "Kerilixir ACME-like Root CA"}}
     ]
   ]},
  {:Validity, {:utcTime, ~c"250730141050Z"},
   {:generalTime, ~c"20500730141550Z"}},
  {:rdnSequence,
   [
     [{:AttributeTypeAndValue, {2, 5, 4, 6}, ~c"US"}], ...

[voltone]

Unfortunately Erlang/OTP's :public_key application sometimes has two internal representations for the same object: :plain and :otp, where the latter tends to be the result of slightly deeper parsing. This is particularly annoying for RDN sequences, as the record name is the same for both, so it is not possible to tell just from the structure which is which.

In your case, if you pass a second parameter :otp to X509.RDNSequence.new you will get an RDN sequence record that will work in a certificate. I need to look into this a bit more to see if I can make the Certificate functions accept RDNs in both formats transparently (and reliably).

BTW, you can also simplify your first two lines to just ca_sk_struct = X509.PrivateKey.new_ec(:secp256r1)...

[daidoji]

That does sound annoying, thanks.

[voltone]

BTW, you can also simplify your first two lines to just ca_sk_struct = X509.PrivateKey.new_ec(:secp256r1)...

...or, if you want to call Erlang/OTP directly, :public_key.generate_key({:namedCurve, :secp256r1}). I would avoid using the :crypto module for anything involving asymmetrical keys/algorithms: you'll find that :public_key can do almost anything :crypto can do, but using higher-level APIs that are safer to use and save you the hassle of having to assemble record representations manually.

[daidoji]

Oh I agree completely and in normal circumstances I would do that. However, I'm implementing a distributed DPKI protocol (https://trustoverip.github.io/tswg-keri-specification/ if you're interested) at the moment that doesn't use the traditional x509 infrastructure and so the key material and their public representations are all in another format preferred by that protocol.

So to issue x509 certs from my particular implementation requires that I get down to that level unfortunately :-(

Thank you for the tips though.