r23 - 14 Jul 2004 - 07:59:14 - HeikkiToivonenYou are here: OSAF >  Projects Web  >  DevelopmentHome > SecurityFramework > DartmouthPkiProposal

PKI for P2P Authentication Without All the CA Hassles: A Proposal by the Dartmouth PKI Lab

The proposal is posted here with permission, the original is at http://www.dartmouth.edu/%7Edeploypki/justifying/P2P_AuthN_Concept.doc

1/27/2004 by Mark Franklin

Executive Summary

PKI offers an elegant way to address distributed authentication issues with peer to peer (P2P) systems in the absence of an institutional authentication authority. The use of x.509 certificates issued by peers optionally combined with x.509 certificates issued by institutions and with Shibboleth can gracefully handle the wide variety of authentication scenarios faced by LionShare and Chandler without ever resorting to awkward and less secure username/password solutions. We propose that LionShare and Chandler implement an x.509 based solution as their first authenticated solution and skip the complexity of implementing interim username/password solutions. We also propose that the two projects (and any others with similar needs) share this solution as much as is practical.

The rest of this document elaborates on the problems inherent in P2P authentication, the advantages of the proposed solution, and proposed actions to implement it.

Authentication for P2P

Peer to Peer (P2P) applications have traditionally been rather short on authentication. In fact, many people engaging in some of the less legal uses of P2P almost certainly wouldn’t see the value in authenticating to peers. Yet there are legitimate uses of P2P which do require authentication of peers in order for honest users to utilize their full potential. Two such uses of P2P are planned by LionShare? and Westwood/Chandler. Both recognize the high value of being able to share information with some peers but not provide free access for all. This implies that the peers need to be able to authenticate each other, either as individual users or as members of a class of users (e.g. all Penn State users). This proposal focuses on the case where two peers from different institutions (or not from any institution) want to authenticate with no institutional authentication support such as that provided by Shibboleth or institutional Certification Authorities, but the proposed solution can dovetail nicely with institutional PKI or Shibboleth.

Problems With Username/Password

Authentication between two peers with no institutional infrastructure presents some interesting challenges which traditional authentication schemes don’t handle well, especially as the number of users interacting with each other grows beyond a handful. In particular, username/password solutions don’t scale well. Because there is no central authority to manage consistent usernames and passwords, each peer in server mode needs to manage a database of usernames and passwords for peers it is willing to allow to access its protected services. A user wishing to serve information to ten colleagues will have to somehow generate usernames and passwords for all ten, and those colleagues (or their peer software) will each have to keep track of those usernames and passwords. And they need to do this for each peer from which they wish to access services. So a group of ten Chandler users who wish to share calendar information with each other but not with the world would need 100 username/password pairs. One could possibly ease this situation for the users by automatically saving the username/password pairs in the application, but this involves quite a bit of coding and will likely cause much user confusion and frustration if not implemented very carefully. Or users could attempt to re-use the same username/password pair on all ten colleague’s systems (assuming the peers let them), but then there is the risk that one peer gets hacked and exposes the other nine to illicit access by the hacker.

P2P Authentication Requirements

For authenticated peer to peer applications to work, we need to minimize the effort and hassle required of users, or sharing of sensitive data will be severely hampered. Shibboleth federations or institutional authentication servers can help both LionShare? and Chandler conveniently provide authentication services for potentially large groups of users, but this only works if institutional infrastructure is available and only works for groups of users. These mechanisms won’t work well if a user wants to allow privileged access to a handful of colleagues instead of anyone in a group managed by their institution. For example, a professor using Chandler isn’t likely to want to share their calendar with everyone from their institution. Likewise, a group of researchers sharing data via LionShare? may not want the rest of their institution to view it until they publish it. And Chandler explicitly seeks to address users who do not have affiliation with an institution that can provide them with infrastructure.

What we need is an authentication technology that conveniently allows both coarse and fine-grained control of who is authenticated to access a peer’s services while still being able to work without an institutional infrastructure.

