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

From: "Miklos, Sue A." <[email-masked]>
Date: Mon, 1 Feb 1999 11:03:08 -0500

the 1997 X.501 contains the following definition for an encrypted attribute
(independent of whatever attribute type is contained within) - didn't know
if this is useful for the 'crypto-protected' feature mentioned.

18.2.2	Encrypted Attribute Value Template
If an encrypted variant is required of an existing directory attribute type,
the following syntax is used:
	EncryptedAttributeSyntax {AttributeSyntax} ::= SEQUENCE {
			keyInfo		SEQUENCE OF KeyIdOrProtectedKey,
			encAlg			AlgorithmIdentifier,
			encValue		ENCRYPTED { AttributeSyntax
} }
	KeyIdOrProtectedKey ::= SEQUENCE {
			keyIdentifier		[0]	KeyIdentifier
OPTIONAL,
			protectedKeys	[1]	ProtectedKey OPTIONAL}
	-At least one key identifier or protected key must be present 
					}
	ProtectedKey  ::=  SEQUENCE  {
		authReaders		AuthReaders,
						-- if absent, use attribute
in authorized reader entry
		keyEncAlg		AlgorithmIdentifier  OPTIONAL,
						--  algorithm to encrypt
encAttrKey
		encAttKey		EncAttKey  }
						-- confidentiality key
protected with authorized user's
						-- protection mechanism
	AuthReaders  ::=  SEQUENCE OF Name
	EncAttKey ::= PROTECTED {SymmetricKey, keyProtection}
	SymmetricKey ::= BIT STRING
	keyProtection PROTECTION-MAPPING ::= 
		SECURITY-TRANSFORMATION {genEncryption}

NOTE -  It is not reasonable that ordering matching rules or sub-string
matching rules be used for encrypted attributes. It is also recommended that
encrypted attributes are only defined for user attributes.

> ----------
> From: 	Stephen Kent[SMTP:[email-masked]]
> Sent: 	Friday, January 29, 1999 5:56 PM
> To: 	Tammy Carter
> Cc: 	[email-masked]
> Subject: 	RE: Attribute used to store cached certificate chains?
> 
> 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
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 1 Feb 1999 17:54:47 -0500

Bill,

>Maintaining a copy of a user's certificate chain has implications for
>digitally signed archives, as well.
>
> In the case of an archived (and signed) document, should the document
>itself retain a copy of the certificate >chain to aid in validation? Or
>will PKI's/Directories support future path validation for archived
>documents?
>
> Thoughts/comments?

I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem.  After all,
only a relying party knows how long to keep this data, and this model
parallels what we do in the physical world (outside of the Latin Notaire
context).  But, some folks object to this notion and want CAs or others to
provide these services for them, so there is no single right answer here.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 2 Feb 1999 12:14:33 -0600

A contribution to the issue:-

There is a difference between system design
for caching trust information to achieve performance
improvement or control trust-policy enforcement, and
storage of transactional data after the fact of
signature verification and certificate-chain validation.

Responsibility for maintenance of transactional
data is the current thread topic.  In the enterprise context, does
it fall to the individual or the company? For whom is the reliability of
access to the data critical, asks the risk management professional?

In the private key escrow (renamed key management)
debate, we learn from govts that no individual can be trusted
by the corporation to control the private key in
the ultimate interests of the company. Third-party escrow
is a required feature of the corporate environment,
therefore. The users system must be denuded of
potential capability to compromise such a corporate
requirement,  in consequence.

Using a similar logical argument, if a *companies* validation
of a signed transaction is performed by an individual, surely
the company cannot trust the individual to maintain
the accurate logs/data/context on the historical
information, should that data be required as proof-basis/evidence
in the future.  Therefore, a company-maintained
repository of transaction reconstruction/audit data
is required, just as centralized, mandatory key recovery is
required to ensure business continuation capability.

This argument strongly suggests that *enterprise-based*
verification/transaction-reconstruction services will be required.

I would, however, disagree that it is necessarily the enterprise CA which
performs such a mandatory repository function, however. Many
companies could outsource this function today to such providers
as Surety. Though reliability-critical, such "safe storage" (with
optional notarization) is not especially security critical in the sense
of the specific technical risks which the enterprise CA manages when
issuing valid certificates.

Peter.
    -----Original Message-----
    From: Stephen Kent <[email-masked]>
    To: WHenry <[email-masked]>
    Cc: [email-masked]' <[email-masked]>; [email-masked]'
<[email-masked]>
    Date: Tuesday, February 02, 1999 10:23 AM
    Subject: Re: FW: Attribute used to store cached certificate chains?

    Bill,

    > In the case of an archived (and signed) document, should the document
itself retain a copy of the certificate >chain to aid in validation? Or will
PKI's/Directories support future path validation for archived documents?

    I've always been of the school that calls for a relying party to take
