Re: Securing a CA
Mark H. Wood wrote: Um, feel free to point me elsewhere, but I'm having trouble visualizing what's being discussed. I keep reading branched certificate chain, but what I understood from the description is like this: Before:OurRoot --- Level1 --- EndUsers After: IdenTrust --- OurRoot --- Level1 --- EndUsers What is the contents of the issuer field of the cert marked OurRoot? Before: our name After: IdenTrust's name So consider a browser that still has the OLD OurRoot sitting it its disk file, and then it gets ANOTHER DIFFERENT OurRoot in the chain shipped down from the server. Now, it starts building the chain with EndUsers, gets to Level1 OK, but when it wants to extend the next time, it has two choices, the OLD OurRoot still in its disk file, and the NEW OurRoot (which is not actually a root anymore) that came from the server. I could draw you more complicated diagrams in the context of the problem I was trying to solve last year: transparent upgrade from an old local root to a new local root. The approach I was trying was various forms of old root signed by new root and new root signed by old root but as I said I cannot show you something that actually works because I didn't find one... :-) -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Um, feel free to point me elsewhere, but I'm having trouble visualizing what's being discussed. I keep reading branched certificate chain, but what I understood from the description is like this: Before:OurRoot --- Level1 --- EndUsers After: IdenTrust --- OurRoot --- Level1 --- EndUsers where the arrow is pronounced signed. In what way is this branched? Now, if you did it this way: Before: OurRoot --- Level1 --- EndUsers OurRoot \ After:-- Level1 --- EndUsers -- IdenTrust/ (That is, two roots have signed the Level1 CA's cert.) then I could see calling it branched, and that a very simple verification algorithm could be confused. But multiple signatures don't seem to be allowed by the ASN.1 definition of Certificate that I find in RFC3280, so this can't happen. I guess that the branching is actually this: the verification code reaches a point at which it is known that a certificate for OurRoot is in our store of trusted roots, and *also* that a different, non-selfsigned certificate was provided by the other end. The code could: o check first in its own store, when verifying Level1, see a selfsigned cert. that is trusted, and consider the chain completed; o check first in the stack of cert.s offered in the exchange, see that OurRoot is itself a subordinate cert., and continue chaining back to IdenTrust; o check *both*, note a discrepancy, yell bloody murder! and ask the user for a decision. If I've misunderstood the problem, what would you recommend I read? - -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Open-source executable: $0.00. Source: $0.00 Control: priceless! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFAh+WUs/NR4JuTKG8RAi/eAJ4wirlIcDZTUNVGnlp6U+DyVXl35wCfX2i6 HQ99YtYMAilcyLM/i1pmZv4= =PHLU -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Rich Salz wrote: At the risk of being immodest, you might find this column useful: http://webservices.xml.com/pub/a/ws/2003/12/09/salz.html This is a verbatim quote from the text at that URL: The root will sign the Level 1 CA and then be taken offline. Anyone who wants to validate any identity within our organization only needs to have our root certificate. If the enterprise merges ... or joins a commercial PKI (such as Identrus), then we only need = to get the root certificate signed by our new super root. = Now, I've seen this (kind of) quote over and over again from the theoreticians of PKI, but as a practical implementor I've never really understood how things could be quite this simple. Perhaps it would be edifying if somebody who's been in this stuff more than just a few years could straighten me out. The example PKI from that article has only one intermediate certificate (called the Level 1 CA) so there would seem to be only two possible configurations for an SSL server operating under this example: either the server has a two-certificate chain (the L1 certificate and the end-user certificate for the server itself) or a three-certificate chain (above plus ROOT CA). Now, what has to happen at EACH server in the enterprise when doing a transition from this local CA to a commercial PKI (such as Identrus) If (without loss of generality) Identrus signs the pre-existing root certificate, that produces a new root certificate, although it contains the same public key as the pre-existing root. In the two-certificate case above, nothing needs to be done to the server, since it never had the root in the first place. In the three-certificate case, the new root certificate (signed by Identrus instead of signed by itself (self-signed)) must be installed on every server. I understand this. HOWEVER, what now happens at the client? In the two-certificate case, the client lacks the critical link from L1 to the Identrus root it already have (came installed in the browser) so in this case we need to visit every server and convert it from the two-certificate to the three-certificate configuration to get the missing link available to the client? In the three-certificate case do we need to replace the self-signed root in every server with the missing link certificate? In any case, it seems like we must do something explicit at every server in the enterprise. Am I missing something here? -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Follow up to previous posting: I did try to do some experimentation in the context of trying to design a clean transition from the root we made in 1998 to the root I made in 2003. I did not have a great deal of success because the browsers I was working with at the time (Netscape 4.7x and IE 4 or 5) could not properly deal with what the PKI theoreticians call a branched certificate chain, which was what was really needed to address that problem. Could the PKI theoreticians acknowledge the fact that the real world certificate verifiers out there in fact cannot properly deal with a branched certificate chain, and that this deficiency severely limits the utility (e.g., truth :-) of statements such as If the enterprise merges or joins a commercial PKI (such as Identrus), then we only need to get the root certificate signed by our new super root? Needed added text: AND arrange for the NEW CERTIFICATE formed by getting our root certificate signed by our new super root to be available to the certificate chain validation software out there in the clients, AND make sure that in none of the four transition cases* is there any ambiguity in forming the certificate chain to be verified (this is the branch question) since the browsers don't deal well with trying to deal with branched certificate chains? Or am I living in the past, and up-to-date browsers have been fixed so this is no longer a problem??? N.B., the branched-certificate-chain case also occurs when you talk about so-called bridged PKIs. You have been warned. *Four transition cases I was considering: 1. unmodified client and unmodified server 2. unmodified clinet and updated server 3. updated client and as-yet unmodified server 4. updated client and server In all fairness my case was a bit harder since it was from one local root to another local root so it could not be assumed that the new local root was already in the client, while the present situation is that we can assume that the Identrus root is already present in the client, so the case of an unmodified client does not happen... -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Actually, it might be as easy as changing the name of the root and issuing a new L1 certificate. The branch happens when an unmodified client (which still has the local root installed) needs to decide who has signed the L1 certificate. Its two choices are 1. the local root 2. the missing link that the server gave it, which has the same name (e.g., Subject Key Identifier, which is a hash of the Subject DN information) If you subtly change the Subject DN of the root (which in the new scheme of things becomes a first level down from the Identrus root), and then reinstall a L1 certificate in the server that has the new Issuer ID but the old Subject ID, then the end user certificate does not need to be redone (since its hash is based on the L1 name which was not modified), and when the verifying software is looking for the issuer of the L1 certificate, this hash HAS been modified, so the old root is no longer in contention... I'll do some gedanken-thinking about this... -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
I was envisioning something much simpler. Existing applications that know about the root CA work without configuration changes. New applications that need to know about the new larger PKI just add the new root to their list of trust anchors. I suppose that's really a bridge-CA. I don't think branched cert chains need to get involved, so I don't think I need to qualify or disclaim what I wrote. Yes, I ignored the details of distributing the new root certificate; there's a limit on the column length, ya know. In retrospect, adding (and get hte new root distirbuted and used) would probably have been worth adding. At any rate, the key point is that if you anchor everything you do under a single root, than moving your tree underneath something else is a lot eaiser if only one root has to move, rather than everything. okay? /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
Rich Salz wrote: I was envisioning something much simpler. Existing applications that know about the root CA work without configuration changes. New applications that need to know about the new larger PKI just add the new root to their list of trust anchors. I suppose that's really a bridge-CA. This is under some kind of assumption that the branched certificate chain does not totally confuse the verifier and cause it to crash or return I dunno so fail!. It seems, with some futher thought, that one might assume that if the chain will verify either way, it doesn't matter WHICH way the client chooses to go. However, this IS making an assumption about client software behaviour. However, I must ask the question: Have you actually DONE this before? If anybody on the list actually has experience with moving from a locally created root to being under one of the well-known PKI vendors a short note on successes, failures, and/or pitfalls would I think be greatly appreciated by the readership. Also, I guess I need to point out the vagueness of your reference above: New applications that need to know .. just add the new root to their list of trust anchors. This is not talking about servers or clients and could imply that explicit action is required AT THE CLIENT which I think we have determined is actually not necessary, at least as long as the old root doesn't interfere with the new chain validation. I don't think branched cert chains need to get involved, so I don't think I need to qualify or disclaim what I wrote. Yes, I ignored the details of distributing the new root certificate; there's a limit on the column length, ya know. In retrospect, adding (and get hte new root distirbuted and used) would probably have been worth adding. Yes, I understand there is a limit on column length, and that your real purpose was to publicise XKMS :-) So the comment I seized on was just a throw-away platitude, and maybe it was not appropriate for me to have made such a mountain out of that particular molehill. At any rate, the key point is that if you anchor everything you do under a single root, than moving your tree underneath something else is a lot eaiser if only one root has to move, rather than everything. This is quite true. One of the things we DID have to deal with during our old local root to new local root transition was people who decided to mark the end-user certificate as trusted in their browsers rather than take the risk of trusting our root. Of course that doesn't survive a transition at all... :-) Best regards -zben -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Securing a CA
However, I must ask the question: Have you actually DONE this before? Yup. But not with SSL and browsers. You're focused on that, but I was talking in general. In reality, of course, everyone just buys a commercial SSL cert rather than try to fight with the browsers's (sic!) trust issues. New applications that need to know .. just add the new root to their list of trust anchors. This is not talking about servers or clients and could imply that explicit action is required AT THE CLIENT which I think we have determined is actually not necessary, at least as long as the old root doesn't interfere with the new chain validation. By need to know I meant applications that need to know about *other* CA's that the new root has signed. Those clients will need to incorporate the new root into their list of trust anchors. Old clients don't. our old local root to new local root transition was people who decided to mark the end-user certificate as trusted in their browsers rather than take the risk of trusting our root. If you want PGP you know where to find it. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Securing a CA
Hi! I need some info about the protocols or standars for securing a CA Root thanks Leonardo Uzcategui Grupo de Seguridad de Computo RedULA-CPT Merida-Venezuela smime.p7s Description: S/MIME cryptographic signature
Re: Securing a CA
I need some info about the protocols or standars for securing a CA Root At the risk of being immodest, you might find this column useful: http://webservices.xml.com/pub/a/ws/2003/12/09/salz.html /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
