Re: Root CA CRLs
- From: Brian Komar [MVP] <bkomar@xxxxxxxxxxxxxxxxx>
- Date: Wed, 25 Oct 2006 13:42:52 -0500
In article <m3d58gjn3l.fsf@xxxxxxxxxxxxxxxxxxx>, lynn@xxxxxxxxxx says...
Seeker <newsgroups@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:.
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
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
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.
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
- Re: Root CA CRLs
- From: Paul Adare
- Re: Root CA CRLs
- Prev by Date: Re: releasing confidential docs
- Next by Date: Re: Root CA CRLs
- Previous by thread: Re: Root CA CRLs
- Next by thread: Re: Root CA CRLs