responsibility for acquiring and retaining the certs and CRLs, and
timestamping them, to support a future repudiation problem. After all, only
a relying party knows how long to keep this data, and this model parallels
what we do in the physical world (outside of the Latin Notaire context).
But, some folks object to this notion and want CAs or others to provide
these services for them, so there is no single right answer here.

    Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Feb 1999 13:30:33 -0700

I agree with Steve on this.  The simple, obvious, reliable, (but perhaps
inelegant) solution to non-repudiation of an archived document is 
for any and all interested parties to take the responsibility themselves
for archiving the certificate chain and CRLs, etc., along with the 
document itself.

This approach is almost idiot-proof.  Alternative schemes, such
as trying to save storage space by collecting the certificates (and CRLs,
which are time-dependent and hence likely to be unique per document), 
and associating a use count and/or "document-owner", are likely to
fail if someone deletes other documents that refer to the same certificates 
and the use count gets messed up somehow.

In my view, the distinguishing characteristic that differentiates a directory from
a repository is that a directory reflects a snapshot of a world-view at a
more or less current instance in time, whereas a repository attempts to
maintain a reliable historical record.

The Y2K problem has reemphasized a lesson that a gifted instructor at IBM's 
System Research Institute taught me more than 30 years ago -- that memory 
is the _least_ costly component of a system, when you count the true cost of 
trying to optimize the memory utilization.  If that observation was true in 1966,
it is most certainly true now.  (If the horse she was riding in Central Park hadn't
thrown her and broken her neck, maybe a few more people would have paid
attention, and we wouldn't be facing the problems we are today.)

A relying party may choose to try to save disk space by optimizing the 
necessary nonrepudiation information, or by contracting out such 
functions, but if they don't have it when they need it, they'll know
who to blame.

Bob

>>> Stephen Kent <[email-masked]> 02/01/99 03:54PM >>>
Bill,

Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 02 Feb 1999 13:53:01 -0700

I like Peter's contribution as well as Steve's, although it is 
interesting to see how people's perspective may change as 
they change employers (or vice versa).

My earlier comments regarding the desirability of associating
nonrepudiation evidence with the document itself, at least for
the sake of simplicity, should not be interpreted as casting
aspersions on either repositories or validation services, which
presumably have their place in the business world.  

When was talking about the "relying party," I should not have 
implied that that function necessarily rested exclusively with
the individual who decided to accept the transaction at the time,
for that individual might have left the company or decided to 
repudiate his own actions when push came to shove.
For important, company-related transactions, the company as 
relying party should take whatever steps are necessary to 
preserve the necessary information from destruction or alteration.

Of course, it sometimes happens that an individual who takes 
some action is later accused (at least in his eyes) of either 
doing or not doing something.  In that case, the individual is 
potentially yet another relying party, and in that case it might 
behoove him to keep his own set of records, in case the 
company decides to purge its files of some inconvenient fact.

If the company is viewed as the exclusive "owner" of the data,
and if the nonrepudiation information is under their exclusive
control (whether subcontracted out or not), the employee might
not have any recourse or evidence unless he kept his own copy
of all of the necessary information.

For examples of this kind of ugliness, look at almost any notorious
whistle-blowing case, and the increasing tendency of corporate 
counsel to urge a complete and ruthless purge of all e-mail more 
than a few months old.

Bob

>>> "Peter Williams" <[email-masked]> 02/02/99 11:14AM >>>

Peter.
    -----Original Message-----
    From: Stephen Kent <[email-masked]>
    To: WHenry <[email-masked]>
    Cc: [email-masked]' <[email-masked]>; [email-masked]' 

    Bill,

    Steve

---

From: Alan Lloyd <[email-masked]>
Date: Wed, 3 Feb 1999 12:27:35 +1100

A comment

> From:	Bob Jueneman 
> Sent:	Wednesday, February 03, 1999 7:31 AM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
	snip

> maintain a reliable historical record.
	A directory service - is a distributed information system which
has an information doctrine. In terms of its characterisation by X.500 -
it is object oriented, has an authentication and access control regime,
has a common schema and information management model and offers both
distribution and replication facilities in order to satisfy ownership
and administration as well information service levels. A directory is a
protected object oriented distributed name based transaction system
which operates on knowledge.
	A repository may in its comercial implementation have some of
the above features. However, I don see to many standards for
"repositories". So they tend to be related to central storage /DB type
systems.
	A directory service can be used as an archive. In fact the
archive component can in fact be part of the DIB.

	regards alan

---

From: "Tammy Carter" <[email-masked]>
Date: Wed, 03 Feb 1999 14:22:00 -0700

Alan,

You bring up an interesting idea.  Perhaps, instead of caching the certificate chain on the user's object, the user should be selectively caching directory objects which could be periodically refreshed.  The question is:  If such a mini-directory were provided on a client, would applications take advantage of it?  Would my email package be able to go and look there for certificates rather than turning to a personal address book?

Perhaps, but the "personal address book" or some kind of certificate repository would still be necessary in some cases.  People who use CAs which are external to their tree (e.g., VeriSign, or even CA's in a different tree) would still need to cache the certificate(s) necessary to make up a certificate chain for inclusion in an S/MIME message since these certificates may not always be easy to get to.

Interesting notion to download portions of the directory to the client....  Rather than doing LDAP off of your client, you could do it to access the locally cached directory.  Interesting.....

Tammy Green Carter

>>> Alan Lloyd <[email-masked]> 1-31-99 4:20:45 PM >>>

<snip>

I think the two biggest areas that need to be applied into the theory of
PKI is 
a) There is a business/trust/cost model which will be operationally
driven - that the theory of PKI will have to fit into. And
b) In many, many cases, that this will be applied to a distributed
directory service.

