Subject: RE: Correct approach to certificate validation?

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 5 Jun 2000 19:06:58 -0700

Hi Denis,
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. 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. 
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. 
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: Denis Pinkas <[email-masked]>
Date: Tue, 06 Jun 2000 10:33:14 +0200

> 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
> 
> extension is present, does not perform a comparison of the
> issuer-DN in the
>   - or the approach of Netscape and IIS4, which, even if an
> Authority Key
> Peter Williams from Valicert who devoted much of his time to help
> me solve
> Subject:        Report - certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
> 
> Hello,
> 
> validation code in IIS4. I have now resolved the problem that was
> the reason
> insight into how certificate chains are handled in IE5 and Outlook
> / IIS4
> I produced my own certificate generating utility, the intention of
> which was
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> 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