Greetings,
You're right. There's no use in continuing the discussion. I would
refer the discussion to ISO 15782 to get a better understanding of the
exposures and what the international standards say about it. There is
also a recent ANSI standard that talks to this point developed under X9,
though I don't recall the designation (X9.79 maybe?).
Contact me off-list if you would llike to continue the dscussion.
If you have any quesitons, please don't hesitate to contact me directly.
Bill
Hernath Szabolcs wrote:
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
-------------------------------------------------------
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
