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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 Aug 2004 17:54:11 +0100

Well,

That doesn't really help. What you say is what I assumed is the case.

However, I don't see any real threats avoided with the current approach,
only problems.

The only aspects that are influenced by this logic are name constraints
and processing anyPolicy when inhibited. I have tried to think hard here
but I can't see any real threats avoided by the current logic.

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.

Likewise, if ICA is valid for a certain set of policies, then those
policies would also be good for the rollover cert, regardless of whether
it is used as an intermediary cert or validated as target cert.

I just don't see the threat NOR the real benefit.

The problem that I sense (if this is a problem at all) is that the same
certificate placed under the same certificate path, may be both valid
and invalid at the same time, depending on the context within which you
examine it.

An example:

You look at the certificate path in a viewer and see the complete path
as valid. Then you click on the rollover cert to take a closer look at
it and suddenly that cert shows as invalid. It shows as invalid because
when you take a look just at this cert, it is now at the end of a path
and can't be validated.

Do you see the problem or are my worries completely false here.
I want to know whether I just see ghosts.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> I tried to address that at the end of my email but probably didn't do
a
> very
> good job of it. The reason for making the exceptions was primarily so
that
> CA key rollover didn't interfere with business controls for path
> processing.
> However, if the self-issued certificate is the final certificate in
the
> path
> then it should no longer get excepted because it is now the target of
the
> path validation and therefore the constraints should apply to it. In
the
> intermediate case the certificate's existence is most likely not even
> known
> to the RP. If it is the target cert however, then it is most
definitely
> known to the RP and any business controls, whether imposed directly by
the
> RP through initializing settings for the path validation variables or
by
> CAs
> in cross certs should apply.
> 
> Does that help at all?
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Friday, August 27, 2004 10:01 AM
> To: Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Sharon,
> 
> I think you misread my question/issue.
> 
> I do not question why self-issued certs are excepted from path length
> counting or anyPolicy inhabitation.
> 
> My question is why some exceptions for processing self-issued
certificates
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> different if the self-issued certificate is intermediate or the last
> certificate in the path.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: Sharon Boeyen [mailto:[email-masked]]
> > Sent: den 27 augusti 2004 14:56
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> > Hi Stefan,
> >
> > The reason for the exception cases for self-issued intermediate
> > certificates deals mainly with their role in a CA key rollover
> > situation. In this situation, the fact that a CA has rolled its key,
> > should not change
> the
> > processing of a path. For example if a path length constraint of 3
is
> ok
> > before the rollover that same path length constraint should be ok
with
> the
> > self-issued intermediate cert that perfoms the key rollover. Similar
> logic
> > applies to the anyPolicy and to name constraints. From an X.509
> > perspective, note that the anyPolicy situation was handled by DR
276.
> > FYI, here is
> just
> > the rationale piece of that DR. You can check its processing via the
> > regular docs on Hoyt's server. I could look up the DTC TC numbers if
> > you need them.
> > DR 273 addressed the name constraints issues in this area. Some of
the
> > other
> > areas, such as basic constraints, were addressed in the 4th edition
> text.
> >
> > Rationale text from DR 276:
> > ---------------------
> > One use of self-issued certificates is for a CA to roll over its
> > certificate and/or CRL signing keys without disruption to
> > certification paths that were
> > previously established. In such cases it is convenient for the CA to
> > include
> > the special value anyPolicy in the certificate policies extension of
> the
> > self-issued certificate. This allows the self-issued certificate to
> > provide a link in certification paths for any policy that would be
> > valid if
> the
> > self-issued certificate did not exist. However, there is a problem
if
> the
> > inhibit-any-policy-indicator is set in the certification path
> processing
> > procedure prior to a self-issued certificate. The current text would
> > result in failure of the path because of the existence of anyPolicy
in
> > the self-issued certificate. However, if the self-issued certificate
> > did
> not
> > exist (i.e. the CA had not yet rolled over its key), paths for which
> > specific policies are present in all subsequent certificates may
have
> > passed, but will always fail due to anyPolicy in the self-issued
> > certificate.
> > ---------------------
> > That particular DR was accepted (along with other related ones and
> > original non-defect changes in the 2000 text)
> >
> > These exceptions applied only to intermediate self issued certs
> because
> > the
> > exceptions are to allow paths to have the same result in these areas
> > regardless of whether or not one or more CAs in the path had
undergone
> a
> > key
> > rollover. However, if the end certificate happens to be a
self-issued
> > certificate, the exceptions do not apply because that is the
> certificate
> > that is the one of interest. Therefore if any constraints preclude
> that
> > certificate, it cannot be considered valid.
> >
> > Cheers,
> > Sharon
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]]
> > On
> > Behalf Of Stefan Santesson
> > Sent: Friday, August 27, 2004 6:01 AM
> > To: [email-masked]
> > Subject: RFC 3280 bug? - Special processing for self issued
> certificates
> >
> >
> >
> > I just cam across a small problem that we might want to add to the
> issues
> > list of RFC 3280.
> >
> > At a number of places in the path validation logic define a special
> > exception case for self issued certificates, expressed with the
> following
> > logic:
> >
> >       If certificate i is self-issued and it is not the final
> >       certificate in the path....
> >
> > When this condition is fulfilled no name constraints applies.
Further,
> > anyPolicy is processed in the certificate even if anyPolicy
> has
> > been inhibited.
> >
> > The latter has the same logic expressed in a slightly different
form:
> >
> >       If the certificate policies extension includes the policy
> >       anyPolicy with the qualifier set AP-Q and either (a)
> >       inhibit_any-policy is greater than 0 or (b) i<n and the
> >       certificate is self-issued, then
> >
> >
> > Now to the problem:
> >
> > If I apply these rules to a self issued certificate that is
perfectly
> > valid inside I path, that certificate may appear as invalid when
> > examined on
> its
> > own. That is because when it is examined on its own, it is now the
> last
> > certificate in the path and suddenly other rules apply for what is
> valid
> > and
> > what is not.
> >
> > E.g. the self issued certificate may have just anyPolicy present and
> when
> > examined on its own an inhibit_anyPolicy setting of the path will
then
> > result in an empty policy set of the path.
> >
> > The same type of situation may apply to name constraints (at least
in
> > theory)
> >
> > This creates the odd situation where valid self-issued certificates
> can't
> > be
> > examined on their own. Situations where this could be trouble are in
> > certificate viewers and logic where you manage, examine and handle
> > individual certificates in a local environment where some valid
> > certificates can't be validated and thus show up as invalid.
> >
> > Can anyone remember why we can't make all self issued certificates
to
> be
> > exceptions even if they are the last certificate in the path?
> >
> > I can't see the problem here to allow generic processing of all self
> > issued certificates regardless of position.
> >
> > Maybe I'm missing something.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >

---

From: Steve Hanna <[email-masked]>
Date: Mon, 30 Aug 2004 11:07:00 -0400

Stefan,

You wrote:
 > 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 <[email-masked]>
To: PKIX List <[email-masked]>
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: [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