I think the notion that all certs, CRLs and all user information will
fit in one server or Database which is accessed by LDAP or OCSP on its
own is the same as designing a big central mainframe system - something
a few of us did 25 years ago! :-)

So in answer to your question - caching. I have an X.500 directory on my
notebook which can be a) Part of the companies DIB for which I am
responsible for - a locally maintained - distributed component. AND a
replicated part of the companies DIT which I extract for my own purposes
in order to do my job. This is centrally managed. In all this keep all
the info necessary to support my moble env.

The issues to me are stated above. Its the knowledge of potential
recipients, what domains they work in and what policies and mechanisms
they use for validating me. Such info and control has to be external to
my environment and in a commonl information  infrastructure - a
directory.

Hope this helps with the debate
regards alan

> From:	Tammy Carter 
> Sent:	Friday, January 29, 1999 11:09 AM
> To:	< ; [email-masked]; [email-masked] 
> Hi, Alan,
> Thanks for clarifying.  It _is_ incorrect to say that an entire
> directory is off-line.
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the
> set of
> objects from which a chain can be constructed.  This inability could
> be caused by network outages (planned or unexpected), a bad
> replication scheme, or even the inability of the client to communicate
> with the necessary servers using the right protocols.
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user
> object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition
> containing
> my user object on a server in China so that a copy of my object is
> being maintained locally.  Now, I want to send email and I need to
> send a certificate chain with my S/MIME message.  My CA has an
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's
> certificate chain on their object rather than forcing the user to
> store it on the client's file system, or on a floppy disk.  This
> allows a "free seating policy" so that users can go to any
> client and perform their job functions without having to carry
> around floppy disks.
> 
> My initial question was:  has anyone thought of caching this
> information in the directory yet?  If so, what attributes are being
> used?
> 
> 
> Tammy Green Carter
> [email-masked] 
> 
> 
> >>> Alan Lloyd <[email-masked]> 1-28-99 3:03:33 PM
> >>>
> Some comments
> 
> This debate seems to say that a directory tree is unavailable and
> therefore local caching is used. It would strike me that a major part
> of
> the system design of an organisation's information system. eg HR,
> database or PABX or RADIUS directory,  that replica's are placed at
> certain points to avoid service failures. Although there are major
> functional distinctions between a database, a file system, a directory
> service, etc. The system design and operational deployment of all of
> these things makes sure that service levels are maintained. Saying
> that
> "a directory" is off line is like saying a database is off line or the
> file server is off line. I would expect that a User who is mobile to
> contain on their local directory/file system all the things that
> support
> that environment eg address books, mail boxes and a bunch of keys and
> certs..which can be replica entries of the CAs system.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 03 Feb 1999 15:26:58 -0700

This discussion has kicked off several subthreads, and I'd 
like to comment on a couple of them.

With respect to the private keys, regardless of where the key 
is generated, there are several places where it could be stored --
on a smart card (perhaps where it was generated), on a floppy disk 
or password protected file on the user's workstation, or on some 
server, notably a directory server.

Each of these storage locations has advantages and disadvantages,
depending on the security of the systems involved and the use of the key.

In the case of the smart card, if I lose it or leave it at home I can't get my
work done, and in order to assure the continuity of the business if something
happens to me, a copy of my encryption keys are almost surely going to 
have to be stored elsewhere as well.  In addition, if I use multiple 
machines, e.g. my desktop workstation, my laptop, and my home machine, 
I may need to have multiple smart cards if I use more than one at a time.

In the case of the floppy disk or the password-encrypted file on a hard disk, 
the same concerns apply.

But if I put the private key in my company's directory (note that I am not assuming 
some untrusted, unrelated third party directory provider such as an ISP or telco),
and assuming I go though an encrypted and authenticated logon process that 
at least uses my password to securely authenticate me to the directory, then the 
company that owns the data and owns the server and probably needs a 
backup copy of my key has access to it.  So what -- they have the key to my 
office and my desk as well. At least this allows me to use any computer that I trust 
adequately, anywhere in the facility or even remotely, to decrypt or even sign my data.