How PKI Fits

With some creativity about what constitutes a Certification Authority and a little flexibility about certificate exchange, PKI can meet our “P2P authentication without institutional support” requirements quite nicely:

  1. Each peer can issue its own self-signed end-user x.509 certificates and to be used for access from that peer to services offered by other peers.
  2. Alternatively, each peer has the ability to use x.509 certificates issued by an external CA for the end-user credentials (if the user has access to such a service).
  3. Each peer has the ability to register for trust end-user certificates issued by other peers (without requiring any root certificates – it will just record the end user certificate as trusted). Later, it can validate TLS, SASL, or other PKI challenge/response authentications for registered certificates by using the public key in the trusted end user certificate and verifying via decryption that the authenticating party has its private key.
  4. Each peer has the ability to register institutional root certificates for trust. This enables trust for any peer holding a certificate issued by that institution without pre-registration.
  5. Each peer can provide access control to its data and services at the institutional (Shibboleth federation or root CA) level or at the individual (registered or trusted via root certificate) level. To the user, this is presented as “aggregate users” (institutional groups) or “user accounts. So users could allow access to a particular service by specifying that:
    • any valid certificate from an institution is authorized, or
    • any peer authenticated as a class of user by Shibboleth is authorized, or
    • a particular user certificate is authorized.
  6. For convenience, peers could allow access based on groups of the peer types in 5. For example, a user could allow access to a collection of images by user 1, user 2, anyone issued an PKI credentials by school 1, or anyone with Shibboleth authentication as faculty from school 2. This example shows all the possibilities; most user groups would probably be simpler, and some peers might not even use some of the authentication options.

A critical element of item 3 above is how the peer registering the x.509 certificate knows that this certificate represents legitimate credentials for the user requesting access. A substantial portion of the infrastructure part of Public Key Infrastructure is dedicated to determining certificate trustworthiness automatically without requiring additional exchange of information between client and server. The potential danger is that a “bad guy” might intercept the certificate in transmission and replace it with a bogus one whose private key they control, thereby gaining illicit access to services on the peer that trusts these bogus credentials. Traditional PKI relies on a cache of trusted root certificates and then considers certificates issued by those CAs to be trustworthy. In our distributed “peer-issued certificates” configuration, this doesn’t make sense because we now have potentially many peers issuing certificates. This is the reason for trusting individual certificates. But how does the user know to trust the particular certificate they just received from a peer? And what mechanism should we use for conveying the certificates between peers? A simple way to handle this is already built into PKI. DER or PEM formatted files contain x.509 certificates and public keys. And x.509 certificates have “thumbprint” values which are virtually certain to be at least mostly different for two different certificates. The user requesting access can send their certificate to the peer with the service (we can automate this using the peering protocol). Through some other mechanism (email message, IM, phone call, etc.) this user can also send the thumbprint. The user with the service verifies that the thumbprint matches and accepts the certificate. This is a manual step, but the user is already doing a manual step to set up special authorization for their colleague. The extra step can be as easy as a dialog box asking the user to verify the thumbprint and accept or reject the certificate. This one operation has now given the peer with the service a very strong way to authenticate the client’s peer. Plus in the case of Westwood it now has the PKI certificate for S/MIME email purposes.

The actual implementation of this is largely standard PKI, and the peer-issued certificates will work alongside CA-issued certificates, using the same implementation for authentication, authorization management, S/MIME, etc. This approach combined with Shibboleth answers all of Chandler’s and LionShare?’s authentication needs in the long run and yet will likely not require much extra effort to implement in the short run than less versatile, weaker, and less user-friendly username/password solutions. And users only need to learn how to manage one type of authenticated peer credentials instead of dealing with both username/passwords and (eventually, at least in Westwood) x.509 certificates. The end product will not have any username/password logic in it to maintain and support into the future.

Specific Actions to Take

