Subject: RE: Attribute used to store cached certificate chains?

From: "Tammy Carter" <[email-masked]>
Date: Wed, 27 Jan 1999 16:43:02 -0700

Andrew,

The question may seem a bit recursive on the surface, but I 
don't think that it is.  Alice has a certificate which, after she received
it, she validated by walking her directory tree.  Now, a couple of
months later, she needs to use her certificate, but she is disconnected
from her tree and won't be able to access it until tomorrow.  But,
she needs to get to her chain today.  Is she out of luck??  Is Alice
unable to use her key pair unless she can access her directory???

If so, something is dreadfully wrong here.  That would mean that
users would be unable to send signed email while disconnected
from their tree simply because they would be unable to construct
a suitable chain for inclusion in the S/MIME message. 

What seems reasonable is that a user would have their certificate
chain (or some PKCS 7 bag of certificates which can be used to
verify their certificate) cached somewhere for times when
they are unable to reach the tree to construct the chain.  Perhaps
it would be stored on the client, or on a floppy, or in their email 
package.... somewhere.

Now, I was thinking about the case where the user is partially
connected to the tree.  In other words, the user is able to read
their own object, but is unable to construct the chain.  Could the
chain be cached in an attribute on the user's object instead of
on the client?

Tammy Green Carter

>>> Andrew Probert <[email-masked]> 1-27-99 3:29:53 PM >>>

> -----Original Message-----
> From:	Tammy Carter [SMTP:[email-masked]] 
> Sent:	Saturday, January 23, 1999 7:06 AM
> To:	[email-masked] 
> Subject:	Attribute used to store cached certificate chains?
> 
> Consider the following scenario:
> -----------------------------------------------
> A user, Alice, is a user of a directory service and the
> PKI that she uses exists entirely within her own tree.  
> Due to the nature of the directory, she is often unable
> to compose her certificate chain (a chain back to a root
> which she knows and trusts and which other people within
> her tree know and trust) on the fly by walking her tree.  
> Sometimes, Alice needs to construct her certificate 
> chain in order to validate one of her own certificates.  
> 
[Andrew Probert]  This sounds a bit recursive!  If she can't validate her
own chain locally, she's in trouble trust-wise.

> Other times,
> she needs to send the certificate chain to another user, Bob, 
> who may also not be able to walk the tree, but who needs to
> validate her certificate.
> 
	[Andrew Probert]  PKCS#7 (and the SMIME profile) is typically used
to do this

> If Alice wanted to cache her certificate chain in the directory on
> her user object for use when she was disconnected, what attribute
> should she store it in?  Has such an attribute been defined yet?
> 
	[Andrew Probert]  Certificates would normally be stored discretely,
under their own names.  Its up to 
	the client software to walk the tree and retrieve each by name etc.

> Thanks,
> Tammy Green Carter
> [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 29 Jan 1999 17:56:33 -0500

Tammy,

I agree wholeheartedly with your observations.  I've designed a number of
certificate-enabled systems over the last decade, and they have always
included the notion of a local cache of validated certificates and CRLs.
Directory access is not always feasible, and it always imposes some costs
in terms of delays.  Caches are a fine way to improve performance in
certificate chain validation, and a well-understood part of most system
designs.

The separate question is how to make such caches mobile, when a user is not
able to bring his/her computing environment along in all cases  In that
context I think it very appropriate to provide a well-defined directory
attribute for use in storing a crypto-protected cert, CRL, and key context.
At the RSA show a week ago, this was a common theme. The basic concept is
not new; it appears in the DEC Distributed System Security Architecture
published in the latter 80s, e.g., in the IEEE Security and Privacy
Symposium.

Steve