HI,
I think there is no point in arguing about details anymore, if we clearly
disagree on the most fundamental point.
If one considers the new encoding of the root cert a 'new certificate',
all you write is true about the separate hierarchies, the problems etc.
If, however, you know that the modifications do not change anything about
the trust associated with the CA root keypair, then the two versions of
the root cert will function identically *by definition* . This means, of
course, that you are not even interested in differentiating the two.
Szabolcs
P.S. I guess if we continue the discussion, we should nott OFF the list
anymore, rather, do it in private mail.
On Wed, 16 Nov 2005, silverhairbp wrote:
Hernath Szabolcs wrote:
On Wed, 16 Nov 2005, silverhairbp wrote:
Hernath Szabolcs wrote:
On Wed, 16 Nov 2005, silverhairbp wrote:
Lets review this.
OK
If a new certificate is issued with different information but the
same public key and serial number as the original, then there is no
point in reissuing since the original certificate can't be CRL'ed
and will still be active through its life. That is one of the
reasons why each certificate MUST have a unique serial number.
I think the point of discussion is 'new certificate' here. It is the
same certificate as before. Only the encoding is different, but their
signatures are identical, and therefore trust validation yields the
same with either copies. They have the same Subject/Issuer DN. The
same public key. The same extensions (well, almost, that is). The same
fingerprints. The same validity period. They provide exactly the same
level of trust for the relying parties. It is not a 'new certificate'
by any stretch of the imagination.
As a point of reference, the new certificate is not the same as before.
It will only copy some of the information from the original certificate
and use the same key pair, but will most certainly be unique to itself.
Since there is no way to CRL the original certificate (no unique DN /
serial number
As said, there is no need to revoke anything...
combination), the original certificate will still be valid. The
signature over the new self-signed root will certainly be different if
the contents of the certificate are changed. Wasn't David's point that
he wanted to change
Well, the signature *over* the root cert itself will actually be different
in the two versions, but
1. These are self-signed anyway, the signature just needs to be valid.
2. What is really important is what kind of signatures these two versions
*produce* on issued certificates & CRLs? They always produce the same
signatures over any request. They will validate each other's signatures in
exactly the same way. They produce the same result in the validation
chain.
That is precisely the problem. Its not a technical problem, its an
operational and trust problem. Its also going to be an inconsistency in the
practice and policies (if their folow standards). Its impossible to
determine which root signed the hierarchy. If one root certificate is deemed
invalid because its contents need to be changed, how do you get rid of it.
the root to better define its use? If the original root certificate is
still available, it undermines the effort to create a new certificate.
I'd wager that 'to better declare its use' would be more appropriate. I
guess he already has the best practice to only use the CA private key for
cert & crl signing. This will not change. Jsut it is now declared in a
flag (well, actually not pricesely, but...), and declared in the policy
(to which an actual policy identifier extension points in all certs,
right?). Then again, no 'new certificate' is created.
What happens during chain validation if the PKCS#9 package contains the
entire chain of certificates back to and including the original root?
It certainly won't match the cached root.
Making your clients reload the root cert in their browsers can be a PITA.
Then again, if you have a proper root distribution framework, it might be
manageable.
It will never be managable unless rebuilding the system is considered
manageable.
And, of course, the original "can't be CRL'ed," I said the exact same
thing. There is no point in revoking a self-signed certificate, if
your CA signing keypair has to be changed. In any case of key
changeover, you roll out a new PKI, and destroy the old keypair. You
must have a working, safe root cert distribution mechanism to the
relying parties anyway.
There is a point of revoking a root certificate if the hierarchy is
being retired before its expiration. Otherwise the hierarchy remains
active and must be managed to prevent its compromise and misuse. It
relates back to the certificate policies and practices created for the
PKI being retired and the new one being established.
I already summarized my preferred practice about this scenario. If you
revoke all issued certificates, and destroy the keypair, and use your
out-of-band secure channels to notify your relying parties about the
changes, the hierarchy is not 'active' anymore. And a self-signed
certificate signing its own revocation simply does not quite make sense.
I think the point is who are the relying parties and the scope of
certificate distribution. If the certificates are used for other than
PIRMA access control against a private system where only a single root
is used, the scheme, dirty as it is, may continue to function. But as
soon as the the hierarchy is used outside of the closed system, trust
fails since more than a single root certificate exists. It is more than
a technical issue, but rather one also associated with the trust
hierarchy.
I have seen the practice in question work virtually flawlessly in a
global, heterogenous, large-scale (about 30000 active certs)
authentication fabric. The only problem seemed to be with some browsers
complaining on reloading the new root cert versions. It could be solved.
The only way is to generate a new rot and suordinate hierarchy. Other ways
are dirty.
It is NEVER permissible to reissue a certificate reusing a serial
number.
Well, first of all this is generally very true - this is a special
case, however. Secondly, it is not quite 'reissued,' see above.
Not "generally" very true, but absolutely. It is the only way a PKI
using the same DN can maintain certificate differentiation.
Except you do not need to differentiate the root cert from itself.
But reusing keys and serial numbers for the root begs the question of which
cert is being referenced. So there is a need for differentiation.
Each certificate must have a unique serial number.
Yes. Same certificate -> same serial.
The scheme descrived by David REQUIRES the extablishment of a new
certificate hierarchy with a new root certificate.
Well, I don't quite agree. If the level of trust put in signatures
does not change with this technical alteration, I see no reason for a
key changeover. It is only a different version of the same root cert
with notably one single different value for an extension.
It is only bad practice to reuse a key pair.
Again, generally this is very true. But this is not an actual re-use.
When keys are reused, the management of the hierarchy requires the
management of the certificates under it. When a key pair is used across
more than one hierarchy, both must manage the key integrity. It is
reuse of in practice to maintain a key in multiple hierarchies. The
compromise of a single reused key impacts multiple hierarchies. The
reason why reuse is (at the very least) bad practice is because it
requires the synchronization of the hierarchies containing the shared
key in the change of user access rights or key exposure.
Well, the keypair is the same. There is absolutely no problem with
integrity. The hierarchy is the same. OTOH, 'requiring the synchronization
of the hierarchies containing the shared keys in the change of user access
rights' is not something you should generally care about if you designed
your namespace and signing policy in a clever way.
That very much depends on how the PKI is being used. For PIRMA SSL implicit
access, it is critical since that is the primary management control.
Reusing the keys requires that both hierarchies must bear the responsibility
of managing separate CRLs for those keys shared between the hierarchies. In
managing what was at the time, the largest private PKI hierarchy, we
absolutely never allowed reuse of keys so that we didn't have to concern
ourselves with whether there would be multiple CRL postings for a single set
of keys.
Bill
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Openca-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openca-users
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Openca-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openca-users
