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

From: Andrew Probert <[email-masked]>
Date: Thu, 4 Feb 1999 12:58:59 +1100

Sundry comments.. 

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

> -----Original Message-----
> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Thursday, February 04, 1999 9:27 AM
> To:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> This discussion has kicked off several subthreads, and I'd 
> like to comment on a couple of them.
> 
	[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..

> 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.
> 
> 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?)  
> 
	[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.)

	If the Internet cannot work with pre-registered DNSes and entries,
then why do we expect global interoperable PKI to work without
pre-registration!

	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?

	It does not seem too much trouble for an organisation to run a Level
1 DSA as a registry of DSAs and in fact the names and network addresses of
OCSP servers, ICAP Servers (draft-sakurai-pkix-icap-01.txt) and in fact all
of the plethora of PKIX server and protocols that seem to be coming!

> Unfortunately, the performance hit in this case would be even worse than
> in the 
> local directory. 
> 
	[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.

> 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?
> 
	[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?

> 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: Tony Bartoletti <[email-masked]>
Date: Wed, 03 Feb 1999 19:24:06 -0800

>alternative of not having keys accessible to operators..

The only way you can _ensure_ "sufficient separation" of these duties is
with an "air gap" and guards with guns.  One cannot rely upon "company
policy" that these duties remain separate and inviolable.

[snip]

>then why do we expect global interoperable PKI to work without

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.

___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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 1999 20:04:02 -0500

Andrew,

>alternative of not having keys accessible to operators..

I'm not sure I understand this proposal, and how it provides more secure
private key storage in a directory.  It would seem to rely on successful
enforcement of access controls within the directiry, but if we had lots of
confidence in them, we might not feel the need to consider other solutions.
Also, any approach that begins with "download active content" worries me.

>to a DNS for IP Address resolution.)

This isn't quite true, is it?  There is a distributed root for the DNS, and
the TLDs you mentioned, plus all the country TLDs, are under that.  The
Internet is not authoritative for all of those TLDs, nor for the DNS root.

>then why do we expect global interoperable PKI to work without

I presume you mean " ... without pre-registered ..." right/

>that have crypto and certificate capability?

There may be lots of PKIs, depending on which PKI models one assumes will
prevail.  However, many of them may be closed PKIs, and thus may not impose
significant, global directory demands.

Steve