Can an Intermediate CA extend its "Certificate Key Usage" by issuing a new certificate for itself?

Question

I'm trying to understand the purpose of defining self-issued certificate concept in RFC5280 (Internet X509 PKI Certificate and CRL Profile):

Regarding this concept the RFC states:

This specification covers two classes of certificates:

1. CA certificates, and
2. end entity certificates

CA certificates may be further divided into three classes:

1. cross-certificates,
2. self-issued certificates, and
3. self-signed certificates

Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs.

Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations.

Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths.

End entity certificates are issued to subjects that are not authorized to issue certificates.

Ok, let's dive into questions:

• First Question: What exactly is the difference between self-issued and self-signed certificates? Based on my understanding, all self-signed certificates are self-issued and also all self-issued certificate are self-signed! So they must be same thing! The only difference that I can imagine is that: self-issued certificate can appear in the middle of trust-chain (somehow!), but the self-signed can't.

To answer the above question clearly, I think I have to also ask the second quesiton:

• Second Quetions: Should an intermediate CA be able to issue a new certificate with different attributes for itself (for example with extended Certificate Key Usage)?

Well, I think no, it souldn't! Because such a capability can bypass the need for Root CA to sign Intermediate's Certificate Key Usage data!

And if I am correct about it, then the only entity that can issue self-issued certificate would be the root CA itself. But why a root CA may needs self-issued certificate? What are the use-cases? Why it just not create a whole new root certificate instead of adding a new member to trust-chain if it needs new attributes?

And if I am wrong about it, then it means that there must be some cases that the intermediate CA shall be able to issue new certificates for itself. If so, can an intermediate CA extend its certificate capability by issueing a new certificate for itself with extended Certificate Key Usage data? Isn't this a flaw in the chain of trust? Moreover, how the certificate verifier can find out if an intermediate CA in the trust-chain is allowed to do such a thing or not?

Answer 1

What exactly is the difference between self-issued and self-signed certificates?

A self-issued certificate is a certificate where the Issuer Name and Subject Name are the same.

A self-signed certificate is a certificate which was signed with the private key that matches the public key from the certificate. RFC 5280 further restricts the term to only be self-issued certificates comply.

A self-issued certificate need not be self-signed. Here's a sample chain with a self-issued certificate as both the root (self-signed) and the intermediate (not-self-signed):

