Re: [fossil-users] Client certs - revelation
On Wed, Mar 16, 2011 at 11:40 PM, Ron Wilson ronw.m...@gmail.com wrote: I need to read up on ~/.fossil and _FOSSIL_ though to see if there's any risk of accidental information leak when pushing/pulling. The question is if the client key should be stored in the database, or if it's safer to store a reference to it instead, and keep the actual key outside (in the file system). I would keep the certs, themselves, completely outside of Fossil or any other VCS, just storing paths to the files containing the certs. Yeah, and another point I thought of was that it also makes it much easier to globally update the certificate/key in case the certificate gets revoked or expires. (Which happens..). Even the public certs. The public certs you use are your means for authenticating who you trust. You want to be very careful accepting them. That's true for distributed web of trusts, but if you're using PKI you (typically) use the CA certificate to verify the authenticity of a client certificate. It's a different trust model. On that note.. Planning a little bit further into the future here. Is anyone interested in full support for PKI in fossil? For instance, signing commits using a client key belonging to a certificate Signing commits is a good idea. I would recomend invoking gpg (or other crypto tool) to generate and validate signatures, rather than even using a library. Tools like gpg receive a huge amount of scrutiny, so it is very probably safer than performing those functions in Fossil. I know this goes against the Fossil philosophy of providing a single, self-contained executable, but this is one area where using a dedicated, purpose-made tool for the job makes sense. As Joshua mentioned, gpg signing is already supported. But my proposition was to add another trust model, for organizations/industries which are not allowed to trust anything but PKI structures. Anyway, that's further down the road; just wanted to see if there was any immediate interest for PKI in fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Client certs - revelation
On Thu, Mar 17, 2011 at 2:46 AM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On Wed, Mar 16, 2011 at 11:40 PM, Ron Wilson ronw.m...@gmail.com wrote: Even the public certs. The public certs you use are your means for authenticating who you trust. You want to be very careful accepting them. That's true for distributed web of trusts, but if you're using PKI you (typically) use the CA certificate to verify the authenticity of a client certificate. It's a different trust model. I have implemented PKI systems, before. The difference is in the rules used for determining which certs you are willing to trust. Somebody (you?) mentioned his (your?) company uses smart cards. Depending on the system, theses cards range from secure ways to carry and present certs for validation, to ones with a hardware crypto module in both the card and the reader that perform validation using what is called a Zero Knowledge Proof, so that no certs are ever actually read out of the card. (The card's crypto module can also be used to generate and validate signatures by providing a copy of what you want signed or validated to the card. (or, more likely, a hash of what you want signed)) But even without smart cards, the primary rule is that you are only allowed to trust certs signed by a specified CA, which might be your company. (A web of trust loosens this rule by allowing a few levels of indirection.) Of course, just because your company says you MAY trust certs signed by their CA does not necessarily mean you want to or even should. In the most restrictive scenario, you not only require the certs be signed by your company (and/or other designated CAs), but also that you already pocess trusted copies of the individual certs. Or, alternatively, you have a list of the IDs of the certs you are willing to trust - provided they also meet the signing requirements. If the validated cert does not match, you don't trust it. (Of course, you also do not trust certs that fail validation.) As Joshua mentioned, gpg signing is already supported. But my proposition was to add another trust model, for organizations/industries which are not allowed to trust anything but PKI structures. The vendor of your company's mandated PKI system likely provides a similar tool that you can configure Fossil to invoke in much the same way it invokes gpg. And I am suggesting using that tool. (see: fossil help settings). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Client certs - revelation
On 03/16/11 00:37, Dmitry Chestnykh wrote: I figured out why no one is explaining to me how to specify which client certificate to use when connecting with https: Because fossil doesn't support it yet. :) You're right :-) http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04069.html I promise I won't simply grep and extrapolate again. :) Our development server only allows fully verified certificate chains when connecting to it (with the exception of ssh); I added support for specifying a certificate and key file to my local fossil copy, and now I can properly access our repositories through https (via apache and cgi). However, it seems appropriate to implement this properly so that everyone can benefit from it. What's the user interface for specifying a certificate and key file? I just added hardcoded support for ~/.pki/clientkey.pem and ~/.pki/clientcrt.pem. To get that basic functionality, it's really as simple as adding two lines of code(!). However, as for how I'll implement the real solution; that's still open for discussion. As I figure, the two most fossilic solutions would be one of the two: 1) Store key/certificate (or reference to them) in the local datastore (_FOSSIL_) 2) Store key/certificate (or reference to them) in the global datastore (~/.fossil) Option 1 has a painfully obvious chicken-and-egg problem, as the certificate/key may be required to even get a clone of the repository. Also, conceptually, a client certificate is normally issued to a person, not a service. Therefore it makes much more sense to have a global certificate store of some kind (to identify the person who owns the home directory, rather than the specific repository). So my first goal is to add a command line interface (including a web gui interface?) to manage client certificates/keys, bundling them together into some named data entity in the global data store (~/.fossil). Then when a clone open are performed, the user can - through a switch - choose which certificate entity to use to connect to the server. This information will be - through some magical means - stored in the local (_FOSSIL_) data store for future use (for push/pull/sync) after an open. I need to read up on ~/.fossil and _FOSSIL_ though to see if there's any risk of accidental information leak when pushing/pulling. The question is if the client key should be stored in the database, or if it's safer to store a reference to it instead, and keep the actual key outside (in the file system). Any input from seasoned fossil developers on this is much appreciated. I don't use client certificates, but I agree that fossil should support them. Yeah; for some (like me) it's an actual requirement. On that note.. Planning a little bit further into the future here. Is anyone interested in full support for PKI in fossil? For instance, signing commits using a client key belonging to a certificate, adding means to distribute public certificates for purposes of verification, etc. The way the repo data can be sync'd could make it almost ideal for sharing certificates. And I would obviously add support for signing commits using smart cards (using PKCS#11). In the industry I work, web of trust signatures are not accepted. (I'm not saying this is right, but it's the way it is). In fact, smart cards are the only accepted mechanism for signing digital documents. I'm not saying that it's in any way implied that we'd get new users by supporting PKI, but it could open a door which is most definitely closed right now. Anyway, this is just some random brainstorming. If anyone sees any value in it, let me know. -- Kind regards, Jan Danielsson signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Client certs - revelation
On Wed, Mar 16, 2011 at 5:08 PM, Jan Danielsson jan.m.daniels...@gmail.com wrote: I need to read up on ~/.fossil and _FOSSIL_ though to see if there's any risk of accidental information leak when pushing/pulling. The question is if the client key should be stored in the database, or if it's safer to store a reference to it instead, and keep the actual key outside (in the file system). I would keep the certs, themselves, completely outside of Fossil or any other VCS, just storing paths to the files containing the certs. Even the public certs. The public certs you use are your means for authenticating who you trust. You want to be very careful accepting them. On that note.. Planning a little bit further into the future here. Is anyone interested in full support for PKI in fossil? For instance, signing commits using a client key belonging to a certificate Signing commits is a good idea. I would recomend invoking gpg (or other crypto tool) to generate and validate signatures, rather than even using a library. Tools like gpg receive a huge amount of scrutiny, so it is very probably safer than performing those functions in Fossil. I know this goes against the Fossil philosophy of providing a single, self-contained executable, but this is one area where using a dedicated, purpose-made tool for the job makes sense. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Client certs - revelation
On Mar 15, 2011, at 4:14 PM, Jan Danielsson wrote: I figured out why no one is explaining to me how to specify which client certificate to use when connecting with https: Because fossil doesn't support it yet. :) You're right :-) http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04069.html Our development server only allows fully verified certificate chains when connecting to it (with the exception of ssh); I added support for specifying a certificate and key file to my local fossil copy, and now I can properly access our repositories through https (via apache and cgi). However, it seems appropriate to implement this properly so that everyone can benefit from it. What's the user interface for specifying a certificate and key file? I don't use client certificates, but I agree that fossil should support them. -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
