|
Posted by Brian Komar [MVP] on October 25, 2006, 2:42 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> > I'm setting up a two-tier PKI hierarchy. The root will be offline and
> > will sign the issuing CA certificate. What is the best-practice for the
> > root Certificate Revocation List and revoking the root certificate?
> >
> > Should I immediately revoke the root certificate after creating the
> > issuing CA and store it in a secure location in case the passphrase is lost?
> >
> > Should I create a certificate revocation list from the root or only on
> > the issuing CA? I certainly don't want to have to retrieve the root
> > authority to update the list, but will the clients handle this OK if the
> > root public key is in the browser but the issuing CA revokes
> > certificates and publishes the list? I would think so, since the chain
> > should be intact.
>
> scrap PKIs, certification authorities, and certificate revocation list
> ... and migrate to real-time, online infrastructure.
>
> the original kerberos pk-init ... misc. past posts
> http://www.garlic.com/~lynn/subpubkey.html#kerberos
>
> started out with a certificateless public key infrastructure ... the
> registration authority (which is common to lots of business processes)
> just registered the public key in lieu of a password ... w/o having to
> issue a certificate ... misc. past posts
> http://www.garlic.com/~lynn/subpubkey.html#certless
>
> so entities can connect/login just thru kerberos digital signature
> authentication protocol ... where the digital signature is directly
> verified by doing real-time access to the registered public key.
>
> note there was also a similar certificateless done for radius ...
> again, w/o having to resort to any of the PKI, certification
> authority, and/or certificate revocation list stuff.
>
> for the SSL, server authentication/encryption scenario ... misc.
> past posts
> http://www.garlic.com/~lynn/subpubkey.html#sslcert
>
> the scenario involved registering public keys with the domain name
> infrastructure ... and doing real-time retrieval of public keys as
> part of the existing domain name infrastructure protocols (even
> piggyback in existing transmission).
>
> the issue here was that the PKI/CA business operations were already
> somewhat advocating registration of public keys with the domain name
> infrastructure ... as a countermeasure to some integrity issues that
> the SSL domain name certificate operations have ... aka as part of a
> ceritification authority certifying a SSL domain name certificate
> operations ... they have to validate that they are dealing with the
| 
XML site map