All of these actions are in collaboration with the PKI Lab and other projects adopting this strategy.

  1. Read this proposal, ask questions, brainstorm improvements, and adapt/generalize it as needed.
  2. Work with other projects adopting this strategy to identify appropriate crypto libraries to use (Mozilla’s NSS? OpenSSL? Other?).
  3. Consider the possibility of sharing the same implementation or portions of the implementation between projects. GUIs will clearly vary, but the underlying encryption, certificate management, and authentication management code should be re-usable across projects.
  4. Define the architecture of your authentication/authorization mechanism incorporating the proposed PKI capabilities.
  5. Define your application’s authentication/authorization GUI.
  6. Implement the authentication/authorization mechanism and share as much as possible with other projects.
  7. Implement the GUI and share as much as possible with other projects.

Related documents

An earlier OSAF document describes how sharing would work in a PKI architecture: http://wiki.osafoundation.org/twiki/bin/view/Jungle/DataSharing

Difference in sharing workflow

It seems like PKI will require at least a different workflow than username/password when it comes to sharing. With username/password, user B can share views with user A just by creating username/password for A and sending A this information. With PKI, before B can share with A, B will need A's certificate, and additionally B may need to verify A's certificate. See figures below:

Figure: Different workflows with PKI and password based systems

  • Note that checking of thumbprint should be done out of band.
  • MarkFranklin - 07 Feb 2004: The "Ask thumbprint" and "Send thumbprint" steps in the diagram need to be out of band. The model is very much like PGP - for strong security, we need a way to verify that the certificate wasn't intercepted in transmission and replaced with a bogus look alike that will give someone other than A access. The thumbprint is a hash value that is virtually guaranteed to differ for different certificates, so if A and B verify a hash match in some out of band connection (phone call, email, letter, etc.), then one can rest assured that the certificates are the same (unless of course, the bad guy managed to intercept the out of band communication too, which is very unlikely - especially if one recognizes the voice on the out of band communication). People comparing thumbprint hash numbers might not do so accurately - it might be a useability improvement to map the hash value to an easily described picture chosen from a selection of thousands. This would be less guaranteed to be different for different certificates, but would use people's superior ability to recognize pictures to make the comparison easy and less error prone.
  • There is actually a step missing in the PKI model - checking if we trust A. In this model checking would mean: "have I signed A's certificate?" Alternatively we could skip signing and checking of signature and just set a bit on the address book entry to say the contact is trusted.
  • It is unclear if we want to support webs of trust in Canoga (which would enable skipping signing non-CA certificates), and if we did, how far should the trust be extended along the chain.

  • The DataSharing related document proposes to use obfuscated URL for first access, after which certificate exchange would take place.
  • Interesting idea that might help here is if we adopted an approach similar to http://orkut.com and other networking initiatives where you create a friends network. To be friends means you would exchange certificates. Then, it would be simple to share with your friends.

Questions and Answers

Here Heikki/OSAF is asking questions, and Mark/Dartmouth PKI Lab is giving answers.

Q1: Existing libraries should be able to do most of the heavy lifting, but what are the remaining major areas of work? Some example areas we think would require significant amounts of work: UI in general, creating user certs (there are expert tools for this - how much work is it to make a version for dummies), using the Chandler repository for data storage. Roughly how much work is there (estimated man months)?

A1: You are right that the heavy lifting is available in existing libraries, but there is definitely some important work to be done in the GUI area. I am thoroughly convinced that we can make this unobtrusive. We need more thorough requirements before we can estimate how many man months are required. I contend that to make the username/password solution usable will take roughly the same amount of GUI work.


Q2: Is there a clear separation of work for crypto parts, and the use of those crypto components? It seems like OSAF would need to retain the expertise in house to use the crypto parts, but the crypto libraries themselves could be thought of as black box.

A2: Yes, I think it is a reasonable approach to consider the crypto libraries a black box and focus OSAF expertise on using them and on appropriate GUI.


