Hi Eric and Mimi,
On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote:
A CA cert shall be defined as any X509 certificate that contains the
keyCertSign key usage and has the CA bit set to true.
Hi Eric,
Allowing CA certificates with the digitalSignature key usage flag
enabled defeats the purpose of the new Kconfig. Please update the
above definition to exclude the digitalSignature key usage flag and
modify the code accordingly.
Within v2, the request was made to allow Intermediate CA certificates to be
loaded directly. The Intermediate CA referenced was the one used by kernel.org.
This Intermediate CA contains both digitalSignature and keyCertSign. If the code
is changed to exclude this certificate, now the root CA has to be loaded again. Is that
the intent?
That definitely was not the intent. Nor would it address the issue of
a particular intermediate CA certificate having both keyCertSign and
digitalSignature.
Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains
both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate
CA cert like the one used on kernel.org?
I must be missing something. Isn't the purpose of "keyUsage" to
minimize how a certificate may be used? Why would we want the same
certificate to be used for both certificate signing and code signing?
Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set.
Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature
set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be
challenging and will severely limit usage.
How about allowing both keyCertSign and digitalSignature asserted but
issuing a warning for this case?
Here's my rationale for this proposal.
I assume we should conform to some X.509 specifications. So I checked
"RFC 5280: Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10)
[2].
[1] states in 4.2.1.3. Key Usage,
"If the keyUsage extension is present, then the subject public key
MUST NOT be used to verify signatures on certificates or CRLs unless
the corresponding keyCertSign or cRLSign bit is set. If the subject
public key is only to be used for verifying signatures on
certificates and/or CRLs, then the digitalSignature and
nonRepudiation bits SHOULD NOT be set. However, the digitalSignature
and/or nonRepudiation bits MAY be set in addition to the keyCertSign
and/or cRLSign bits if the subject public key is to be used to verify
signatures on certificates and/or CRLs as well as other objects."
and [2] states in 8.2.2.3 Key usage extension that,
"More than one bit may be set in an instance of the keyUsage extension.
The setting of multiple bits shall not change the meaning of each
individual bit but shall indicate that the certificate may be used for
all of the purposes indicated by the set bits. There may be risks
incurred when setting multiple bits. A review of those risks is
documented in Annex I."
I interpret the above texts as we should allow both keyCertSign and
digitalSignature. However [2] warns about the risks of setting multiple
bits. Quoting Annex I,
"Combining the contentCommitment bit in the keyUsage certificate
extension with other keyUsage bits may have security implications
depending on the security environment in which the certificate is to be
used. If the subject's environment can be fully controlled and trusted,
then there are no specific security implications. For example, in cases
where the subject is fully confident about exactly which data is signed
or cases where the subject is fully confident about the security
characteristics of the authentication protocol being used. If the
subject's environment is not fully controlled or not fully trusted, then
unintentional signing of commitments is possible. Examples include the
use of badly formed authentication exchanges and the use of a rogue
software component. If untrusted environments are used by a subject,
these security implications can be limited through use of the following
measures:
– to not combine the contentCommitment key usage setting in
certificates with any other key usage setting and to use the
corresponding private key only with this certificate;
– to limit the use of private keys associated with certificates that
have the contentCommitment key usage bit set, to environments which
are considered adequately controlled and trustworthy"
So maybe it's useful to add a warning if both keyCertSign and
digitalSignature are asserted.
--
Best regards,
Coiby