If the server uses a secure hardware crypto facility, then the keys can be protected 
just about as well as can be, given the fact that I am probably using them in
the clear within my untrusted workstation in any case.  Even if the server uses 
software crypto, the master key storage key is presumably obfuscated as well as it
can be without requiring another secret key, and is stored in a file to which ordinary user programs don't have access.

Now, would I trust my personal private encryption key to my company directory, the 
one I use to encrypt my love letters to my mistress, or anything else I don't want 
anyone else o know about? Absolutely not!  But I also wouldn't compose such a 
document on my company owned workstation, especially since the system 
administrator can and often does download new copies of the software onto 
my machine without my permission or even knowledge.

Likewise, would I trust my system administrator with a copy of my private
digital signature key, even if that key was only supposed to be used 
for company business?  Again, no way. Someone might forge my signature to
some hate mail sent to the CEO, or change the beneficiary for my life insurance,
or even withdraw funds from my 401K, so that would be intolerable.

For that reason, although a system administrator for Novell's NDS directory
may be able to change the rights to my user object so that he could 
access my key, in the case of a digital signature key the act of allowing 
access to someone else also destroys the old key, so that nonrepudiation 
is maintained.  

With respect to Tammy's question about how best to store a certificate chain 
in the directory, there was an implicit assumption that should probably be 
made explicit -- directory performance issues would tend to strongly discourage 
repeatedly walking the certificate hierarchy to retrieve each certificate in the chain, 
especially if the chain is more than one or two certificates in length.

In addition, there is another problem that is not quite so obvious, and that concerns
directories that are not necessarily fully interconnected.

Ideally, every X.500 directory in the world would know about every other one, and 
they would all be interconnected and share precisely the same schema for DNs, etc.

But that isn't going to happen any time soon, if at all.

So it isn't necessarily the case that the subscriber and the relying party share a 
common directory, or even that the subscriber and the CA that issued the certificate 
share a common directory.  One of the CAs in the certificate chain might not even 
_have_ a directory.

So what is the poor subscriber or relying party to do?

Well, one solution would be to import all of the certificates in the chain, and to stash 
them in the user's directory under the DN in each certificate, and if necessary create a new subtree in the DIT to accommodate that entry.  Unfortunately, some directory 
administrators may be somewhat unsympathetic to that problem, especially if it means 
changing the directory schema, etc.