Q3: It seems like users might more readily understand the username/password system, and even think of it as more secure. Is there a way to make this system feel as secure to users by UI selections etc.? In general, how can normal users understand this system and use it securely?

A3: It is true that most users understand usernames/passwords, but also true that they HATE them. The model I propose is also pretty straightfoward. It's kind of like registering a student ID in order to gain admittance to a club room. Once the door keeper has a photocopy of the ID in the "who's authorized to enter" book, then that user will be admitted. I suspect the users will be happy to go with anything that avoids having to remember passwords. But I also think that any non-centralized username/password scheme for P2P will have to automate and hide passwords from the users, or it will drive them crazy. Remember that the 10 colleagues sharing calendar information will need 10 username/password pairs each.

Heikki: But 10 users sharing in the PKI model would need to connect 10 times to check thumbprints. Either you establish username/password with everyone with who you share, or you establish trust with everyone by verifying thumbprint. It just seems like there is no savings for the users.

Mark: Agreed, but at least it's not 10 different usernames and passwords on the client peer side - it's just the one certificate.


Q4: Is there a big difference in handling user created certs vs. CA certs (programmatically, not from user's point of view)? Additional work?

A4: I think from a user's point of view, there would be little visible difference between CA created certs or peer created certs. The peer created certs would be the default but they would also have the optional ability to install a CA created cert. If they install a CA created cert, then it would simply replace the peer-created one. This gets a little tricky if they have already used the peer-created one, but we can implement a secure conversation between peers to update from an older cert to a newer one (this would also handle the case of replacing expired or revoked certs). CA created certificates may not require the thumbprint check if the "server" peer trusts the root certificate for that CA, or it can work the same way as a peer generated certificate if its root CA certificate is not trusted by a "server" peer.


Q5: How do you propose we handle situation where a user loses a cert?

A5: When a user loses their certificate, they would just go through the regular registration process with a newly generated certificate. This is no worse than if they lost their username/password.


Q6: How can users change their private key?

A6: Circumstances I can think of where users would want to change their private key are:

  • They have a new certificate they want or need to use.
  • They feel they need more bits in the key for security (not very likely with 1024 bits or higher).
  • They fear that someone has somehow stolen their private key (most likely due to sharing or other password compromise).
In any of these cases, they can simply re-register with a new certificate, and the "server" peer will forget the old private key. This could be exactly the same as what they would do when they lose their certificate, or (since they still have the old private key) we could avoid the thumbprint checking case by using authentication with the old certificate/private key to authorize installing the new certificate/private key.


Q7: How do you propose certificate revocations to be handled?

A7: Revocations are straightforward but not foolproof. I believe we can do at least as well as we can revoking compromised passwords. The peer with the certificate to be revoked can keep a list of "server" peers with which it has registered that certificate. The user of this peer can invoke a revocation feature which will automatically notify the peers that registered that certificate to forget about the registration. The tricky part is that some of these peers may not be online when the user invokes the revocation. In this case, the revoking peer will need to remember to try again later. I believe that invalidating passwords will have this same problem. Of course, if both peers are using the same institutional CA, then revocation can happen using normal PKI mechanisms (CRL or OCSP).


Q8: How do we handle the situation when there are multiple Chandler clients used by the same user (e.g. kiosk mode or just home/work pair of computeres)?

A8: Multiple clients for the same user is best handled with a smart card or USB token. That device can hold their certificates/keys and supply them to whatever computer the user is on at the moment. For under $50, the user can get a device that does all the cryptography on-board and is a very secure way to hold the keys. Dartmouth is starting to deploy Aladdin's eToken Pro for this purpose. Aladdin also has software for securely remembering username/password pairs (not PKI, but another way to ease the pain of passwords for our beleaguered users). http://www.ealaddin.com/etoken/default.asp

Heikki: I don't think smart cards or other external tokens would work for normal people. In fact, the only people that I know personally that use them are cryptographers. Until every PC comes with a token & reader and people have to use them to login, I think this will remain a dream. It can work in institutional settings, though.

Mark: Perhaps not. But sophisticated users may find the tokens to be a reasonable solution, even without institutional settings. It can be optional.

Now that I think more about it, I realize we can provide a feature to synchronize software certificates with another peer owned by the same individual. We should be able to automate this just as much as we could automate synchronizing username/password databases.

The other way to handle multple clients isn't as convenient for the user. We can allow them to export a certificate to a specially formatted (PKCS#12) file and then import it on the other computer.

Mark: See above, I think we can make this more automatic than PKCS#12 files.

Unless we expect users to remember passwords for all their colleagues, they will have a similar problem with usernames/passwords and multiple passwords. If we hide the passwords for those 10 calendar sharing colleagues for convenience, then we will need to provide users with a way to export them to other computers. But in this case, users will need to re-export the passwords each time they add a colleague instead of just exporting a certificate once or getting true mobility with PKI.


Q9: Suppose you receive an S/MIME signed/encrypted email from someone, can you get a cert from there to initiate sharing?

A9: Encrypted email does not involve the sending user's certificate (it uses the receiving user's certificate and private key). But your thought is an excellent one if you simply change "encrypted" to "signed". Most S/MIME capable mail applications include the sender's certificate along with the signed message (on some this is configurable by the user). It is usually possible to extract the certificate from the message (Outlook, Thunderbird, Mozilla, and I'm sure others can do this). The "server" peer user could then import this certificate for trust. I thought about proposing this as a mechanism for registering, and it might be a good starting point. But I think we can make things significantly easier for users if we share the certificate via our P2P mechanism and automate the process of receiving and trusting it.

