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.
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.
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.
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.
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.
Szabolcs
Bill
Szabolcs
Bill
Hernath Szabolcs wrote:
On Wed, 16 Nov 2005, David Bannon wrote:
OK Hernath, that makes sense. But how do I get OpenCA to accept a
new,
additional certificate if it does not make it itself ? I tricked it
How do you mean accept?
into letting me make a new one (by removing the existing files) but
if I
Sorry, I don't get it...
generate a new certificate externally and then just put the files
where
OpenCA keeps them, OpenCA will not notice and won't add them to its
I don't have access to my signing machine right now, but I think you
should simply overwrite all instances of the CA root cert within
opencas directory tree with the new version.
Szabolcs
database.
David
PS : When this is all over, I'll write up the procedure for the FAQ,
other people must want this occasionally !
On Wed, 2005-11-16 at 11:40 +0100, Hernath Szabolcs wrote:
Hi,
On Wed, 16 Nov 2005, David Bannon wrote:
Is it necessary for the start and end dates to be the same as
the
original ? Means I cannot use the OpenCA gui to create it but
thats not
too much of a problem.
You certainly don't want to change the start of validity date of
your root
certificate, so you have to create it by hand. You may change the
end date
if necessary. In any way, the change (even if you only alter the
keyUsage
criticality) should be reflected in your new CP/CPS version.
Szabolcs
Would make life a lot easier !
David
Hi All,
On Tue, 15 Nov 2005, silverhairbp wrote:
David Bannon wrote:
Folks, I would like to ask for some advice here. We have a
problem and
below is our plan to solve it. I'd be very grateful if you
could have a
look at it and let me know if you see anything thats going
to bite us
expectantly.
The problem
-----------
We use OpenCA 0.9.2 and it was setup some 12 months ago
using default
settings. Our CA Certificate was originally issued without
the necessary
parameter of keyUsage being 'critical'.
The solution
------------
Revoke all 220 certificates, revoke the CA Certificate,
issue a new CA
certificate (using existing key) and issue new
certificates to users.
I think you should not do that. If the only thing you want to
change is
technical parameters in your root cert, but otherwise use the
same
keypair, you essentially maintain the trust based on the the
signatures
made with your original signing key. In other words, you do
not need to
revoke anything, instead you simply reissue your root cert
with the same
DN, serial, keypair and validity dates and changed technical
parameters
(e.g., fixing the keyUsage, changing the signature algorithm
etc). In this
way, signatures made with the old or new root certs will
validate against
either of them. The already issued certificates will not be
effected.
Besides, there is no point in revoking a self-signed
certificate anyway,
in case you want to terminate the trust associated with the
signatures
made with a CA's signing key before the expiration of the root
cert
(emergency key changeover), you revoke all issued certificates
(except the
root), publish a last valid CRL, destroy all copies of the CA
signing key,
and start anew with a fresh PKI.
If you only want to terminate the usage of a CA's signing key
-without
disruption of the trust associated with its signatures-
(routine key
changeover), you can harmonize various validity dates and CRL
issuance
frequency such that you can keep your usual operating
procedures (issuing
CRLs as usual) and let all certs (issued and root) expire.
Before that
happens, you already start your fresh PKI in parrallel with
some useful
overlap time.
Good Luck,
Cheers
Szabolcs
P.S.: as a sidenote, if the keypair of sub-CA is actually
compromised in a
multilevel hierarchy (as opposed to having some flags
misconfigured), I
would definitely *revoke* the sub-CA's root certificate for
good, not only
suspend it. The keypair is the root of your trust - if it's
compromised,
your pki (under that sub-CA's level) is over.
The Plan
------------
We have established that we can generate a new CA
Certificate and OpenCA
(0.9.2) is quite happy. So this is what we'll do, steps 1
- 3 (below)
must be done before implementation date.
1) Encourage all end users and RA Operators to lodge new
requests for
new certificates.
2) Ordinary users must meet (again) with RA Operators to
show photo ID.
RAO must authorise new applications in normal manner.
3) CA Operators and CA Manager will phone RAOs to
explicitly confirm
details of their own personal applications, in normal
manner.
------ Implementation Day --------
4) On the CA machine, move the existing CA Certificate
files
(from /var/crypto/cacerts) out of the way. Their details
will remain in
the database. Start openCA, make a new request for a self
signed
certificate and then Generate it.
(General->Initialization->Request
Setup, Certificate Setup).
5) On RA, revoke all user certificates and process to CA.
6) On RA, revoke the old CA Certificate and process to CA.
7) Commence issuing the backlog of certificate requests
currently
pending, in the normal manner.
Although we will aim for completing this process in one
day, I doubt we
will be able to do so.
--------------------
I'll be very grateful for any comments you care to make.
David
Rather than revoking the original CA certificate, have you
considerd
suspending it to see if there are any user that have not
installed their new
certificates? It would be easy to roll back the old root
cert and convert
that last users, repead the suspend root process until all
users are
converted. That way you can motivate slow converters to get
new certificates
while minimizing their down time.
As a suggestion, when deploying the new hierarchy, manage
the validity period
closely so taht you can migrate to a new root without a lot
of hassle. There
are papers on the technique available.
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
-------------------------------------------------------
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
-------------------------------------------------------
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
-------------------------------------------------------
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
