Skip to content

Improve the documentation of cert path building and validation#13735

Closed
DDvO wants to merge 7 commits intoopenssl:masterfrom
siemens:chain_build_verify_doc
Closed

Improve the documentation of cert path building and validation#13735
DDvO wants to merge 7 commits intoopenssl:masterfrom
siemens:chain_build_verify_doc

Conversation

@DDvO
Copy link
Contributor

@DDvO DDvO commented Dec 23, 2020

This has been motivated initially by a recent question in the openssl-users mailing list.
Answering it, I found that some important points were missing from the documentation
of the certification path building and validation process, which I've added.

This also updates and strongly improves the documentation of trust anchors and the related concepts of "purpose", "use", and "trust" attributes
and moves documentation of EKU cert extension checking from openssl-x509.pod.in to openssl-verification-options.pod.

Still, there are many more details that would be good to add.

On this occasion, as motivated by #13735 (comment):

  • X509_verify_cert(): Take first element of untrusted list as default target certificate
Checklist
  • documentation is added or updated
  • tests are added or updated

@DDvO
Copy link
Contributor Author

DDvO commented Jan 2, 2021

The "check_update" CI failure is unrelated and should be handled elsewhere.
I've extended this PR as discussed in #7871; it is ready for further review.

@DDvO DDvO force-pushed the chain_build_verify_doc branch from f191711 to 813f382 Compare January 4, 2021 07:15
Copy link

@vdukhovni vdukhovni left a comment

Choose a reason for hiding this comment

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

Not a thorough review, just a few nits from a drive-by read.

@DDvO
Copy link
Contributor Author

DDvO commented Jan 4, 2021

I've just added the following (small) commits:

  • X509_STORE_CTX_new.pod and x509_vfy.h.in: rename some params for clarity, improve their doc
  • x509_vfy.c: Improve a couple of internally documenting comments
  • x509_trs.c: rename to x509_trust.c for clarity and correct comment in trust_compat()

@DDvO
Copy link
Contributor Author

DDvO commented Jan 4, 2021

Thanks @vdukhovni for having a quick look
and sorry for all those typos (it was a long day yesterday). Fixed them.

@DDvO
Copy link
Contributor Author

DDvO commented Jan 4, 2021

I've meanwhile updated and strongly improved the documentation of trust anchors.
This took me half a day because to this end had to understand at least to some level
the related concepts of "purpose", "use", and "trust" attributes, which are very poorly documented.
The text I've added/updated here is still not complete on these topics but should bring major improvements.

@DDvO DDvO added this to the 3.0.0 milestone Jan 6, 2021
@DDvO DDvO added the triaged: documentation The issue/pr deals with documentation (errors) label Jan 6, 2021
@DDvO
Copy link
Contributor Author

DDvO commented Jan 6, 2021

Doing further improvements on the x509 app I just came across documentation of EKU cert extension checking in openssl-x509.pod.in.
Since this is actually of more general nature and makes much more sense in openssl-verification-options.pod I've moved it there.

@DDvO
Copy link
Contributor Author

DDvO commented Jan 14, 2021

Are there any further review comments on this?

@t8m
Copy link
Member

t8m commented Jan 20, 2021

Needs rebase now

@DDvO DDvO force-pushed the chain_build_verify_doc branch from 8d2ca69 to 9f5a89e Compare January 21, 2021 07:58
@DDvO
Copy link
Contributor Author

DDvO commented Jan 21, 2021

Needs rebase now

Thanks for the notice; done.

Copy link
Member

@t8m t8m left a comment

Choose a reason for hiding this comment

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

Just some nits. Otherwise good work!

@vdukhovni
Copy link

Is it time yet to retire support for the "Netscape" certificate features? Perhaps this is all dead code that no users are relying on?
Are any CAs still creating this type of certificate?

@richsalz
Copy link
Contributor

See #9247 #9242 #9241

Quoting a comment from #9241: "To quote email from Mozilla folks I have: "In general if there is an IETF PKIX replacement for a Netscape datatype, then you don't need to support the Netscape datatype. Therefore OpenSSL does not need to support Netscape cert types and Netscape cert sequence." "

@DDvO DDvO force-pushed the chain_build_verify_doc branch from 8be23b4 to 18a5006 Compare January 27, 2021 20:08
@DDvO
Copy link
Contributor Author

DDvO commented Jan 27, 2021

Good point that support for Netscape certs and the respective documentation should be removed.
This is certainly to be done in a separate PR.

@DDvO
Copy link
Contributor Author

DDvO commented Jan 27, 2021

Just some nits. Otherwise good work!

Thanks @t8m. I've handled all items (as far as it makes sense within this PR).

Choose a reason for hiding this comment

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

While you're here, perhaps rewrite the first (remaining) sentence. It is rather clumsy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed. I've polished this one and the following paragraph.

Choose a reason for hiding this comment

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