-----BEGIN CERTIFICATE-----
MIIBOzCBw6ADAgECAgQCAAAAMAoGCCqGSM49BAMCMA8xDTALBgNVBAMTBFNlbGYw
HhcNMjMwMTMxMjI1NzM0WhcNMjMwMTMxMjMwNzM0WjAPMQ0wCwYDVQQDEwRMZWFm
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE/jQ9efIuXzQvKllT2z5EudFKPyHq
l48oObSTIG8lNoOdkCg3uz0A/ZSdVOlUr/UUI9o46QEDFuvo6RXPsxB8XqMNMAsw
CQYDVR0TBAIwADAKBggqhkjOPQQDAgNnADBkAjAsJVkGJrDh0X1/uZ5tHgfvCziw
CnoHd1Dme7PrmkHRiu73c8pw2oBnnpUbObWuUdkCMBxKjiAk8A1PtSYSHIOWFQx2
zZ4e3IHs2ksXR2czgpX3DnjfdWzBzk5Zg+ubHDrl3Q==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICUTCCATmgAwIBAgIEAQAAADANBgkqhkiG9w0BAQsFADAPMQ0wCwYDVQQDEwRT
ZWxmMB4XDTIzMDEzMTIyNDczNFoXDTIzMDEzMTIzMTczNFowDzENMAsGA1UEAxME
U2VsZjB2MBAGByqGSM49AgEGBSuBBAAiA2IABKkn3SOCpGnXwNrqXER6ZCRjwI8R
UI94Dq0P23nBL/LCxv62KfQIk5E8q/OL3BgUuPG+W9UZToiT3MSnRhnhSNezu2D7
NDToMkUb1Y7N81MgMgCQDnm5mPd+1bfpTQFitaNjMGEwDwYDVR0TAQH/BAUwAwEB
/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFG06LdN0JEKz/09kt3ebThRw8JEJ
MB8GA1UdIwQYMBaAFPkA3D9/yC1hMOBqhF5ywbosxsUZMA0GCSqGSIb3DQEBCwUA
A4IBAQArK7DfRVxfTlQQFli1NLFRqZjHlWzWlDbTIwjuWWuZamxgk30QE8UV2ex+
FqBaiMI2fg9sMEdU+SW03BLreNd//hztu22ws/rPZokdt/NUoFmj+T+qWWj36e1E
vDLGf1XrfmAQRtDlLMfUofJNCcY3EOK0uD1gv6VDVh8OBwfCJG4J7UYrJlRtlJ9e
LXWoNp5bcekCrD9xbNihTbJs2XfFl090izEr3hzeNHFC49BfMsOrLsTVg7qbRYIM
Dm4CRL7FgEzCTUW4WQC/yXORKInaZyZfT7rTYvX2NFRStKc/7yLaA1xBAnFYDRdi
FQVzon2oAkEUMbmmZK57brpU9zI4
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC4jCCAcqgAwIBAgIIPK+1z76F+u4wDQYJKoZIhvcNAQELBQAwDzENMAsGA1UE
AxMEU2VsZjAeFw0yMzAxMzEyMjQyMzRaFw0yMzAxMzEyMzIyMzRaMA8xDTALBgNV
BAMTBFNlbGYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDexGJ26Ax5
DtJahbhNodv/X6TLMYMzNHN6E5xce/SSREe+VAAnI2qvARIEc3KqTyHEdxsHmwmX
Zg3sA05BzYOBk647yNe1fLtTCjyyOIyfF2NfDQ03D/u55XeXAl6DojJC4QXHJos3
Oku5fATC3skBsAXLjSAzZqqPVIYcyEAbLVwYE7Msqnhj2CcUzMyjKsua/KYPtGh9
RUwQEu5bQ2PioCxSm24CkvNq7Ec1dIDzFEg1Md5UuQ/2Fyk+OCTfxqwmSRrqqxsE
DhOa4i7+gdbb+FdMw3NaN4Eyw5Egbcx0PMRW14Fj4hjle+jmUBYoMIQf4+R86Ys/
JxFuj09SM2nZAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQD
AgEGMB0GA1UdDgQWBBT5ANw/f8gtYTDgaoRecsG6LMbFGTANBgkqhkiG9w0BAQsF
AAOCAQEAtODz6pGv5TD+QDEAOB0vNx0Ua2gvKArbSAzSkgTzp7+mMDfcFvo44yqD
hlGZYuICCkxyq1QrtqRMvdI01zLJnIUl6fBnsn15jFrGEJarplh/FA2/6OhssuOV
SX/42w4aMdWpQiffnUcgXBkFuU0l/mMeBt/+Pd/QCh5iwjw7PqvAZ4WyNP1Z5PSr
5d6SKCsguBf3oyXnzwFIP8cOIxmDb7TLZmcqnx8hqUDUJBdLfteskEmXWqLa6VOF
PenfD6DtPgeTjbMcGFiXK2D8xLs24mbQHoq3+aURWJSA4sSBWp+6zdi6EaRovm3u
a8rSz5cMX2q5NpsxH+4dbTy7nWy2jw==
-----END CERTIFICATE-----

The root uses an RSA-2048 key, and just to show how different they are, the intermediate uses an ECDSA secp256r1 key.

You may run into mixed mileage with chain engine support for self-issued-but-not-self-signed certificates. If those certificates were not linked by Subject Key Identifier + Authority Key Identifier, the Windows chain engine ignores the RSA-based-Self and says it's a two-item chain but the root's signature doesn't work out correctly. The OpenSSL chain engine, by default, doesn't even bother checking the signature for a self-issued cert that is "probably" self-signed, so it returns the same two-item chain that Windows does, but says it worked out just fine (if you pass the two "CN=Self" certs in the same -CAfile file, so they both count as trusted).

Should an intermediate CA be able to issue a new certificate with different attributes for itself (for example with extended Certificate Key Usage)?

Sure. For places where you're restricting purpose (Extended Key Usage, Name Constraints) there are already narrowing rules in place for the chain, the new CA can't "gain scope", but it can certainly rewrite attributes about "itself". It's not generally done, but it's technically possible.