Another solution if the directories were interconnected would be to either chain or refer to 
the other directory, but that might not be feasible if one directory doesn't know the
details of where the other directory is located, its DNS name and port number, etc.
(Isn't it interesting that we have define referral mechanisms to tell the relying party
where to find the CRL or OCSP provider, but not the Issuer's directory?)  

Unfortunately, the performance hit in this case would be even worse than in the 
local directory. 

So it appears that we need to be able to store an entire chain of certificates in one place,
presumably associated with the user's object. So what kind of attribute should be used, and where should it be located?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> "Tammy Carter" <[email-masked]> 02/03/99 02:00PM >>>
Steve,

Generally speaking, information which is stored in a directory is accessible only to those people who are granted explicit access rights.  And, by default, only the user would be given rights to his encrypted private key stored on his own object.  Thus, the user would have to specifically gave someone else rights to access his private key.  

However, those administrators with direct access to the directory database wherein my object resides could give themselves rights to my private key.  Or copy it for an off-line attack on the encryption.  Or even change it.  When my encrypted private key is stored in the directory, it is vulnerable to anyone who can get to a server which holds a copy of my object.  As we are fond of saying here - - Once someone has physical access to the server, all bets are off.  

BUT....  That's true about any information which is stored in a directory.  Not just about my private key.  From a company's perspective, there are far worse things that someone can do with physical access to a server than to pose as one of their employees.  So, a company would (hopefully) screen people a bit before giving them the keys to the kingdom.

It certainly seems reasonable for me to store the encrypted private key that I use for business purposes in the directory that my company maintains.  But, would I store the encrypted private key that I use for my on-line banking there?  I think that I'd have to weigh the pros and cons.  On one hand, if I store it in the directory, I can use it even if I don't have my smart card and I never have to worry about losing it.  On the negative side, some administrators could, potentially, pose as me.  If I stored it in a smart card, I have control over it.  But, how well do I guard my wallet against theft?  How often do I lose it?  Anyone who finds/steals my smart card could break the PIN number and pose as me.  

The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomings.  It all seems to boil down to:  Who do you trust?  and   What kind of availability do you need?

Tammy Green Carter

>>> Stephen Kent <[email-masked]> 2-1-99 3:14:41 PM >>>
Tammy,

>You asked about storing the private key.  Currently, Novell's PKI solution
>encrypts the private key and stores it in the user's object.  The private
>key is encrypted with a partition specific key such that each server
>holding a replica of the partition in which the user's object resides can
>decrypt the private key.  We use ACLs provided by the directory (NDS in
>our case), to keep unauthorized people from reading the private key.  For
>those users who don't trust the directory or their administrators, we are
>working on a solution which will store the private key on a smart card.
>When smart cards come along, the obvious place to store the chain is on
>the smart card, eliminating these issues altogether.

I'm surprized by the description above, if I understand it.  Why is the
private key for a user accessible to anyone but the user?  Letting
directories have access to that key seems like a very a serious security
problem.  Even when smart cards are more widely used, their storage is
limited, so you may find it appropriate to keep private keys and certs, as
well as cert chains, in a directory object, on a per user basis, so that
this info ca  be downloaded and the appropriate private keys moved into the
user's smart card, as needed.

Steve

---

From: Andrew Probert <[email-masked]>
Date: Thu, 4 Feb 1999 15:15:48 +1100

Sorry typo in previous email ..

> 	If the Internet cannot work [Andrew Probert]   *without*
> pre-registered DNSes and entries,
> then why do we expect global interoperable PKI to work without
> pre-registration!
> 
>

---

From: Andrew Probert <[email-masked]>
Date: Thu, 4 Feb 1999 16:24:21 +1100

> Beg to differ on this ..
> 
> <snip>
> 
> >	If the Internet cannot work with pre-registered DNSes and entries,
> This analogy is often used, but I wonder how appropriate this is.
> The internet DNS has the job of routing traffic.  The "global PKI"
> is not in the business (centrally) of routing traffic.
> 
> [Andrew Probert]  DNS is in the business of providing a registry where we
> can register FQDNs (Fully Qualified Domain Names) againsts their matching
> IP addresses xxx.xxx.xxx.xxx.  
> 
> The job of routing is performed in a meshed manner by the network hardware
> using the resolved IP addresses.
> 
> The key feature is that it allows us to give devices and applications
> logical names and a level of indirection from the infrastructure.
> 
> DNSes only route DNS queries i.e. if your local DNS cannot resolve a FQDN
> to an IP address from its local database or cache, it will query its
> superior DNS eventually returning the IP address in question.  From then
> on the DNSes do not particpate in the subsequent point to point
> communication / protocols.
> 
> The reason it works is that there are Naming Rules and Registration Rules
> applied to this namespace.
> 
> I believe the analogy is strong for the needs for Naming Rules and
> Registration Rules to be applied to the PKIX architecture .. with a naming
> lookup service?
> 
> If people want to run closed user group networks, today they have private
> DNS and private namespaces.  If they want to run in the global
> interoperable world they must abide by 'rules'.  Why should PKI not follow
> this model?
> 
> 
> ___tony___
> 
> Tony Bartoletti                                             LL
> SPI-NET GURU                                             LL LL
> Computer Security Technology Center                   LL LL LL
> Lawrence Livermore National Lab                       LL LL LL
> PO Box 808, L - 303                                   LL LL LLLLLLLL
> Livermore, CA 94551-9900                              LL LLLLLLLL
> email: [email-masked]   phone: 925-422-3881             LLLLLLLL
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  +61 3 9690 8877
> Fax +61 3 9690 8171
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Feb 1999 10:24:20 -0700

I'm not sure I understand your comment, Tony.
Certainly we're not suggesting that any particular paradigm
be mandated, or even favored, merely allowed to be supported.

Remember that this discussion started off by asking the question of where
certificate chains should be stored in a directory. How is that going to 
disaffect some subset of users?

Obviously we could go off and do whatever we need to do in
a proprietary manner, but that wouldn't be very helpful with respect 
to achieving interoperability of PKI and directories, would it?

Surely you're not suggesting that one faction of the standards community 
should _prevent_ another group from doing whatever they need to do?

Bob

>>> Tony Bartoletti <[email-masked]> 02/03/99 08:06PM >>>
>Steve,

[snip]

>The choice seems to be about how much I trust myself as opposed to the company whose directory I'm using.  There's no right answer here.  Both have their vulnerabilities.  Both have their shortcomin…

And is it wise to design into infrastructure a "favored" paradigm, when it is
guaranteed to disaffect that half of the community who want to do it the other way?

____tony____

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL

---

From: "Tammy Carter" <[email-masked]>
Date: Thu, 04 Feb 1999 12:19:00 -0700

Francois,

I did look at CertificationPath.  I had a couple of concerns about using it, though.  

1.  No other X.500 attributes have this syntax.  This, in and of itself, is not bad.  However, it does give me pause to wonder if there is a "better" syntax?

2.  I am unsure how to use CertificatePair correctly in this context.  After all, it hasn't been that long ago that the PKIX community realized that there were two separate understandings of how CertificatePair was to be used in the attribute crossCertificatePair.  So I wasn't sure that I wanted to open the can of worms and blaze the trail.

Has anyone else seen this data type used before?  If so, in what situations?

Tammy Green Carter
[email-masked]

>>> Francois Rousseau <[email-masked]> 2-4-99 7:00:05 AM >>>
Tammy,

Have you considered for this using the ASN.1 data type "CertificationPath",
which is defined at the end of Clause 8 of X.509 (97) as follows:

CertificationPath		::=	SEQUENCE {
	userCertificate		Certificate,
	theCACertificates		SEQUENCE OF CertificatePair OPTIONAL }

CertificatePair		::=	SEQUENCE {
	forward		[0]	Certificate OPTIONAL,
	reverse		[1]	Certificate OPTIONAL
			-- at least one of the pair shall be present -- }

Francois Rousseau
AEPOS Technologies

Bob Jueneman wrote:
[snip]
> So it appears that we need to be able to store an entire chain of
certificates in
> one place, presumably associated with the user's object. So what kind of
attribute
> should be used, and where should it be located?
>
> Bob
>

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 04 Feb 1999 11:41:18 -0800

At 11:52 AM 2/4/99 -0500, Paul Koning wrote:
>>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>
> Tony> This analogy is often used, but I wonder how appropriate this
> Tony> is.  The internet DNS has the job of routing traffic.  The
> Tony> "global PKI" is not in the business (centrally) of routing
> Tony> traffic.
>
>I must be missing something.  DNS doesn't do routing.  It maps names
>to identifiers (so-called IP "addresses").  Nothing in DNS has any
>connection to routing -- that's the job of OSPF, BGP, and sundry
>others.
>
>	paul

OK.  I meant it directly supports the routing of traffic, and its function
should be leveraged more than be co-opted.  I am of two-minds on this, for
there is value in NOT relying upon the "one naming authority in the sky"
for all identity resolution as well.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL

---

From: "Tammy Carter" <[email-masked]>
Date: Thu, 04 Feb 1999 12:57:42 -0700

Comments below.....

>>>> Andrew Probert <[email-masked]> 2-3-99 6:58:59 PM >>>
>Sundry comments.. 
>
>Andew Probert
>> From:	Bob Jueneman [SMTP:[email-masked]] 
>> Sent:	Thursday, February 04, 1999 9:27 AM
>> To:	[email-masked]; [email-masked]; [email-masked] 
>	[Andrew Probert]  <snip> 
>	If you allow active content to be downloaded, you could store
>encrypted keys in directory and download to the user, where they use their
>password to decrypt it and use it.  If you have sufficent seperation of
>duties from applet download / admin and the directory, it offers the
>alternative of not having keys accessible to operators..

Unfortunately, even in this situation, the keys are still vulnerable to off-line encryption-breaking attacks by the operators.  However, as per my previous emails, I believe that, for some keys, the risk is acceptable.  

(Bob's personal signature key would obviously not be one of those keys.  :)

<snipping Bob's comments>

>	[Andrew Probert]  Excellent points...  
>
>	The Internet only works because the DNS system is there, all DNSes
>know about their superiors up to the top *.NET, *.COM, *.ORG etc and
>InterNIC runs them.  (The CRL / OSCP is relying on a URL for a Name to map
>to a DNS for IP Address resolution.)
>
>	It is fundamental to the working of PKI that this point is addressed
>as infrastructure i.e. registration of CA directories etc.!!  
>
>	There are not going to be an unlimited number of PKIs, in fact there
>are not too many now, so the the registration structure should be put in
>place now, akin to DNS.  Where are our "authoritative servers" in the
>architecture that perform PKI equivalents to DNS name -> address resolution
>that have crypto and certificate capability?

Here I would beg to differ.  There are several vendors (Entrust, Netscape, Microsoft, and Novell to name a few) which sell create-your-own-PKI software.  Using this software, any company can establish it's own top-level CA and set up their very own PKI.  Perhaps there aren't very many "roots" which are recognized by the world or listed in the major browsers, but I would hypothesize that there are several burgeoning PKIs which are known only within particular communities.  

It is certainly an option to have a "PKI root CA registry."  But, do we really want to?  Is there a better way?  When an extension was added to a certificate to hold a location at which revocation information could be found, the registry option must have been considered and rejected.  Why was is rejected?  Perhaps Bob is right and a similar extension should be added for the location of the issuer's certificate.

<snip>

>	[Andrew Probert] Performance hits are relative.  If I have a
>directory with a 30 millisecond response time to a single read, out of a
>directory with > million entries, is this slow or fast enough?  
>
>	We need to provide some operational criteria about retrieval rates,
>volumes etc required for Global PKI, then apply technology, partitioning,
>cacheing strategies to suit the requirement.

Criteria would be a great thing to see.  But, I'm not sure that it helps when you consider some of the worst-case-scanrios.  My biggest concern is not a 30 millisecond retrieval time.  Instead, it is that the client may not be able to get to a server (or to the right server) for hours or even days due to network outages, protocol incompatibilities, downed WAN links, etc.

<snip>

>	[Andrew Probert]  I think it will be located in many / multiple
>places.  So may as well start by defining its structure, then where to put
>it etc is the second issue.  An ASN.1 structure, maybe PKCS#7?  What else do
>we need to know about it?

As Francois Rousseau reminded me, an ASN.1 structure does exist.  It is called CertificateChain.  However, as I said in a previous email, I haven't heard of anyone using it yet.  Perhaps it has fallen out of favor?

Tammy Green Carter
[email-masked]

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 04 Feb 1999 11:53:03 -0800

>be mandated, or even favored, merely allowed to be supported.

I understood this, I think.  As you say, we are only suggesting that
a particular paradigm be "allowed to be supported."  The somewhat heated
exchange on this thread indicates a variance on allowance that goes
beyond a mere debate about optimizations.  As Tammy Carter point out,
it is about who you will trust.  Unfortunately, decisions which impact
performance to one paradigm or another can have multiplicative consequences
down the line.

Perhaps you read my comment as contrary to Tammy's observation.  I intended
to be supportive.  I suppose it could have been taken either way.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Feb 1999 09:56:29 +1100

Most systems now have the ability to go from local files, -> address
books ---> LDAP servers - eg SUN, Msoft, Lotus - so the interfaces are
being implemented.
I can use the X.500 on my laptop to store a company org, a set of
documents and some demo stuff with movie clips in.
I could also put in a local DIB for "cert paths I like to use"....

Directories (and Boats) are wonderful eh! :-)

regards alan

> Sent:	Thursday, February 04, 1999 8:22 AM
> To:	PKIX ; [email-masked]
> You bring up an interesting idea.  Perhaps, instead of caching the
> certificate chain on the user's object, the user should be selectively
> caching directory objects which could be periodically refreshed.  The
> question is:  If such a mini-directory were provided on a client,
> would applications take advantage of it?  Would my email package be
> able to go and look there for certificates rather than turning to a
> personal address book?
> 
> Perhaps, but the "personal address book" or some kind of certificate
> repository would still be necessary in some cases.  People who use CAs
> which are external to their tree (e.g., VeriSign, or even CA's in a
> different tree) would still need to cache the certificate(s) necessary
> to make up a certificate chain for inclusion in an S/MIME message
> since these certificates may not always be easy to get to.
> 
> Interesting notion to download portions of the directory to the
> client....  Rather than doing LDAP off of your client, you could do it
> to access the locally cached directory.  Interesting.....
> 
> Tammy Green Carter
> 
> 
> >>> Alan Lloyd <[email-masked]> 1-31-99 4:20:45 PM
> >>>
> 
> <snip>
>

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Feb 1999 10:24:26 +1100

The good thing about infrastructures is that they evolve over time. by
contribution, by investment and by usage - and if they are good they get
protected by law, defence agencies, or service providors or by
commercial policy.

Debating if a set of DSAs with protocols and X.509 objects is good or
bad as an infrastucture seems to be a waste of time.

And again  if half of an organisation does not use an infrastructure -
then some thing somewhere that is highly related to Humans - such as
business policy, human team spriit and engineering excellence has gone
wrong.

Over the last few hours I used the phone, roads, water, gas and internet
infrastructures - along with billions of others:-) 