I don't see that the subject key identifier is particularly special here. Perhaps you're thinking about checks whether the TA cert is self-signed, which may in some cases use the SKID to make that conclusion. If so, just say that OpenSSL will likely also check whether the TA cert is self-signed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Self-signedness of TAs is usually not checked.
I referred to the SKID at this point for another reason.
I've made this more clear by:

OpenSSL checks the validity period of such certificates
and makes use of some further fields.
In particular, the subject key identifier extension, if present,
is used for matching trust anchors during chain building.

Choose a reason for hiding this comment

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

This needs a bit more work. "... related to the purposes of using ..." is not particularly clear or well phrased.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is indeed a bit unclear - precisely because, as I wrote, I am not fully sure about how purpose, EKUs, and trust attributes interrelate. Here is a 2nd try.

From the OpenSSL perspective, a trust anchor is a certificate
that should be augmented with an explicit designation for which
uses of a target certificate the certificate may serve as a trust anchor.
In PEM encoding, this is indicated by the C<TRUSTED CERTIFICATE> string.
Such a designation provides a set of positive trust attributes
explicitly stating trust for the listed purposes
and/or a set of negative trust attributes
explicitly rejecting the use for the listed purposes.
The purposes are encoded using the values defined for the extended key usages
(EKUs) that may be given in X.509 extensions of end-entity certificates.

Choose a reason for hiding this comment

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

This makes it sound like certificates not in the trust store might be trusted just by matching a few fields of a trusted certificate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought it was this way, but it I understand you correctly,
at least the intended semantics is as follows, and I've changed the text accordingly:

A certificate, which may be CA certificate or an end-entity certificate,
is considered a trust anchor for the given use
if and only if all the following conditions hold.

  • It is an an element of the trust store.
  • It does not have a negative trust attribute rejecting the given use.
  • ...

@DDvO DDvO force-pushed the chain_build_verify_doc branch from abe06de to 3900a21 Compare April 21, 2021 05:06
@openssl-machine
Copy link
Collaborator

This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago

@DDvO
Copy link
Contributor Author

DDvO commented Jun 3, 2021

@openssl/otc, this PR (as well as a couple of other cert-related PRs of mine) have been stuck for many months due to missing further treatment by the OTC.

The relevance of improving the documentation of cert path validation, in particular on the details of trust vs. purpose, is exemplified by a recent discussion on https://www.mail-archive.com/[email protected]/msg89496.html.
Among others, the author of that thread complained, like I did more than a year ago, about the pretty tautological and thus useless "documentation" of X509_VERIFY_PARAM_set_trust():

X509_VERIFY_PARAM_set_trust() sets the trust setting in B<param> to B<trust>.

@t8m
Copy link
Member

t8m commented Jun 3, 2021

IMO, apart from the x509.h changes this would be mergeable after the beta release. It is also a quite big change to the documentation, so it will require some time to properly review and so it would be nice to be able to postpone this after beta. Unfortunately this is another example of PR that mixes multiple unrelated things into a single PR.

@DDvO
Copy link
Contributor Author

DDvO commented Jun 3, 2021

Thanks for your response.
So when I find the time I will somehow split this PR in more digestable pieces.

@DDvO
Copy link
Contributor Author

DDvO commented Jun 3, 2021

BTW, when is the beta release currently planned/expected?
Is it June 30th as indicated in the respective GitHub milestone label?

Copy link
Contributor

@paulidale paulidale left a comment

Choose a reason for hiding this comment

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

Typographic and wording suggestions. This looks good.

Copy link
Contributor

Choose a reason for hiding this comment

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

Drop it is my vote.

@github-actions github-actions bot added the severity: fips change The pull request changes FIPS provider sources label Jun 4, 2021
@paulidale paulidale added approval: done This pull request has the required number of approvals branch: master Applies to master branch and removed approval: otc review pending labels Jun 7, 2021
@openssl-machine openssl-machine removed the approval: done This pull request has the required number of approvals label Jun 8, 2021
@openssl-machine
Copy link
Collaborator

This pull request is ready to merge

@openssl-machine openssl-machine added the approval: ready to merge The 24 hour grace period has passed, ready to merge label Jun 8, 2021
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
…ity, improve their doc

Reviewed-by: Paul Dale <[email protected]>
(Merged from #13735)
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
This hopefully alleviates the fact that the name is unclear/misleading.

Reviewed-by: Paul Dale <[email protected]>
(Merged from #13735)
openssl-machine pushed a commit that referenced this pull request Jun 8, 2021
@DDvO
Copy link
Contributor Author

DDvO commented Jun 8, 2021

Merged. Glad this through, after long time in between.
Thanks to all who contributed and to @pauildale for giving the final thrust.

@DDvO DDvO closed this Jun 8, 2021
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
This hopefully alleviates the fact that the name is unclear/misleading.

Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#13735)
devnexen pushed a commit to devnexen/openssl that referenced this pull request Jul 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval: ready to merge The 24 hour grace period has passed, ready to merge branch: master Applies to master branch severity: fips change The pull request changes FIPS provider sources triaged: documentation The issue/pr deals with documentation (errors)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants