Subject: 3280bis issue: issues related to self-issued certificates

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 17 Nov 2004 18:36:54 +0800

The definition of the term "self-issued certificate" is too vague.

The current text of RFC 3280 only mention

"A certificate is self-issued if the DNs that appear in the subject
 and issuer fields are identical and are not empty....a CA may
 issue a certificate to itself to support key rollover or changes in
 certificate policies.  These self-issued certificates are not counted
 when evaluating path length or name constraints."

However, there are many kinds of self-issued certificates. For
example:

(a) self-signed certificates (this is a special case of self-issued certificate)
(b) self-issued certificates with keyCertSign key usage (might with cRLSign key usage as well)
(c) self-issued certificates with cRLSign key usage only (a CA using separate key for CRL signing)
(d) self-issued certificates with key usages other than keyCertSign and cRLSign

Self-issued certificates of type (c) are also known as "self-issued
intermediate certificates" according to the X.509 (2000) standard.
Obviously, only self-issued certificates of type (c) are thought to
be CA certificates. However, they are special CA certificates
for special purpose (e.g., Key Rollover) so that they do not contribute
to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation.

Self-issued certificates of type (a), (c) and (d) can not be
intermediate certificates and thus the above special processing
rule does not apply to them. This is not crystal clear in the current
text of RFC 3280.

Obviously, self-issued certificates of type (a) and (b) should conatins
a basicConstraints extension with cA = TRUE since they are
CA certificates.

It is not clear whether self-issued certificates of type (c) should
also conatins a basicConstraints extension with cA = TRUE.

Self-issued certificates of type (d) should be thought as EE
certificates, therefore they should not contain  a basicConstraints
extension with cA = TRUE. However, some PKIX WG members
might not agree to this interpretation.

When perform path validation, it is not clear what will be the effect
if some certificate extensions such as polcyMappings, policyConstraints,
nameConstraints, and inhibitAnyPolicy appear in self-issued 
intermediate certificates (i.e., self-issued certificate of type (b)).
The current text only says that this type of self-issued certificates do not
contribute to the path length for purposes of processing some constraint
extension and name constrains extension in certification path validation,
it is not clear that whether these extensions can appear in this type of
self-issued certificate.

