On 4/8/20 6:37 PM, Andrew Zaborowski wrote:
In the case that the trusted CA certificates are provided to
l_certchain_verify() and one of them binary-matches the top CA
certificate in the chain being verified, we'd skip linking it to the
keyring and we'd link the next certificate directly. As a result
that second certificate would be linked to an empty unrestricted keyring
and would not be verified at all.
Instead add the top CA to the keyring and restrict it the same way we
proceed when no trusted CAs are provided.
ell/cert.c | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
@@ -477,19 +479,22 @@ LIB_EXPORT bool l_certchain_verify(struct
* already possess it in order to validate it in any case."
* The following is an optimization to skip verifying the root
- * cert in the chain if it is identical to one of the trusted CA
- * certificates. It also happens to work around a kernel issue
- * preventing self-signed certificates missing the AKID
- * extension from being linked to a keyring.
+ * cert in the chain if it is bitwise-identical to one of the
+ * trusted CA certificates. In that case we don't have to load
+ * all of the trusted certificates into the kernel, link them
+ * to @ca_ring or link @ca_ring to @verify_ring, instead we
+ * load the first certificate into @verify_ring before we set
+ * the restric mode on it, same as when no trusted CAs are
+ * provided.
+ * Note this happens to work around a kernel issue preventing
+ * self-signed certificates missing the optional AKID extension
+ * from being linked to a restricted keyring. That issue would
+ * have affected us if the trusted CA set included such
+ * certificate and the same certificate was at the root of
+ * the chain.
This comment makes things _much_ clearer now. I love it.
All applied, thanks.