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

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

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: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 Aug 2004 15:01:08 +0100

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

> -----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.
following
> logic:
> 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.
when
> examined on its own an inhibit_anyPolicy setting of the path will then
> result in an empty policy set of the path.
> 
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.
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 30 Aug 2004 22:54:41 +0100

Santosh,

Yes that's true. That was not my question though :-) 

The question is: If we have an exception not to inhibit anyPolicy for
self issued certificates, since it only passes the policies from its
parent certificate, then why do we need to enforce inhibit anyPolicy
just because the self-issued certificate is last in a path.

Stefan Santesson

> On Behalf Of Santosh Chokhani
> Sent: den 30 augusti 2004 22:45
> To: [email-masked]
> Stefan:
> For inhibit any policy, when you define skip certs, you want to
enforce
> the
> constraints on a specific CA down stream from you regardless of
whether
> the
> path is from your current certificate or from a current to roll over
> certificate.  Thus, skip certs for inhibit policy should not count
> self-issued certificates.
> 
> Sent: Monday, August 30, 2004 12:42 PM
> To: Steve Hanna
> Cc: Sharon Boeyen; [email-masked]
> Thanks Steve,
> Yes, this is a valid technical argument.
> I suppose it is reasonable to accept a certificate as a key rollover
cert
> despite name constraints violations in subjAltName while you wouldn't
> accept
> those violations if the same certificate was used as an EE cert to
> validate
> e.g. a new name constraints violating e-mail address of that CA.
> 
> It seems harder however to transfer this logic to inhibit anyPolicy.
Any
> ideas/arguments there?
> > On Behalf Of Steve Hanna
> > Sent: den 30 augusti 2004 17:07
> > To: Stefan Santesson
> > Cc: Sharon Boeyen; [email-masked]
> > Subject: Re: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> >
> > 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 <[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
> 
>