There is a serious security problem related to revocation status
checking for self-issued certificates of type (b) and (c).
For type (b), it might be a CA key rollover situation, and if the CA stopped
using its old key to issue CRL, then there is no way to check the revocation
status of the new self-issued certificate unless there is another way (e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If the new key is unfortunately compromised later, this will be a serious
security problem.

For type (c), since the CA is using separate key for CRL signing and
its Certificate with cRLSign key usage is signed by itself not signed
by another CA. Therefore, no one can provide the revocation status
info for that self-issued certificates unless there is another way (e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If its CRL signing key is unfortunately compromised, this will be a serious
security problem.

Finally, it is not clear that, when a RP choose to use X.500 string matching
rules (or StringPrep-based String matching rules), whether certificates with
identical non-empty issuer name and subjec name but with different string
encoding (e.g., one in PrintableString while one in UTF8String) are also
thought as self-issued certificates.

Wen-Cheng Wang

---

From: Tom Gindin <[email-masked]>
Date: Thu, 18 Nov 2004 07:36:36 -0500

Wen-Cheng:

        Do we also need to distinguish between self-signed certs used as 
CA roots (either v1 or those with keyCertSign set) and all other 
self-signed certs?
        Responses below.

                Tom Gindin

"Wen-Cheng Wang" <[email-masked]>
Sent by: [email-masked]
11/17/2004 05:36 AM
 
        To:     "David A. Cooper" <[email-masked]>, "pkix" 
<[email-masked]>
        cc: 
        Subject:        3280bis issue:  issues related to self-issued 
certificates

(a) self-signed certificates (this is a special case of self-issued 
certificate)
(b) self-issued certificates with keyCertSign key usage (might with 
cRLSign key usage as well)
(c) self-issued certificates with cRLSign key usage only (a CA using 
separate key for CRL signing)
(d) self-issued certificates with key usages other than keyCertSign and 
cRLSign

[TG] You do mean type (b), don't you?

[TG] RFC 3280 4.2.1.10 says MAY, and it classifies CMP certificates with 
them.

The current text only says that this type of self-issued certificates do 
not

There is a serious security problem related to revocation status
checking for self-issued certificates of type (b) and (c).
For type (b), it might be a CA key rollover situation, and if the CA 
stopped
using its old key to issue CRL, then there is no way to check the 
revocation
status of the new self-issued certificate unless there is another way 
(e.g.,
OCSP or other out-of-band mechanism) to check its revocation status.
If the new key is unfortunately compromised later, this will be a serious
security problem.

If its CRL signing key is unfortunately compromised, this will be a 
serious
security problem.

[TG] Issue a new CRL signing key and revoke the old one.  The revocation 
will take effect with the same timing effects as the revocation of an EE 
certificate - an attacker can always replay a CRL until its expiration 
time.

Finally, it is not clear that, when a RP choose to use X.500 string 
matching
rules (or StringPrep-based String matching rules), whether certificates 
with
identical non-empty issuer name and subjec name but with different string
encoding (e.g., one in PrintableString while one in UTF8String) are also
thought as self-issued certificates.

Wen-Cheng Wang

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Nov 2004 14:27:23 -0500

>rule does not apply to them. This is not crystal clear in the current

I think the rules are spelled out very clearly in section 6.

Self-signed certificates are only used as a source of trust anchor 
information.  Section 6.1.1 step (d) specifies the information that is 
to be extracted from the self-signed certificate (and also indicates 
that this information does not need to be provided in the form of a 
self-signed certificate).  X509 explicitly states that self-signed 
certificates may not appear as intermediate certificates, and this 
should probably be stated in 3280bis as well.

In sections 6.1.3, 6.1.4, and 6.1.5, self-issued certificates (whether 
intermediate or not) are treated in exactly the same manner as other 
certificates except where the text explicitly states that they should be 
treated differently.

For example, in section 6.1.4, steps (a) and (b) do not provide an 
exception for self-issued certificates, so any policyMappings extension 
would be processed the same as if it were in a non-self-issued 
certificate.  Similarly, step (i) indicates that a policyConstraints 
extension should be processed the same for self-issued and 
non-self-issued certificates.  However, step (h) indicates that the 
explicit_policy and policy_mapping counters would not be decremented 
when processing a self-issued certificate.

In general, if a constraint extension appears in a self-issued 
certificate (other than a self-signed certificate), it is processed in 
the same way as if it appeared in a non-self-issued certificate.  
However, intermediate self-issued certificates are usually (but not 
always) exempted from the constraints imposed by certificates that 
preceded it in the path.

>might not agree to this interpretation.
This confusion is very unfortunate.  X.509 is very clear: "The cA 
component indicates if the certified public key may be used to verify 
certificate signatures."

So the problem is with RFC 3280.  X.509 is quite clear that the cA bit 
is not set to true for self-issued certificates of types (c) and (d) 
because the certified public key may not be used to verify certificate 
signatures.

>if some certificate extensions such as policyMappings, policyConstraints,
I think it is important to address these issues, but believe that will 
need to be in a separate document, not in 3280bis.

>thought as self-issued certificates.
If the issuer and subject name in a certificate match (according to the 
rules specified in stringprep or whatever), the the certificate is a 
self-issued certificate.  The problem, of course, is that many relying 
parties, using more limited matching rules, will not recognize that the 
certificate is self-issued and will treat it as a non-self-issued 
certificate.

Dave

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 19 Nov 2004 18:06:51 +0800

Tom,

Yes, I do mean certificates of type (b) are self-issued
intermediate certificates. Thanks for correcting my typo.

And, you are right, RFC 3280 4.2.1.10 implies that type (c)
MAY contain a basicConstraints extension with cA = TRUE.
It even implies that type (d) MAY also contain a basicConstraints
extension with cA = TRUE, which are CMP certificates you
refered.

However, after rereading RFC 3280, my feeling is the
definition of the term "CA certificate" is not clear enough.
The meaning of the term "CA certificate" is not consistent
all over the text of RFC 3280.

For example:

RFC 3280 4.2.1.2 says
   To facilitate certification path construction, this extension MUST
   appear in all conforming CA certificates, that is, all certificates
   including the basic constraints extension (section 4.2.1.10) where
   the value of cA is TRUE.

That seems to imply "CA certificates" are "certificates contain the
basicConstraints extension with cA = TRUE". This also implies
that "certificates that do not conatin the basicConstraints extension
with cA = TRUE" are not "CA certificates". (i.e., they are EE
certificates.)

However, RFC 3280 4.2.1.10 says
   This extension (basicConstraints) MAY appear as a critical
   or non-critical extension in CA certificates that contain public keys
   used exclusively for purposes other than validating digital
   signatures on certificates.

That imply "CA certificates" need not conatin "the basicConstraints
extension with cA = TRUE" as long as the keyCertSign bit is not set
in the keyUsage extension it contains (if any).

Actually, I found the X.509 standard itself has some conflicts
about the definition of "CA certificates".

X.509 (2000) 3.3.9 says
   CA-certificate:  A certificate for one CA issued by another CA.

It seems that the term "CA certificate" is simple a synonym of
"cross certificate".

However, X.509 (2000) chapter 7 says
   A CA-certificate is a certificate issued by a CA to a subject that is
   itself a CA and therefore is capable of issuing public-key certificates.
   CA-certificates can be themselves categorized by the following types:
     - Self-issued certificate - ...
     - Self-signed certificate - ... 
     - Cross certificate - ...

That means a CA certificate not only can be "a certificate for one CA
issued by another CA" (a cross certificate) but also can be "a
certificate for one CA issued by the CA itself" (a self-issued certificate or
a self-signed certificate).

