Subject: RE: Correct approach to certificate validation?

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 6 Jun 2000 19:42:06 -0700

We use AKI, but don't require it, as the field can be calculated on the
fly so to speak.
I am not linking the enforcement of name constrains with the enforcement
of name chaining in any. We will enforce name constraints as this is a
security issue, we don't enforce name chaining. 
We trust the CA because we have built a chain of certificate to a
trusted root, with valid policy and name constraints.

 -----Original Message-----
From: 	Denis Pinkas [mailto:[email-masked]] 
Sent:	Tuesday, June 06, 2000 1:33 AM
To:	Trevor Freeman
Cc:	[email-masked]; [email-masked]
Subject:	Re: Correct approach to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path construction,
> causes more problems than it solves. We therefore have reverted to
> using the name as just a hint, rather than a critical factor and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain. 

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building. 

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459". 

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted. 

Denis
 
> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a bad
> idea.
> 
> Trevor
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, June 04, 2000 11:19 AM
> To: [email-masked]
> Subject: Correct approach to certificate validation?
> 
> Now, based on my previous message, my question for this workgroup:
> 
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if an
> Authority Key
> Identifier extension is present, DOES still perform a comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
> 
> Regards,
> 
> denis bider
> 
> PS. I would like to thank Ace Swerling from Microsoft Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to help
> me solve
> this issue. I appreciate your feedback very much.
> 
>  -----Original Message-----
> From:   denis bider [mailto:[email-masked]]  On Behalf Of
> [email-masked]
> Sent:   Sunday, June 04, 2000 20:08
> To:     [email-masked]'
> Subject:        Report - certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
> 
> Hello,
> 
> a while ago I sent to this list an enquiry regarding Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and Outlook
> / IIS4
> and Netscape, and since the behavior in question should be covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings to
> you.
> 
> I produced my own certificate generating utility, the intention of
> which was
> to generate certificates which could be used by IE5 to login into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be valid,
> and
> although Outlook properly signed and verified messages signed by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate was
> imported
> into Netscape, Netscape didn't even show it as an elligible choice
> for SSL
> client authentication.
> 
> To sum it up, the problem was that there was a glitch in my code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
> 
> denis bider

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jun 2000 18:42:12 -0400

Trevor,

Two observations:

	- path construction (going up toward a root) is nominally 
based on the use of the issuer name to find the right CA certificate, 
with the AKI/SKI used to disambiguate among multiple valid CA certs. 
I recall that the list discussed the potential problems of using just 
the AKI to locate a CA certificate.  I expressed concern then that 
the AKI didn't provide a means of locating a CA certificate when it 
was not local, i.e., one would need to have a database that was a 
flat file for all possible CA certificates to do the lookup.  My 
concern was that we were creating a situation where people might 
build systems that had all the shortcomings of LAN e-mail systems, 
e.g., they worked well locally, but did not scale across the 
Internet. Of course, if one uses the AIA extension this problem might 
be ameliorated.  So, my question is how do MS products locate a CA 
cert that is not available in a local cache or local LDAP directory, 
using just the AKI?

	- name constraints are critical to secure use of certs, so I 
do hope that you are correctly enforcing this extension, when it is 
present.  Contrary to what  Amir said, this is PKIX, not SPKI.  We 
don't buy into the notion that keys are principals here :-).  If one 
always uses name constraints in cross certs that link to other 
administrative domains, something that a local CA or  can enforce 
unilaterally, then names are reasonably safe to employ for access 
control purposes. (Of course, one can't do this with TTP, but maybe 
that's another good reason for not using them when identification for 
access control is important.)  But, if you're violating the standards 
to accommodate administrative sloppiness in managing CA names for 
chaining, then maybe you're assuming an environment where one can 
never rely on names for ACLs anyway. That's a scary environment.

Steve