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

From: Sharon Boeyen <[email-masked]>
Date: Fri, 27 Aug 2004 08:56:21 -0400

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: Sharon Boeyen <[email-masked]>
Date: Fri, 27 Aug 2004 11:04:01 -0400

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

> 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
> 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.
> 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
> 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
> 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
> 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
> regardless of whether or not one or more CAs in the path had undergone
a
> key
> From: [email-masked]
[mailto:[email-masked]]
> On
> When this condition is fulfilled no name constraints applies. Further, 
> anyPolicy is processed in the certificate even if anyPolicy
has
> 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
> certificate in the path and suddenly other rules apply for what is
valid
> and
> This creates the odd situation where valid self-issued certificates
can't
> be
> individual certificates in a local environment where some valid 
> certificates can't be validated and thus show up as invalid.
> 
> I can't see the problem here to allow generic processing of all self 
> issued certificates regardless of position.
>

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 30 Aug 2004 10:36:02 -0400

I don't see a problem with the certificate validating differently in
different contexts. This happens all the time with target certificates if
client side setting of business controls is used (I like to call these
'process controls' as opposed to 'infrastructure controls' which is the term
I like to use for business controls placed in certificates). With the
identical certification path a certificate may pass validation in one
context (e.g. if the client side settings impose a policy related control
for one validation event but not for another). The process constraints could
be set different by the same RP for different applications, different
transactions, different physical environments etc. While I agree that this
is slightly different than the case you are describing because you aren't
using process constraints, I just wanted to provide an example of where the
same cert can have different results depending on the context in which it is
being validated. Therefore I don't see what you are describing as a problem
from that perspective.

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, August 27, 2004 12:54 PM
To: Sharon Boeyen; [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates

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

> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [email-masked]
> I tried to address that at the end of my email but probably didn't do
a
> very
> 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
> 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
> RP through initializing settings for the path validation variables or
by
> CAs
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> > 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
> > you need them. DR 273 addressed the name constraints issues in this 
> > area. Some of
the
> > other
> > certification paths that were previously established. In such cases 
> > it is convenient for the CA to include
> > self-issued certificate did not exist. However, there is a problem
if
> > When this condition is fulfilled no name constraints applies.
Further,
> > Can anyone remember why we can't make all self issued certificates
to