In both X.509 and RFC 3280, mostly the term "a CA certificate" actually
means "a CA certificate with keyCertSign key usage".

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) says

   This field, which shall be used in CA-certificates only, ...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in CA certificates. ...

In these cases, by "CA certificates" they actually mean
"a CA certificate with keyCertSign key usage" since policy
mappings extension should not appear in a CA certificates
without keyCertSign key usage.

The current usages of the term "CA certificate" in both X.509
and RFC 3280 are not precise enough. As a result, when we
see the term "CA certificate" in X.509 and RFC 3280, we have
to guess its meaning from the context.  It might mean a
Root CA certificate, a cross certificate, an self-issued
intermediate certificate (with keyCertSign key usage ),
a self-issued certificate with cRLSign key usage only, or
a self-issued certificate with key usages other than keyCertSign
and  cRLSign.

To make the useage of the term more precise, I suggest
RFC3280bis (and X.509 as well) should claerly define the
following terms:
  "self-issued certificate"
  "self-signed certificate"
  "self-issued intermediate certificate"
  "cross certificate"
  "CA certificate"
  "root CA certificate (a.k.a. root certificate)"
  "intermediate CA certificate (a.k.a. intermediate certificate)"

For example, the term "intermediate CA certificate" might
be defined as follows:

   intermediate CA certificate:
         a cross certificate or a self-issued intermediate certificate

With this definition, the usages of the term "CA certificate" in
both X.509 and RFC 3280 can be more precise.

For example,

X.509 (2000) 8.2.2.7 (Policy mappings extension) can say

   This field, which shall be used in intermediate CA-certificates only, ...

RFC 3280 4.2.1.6 (Policy Mappings) says
   This extension is used in intermediate CA certificates. ...

Especially, I think we should distinguish between root CA certificates
and intermediate CA certificates because there are many extensions
that should not appear root CA certificates.

As for the distinction of different type of self-signed certificates:
Yes, I think it is better to distinguish between self-signed certs used as 
CA roots and all other self-signed certs. That is why I suggest
the term "root CA certificate" or "root certificate" should be defined.

As for the security problem of CRL signing key compromised, I
do not think "Issue a new CRL signing key and revoke the old one"
can help for solving the problem. Please see the following case:

TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)------>CRL1
TA->CA1(keyCertSign Key)->CA1(crlSign Key 2)------>CRL2

which means the crlSign Key 1 of CA1 is compromised and
CA1 changes to use the crlSign Key 2 for signing CRL.

Since the RP will not check the revocation status of crlSign Key 1,
the path "TA->CA1(keyCertSign Key)->CA1(crlSign Key 1)" will
still look valid from the viewpoint of the RP. Therefore, the RP
will accept CRL1 (signed by crlSign Key 1), which might be
a foged CRL. The RP will never that it should check CRL2 (signed
by crlSign Key 2) for the revocation status of crlSign Key 1.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 19 Nov 2004 18:47:51 +0800

Dave,

Please see my response in-line.

Wen-Cheng Wang

----- Original Message ----- 
From: "David A. Cooper" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Friday, November 19, 2004 3:27 AM
Subject: Re: 3280bis issue: issues related to self-issued certificates

> because the certified public key may not be used to verify certificate
I think X.509 is also not quite clear about that.
X.509 (2000) 8.2.2.3 says:
   The bit keyCertSign is for use in CA-certificates only. If KeyUsage
   is set to keyCertSign and the basic constraints extension is present
   in the same certificate, the value of the cA component of that extension
   shall be set to TRUE. CAs may also use other of the defined key usage
   bits in KeyUsage, e.g. digitalSignature for providing authentication and
   integrity of on-line administration transactions.

It looks like CA-certificates might contain the basic constraints extension
with the cA value set to TRUE and contains key usage extension without
the keyCertSign bit set.

X.509 (2000) 11.2.2 says:
  The cACertificate attribute of a CA's directory entry shall be used to store
   self-issued certificates (if any) and certificates issued to this CA by CAs
   in the same realm as this CA. In the case of v3 certificates, these
   certificates shall include a basicConstraints extension with the cA value
   set to TRUE. The definition of realm is purely a matter of local policy.