regards alan

> From:	Tony Bartoletti 
> Sent:	Thursday, February 04, 1999 2:07 PM
> To:	Tammy Carter; [email-masked]; [email-masked]
> >The choice seems to be about how much I trust myself as opposed to
> the company whose directory I'm using.  There's no right answer here.
> Both have their vulnerabilities.  Both have their shortcomings.  It
> all seems to boil down to:  Who do you trust?  and   What kind of
> availability do you need?
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 1999 18:26:10 -0500

Tammy,

>Generally speaking, information which is stored in a directory is
>accessible only to those people who are granted explicit access rights.
>And, by default, only the user would be given rights to his encrypted
>private key stored on his own object.  Thus, the user would have to
>specifically gave someone else rights to access his private key.

This assumes that the directory access controls are not violated, e.g., via
subversion of the underlying OS or as a result of a management error.
Experinece suggests that such assumtpions are generally unwarranted.

>However, those administrators with direct access to the directory database
>wherein my object resides could give themselves rights to my private key.
>Or copy it for an off-line attack on the encryption.  Or even change it.
>When my encrypted private key is stored in the directory, it is vulnerable
>to anyone who can get to a server which holds a copy of my object.  As we
>are fond of saying here - - Once someone has physical access to the
>server, all bets are off.

Which is a good reason to not take such chances.

