Improve the documentation of cert path building and validation#13735
Improve the documentation of cert path building and validation#13735DDvO wants to merge 7 commits intoopenssl:masterfrom
Conversation
9df6957 to
f5f63e0
Compare
|
|
f191711 to
813f382
Compare
vdukhovni
left a comment
There was a problem hiding this comment.
Not a thorough review, just a few nits from a drive-by read.
|
I've just added the following (small) commits:
|
|
Thanks @vdukhovni for having a quick look |
|
I've meanwhile updated and strongly improved the documentation of trust anchors. |
|
Doing further improvements on the |
|
Are there any further review comments on this? |
|
Needs rebase now |
8d2ca69 to
9f5a89e
Compare
Thanks for the notice; done. |
t8m
left a comment
There was a problem hiding this comment.
Just some nits. Otherwise good work!
|
Is it time yet to retire support for the "Netscape" certificate features? Perhaps this is all dead code that no users are relying on? |
|
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." " |
8be23b4 to
18a5006
Compare
|
Good point that support for Netscape certs and the respective documentation should be removed. |
Thanks @t8m. I've handled all items (as far as it makes sense within this PR). |
There was a problem hiding this comment.
While you're here, perhaps rewrite the first (remaining) sentence. It is rather clumsy.
There was a problem hiding this comment.
Indeed. I've polished this one and the following paragraph.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This needs a bit more work. "... related to the purposes of using ..." is not particularly clear or well phrased.
There was a problem hiding this comment.
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 theC<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.
There was a problem hiding this comment.
This makes it sound like certificates not in the trust store might be trusted just by matching a few fields of a trusted certificate.
There was a problem hiding this comment.
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.
- ...
abe06de to
3900a21
Compare
|
This PR is in a state where it requires action by @openssl/otc but the last update was 61 days ago |
|
@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. |
|
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. |
|
Thanks for your response. |
|
BTW, when is the beta release currently planned/expected? |
paulidale
left a comment
There was a problem hiding this comment.
Typographic and wording suggestions. This looks good.
|
This pull request is ready to merge |
Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
…ity, improve their doc Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
This hopefully alleviates the fact that the name is unclear/misleading. Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from #13735)
|
Merged. Glad this through, after long time in between. |
Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
…ity, improve their doc Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
This hopefully alleviates the fact that the name is unclear/misleading. Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
Reviewed-by: Paul Dale <[email protected]> (Merged from openssl#13735)
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.intoopenssl-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 certificateChecklist