Heikki: Thanks for the clarification. In reality, I think most S/MIME mail is actually just signed mail, and most encryped S/MIME mail is also signed.

Mark: Agreed.


Q10: We have not yet decided what email library we will be using in Chandler, or what HTML editor/viewer to use. If the answer to any of these is to use Mozilla, it would present a compelling argument to use NSS from Mozilla for all cryptographic needs as well. That would also mean that there should not be many changes in NSS itself, or they should be of form that would be acceptable to the Mozilla project. Is this possible?

A10: I agree that NSS is a leading contender for the crypto library (OpenSSL is the other). I believe that we should be able to get the functionality we need from NSS through its existing API. If we do need to make modifications, I expect they would be minor and could be accomplished in the form of additions that don't affect existing uses of NSS. I would expect that the keepers of NSS would be pleased to see it used for P2P authentication (clearly an important application).


Q11: If we decide to use c-client for email backend, it may be architected in such a way that it would interface easily with OpenSSL (this is assumption based on Pine, which uses c-client and can interface with OpenSSL).

A11: I am not familiar enough with c-client and Pine to confirm or deny this. Your hypothesis certainly seems plausible.


Q12: Without CA certs, wouldn't PGP feel like a more natural way to implement this?

A12: This concept is indeed similar to PGP. What is "more natural" is open to interpretation. I think PGP provides a comforting existence proof that this sort of thing can work. AOL AIM's recent windows client has the ability to trust an individual's certificate in the absence of a root CA certificate for it (but only on a per-session basis - I wish they would provide a way to record and trust a particular certificate every time it appears). I like using x.509 certificates for this because they are standards based and interoperate with other applications. Shibboleth with KCA (a direction that LionShare? seems to be heading) is a way to supply x.509 certificates to a "server" peer. And institutions using institutional PKI will of course have x.509 certificates. And smart cards and USB tokens provide added security and usability for x.509 certificates. I am unaware of interoperability like this for PGP. But you are absolutely right that the concept is the same and that PGP could probably be used the same way.


Q13: Are there other viable crypto libraries besides NSS and OpenSSL?

A13: There are many, but the ones that I know of that have both acceptable licensing and widespread use (proven by millions of users) are NSS and OpenSSL. One other that might merit investigation is Cryptlib http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ . This one is reputed to be an excellent implementation, but may not have a workable license and is less widely used.


