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

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

Comments in line -

> -----Original Message-----
> From:	Tony Bartoletti 
> Sent:	Thursday, February 04, 1999 2:24 PM
> To:	Andrew Probert; 'Bob Jueneman'; [email-masked]; [email-masked];
> [email-masked]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> At 12:58 PM 2/4/99 +1100, Andrew Probert wrote:
> >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..
> 
> 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.
>   
	logic error detected here :-)
	But having implemented air gaps and putting guards with guns
around them must have been directed by a company policy.

> [snip]
> 
> >	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!
> 
> 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.
> 
	DNS provides resolution of domain space to IP addresses  so that
the Internet traffic can be routed (by routers)
	PKI functionality (global or otherwise) if based on directory
infrastructures will route transactions based on object names and system
knowledge of those names and name spaces. Transactions in this case will
be get a cert or crl or other PKI related information object .

	regards alan
> ___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: Tony Bartoletti <[email-masked]>
Date: Thu, 04 Feb 1999 16:24:32 -0800

>around them must have been directed by a company policy.

OK, point taken :)

I guess they would have to be MY guards and guns (and they won't go for that)
so I would settle for having these global resources provide highly reliable
access to (potentially) "named opaque blobs".  Then no breach of internal
separations is a problem.  As long as the parties-at-risk are the only ones
who can make use of a blob, then there should be no objection to centralized
directory services.  I suppose it was Bob's comments about where he might
or might not keep his (unencrypted) secret key that set me off.

(Reducing to DefCon level 5)

___tony___

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL