Whether attribute certificates can be used in the public_key module.

We are trying to implement a feature for issuing attribute certificates using records such as AttributeCertificate, which are defined in public_key.hrl

We checked if a certificate generated by the public_key module could be read/parsed correctly by a modified OpenSSL 3 implementation with the attribute certificates.

Since I could confirm that the record was defined in the header, I obtained a test acert.pem that was included in the pull request to make openssl3 support attribute certificates, and tried to see if I could parse it.

I tried to see if I could expand it with public_key:pem_decode/1, but it only returned an empty list.

1> {ok, Bin} = file:read_file("acert.pem").
2> public_key:pem_decode(Bin).

After removing the header and footer listed in the PEM format and changing it to DER format with base64 decoding, we confirmed that it could be read with public_key:der_decode/2.

1> {ok, Bin} = file:read_file("acert.der").
2> public_key:der_decode('AttributeCertificate', Bin).

The current functionality that has already been implemented in public_key module is sufficient for our objective of handling the certificate in DER format.

We would like to use the public_key module functionality for issuing a platform certificate defined by TCG.


I would like to confirm that the handling of attribute certificates in the public_key module of Erlang/OTP will not be deprecated and will remain supported.

Are the attribute certificates defined in RFC5755 and the related RFCs currently supported in the public_key module?


My understanding is that the support, as it is for general X.509 work, is this support is mostly incidental as this is all just pure ASN.1 decoding.

Lurking in https://github.com/erlang/otp/tree/master/lib/public_key/asn1 is a list of .asn1 files that tend to be just verbatim extracted from IETF materials and elsewhere.

During the building of OTP, these get converted into records that represent the underlying ASN.1 form. public_key then provides some functions to work with these records (typically outputting DER).

Anything not in there I suspect would just appear as raw non-human readable objects…plus nothing stops anyone just using their own ASN.1 definitions.

So probably not a question of ‘support’ as all this needs is an ASN.1 decoder which OTP has built in.

To actually work with AttributeCertificate you still need to do the hard coding part which not even OpenSSL does :slight_smile: