# RE: Certificate chaining w/javakey generated DSA certificates

George Chung (gchung@openhorizon.com)
Thu, 18 Sep 1997 17:26:45 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Anno Langen: "Incomplete protection through ACL ownership"
- Previous message: Ian Clysdale: "Behaviour of Cipher class in JCE"

    From: George Chung <gchung@openhorizon.com>

    To: "'David Brownell'" <David.Brownell@Eng>

    Subject: RE: Certificate chaining w/javakey generated DSA certificates

    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".
2) E.g., the SSL extension that you refer to presumes that one peer
delivers the entire chain to the other.
3) other protocols may "establish the chain" via different mechanisms.

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.

> 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: Anno Langen: "Incomplete protection through ACL ownership"
- Previous message: Ian Clysdale: "Behaviour of Cipher class in JCE"