Subject: Ignoring name constraints with self-issued certs

From: Steve Hanna <[email-masked]>
Date: Fri, 04 May 2001 12:44:34 -0400

Regretfully, I must raise another issue with son-of-2459. In section
4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:

   Name constraints are not applied to certificates whose issuer and
   subject are identical.  (This could prevent CAs that use name
   constraints from issuing self-signed certificates to implement key
   rollover.)

This statement is consistent with the validation algorithm in section
6.1, which says:

   A certificate is termed self-issued if the DNs that appear in the
   subject and issuer fields are identical and are not empty.  In
   general, the issuer and subject of the certificates that make up a
   path are different for each certificate.  However, 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, these statements (and the corresponding text in the validation
algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
the text in X.509(2000), which says (in step g of section 10.5.1) "If
the certificate is not an intermediate self-issued certificate, check
that the subject name is within the name-space given by the value of
permitted-subtrees and is not within the name-space given by the value
of excluded-subtrees."

Note the word *intermediate* in X.509(2000). If a self-issued
certificate is the last certificate in the path, the name constraints
check MUST be performed. Otherwise, a security hole is opened up.
Consider the following chain of 2 certificates:

Certificate 1:
 Issuer:  o=trusty, c=us
 Subject: o=shady, c=us
 Basic Constraints:
  cA=true
 Name Constraints:
  Permitted:
   directoryName: o=shady, c=us
   rfc822Name: .shady.com

Certificate 2:
 Issuer:  o=shady, c=us
 Subject: o=shady, c=us
 SubjectAltNames:
  rfc822Name: [email-masked]

If o=trusty, c=us is one of the trust anchors (and the certificate
signatures verify), this chain is valid according to son-of-2459. It is
not valid according to X.509(2000). I think you will agree that the
behavior described in X.509(2000) is correct. Otherwise, self-issued
certificates can be used to completely bypass the effects of name
constraints.

Therefore, I suggest that section 4.2.1.11 of
draft-ietf-pkix-new-part1-06.txt be modified to say:

   Name constraints are not applied to certificates whose issuer and
   subject are identical (unless the certificate is the final
   certificate in the path).  (This could prevent CAs that use name
   constraints from issuing self-signed certificates to implement key
   rollover.)

We should also modify the last sentence of the paragraph in section 6.1
that begins "A certificate is termed self-issued ..." (listed in full
above) to "These self-issued certificates are not counted when
evaluating path length. Name constraints are only applied to a
self-issued certificate if it is the final certificate in the path."

I also suggest that the start of steps (b) and (c) in section 6.1.3 be
changed to read:

      (b) If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is within one of the
      permitted_subtrees for X.500 distinguished names, and verify
      that each of the alternative names in the subjectAltName
      extension (critical or non-critical) is within one of the
      permitted_subtrees for that name type.

      (c) If certificate i is self-issued and it is not the final
      certificate in the path, skip this step for certificate i.
      Otherwise, verify that the subject name is not within one of the
      excluded_subtrees for X.500 distinguished names, and verify that
      each of the alternative names in the subjectAltName extension
      (critical or non-critical) is not within one of the
      excluded_subtrees for that name type.

Comments?

Steve

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 4 May 2001 14:08:43 -0400

Hi Steve, 

In discussion with PKIX folks when we were working on the defect report 
for name constraints, I don't recall any specific discussion of that type 
of a path (with a self issued cert at the end). The defect report doesn't 
change that particular text that you mention, but I suspect that the fact 
that it catches this 'hole' is probably more coincidental that deliberate.

I'm curious whether you think there are legitimate situations where the 
final cert would be a self issued one, or whether you are suggesting that 
the fact that it could happen is a threat. Not that it would change the 
outcome, I'm just wondering which perspective you're coming from so that 
I can understand the issue better.

Thanks
Sharon

---

From: Tim Polk <[email-masked]>
Date: Fri, 04 May 2001 14:35:23 -0400

Sharon,

I can think of one scenario where the end certificate is legitimately
self-issued.  (There may be others.)

Consider a CA that uses separate keys for CRL signing or certificate
management operations.  If that CA issues certificates to itself for
those keys, a PKI client that verifies a signature on a CRL or a message
needs to validate the certificate containing that public key.  In
that case, the end certificate will be self-issued.

Thanks,

Tim

At 02:08 PM 5/4/01 -0400, Sharon Boeyen wrote:

Hi Steve,

that it catches this 'hole' is probably more coincidental that
deliberate.

I'm curious whether you think there are legitimate
situations where the

Thanks

Sharon