That seems to imply that all self-issued v3 certificates (intermediate or
non-intermediate) shall include a basicConstraints extension with the
cA value set to TRUE.

As I mentioned in my mail to reply to Tom, X.509 itself is not consistent
with the definition of CA certificates. I think we have to clarify what kind
of interpretation is suitable for PKIX.

> need to be in a separate document, not in 3280bis.

I have no objection on having a separate document to address these issues.
However, I think RFC 3280bis should at lease mention these issues
in the security consideration section.

It seems that RFC 3280 and X.509 are encouraging implementors
to use self-issued certificates (especially for key rollover and separating
CRL signing key). However, the more deep I investigate issues related to
them, the more I think it is not a good idea to adopt self-issued certificates.

We should have some cautions in RFC 3280bis to remind implementors
the security issues thay will face it they adopt self-issued certificates.

---

From: Tom Gindin <[email-masked]>
Date: Sun, 21 Nov 2004 23:07:02 -0500

In general, the issue is whether "CA certificates" include 
dedicated CRL signing certificates whose DN is that of a CA and other 
similar cases such as CMP certificates.  If we need any new term for this, 
it's probably something like "issuer certificate" or "certificate issuance 
certificate".  I went through RFC 3280 quickly looking for all uses of "CA 
certificate" and classifying them in more detail.
        Anyway, this issue is not wholly theoretical or legalistic.  There 
are several practical effects: first, should the CA flag in the BC 
extension be set for CRL signing certs and CMP certs; second, should such 
certs go into the caCertificate directory attribute or into 
userCertificate (and remember that userCertificate is not a member of the 
pkiCA object class, which argues against putting them into 
userCertificate); last, should such certs go into the crossCertificatePair 
attribute if they are not self-issued?  The answers to these three are 
probably tied together, and we should find out what current 
implementations do.
        Here are the references I found in RFC 3280, by section:
4.2.1.2 Reference to BasicConstraints (thus belonging to a CA)
4.2.1.5 Issuer (1st), Cross Certificate (2nd)
4.2.1.6 Issuer (1st), not EE (2nd)
4.2.1.10        Belonging to a CA
4.2.11  Issuer
4.2.2.1 Not EE (1st), not clear - contained in CCPair (2nd)
4.2.2.2 Not EE but misworded - somebody needs to fix this reference ("may 
be included in subject or CA certificates").
5       Not clear and not important
5.1.1.3 Belonging to a CA
5.2.5   Not EE
6.1.2 k Issuer
6.1.4 k Issuer
6.3.2   Belonging to a CA
9       Issuer
C.1 h   Reference to BasicConstraints (thus belonging to a CA)

        In X.509, most of the text suggests that CA-certificate is only 
for Issuers, but 11.2.2 says that the CACertificate attribute should 
contain self-issued certificates.
        Responses to your requests for definitions are in-line.

                Tom Gindin

11/19/2004 05:06 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "pkix" <[email-masked]>
        Subject:        Re: 3280bis issue:  issues related to self-issued 
certificates

Tom,

For example:

RFC 3280 4.2.1.2 says

X.509 (2000) 3.3.9 says

   itself a CA and therefore is capable of issuing public-key 
certificates.

That means a CA certificate not only can be "a certificate for one CA
issued by another CA" (a cross certificate) but also can be "a
certificate for one CA issued by the CA itself" (a self-issued certificate 
or
a self-signed certificate).

For example,

To make the useage of the term more precise, I suggest
RFC3280bis (and X.509 as well) should claerly define the
following terms:
  "self-issued certificate"
[TG] I think we have a definition.  If not, it's "a certificate whose 
issuer and subject are the same (or match)."
  "self-signed certificate"
[TG] A self-issued certificate which was signed using the private key 
whose public key appears in the body of the certificate.
  "self-issued intermediate certificate"
[TG] No such thing exists.
  "cross certificate"
[TG] A CA certificate (we can argue about whether it has to have 
keyCertSign set) issued by a different CA.  All CA certificates are either 
self-issued or cross certificates.
  "CA certificate"
[TG] This is the only one that causes real trouble.
  "root CA certificate (a.k.a. root certificate)"
[TG] Not easily defined, unless it's a self-signed certificate used to 
represent a trust anchor.
  "intermediate CA certificate (a.k.a. intermediate certificate)"
[TG] Does this exist outside the context of an RP or a chain?

For example,

   This field, which shall be used in intermediate CA-certificates only, 
...

Wen-Cheng Wang