>BUT....  That's true about any information which is stored in a directory.
>Not just about my private key.  From a company's perspective, there are
>far worse things that someone can do with physical access to a server than
>to pose as one of their employees.  So, a company would (hopefully) screen
>people a bit before giving them the keys to the kingdom.

The most sensitive data is unlikley to be stored in a directory, but is may
be stored in various file or web servers, access to which can be effected
once one has acquired the private keys of authorized users. So, which it is
true that a company is concerned about the sensitivity of the data stored
in a directory, I doubt that this data is the most sensitive data in the
company.

>It certainly seems reasonable for me to store the encrypted private key
>that I use for business purposes in the directory that my company
>maintains.  But, would I store the encrypted private key that I use for my
>on-line banking there?  I think that I'd have to weigh the pros and cons.
>On one hand, if I store it in the directory, I can use it even if I don't
>have my smart card and I never have to worry about losing it.  On the
>negative side, some administrators could, potentially, pose as me.  If I
>stored it in a smart card, I have control over it.  But, how well do I
>guard my wallet against theft?  How often do I lose it?  Anyone who
>finds/steals my smart card could break the PIN number and pose as me.

Good points, which get back to the usual question: what is the threat?  If
you are more concerned about muggers that hackers, then a directory might
be the better solution, but I still would want to encrypt the private key
there in a fahsion that does not make it accessible to system
administrators.

