[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Finding PKIX Servers!
Hi Andrew,
I think we should revoke the root certificate of the Pasadena
Ladies Club for wanting to move their oursourced CRL
management from vali-somebody. Wouldn't you agree :-)
Regards,
Ambarish
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
Vali-Somebody, Inc. ambarish@vali-somebody.com
1215 Terra Bella Ave. http://www.vali-somebody.com
Mountain View, CA 94043-1833
> -----Original Message-----
> From: owner-ietf-pkix@imc.org
> [mailto:owner-ietf-pkix@imc.org]On Behalf
> Of Andrew Probert
> Sent: Thursday, February 04, 1999 5:09 PM
> To: 'Bob Jueneman'; ietf-pkix@imc.org
> Subject: RE: Finding PKIX Servers!
>
>
> I love operational scenarios, they really help get to the crux of the
> matter!
>
> I am comfortable with the Pasadena Ladies Club issuing certs
> once a year.
> Lets suppose they they outsource CRL management to "www.vali-somebody"
> Lets suppose they hardcode the "www.vali-somebody" in the
> certs extension.
> Then they want to change CRL outsourcers, WITHOUT REISSUING
> THEIR CERTS!
>
> The alternative approach is, if the IssuerDistinguishedName
> of Pasadena
> Ladies Club is used to query
> the infrastructure, it will return them a service object
> identifying the CRL
> service provider as
> "www.vali-somebody.com", supporting protocols xyz. It may
> have an alternate
> reference as "LDAP://better.mousetrap.com.au/crl"; as the
> Australian cache /
> provider.
>
> Some extra comments inline..
>
>
> 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
>
>
> > 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.
> >
> [Andrew Probert] More precisely, the available service
> providers
> and protocols, IP addresses, ISDN addresses, suported
> protocols etc. We can
> start to formulate objects for these service definitions.
>
> > Does she have to be preconfigured with the LDAP server
> address of her ISP
> > or portal?
> >
> [Andrew Probert] Absolutely! It is configured with
> the address of
> the portal that she trusts.
>
> By analogy, if you check your IP configuration, you
> will find that
> it is mandatory to have your Primary and optionally Secondary DNS
> pre-configured as the pre-requisite to interoperate with the Internet
> infrastrucuture. The ISP may either run their own DNS server, locally
> caching DNS info, or provide you with the IP address of a superior DNS
> server.
>
> If you are a corporate user, you admin people will
> point you at the
> corporate DNS.
>
> Connection to the PKI infrastructure, to give you global lookup
> capability can follow this analogy
>
> > 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?
> >
> [Andrew Probert] Agreed, nobody can know it unless
> they are given
> that "knowledge reference".
>
> > 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.
> >
> [Andrew Probert] As per discussion above, we could
> hardcode this
> into certificates, but it forces us to rely on FQDN naming
> (Fully Qualified
> Domain Names) to resolve the service, plus this hardcodes to a single
> service provider / trademarks "www.better-moustrap.com"
>
> > Bob
>