access to custom extensions

[steffkes]

i can imagine you never needed custom extensions, because for the certstream-server it's unusual to see them - but they do exist :) right now, i just know "it's there", but the library does not offer a way to access it:

iex> EasySSL.parse_der(cert)
%{
  extensions: %{
    extra: ["1.3.6.1.5.5.7.1.323.2", "1.3.6.1.5.5.7.1.323.1"],
  },
  subject: %{
    aggregated: "/CN=my_cn"
  },
  serial_number: "A"
}

using erlang's public_key library i can get it:

{:OTPCertificate, {:OTPTBSCertificate, _, _, _, _, _, _, _, _, _, extensions}, _, _} = 
  :public_key.pkix_decode_cert(cert, :otp)

Enum.filter(extensions, fn
  {:Extension, {1, 3, 6, 1, 5, 5, 7, 1, 323, 1}, _, _} -> true
  _ -> false
end) |> List.first()

Question is, do you see fit for the library or is it too special @Fitblip ? it'd probably include a bit code towards ASN1 handling - to get a least some meaningful values returned ..

[Fitblip]

Hey @steffkes - sorry for the long delay in getting back to you!

I'm not clear on exactly what you're proposing, can you clarify? Maybe an example certificate would help.

Thanks!

[steffkes]

well now i'm the one with the late reply, sorry for that. i was playing around with client certificates back then and the situation would require some additional information to be stored within the certificate while all default/standard fields/properties were already in use and couldn't be misused (just to keep things simple).

so my question was actually about the fact that EasySSL would parse the certificate and obviously tell me, that the certificate does use some custom extensions but it didn't offer a way to access those values at all. i'd have to resort to erlang's public_key module, parse the certificate again to be able to get the values i'm interested in (like in the code example above).

maybe we could just parse those values and return them as part of the result? instead of a list of OIDs it could be a map:

%{
  extensions: %{
-    extra: ["1.3.6.1.5.5.7.1.323.2", "1.3.6.1.5.5.7.1.323.1"]
+    extra: %{
+      "1.3.6.1.5.5.7.1.323.2" => "some random value",
+      "1.3.6.1.5.5.7.1.323.1" => <<2, 0, 0, 0, 0, 0, 0, 29, 70, ..., 56, 10>>, 
+    }
  }
}

however the value of such a custom extension would be handled could/would be up to the user and not the libraries concern. thoughts?

[steffkes]

i'm not really familiar with those github features, but @jgautsch reacted with a thumbs up to my initial post .. maybe he'd like to contribute his thoughts about this here as well?