>The choice seems to be about how much I trust myself as opposed to the
>company whose directory I'm using.  There's no right answer here.  Both
>have their vulnerabilities.  Both have their shortcomings.  It all seems
>to boil down to:  Who do you trust?  and   What kind of availability do
>you need?

Again, one has to answer these questions in the context of a percieved
threat.  Absent a threat model, one cannot evaluate alternatives
meaningfully.  What worried me about what you described is the notion of
encrypting these keys with keys that are accessible to other than the user.
I suggest that there is a reasonable body of literature providing various
ways of protecting personal keys stored outside of my computing environment
without accepting the risks that seem to accrue from this approach.

Steve

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Feb 1999 14:54:23 +1100

Comments in line

> From:	Stephen Kent 
> Sent:	Friday, February 05, 1999 4:57 AM
> To:	Andrew Probert
> Cc:	'Alan Lloyd'; 'Bob Jueneman'; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: FW: Attribute used to store cached certificate
> chains?
> 
> andrew,
> 
> >I think a re-statement and perhaps some may think oversimplification
> of the
> >case is as follows: -
> >
> >CRLs are a batch method for publishing CRLs and we are agreed that an
> online
> >realtime mechanism is required.
> >A client navigating to a single OCSP server looks ok.
> >When there are myriad of OCSP servers, the job becomes far more
> complex.
> >A rationalisation of this is to have a single OCSP server that via
> backend
> >protocols talks to other OCSP servers on the users behalf.
> 
> I can put the name of one OCSP server into a cert and have many
> instances
> of that server available, for reliability.  
	But this means that the OCSP servers need to share the same data
and information sets ie replication is needed > In addition OCSP servers
may wish to do contextual/policy verification - based on locality/value
transaction originator.
	So I think there is a bit more to it than saying a URL to
multiple OCSP servers is OK. Before one says that we need to understand
contexts, policies and information management issues.

> We do this with web servers
> quite well today, 
	These are much simpler that cert validation in a business
transaction context.

> so this is not an unsolvable problem.  Also, having lots
> of OCSP servers is not intrinsically a problem; the problem you cite
> seems
> to arise only when a given cert might be checked by many independent
> servers.  I've not seen compelling arguments suggesting why such an
> arrangement is needed.
> 
	I have a few views about this.

	regards alan

---

From: "Tammy Carter" <[email-masked]>
Date: Fri, 05 Feb 1999 11:08:09 -0700

Steve,

>>>> Stephen Kent <[email-masked]> 2-4-99 4:26:10 PM >>>
>Tammy,
>

Point taken.  There are additional threats other than physical access to the servers.

>in a directory, I doubt that this data is the most sensitive data in the

Again, point taken.  I have been thinking about this from a more Novell-centric point of view.  NDS tries, sometimes more successfully than others, to unify the directory and the file system.  Many other directories, however, do _not_ contain file system information and the access controls for one have no relation to the access controls of the other.  The risks for storing private keys in those types of directories seem much higher.  In such scenarios, perhaps smart cards are the only answer.

>without accepting the risks that seem to accrue from this approach.

I understand your worry and agree.  The classic method to use in protecting the private keys is a password.  In that way the security of the private key lies with the user and what kind of passwords are chosen.  (Well, it also lies with the company maintaining the directory in terms of how well they protect the database.  An attacker with access to the database could do off-line attacks on the encrypted private keys.)  In our environment, however, the benefits of password protection do not outweight the inconvience of making the user remember yet another password.  But, as our users become more savvy, it would certainly make a nice enhancement.

Tammy Green Carter
[email-masked]