Curt, There is some great information in the OpenCA documentation that might be of assistance to you.
http://www.openca.org/projects/openca/docs/openca-guide.pdf http://www.openca.org/~madwolf/index.html Jack D. Pond "Well, dinner would have been splendid... if the wine had been as cold as the soup, the beef as rare as the service, the brandy as old as the fish, and the maid as willing as the Duchess." -- Sir Winston Leonard Spencer Churchill(1874-1965) > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Curt Sampson > Sent: Monday, November 07, 2011 11:54 PM > To: [email protected] > Subject: Fwd: OpenSSL Mailing List Question > > Folks, > > I'm developing a distributed application for which I'm currently planning to use OpenSSL > to handle the security needs, which include a > (privately-run) PKI. > > I can't divulge the details of the application, but this vendor's systems would be installed > at individual client sites as well as having some clients use fully or partially hosted > services, hosted by the vendor. Clients have control over some parts of the system > (such as adding new users to the site), but not other parts (such as the ability to > generate licenses to use certain programs). > > The application runs mostly over proprietary protocols and doesn't interoperate with any > other system except through gateways that speak the application-specific protocols on > one side and whatever they need to on the other side. So I've no particular huge need > to follow standards, except inasmuch they make life easier for me and add a bit of shine > to the marketing materials. > > Amongst these systems, no client trusts or interoperates with any other client; > essentially, each is its own island. > > My tentative plan is to set up a three-level PKI, with the vendor's "master CA" as the sole > root certificate trusted by all software and nodes, and a "client CA" (signed by the > master CA) for each site. > > Within this, we'd have two basic types of nodes. One is for nodes that can be > authenticated/authorized by the client CA, such as local users of the system. The other > would be for, e.g., server programs, which would have some indication in their certificate > that they're valid to operate only with a particular client, but also may be signed only by > the master CA, not by a client CA. > > Two obvious ways I can see to implement this would be a) to add new extension fields > to the SSL certs for node names, types, which client they may operate with, and so > forth, or b) to simply define some new fields for the distinguished name (e.g., "O=Client > A, Type=User, > [email protected]") and do authorization based on that and who signed the cert. > > Does anybody have any thoughts on either approach, or other approaches I should > consider? > > And while we're at it, can someone point me to a reference on the OIDs used for the > various field names (CN etc.) used within distinguished names? This didn't really seem > to be mentioned in the X.501 spec. > > cjs > -- > Curt Sampson <[email protected]> +81 90 7737 2974 > http://www.starling-software.com/ I have always wished for my computer to be > as easy to use as my telephone; my wish has come true because I can no longer figure > out how to use my telephone. --Bjarne Stroustrup > _____________________________________________________________________ > _ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
