Subject: RE: "Basic" path-validation question

From: Roger Younglove <[email-masked]>
Date: Mon, 20 Jan 2003 08:52:38 -0500

Richard,
Comment inserted
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [email-masked]
www.networksgroup.com

-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:[email-masked]] 
Sent: Friday, January 17, 2003 4:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: "Basic" path-validation question

In message <[email-masked]> on Fri, 17 Jan 2003 14:38:46
+0100, Jean-Marc Desperrier <[email-masked]> said:
 
jean-marc.desperrier> What is broken is the application, if it
jean-marc.desperrier> *requires* to install both RootCA and CA1 in
jean-marc.desperrier> order to trust EE_type1.
 
Yet, most software do that, *or* install just RootCA and expect to get
every intermediate CA certificate along with the messages sent to it
(that happens with S/MIME, and many SSL-enabled servers present a
whole chain except for the root itself).  From a purely PKI point of
view, both methods are broken, all needed certificates should be
retrievable from one or several publically available stores...
 
jean-marc.desperrier> It should be possible to install only CA1 as a
jean-marc.desperrier> trust anchor, there is no requirement in the
jean-marc.desperrier> path-validation that the trust anchor be
jean-marc.desperrier> self-signed.
 
Actually, I've heard quite different opinions on that.  Some people
assume that the trust anchors are self-signed.  I see no real problem
with that kind of thinking...  If nothing else, you can always set up
your own small CA, certify any other CA you trust with your CA's key,
and have your CA as trust anchor...
 
Roger> Then what you have in affect is a Bridge CA connecting the path of
trust between the CAs that you trust. This would not be a trust anchor. It
would require agreements between all of your trusted CAs because it would
also affect them by extending their individual paths of trust to each other
and they may not wish to do that.
 
jean-marc.desperrier> If the application is OpenSSL, you were talking
jean-marc.desperrier> with someone who is supposed to be able to do
jean-marc.desperrier> something about it :-)
 
I've certain plans in this area for OpenSSL.  I hope to have most of
it ready for 0.9.8.  As it is right now, it has rather crappy
verification routines, as well as the lookup of certificates (it's
in-memory, and lacks of certain needed features).  No policy checking
(as far as I've been able to see and test), and no support for trees
of certificate chains (i.e. it doesn't support the possibility for any
specific subject to have more than one valid certificate at a time...
 
-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 20 Jan 2003 18:15:12 +0100

Roger Younglove wrote in answer to message from Richard Levitte :
> with that kind of thinking...  

I've been rereading RFC3280 about that, we are both right, the trust 
anchor does not need to be self-signed, but there is also no requirement 
on the application to accept any another form :

6.1.1  Inputs
(d)  trust anchor information, describing a CA that serves as a
       trust anchor for the certification path.  The trust anchor
       information includes:

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
          with the public key.

       The trust anchor information may be provided to the path
       processing procedure in the form of a self-signed certificate.
       The trusted anchor information is trusted because it was delivered
       to the path processing procedure by some trustworthy out-of-band
       procedure.

So the trust anchor can be provided in any form that is seen fit, and 
might not even be a X509 certificate.
But the text does require that an application accepts trust anchors in 
any specific form, only suggesting self-signed certificates.
So as it's the one form that's explicity described, it's no surprise 
it's often the only one that is supported.

> If nothing else, you can always set up
> / Roger> Then what you have in affect is a Bridge CA connecting the path 
> of trust between the CAs that you trust. This would not be a trust 
> anchor. It would require agreements between all of your trusted CAs 
> because it would also affect them by extending their individual paths of 
> trust to each other and they may not wish to do that. /

The trust anchor is anything that is provided as input to the validation 
algorithm, using OOB mecanism.
Even if you use one that looks like a bridge CA, it is not distributed 
on-line, so it does not affect their path of trust outside of your 
private use.