Re: RFC 3280 bug? - Special processing for self issued certificates

[Steve Hanna <[e-mail]>]

Stefan,

You wrote:
 > For all valid paths to a self-issued certificate, the self-issued cert
 > will be preceded by a valid intermediary CA certificate with a
 > matching subject name. Lets call that the ICA cert.
 >
 > It seams reasonable to me that that IF ICA has a valid subject name
 > then that name would be OK also for the rollover cert, regardless of
 > whether it is used as an intermediary cert or validated as target
 > cert.

I will admit I had to check the archives on this one.
Your argument seemed compelling at first. But the email
below explains the problem. In a nutshell, the self-issued
certificate can contain a *subjectAltName* that is not
permitted by the name constraints and not contained in
the ICA cert.

I hope that explains why this requirement is needed.

Thanks,

Steve

-------- Original Message --------
Date: Fri, 04 May 2001 12:44:34 -0400
From: Steve Hanna <[e-mail]>
To: PKIX List <[e-mail]>
Subject: Ignoring name constraints with self-issued certs

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: [e-mail]

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