RE: Finding PKIX Servers!

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

some comments

> -----Original Message-----
> From:	Bob Jueneman 
> Sent:	Friday, February 05, 1999 11:07 AM
> To:	ietf-pkix@imc.org; Tammy Carter; AndrewP@rotek.com.au
> Subject:	Re: Finding PKIX Servers!
> 
> Andrew,
> 
> [snip]
> > 
> 	[Andrew Probert]  Yep.. I agree that an extension could be used
> because the current extension is a Uniform Resource Locator, which
> constrains the reference to a WWW style protocol http://, ftp://, (and
> even
> ldap://).  This current extension presupposes / forces certificate
> validation paths into the infrastructure of URN/DNS/IP/ARP resolution
> and
> protocols.
> 
> 	Alternatively, when I already have the IssuerDistinguishedName,
> if
> there was actually a PKIX naming resolution protocol in place I can
> simply
> look this up to find the servers.   
	No all one needs is a "port" on a directory service  and use the
name to find the issuer - which should I know the comms addresses or
URLs of the issuer. I do not know the wire identifiers or the switch
numbers of the telephone system - I use a phone number for the target
recipient....
	In directories ...  I would use the name to get to the target
object - an entity which is an organisation, an organisational unit, a
device, a role or a person that performs the CA FUNCTION.


	I think of CAs as a function of a real world entity represented
in a directory as an object that INCLUDEs the properties of a CA.

	It seems that some think of CAs a servers with URLs

	The difference is: directories provide an information services
paradigm to this requirement

	directory less approaches provide a protocols and URLs
technology approach - scaleability, application, operations and
management overheads do not seem to be addressed - 
	whereas the directory approach deals with this..

	snip

> 	I suggest that X.500/DSP is stable and mature for online relay
> of
> queries.  X.500/DISP addresses some replication / caching issues.  The
> protocol is already certficate / crypto aware.  It can be accessed by
> front-end protocols of LDAP, DAP and Web/LDAP gateways.
> 
> [RRJ]  Ok, I think we are getting somewhere.
> 
> But...
> 
> Suppose the relying party is the legendary little old lady in Dubuque.
> 
> All she wants to do is be sure that amazon.com is really who they say
> they 
> are.  Let's imagine that she has an LDAP client available through her
> generic 
> browser -- what does she do?
> 
> She is knowledgeable enough to check the certificate for Amazon before
> 
> placing an order, and finds that there is one, but being a little
> suspicious, 
> decides to check on who issued it, and clicks on "Issuer".  Yup, there
> it is,
>      US
>      "RSA Data Security, Inc."
>      Secure Server Certification Authority
> 
> Great! Now her LDAP server knows exactly where to go (assuming that
> this was 
> the next certificate in the chain, and not the root.)  Go to the US,
> and search for 
> RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just
> maybe, it will tell
> you what the DNS name, port number, etc., are that LDAP would have to
> use to 
> do anything.
> 
> Does she have to be preconfigured with the LDAP server address of her
> ISP or portal?
> What if the Issuer is not a well-known public CA, but the Pasadena
> Ladies Garden
> Club,  which hands out certificates to the members once a year, and
> then shuts down
> the server.
> 
> All the members of the Garden Club know that they use an external
> repository to maintain
> their CRL list, but how does the LOLFD know that?  Or even AOL?
> 
	This is a very heart waming story  - but am totally convinced
that little old ladies wont do anything where they have to understand
the stuff that gets discussed on this list.
	Its best if they bash on something with their pension book and
it all happens -  And we know it  will just happen better with a
directory service there.

	eg. I gave my mum my book on OSI and X.500 for xmas some years
go - she got to the part that dealt with DOP and DSA entry updates
across DSA boundaries and multiple superior references and then gave up
... QED :-)))


> The more I think about it, the more I like the idea of including a URL
> for the issuer's
> directory in the certificate itself.
	I dont. Simply because its unnecessary.

	X.509 is part of X.500 - ie the names in a cert should be
entries in the directory system that supports the certficate service.
The only reason you need URLs is the fact you are not using a directory
service. And we all know we need directories for the internet and
telephone and PKI systems to scale and be well managed.


	regards alan
> Bob