# RE: Certificate chaining

David Brownell (David.Brownell@Eng)
Tue, 23 Sep 1997 09:32:41 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David Brownell: "Re: Security Mechanism Direction Query"
- Previous message: David Brownell: "RE: Certificate chaining w/javakey generated DSA certificates"

    Date: Tue, 23 Sep 1997 09:32:41 -0700

    From: David.Brownell@Eng (David Brownell)

    Message-Id: <199709231632.JAA09659@argon.eng.sun.com>

    To: gchung@openhorizon.com

    Subject: RE: Certificate chaining

> From: George Chung <gchung@openhorizon.com>
> Date: Thu, 18 Sep 1997 17:26:45 -0700
>
> Dave,
> OK, this answers a lot of questions. Looks like I should study the specs
> for the SSL extensions. I promise to stop bothering you guys if you could
> kindly answer this last email :-).
>
> So it appears that:
> 1) While there are standard mechanisms for verifying the chain (PKIX) there
> is no standard mechanism for "establishing the chain".

I think this is probably a correct statement.

Various protocols handle this rather differently. For example, neither
PKCS #7 nor SSL are required to provide complete certificate chains
when they provide certificates, and protocols like SET often provide
certificate digests rather than certificates.

> 2) E.g., the SSL extension that you refer to presumes that one peer
> delivers the entire chain to the other.

Actually, no -- I stripped out the docs so you could see just the
APIs, but the array of certs provided can be just the "leaf".

> 3) other protocols may "establish the chain" via different mechanisms.

As noted above, yes. I see this as a requirement. The TrustDecider
API takes a partially established chain as input. It can establish
the rest of the chain using local state, or perhaps it needs to consult
a trusted network service or two in order to establish that chain.
(Then it makes its decision!)

Of course, maybe the whole chain doesn't in fact _need_ to be known
before the trust decision can be made. "Everything signed by this
CA is trusted for purpose <xyz>" just needs to establish that the
chain goes up to that CA, if the decision is for purpose <xyz>.

> On Wednesday, September 17, 1997 11:29 AM, David Brownell
> [SMTP:David.Brownell@Eng.Sun.COM] wrote:
> > When you say "PKI service provider" what do you mean? Is this a network
> > service (e.g. SSL-LDAP server, CA, etc) or is it someone who provides PKI
> > libraries for folk to code against? Or is it vague, "both"? The answer
> > varies depending on exactly what your question means!
>
> I meant both! I was hoping that someone like Entrust, who provide a whole
> PKI, would provide an implementation of some sort of interface (TBD), that
> would allow an authenticator to ask the question, "does this certificate
> chain to one of the root certificates that I trust". If that interface
> required an array of certificates, so be it.

That's the model followed by SSL, yes. Perhaps the full cert chain
is four entries, you were given the first two, and then the API can
fill in the last two.

However, do keep in mind that "do I trust the root" is not the goal of
the decision process! The certificate needs to be valid at the time
in question, in X.509v3 there are many policy-constraining attributes
to be checked, and there's the "trusted for what?" issue that is
captured by the "purpose" identifier passed in to the TrustDecider.

- Dave

> > The SSL extension just talks in terms of arrays of X509 certs, with the
> > root CA last. That array is returned as representing the peer identity.
> > There's also an API, currently internal:
> >
> > public interface TrustDecider
> > {
> > boolean isTrustedFor (
> > X509Cert entity [],
> > String purpose,
> > Date when
> > );
> >
> > X509Cert [] getAcceptedCAs (String purpose);
> > }
> >
> > We provide one implementation of isTrustedFor() which validates the chain
> > using X.509v1 rules, and will in the future support PKIX style validation
> > using the upcoming X.509v3 APIs. Since it's a pluggable component, other
> > rules could be supported, accessing other (secured!) lists of trusted CAs
> > for use in validating. The getAcceptedCAs() method provides the list of
> > CAs supported for the specified purpose, e.g. SSL client authentication;
> > that list is clearly required by any implementation of isTrustedFor.
>
> ...
>

- Next message: David Brownell: "Re: Security Mechanism Direction Query"
- Previous message: David Brownell: "RE: Certificate chaining w/javakey generated DSA certificates"