The X.509v3 CRL Distribution Points (CRL DP) extension plays a crucial role in Public Key Infrastructure (PKI) by ensuring proper certificate revocation handling. Many security frameworks and compliance standards mandate the inclusion of a CRL DP URL, allowing systems to verify the revocation status of certificates efficiently. Without this extension, certificates may not meet essential security requirements, impacting trust and validation processes.
Currently, it appears that TMS Crypto Pack does not provide an option to include the CRL DP extension when generating or signing certificates.
Questions:
Is there an existing method to include the X.509v3 CRL Distribution Points extension in certificates generated with TMS Crypto Pack?
If not currently supported, are there plans to introduce this feature in a future update?
Are there any recommended workarounds to manually add the CRL DP field to certificates created with TMS Crypto Pack?
Hi Helmut,
On 1 and 3, the answer is no because the generated ASN.1 doesn't include these OIDs and you can't fix that manually.
On 2, will try to add these OIDs in the next release. Could take a couple of weeks due to other ongoing tasks.
Since I purchased your license and received the source code, I've extended your code to properly handle CRL Distribution Points according to the ASN.1 standard. I'm eager to contribute these improvements back to your project. Could you please let me know the process or guidelines for submitting contributions?
Hello Helmut, thanks for your offer!
There is no specific process to contribute and I suggest you just send me to modified code with a revision date and possible markers to identify the releavnt functions.
Regarding the X509v3 structure, the standard identifies mandatory and optional sections. However, the OID order within sections is free, and some decoders are more permissive than others.
I recommend you use Lapo instead of Cyberchef for X509/PEM objects. I find it more reliable. Another good tool is ASN.1 Editor (free version).
On the correct/incorrect OID for RSA, it is not that clear as it can depend on factors such as the use context and the reference RFC. Otherwise stated, there is not always a single OID for an algorithm, especially if used in combination with another one.