Q14: How do we handle (non-Shibboleth) groups? See http://wiki.osafoundation.org/twiki/bin/view/Jungle/DataSharing#groups for some previous thoughts.

A14: Well, my first reaction is to use Shibboleth for all institutional groups. This is precisely what Shibboleth is designed to do, and I think we should leverage their efforts rather than do something different. Were there particular sorts of groups you had in mind that may not work with Shibboleth? Was there some other reason for avoiding Shibboleth?

Heikki: I think Chao meant ad-hoc groups outside of institutions, where there would be no Shibboleth groups.

Mark: Yes, I spoke with Chao and now understand the use case here. We should be able to store groups (really just lists of certs and their authorizations) in a peer server repository and use the access control of the repository to manage them. There will be some interesting GUI work to make it easy to maintain the groups.

See below for a link to a paper by Dohrmann and Ellison which has good information about groups.


Q15: Is the "thumbprint" conceptually the same thing as PGP fingerprint? PGP fingerprint use case scenario here: http://pgp.dtype.org/pgpnet/pgp-faq/faq-06.html#6.6

A15: Yes, I believe PKI "thumbprints" are conceptually exactly the same as PGP fingerprints.


Q16: A certificate could easily contain a lot (all?) of the information that the "me contact" holds: name, address, phone, email, ... But if any of that changed, the certificate would need to be revoked and a new one created, right? So it seems like a minimal certificate would seem best to avoid complications due to revocations.

A16: I agree that the best path is to keep the certificates minimal to minimize having to reissue certificates if information in them changes. We could actually make them anonymous - they would still work fine for our purposes.


Q17: Should each user have a single certificate, or a single self signed root CA that they can use to sign their public certificate that they distribute around as their identity?

A17: I think this depends on the crypto library we use. Most likely, it will want a root certificate in the peer to sign the self-signed certificates. Since we're really only using the private key in the user certificate, I don't think it matters much how we treat this "root" certificate. I think we can probably even just ship the same one with every peer to keep things simple. It's the private key in the user certificates that will need protection and needs to be unique.


Q18: Can we use a certificate as the unique identifier for a contact in the addressbook?

  1. How does identity work when there is no certificate for a contact?
  2. How does identity work if there are several certificates for a user?

A18: I don't think the certificates provide a good unique identifier for the address book because the only part that's guaranteed to be unique is the key. Carl Ellison points out that it is quite possible to have two client peer users with the same name (say John Smith). Carl advocates we put the client peers into a unique namespace specified by the user. The idea is to have the server peer user assign their own unique name to each client peer certificate. That way, one John Smith could be "Professor Smith", and the other "Smitty". So I think it's the other way around - the address book provides the unique name for the certificate. If there are two certificates for a given user, then one could be "Smitty home" and the other "Smitty office". But another (perhaps better?) way to deal with this situation is to have Smitty use the same certificate in all contexts.


Q19: How do we do anonymous sharing? Don't involve PKI at all?

A19: Anonymous sharing doesn't require authentication, so I agree there would be no PKI involved.


Q20: Say you go to a conference and want to share something with the 50 attending people, but not the whole world. With username/password you could just post them on the conference wall or something, and be done. How can you do that with PKI without exchanging certificates with all 50 attendees?

A20: One way to handle the conference scenario is to manufacture a user certificate in the server peer and distribute that to the participants. The server peer only needs to trust the one certificate. After the conference, the peer server user can simply remove the authorization for that certificate. I believe this is just as secure as handing out a temporary username/password pair, but it doesn't provide a way to know which of the 50 attending people is doing a particular operation. If that kind of accountability is needed, then the peer server would need to either fabricate and distribute 50 certificates or do the trust exchange with all 50 attendees. The trust exchange could go very quickly (50 clicks) if the peer server is willing to temporarily forgo the thumbprint checking (arguably no worse than usernames and passwords on the wall). We could add automation to make this "no thumbprint" mode easier for large numbers of peers if it came up a lot.


