Skip to content

X509 import#697

Open
sjaeckel wants to merge 45 commits intodevelopfrom
x509_import
Open

X509 import#697
sjaeckel wants to merge 45 commits intodevelopfrom
x509_import

Conversation

@sjaeckel
Copy link
Copy Markdown
Member

@sjaeckel sjaeckel commented Sep 8, 2025

Start implemeting X.509 APIs.

In #693 this was requested and I was already at it and now we have the first part: Parsing of an X.509 certificate and the cryptographic validation of such a certificate.

NB: This does not yet contain the logic that is required to determine whether a CA is eligible to sign a certificate etc.

Checklist

  • documentation is added or updated
  • tests are added or updated

@sjaeckel sjaeckel requested review from karel-m and levitte September 8, 2025 12:20
@sjaeckel sjaeckel marked this pull request as draft September 8, 2025 12:21
@sjaeckel sjaeckel force-pushed the x509_import branch 8 times, most recently from a342826 to d9b0684 Compare September 11, 2025 12:50
@sjaeckel sjaeckel force-pushed the some-improvements branch 2 times, most recently from 028775e to 6fe53a5 Compare September 12, 2025 16:50
Base automatically changed from some-improvements to develop September 15, 2025 13:35
@sjaeckel sjaeckel mentioned this pull request Oct 3, 2025
@sjaeckel sjaeckel changed the base branch from develop to new-rsa-api November 19, 2025 14:44
@sjaeckel sjaeckel added this to the next-next milestone Nov 24, 2025
@karel-m karel-m marked this pull request as ready for review April 11, 2026 21:33
@karel-m karel-m marked this pull request as draft April 11, 2026 21:33
@karel-m
Copy link
Copy Markdown
Member

karel-m commented Apr 11, 2026

@sjaeckel Why was the CI pipeline with tests and builds not triggered after my last commit?

@karel-m
Copy link
Copy Markdown
Member

karel-m commented Apr 16, 2026

I've just reviewed this PR and pushed a few commits. Two issues I’m still not happy with:

  • We are not rejecting certificates that contain unrecognized critical extensions, as required by RFC 5280 section 4.2. I've just added a comment to code about this.
  • It is a bit surprising that x509_free takes ltc_x509_certificate ** as its argument. Other _free functions take a single pointer (rsa_free, ecc_free, pka_key_free ...) so x509_free is currently the odd one out.

I also managed to break the CI tests somehow; however, it is too late tonight for me to fix that now.

Copy link
Copy Markdown
Member

@karel-m karel-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my commits

Copy link
Copy Markdown
Member Author

@sjaeckel sjaeckel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • We are not rejecting certificates that contain unrecognized critical extensions, as required by RFC 5280 section 4.2. I've just added a comment to code about this.

Good point!

  • It is a bit surprising that x509_free takes ltc_x509_certificate ** as its argument. Other _free functions take a single pointer (rsa_free, ecc_free, pka_key_free ...) so x509_free is currently the odd one out.

Because I like the pattern more. I prefer to be on the safe side, see also the commit I just added which introduces the same pattern for s_free().

Comment on lines +649 to +653
/* TODO: RFC 5280 4.2 requires rejecting certs with unrecognized critical extensions
but currently it cannot be rejected here as some critical extensions are not decoded
like: Name Constraints, Inhibit Any Policy, No Revocation Available, OCSP No Check,
Proxy Certificate Information, ac-auditEntity
*/
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While adding some of them as dummy I came to the conclusion: this is just parsing and not validation. Should we maybe track this as "yes, it's a valid topic, but not now"?

I've collected the following infos on the extensions you mentioned which are tracked outside RFC 5280:

  1. No Revocation Available is CRITICALITY { FALSE }
  2. OCSP No Check The RFC says: The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL.
  3. Proxy Certificate Information is indeed critical
  4. ac-auditEntity I couldn't find anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants