Appropo finding X.509 Names

[Andrew Probert <AndrewP@xxxxxxxxxxxx>]

Appropo registration of X.509 names.

The Dante project is running a web page pointing to national authorities -
USA / ANSI, UK - BSI etc.

http://www.dante.net/np/reg-auth.html

I am sure there are lots more....  Please let them know..

Note, this does not prescribe interconnectivity, but it is the mechanism for
name registration into the X.500 namespace.

These standards authorities can register your OID prefix for you.  Here,
Standards Australia have a neat optimisation where OIDs are by convention
encoded as 1.2.36.AustralianCompanyNumber, so every incorporated company has
their OID prefix pre-assigned!



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:	Andrew Probert [SMTP:AndrewP@rotek.com.au]
> Sent:	Monday, February 15, 1999 9:44 AM
> To:	'Phillip M Hallam-Baker'; ekr@rtfm.com; Andrew Probert
> Cc:	David P. Kemp; ietf-pkix@imc.org
> Subject:	RE: Finding PKIX Servers!
> 
> Disagree on some items..
> 
> 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:	Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > Sent:	Saturday, February 13, 1999 3:36 AM
> > To:	ekr@rtfm.com; Andrew Probert
> > Cc:	David P. Kemp; ietf-pkix@imc.org
> > Subject:	RE: Finding PKIX Servers!
> > 
> 	[Andrew Probert]  <snip>
> > Actually, the idea we had was to remove the unnecessary work from
> > the application. FTP's twin connection is far more complex for any
> > application to manage than the HTTP 'idempotent request' model.
> > Similarly the LDAP BIND operation achieves nothing of real value.
> > 
> > The 'complexity' of HTTP/1.1 is due to the caching model. No other
> > retrieval protocol I am aware of has any caching model - the
> applications
> > were too busy performing unnecessary operations such as BIND and UNBIND.
> > Caching is not a particular burden on applications however.
> > 
> 	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
> partitioning example of functionality up into infrastructure, the work's
> got
> to be done somewhere!
> 
> 	Why do you think BIND/UNBIND is unnecessary?  
> 
> 
> > Even with every 1.1 boondoggle, HTTP is by far the most straightforward
> > protocol to implement at the application level.
> > 
> 	[Andrew Probert]  My personal experience is that strong
> authentication has been pushed down into SSL model, then I had to do lots
> of
> backflips and spend real development $$ to intercept SSL strong
> authentication, encode it as HTTP header vars and pass it back up to my
> applications which were on top of HTTP.  (Live ecommerce site, now doing
> 20,000 transactions per month)
> 
> 	Where's the integrated authentication in this model?
> >  
> > In retrospect I think that the confusion that HTTP ended concerned
> > the interface between the authentication/authorization model (an
> > application concern) and the transport connection. 
> 	[Andrew Probert]  Disagree, see above.
> > For some reason it
> > was assumed to be a good idea to keep TCP/IP sessions going
> > indefinitely - instead of simply caching the access control context
> > at each end.
> > 
> 	[Andrew Probert]  Agree SSL is a good model and does cache access
> control.  However, policy regarding timeouts of SSL sessions and
> generation
> of new session keys is weak e.g. do I need to re-authentication every 10
> minutes, 1 hour etc, normally a server side setting!
> 
> > Unfortunately some folk took this a bit far, maybe Eric can remember
> > the name of that chap from Chicago who he used to work with who had
> > the idea of downloding every image in a page as a separate TCP/IP
> > connection. That was definitely a bad idea!
> > 
> 	[Andrew Probert]  Agree..
> 
> > 		Phill