Q21: PGP (for example GnuPG? 1.2.2) allows one to attach an image (photo) to a public key, does X.509 allow for a similar thing?

A21: I don't believe X.509 has an official way to carry an image in the certificate. I'm sure we could use one of the fields to hold a URL, and there may be a way to convey arbitrary image bits in an extension. If this is a priority, I could look into it further.


Q22: How do we mark a certificate/identity/contact/user as trusted? My initial thought was to sign the certificate, and later just check if "I" have signed the certificate to determine trust.

A22: I thought we could just have data in the repository (readable and writeable only by the server peer) which contains the certificates and associates authorization information with them. It's not just that the certificate is trusted, it's also the operations that it is trusted to do. We can certainly sign this information along with the certificate as a way of conveying trust, but I don't think it's necessary. We are already trusting the repository to keep data secure. Can't we use this same mechanism to keep the authentication/authorization information secure too?


Q23: Do we need to connect a contact and a certificate cryptographically, like in http://www.cs.dartmouth.edu/~pki02/Dohrmann/paper.pdf page 142? If so, how?

A23: If we trust the repository to foil tampering, then I don't think signing the contact information with the certificate per Dorhmann and Ellison is necessary. Simply associating the contact information and the authorization with the certificate in the repository should be sufficient. If we are concerned about tampering in the repository, then there may be value in signing the data in this fashion (and carefully controlling access to the signing key), but we should make sure it's worth the extra complexity.


Q24: Has something like this been done before?

A24: In talking with the Internet2 PKILabs group on one of their conference calls about our PKI for P2P proposal, I learned that Steve Dohrmann and Carl Ellison published a paper very much along the same lines in 2002. Their paper is much more rigorous in its presentation, but confirms the gist of our idea. They used SPKI certificates instead of X.509, but Carl acknowledged our reasons for choosing X.509 as valid.

Here is a link to the paper: http://middleware.internet2.edu/pkilabs/ .

http://www.cs.dartmouth.edu/~pki02/Dohrmann/paper.pdf


Comments

Feel free to add comments below, and I'll integrate them into a more coherent document above. -- HeikkiToivonen - 02 Feb 2004

  • There is information that should not be shared at all, like passwords and private keys.
  • It seems like this might affect access control; need to figure out details.
  • If users get used to always having Chandler prompt them to sign non-CA certs, it seems like they would then be suspicuous of CA signed certs which would not require individuals to sign them.


Crypto Library Comparison

  • NSS: http://www.mozilla.org/projects/security/pki/nss/
    • http://pyxmlsec.labs.libre-entreprise.org/
    • "Creating Applications with Mozilla" on NSS: http://books.mozdev.org/html/mozilla-chp-12-sect-5.html
  • OpenSSL: http://www.openssl.org/
    • http://pypgsql.sourceforge.net/misc/python-ssl.html
    • http://www.eclectica.ca/howto/ssl-cert-howto.php
    • http://tinyca.sm-zone.net/
    • http://opensslbook.com/

Item NSS 3.9 with NSPR 4.1.1 OpenSSL 0.9.7c
Binary size (win32) 1.3 MB 1.1 MB*
Documentation some final, some incomplete all incomplete, but there is an excellent book
Python wrappers PyXMLSec (GPL) includes several other crypto libs as well Standard Python socket.ssl (client only), Python OpenSSL Wrappers (defunct?), pyOpenSSL (defunct?), M2Crypto
Usage seems to be used less seems to be in more use
Dependences with possible other Chandler libraries Mozilla c-client, Twisted
Maturity seems more mature, complete missing some ciphers, hashes that NSS has, but maybe under more active development

* This is the combined size of libeay32.dll and ssleay32.dll. Compiled with VC++, but a version that does not support optimization, so these could probably be smaller.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r23 < r22 < r21 < r20 < r19 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.