Re: Policy: revoke on private key exposure
Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. And just count how many 3% of the certs Verisign issued under it's main CA makes. PS : Yes, it's outdated, they did a reset of the CA architecture, generated new roots, and I think the new one is not yet as big. But there's no reason why it won't be some day. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Hi Anders, Good question. If the computers OTOH are just ordinary but shared office computers, critical data should be server-based and protected by user access control. Thin clients is the most common solution to this fairly standard problem. Then it would be X.509 per user rather. I think this gets to the nub of the point at issue. Our customers often have several stores. We do not want our X509 certificates to be 'per user' because what is critical for us is in which *store* the transaction was executed in (what user performed the transaction is of secondary importance - we want to ensure the user is authenticated (which we do with usernames and passwords), but the store information is paramount). If the customer uses windows roaming profiles for their users (which many of the larger ones do) the problem with using standard 'per user' X509 certificates is that, regardless of whether the user logs in to a PC in store A, B or C, the X509 certificate in their profile (which is stored centrally as part of the users' roaming profile) remains the same. Therefore we would be unable to identify at what store the user had processed a transaction unless we asked the customer explicitly. As discussed previously, we are also investigating hardware based tokens for this purpose, but if only we could get access to the machine based certificate store in windows from IE and/or firefox this would solve our problem. I do understand of course that this is not what X509 certificates were designed for, but I think what we wish to do with them is sensible, and worth investigating Hopefully this explains the issue I have. Regards Denis On Fri, Jan 30, 2009 at 10:34 AM, Anders Rundgren anders.rundg...@telia.com wrote: I guess what's puzzling some people like me, is what the security concept behind this arrangement really brings to the table. Authenticating machines connecting to the network is indeed useful but in general only has the function to prove that the device has been accepted and possibly configured by IT (AV etc.) I hope you don't mind me generalizing the discussion a bit: If the machines in question have entirely different function and thus need specific users. This could for example be X-ray equipment that only should be used by authorized and trained personnel. This still seems to point to user authentication. If the computers OTOH are just ordinary but shared office computers, critical data should be server-based and protected by user access control. Thin clients is the most common solution to this fairly standard problem. Then it would be X.509 per user rather. As nothing is more secure than its weakest link, using passwords for getting machine access (and thus being authenticated in the sense that this concept expects...), doesn't appear like an ideal solution. That the concept does not build on AD access, makes me believe that this idea needs a revision or two because administration is a core element of all security solutions and here we obviously have a lot of stuff to administer. Also the word federation rings in my ear. Anders Rundgren -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL problem diagnosis tool
Ian G wrote: On 29/1/09 19:24, Nelson B Bolyard wrote: Ian G wrote, On 2009-01-29 10:01: [...] when firefox trips over a cert, it could show something like that. | There is a problem with this cert! | | == *The cert was not issued by a known CA*== | The cert has expired or is not yet valid | [...] You want the browser to show a list of all possible things that can go wrong, including the ones that are irrelevant to the current situation, but highlight the relevant ones? How is that an improvement over showing only the relevant issue(s)? * if you show a selection of items, then the user tends to read the actual selection, read some of the others, and then think about what that means.[...] I'm not convinced still that « not issued by a known CA » would mean anything for Joe Shmoe. And that's the target we should aim for. Don't take it wrong. I'm strongly in favor in bringing information, but finding what information will be actually useful is *hard*. Maybe the best is a link to an on-line help ressource that will help Joe Shmoe understand that a caCert issued cert on a Debian ressource site is not a big deal, but that this self-signed cert on a home equity loan site that ask him his bank account info *is*. The best solution will still be as much as possible be to not bring out a warning if there's not actually an attack : Don't cry wolf ! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Actually, one other thing. While I agree with you on the thin clients issue, many of our applications use their own PC's to run our application (they have other applications they use on their PC besides ours) On Fri, Jan 30, 2009 at 12:24 PM, Denis McCarthy dmccar...@annadaletech.com wrote: Hi Anders, Good question. If the computers OTOH are just ordinary but shared office computers, critical data should be server-based and protected by user access control. Thin clients is the most common solution to this fairly standard problem. Then it would be X.509 per user rather. I think this gets to the nub of the point at issue. Our customers often have several stores. We do not want our X509 certificates to be 'per user' because what is critical for us is in which *store* the transaction was executed in (what user performed the transaction is of secondary importance - we want to ensure the user is authenticated (which we do with usernames and passwords), but the store information is paramount). If the customer uses windows roaming profiles for their users (which many of the larger ones do) the problem with using standard 'per user' X509 certificates is that, regardless of whether the user logs in to a PC in store A, B or C, the X509 certificate in their profile (which is stored centrally as part of the users' roaming profile) remains the same. Therefore we would be unable to identify at what store the user had processed a transaction unless we asked the customer explicitly. As discussed previously, we are also investigating hardware based tokens for this purpose, but if only we could get access to the machine based certificate store in windows from IE and/or firefox this would solve our problem. I do understand of course that this is not what X509 certificates were designed for, but I think what we wish to do with them is sensible, and worth investigating Hopefully this explains the issue I have. Regards Denis On Fri, Jan 30, 2009 at 10:34 AM, Anders Rundgren anders.rundg...@telia.com wrote: I guess what's puzzling some people like me, is what the security concept behind this arrangement really brings to the table. Authenticating machines connecting to the network is indeed useful but in general only has the function to prove that the device has been accepted and possibly configured by IT (AV etc.) I hope you don't mind me generalizing the discussion a bit: If the machines in question have entirely different function and thus need specific users. This could for example be X-ray equipment that only should be used by authorized and trained personnel. This still seems to point to user authentication. If the computers OTOH are just ordinary but shared office computers, critical data should be server-based and protected by user access control. Thin clients is the most common solution to this fairly standard problem. Then it would be X.509 per user rather. As nothing is more secure than its weakest link, using passwords for getting machine access (and thus being authenticated in the sense that this concept expects...), doesn't appear like an ideal solution. That the concept does not build on AD access, makes me believe that this idea needs a revision or two because administration is a core element of all security solutions and here we obviously have a lot of stuff to administer. Also the word federation rings in my ear. Anders Rundgren -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Annadale Technologies Limited -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
On 30/1/09 13:24, Denis McCarthy wrote: Hi Anders, I think this gets to the nub of the point at issue. Our customers often have several stores. We do not want our X509 certificates to be 'per user' because what is critical for us is in which *store* the transaction Oh, I see! You have an application in mind and you think that X.509 will help you build an application? Sorry, slight problem there. X.509 is a public key system built to a particular security model. Transactions are something else, they are a business application, with very particular and specialised needs. Using X.509 to do transactions is like using a shovel to build a skyscraper. Yes, there are shovels on building sites, but there are so many scale and scope problems that it's a non-starter as a conversation. Or, to put it another way, your earlier intuition was closer: X.509 is a user concept, not a transaction concept. was executed in (what user performed the transaction is of secondary importance - we want to ensure the user is authenticated (which we do with usernames and passwords), but the store information is paramount). Why doesn't the transaction record what store it was conducted in? iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL problem diagnosis tool
On 30/1/09 13:25, Jean-Marc Desperrier wrote: Ian G wrote: Ian G wrote, On 2009-01-29 10:01: [...] when firefox trips over a cert, it could show something like that. | There is a problem with this cert! | | == *The cert was not issued by a known CA*== | The cert has expired or is not yet valid | [...] ... * if you show a selection of items, then the user tends to read the actual selection, read some of the others, and then think about what that means.[...] I'm not convinced still that « not issued by a known CA » would mean anything for Joe Shmoe. And that's the target we should aim for. I don't disagree; my words above were definately edited for brevity and understanding by this audience, not the end-user. How we convey that meaning to the end-user who does not understand what it means is a big problem, yes. It's a big challenge for Mozilla. My view is that eventually Mozilla has to do that, whether it does it this year, or in 10 years, it will eventually have to convey that info to the user who right now doesn't really want to know about it. Don't take it wrong. I'm strongly in favor in bringing information, but finding what information will be actually useful is *hard*. Oh, yes. That's why I *strongly and vociferously* support the experiments that have been conducted by Johnathan and in the past, Gerv, in order to search for the way that works with users. Only by a mix of careful thought and rough tumble in the userspace will we find the path. Maybe the best is a link to an on-line help ressource that will help Joe Shmoe understand that a caCert issued cert on a Debian ressource site is not a big deal, but that this self-signed cert on a home equity loan site that ask him his bank account info *is*. Certainly, we can outsource the tricky bits to a web page. (In my mind, I see the real end-users not clicking on that, but clicking over to their voice-chat program, and getting their pet techie on the line. Hey, bro, what's the difference between CA-not-trusted and you-can't-rely-on-self-signed? what's this mumbo jumbo that Firefox is telling me?) The best solution will still be as much as possible be to not bring out a warning if there's not actually an attack : Don't cry wolf ! Because of the bayesian problem, I believe there is no way to avoid the don't cry wolf dilemma. So, in essence, the path is to bring out the info, and create some sort of shared approach between the user and Firefox, working together. Real security begins at the application and ends at the mind. Which is to say, it is end-to-end, not discrete components. Which is another way of saying, sooner or later, the user has to enter into the security system. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Jean-Marc Desperrier wrote: You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. I can personally attest to the fact that trying to load a CRL with ~250,000 entries destroys Java using the Sun API. I opened a bug with Sun on this issue. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/30/2009 01:25 PM, Jean-Marc Desperrier: Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Jean-Marc, I can't hold back but must tell you that these are clear failures of the CA to assess and plan its infrastructure correctly, assess its design and provide adequate security. A CRL with the size of 34 MB is simply useless - it's like having no CRL and no way to revoke certificates. Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. And just count how many 3% of the certs Verisign issued under it's main CA makes. If the CA doesn't take measures which enables it it revoke 3% of issued certificates, then the infrastructure isn't up to its task. The EV guidelines for example requires ongoing or yearly security planning where issues like this must be addressed. Simply refusing to revoke the certificates is simply not dealing with the issue. There are various ways a CA can deal with this - even in case of Verisign and other CAs which issue a lot of certs. Not doing so is negligence either way, not revoking those weak and potentially compromised keys or letting CRLs grow to non-proportional sizes. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Florian Weimer wrote: * Michael Ströder: Florian Weimer wrote: What about requiring that all certificates must be published by the CA (including sub-CAs)? No, this might lead to also revealing internal DNS names never meant to be public. Huh? Typical CA policies Whatever a typical CA policy is. Note that the requirement mentioned by you above explicitly includes corporate sub-CAs which may issue server certs for servers not publicly accessible over Internet. explicitly state that subscriber certificates are not confidential, and are not treated as such by the CA Keeping certs really confidential and publishing certs in a public searchable database is something different. (so that they can be used by marketing, for instance). This is a different topic. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
On 01/30/2009 02:31 PM, Denis McCarthy: Actually, one other thing. While I agree with you on the thin clients issue, many of our applications use their own PC's to run our application (they have other applications they use on their PC besides ours) Typically server certificates are issued to servers, not clients. Perhaps if your applications behave like servers, they should use a server certificate, if your applications need to authenticate to a different server then they should use client certificates. Both of them don't have to be bound to a person (individual) per se. Many low-assurance certificates are exactly that. Now, when installing a certificate in Windows platforms you've got the possibility to choose the computer account (with the right access rights). You can install all kinds of certificates to the computer account. Making the authentication call is of course a different story. Windows has for example smart card logon, which is again bound to a user, not machine. Having the machine authenticate might be also possible with AD and DC. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
One thing we are investigating is the possibility of writing an ActiveX component to access the computer account to pull the certificate information from there for a browser (we'd probably need to glue the ActiveX component together with some sort of Firefox plugin to get this to work in Firefox, but I think it should be do-able). Would anyone know of any company or individual that I could hire to do such development (our expertise would be mainly server-side stuff and, while we could do it, it would take us much longer than someone who has expertise in the area). Ian, I think you may have misunderstood what I meant by 'transaction' (nothing to be ashamed of, as I can't think of any word with more meanings). When I said 'transaction', I wasn't implying transactional integrity or something like that, I was referring to the process one of our users goes through on our web application to process the financial transaction: i.e., fill in the various fields that need to be filled in on the html page, press submit, and get the confirmation. The application itself is already built and in pilot - we just need to find a balanced security model for a subset of our customers (none of whom are participating in the pilot) that will hit the sweet spot between security and ease of use. We have plenty of security options we could use, but I think if we could access an X.509 certificate from the machine certificate store it would be right on the money for us. Denis On Fri, Jan 30, 2009 at 1:24 PM, Eddy Nigg eddy_n...@startcom.org wrote: On 01/30/2009 02:31 PM, Denis McCarthy: Actually, one other thing. While I agree with you on the thin clients issue, many of our applications use their own PC's to run our application (they have other applications they use on their PC besides ours) Typically server certificates are issued to servers, not clients. Perhaps if your applications behave like servers, they should use a server certificate, if your applications need to authenticate to a different server then they should use client certificates. Both of them don't have to be bound to a person (individual) per se. Many low-assurance certificates are exactly that. Now, when installing a certificate in Windows platforms you've got the possibility to choose the computer account (with the right access rights). You can install all kinds of certificates to the computer account. Making the authentication call is of course a different story. Windows has for example smart card logon, which is again bound to a user, not machine. Having the machine authenticate might be also possible with AD and DC. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Ian G wrote: X.509 is a user concept, not a transaction concept. Hmm, X.509 certs are simply a strong binding between a name of an entity and a public key. Machines can be entities too like with server certs. Still I'd agree that the original poster should rethink his concept. I'd probably prefer the X.509-based user authc and lookup the machine on which the transaction was performed based on other data. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Hi Michael, While I agree that it would make sense for us to not be swimming upstream regarding our usage of X.509 certs, alas we are not in a position to change the fundamental model, as this is the way our customer does its business. Denis On Fri, Jan 30, 2009 at 2:15 PM, Michael Ströder mich...@stroeder.com wrote: Ian G wrote: X.509 is a user concept, not a transaction concept. Hmm, X.509 certs are simply a strong binding between a name of an entity and a public key. Machines can be entities too like with server certs. Still I'd agree that the original poster should rethink his concept. I'd probably prefer the X.509-based user authc and lookup the machine on which the transaction was performed based on other data. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
On 30/1/09 15:07, Denis McCarthy wrote: One thing we are investigating is the possibility of writing an ActiveX component to access the computer account to pull the certificate information from there for a browser (we'd probably need to glue the ActiveX component together with some sort of Firefox plugin to get this to work in Firefox, but I think it should be do-able) Can't you install a client-side cert in each browser, and then use client-side SSL? From inside your server-side application you can then read out the client-side certificate info. (The only thing here is, because of design decisions, it is more or less business-wise impractical to mix client-side certificate SSL with non-client-side SSL.) Ian, I think you may have misunderstood what I meant by 'transaction' (nothing to be ashamed of, as I can't think of any word with more meanings). When I said 'transaction', I wasn't implying transactional integrity or something like that, I was referring to the process one of our users goes through on our web application to process the financial transaction: i.e., fill in the various fields that need to be filled in on the html page, press submit, and get the confirmation. Sure, no misunderstanding here. The user is doing a thing called a transaction which includes collecting a bunch of info, entering it, and hitting the GO button. ( The word transaction derives from accounting, not tech. The tech people had to wrestle with this thing and discovered they kept mucking it up, and decided that transactions had to have something called integrity. ACID and all that ... Actually they needed lots of other things as well, but it kept the tech people happy to think of transactions as their integrity things. ) Getting back to your question. You want the server to also collect the browser's machine location ... Presumably you have already looked at all the browser headers and decided that the IP address isn't good enough. Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The application itself is already built and in pilot - we just need to find a balanced security model for a subset of our customers (none of whom are participating in the pilot) that will hit the sweet spot between security and ease of use. We have plenty of security options we could use, but I think if we could access an X.509 certificate from the machine certificate store it would be right on the money for us. :) iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Getting back to your question. You want the server to also collect the browser's machine location ... Presumably you have already looked at all the browser headers and decided that the IP address isn't good enough. The problem with the IP address is that it does not necessarily identify the user. For example, many ISP's (in the UK at least) will identify web traffic from a single browser as being from an arbitrary address from a block that they own. This can change at any time, and therefore cannot be used as a way to uniquely identify a browser. Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The reason why we want certificates involved is because in general we don't trust the user to do the right thing outside of working hours. This is the real digression we have between standard usage of X.509 and our required usage. We don't want to issue John Doe who just got a job in Kwik-e-Mart with a personal certificate to transact business on behalf of his employer: we want to give him a username and password that will allow him to transact business through our application running on an already authenticated PC under the control of the Kwik-e-Mart IT department. Then, the X.509 installation (and therefore the knowledge of the pass phrase to accomplish such an installation) can be performed by a trusted individual within the Kwik-e-Mart organisation, rather than John Doe (who might get criminal notions and put through transactions using his X509 certificate under his own name from his ADSL connection at home). Regards Denis On Fri, Jan 30, 2009 at 2:59 PM, Ian G i...@iang.org wrote: On 30/1/09 15:07, Denis McCarthy wrote: One thing we are investigating is the possibility of writing an ActiveX component to access the computer account to pull the certificate information from there for a browser (we'd probably need to glue the ActiveX component together with some sort of Firefox plugin to get this to work in Firefox, but I think it should be do-able) Can't you install a client-side cert in each browser, and then use client-side SSL? From inside your server-side application you can then read out the client-side certificate info. (The only thing here is, because of design decisions, it is more or less business-wise impractical to mix client-side certificate SSL with non-client-side SSL.) Ian, I think you may have misunderstood what I meant by 'transaction' (nothing to be ashamed of, as I can't think of any word with more meanings). When I said 'transaction', I wasn't implying transactional integrity or something like that, I was referring to the process one of our users goes through on our web application to process the financial transaction: i.e., fill in the various fields that need to be filled in on the html page, press submit, and get the confirmation. Sure, no misunderstanding here. The user is doing a thing called a transaction which includes collecting a bunch of info, entering it, and hitting the GO button. ( The word transaction derives from accounting, not tech. The tech people had to wrestle with this thing and discovered they kept mucking it up, and decided that transactions had to have something called integrity. ACID and all that ... Actually they needed lots of other things as well, but it kept the tech people happy to think of transactions as their integrity things. ) Getting back to your question. You want the server to also collect the browser's machine location ... Presumably you have already looked at all the browser headers and decided that the IP address isn't good enough. Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The application itself is already built and in pilot - we just need to find a balanced security model for a subset of our customers (none of whom are participating in the pilot) that will hit the sweet spot between security and ease of use. We have plenty of security options we could use, but I think if we could access an X.509 certificate from the machine certificate store it would be right on the money for us. :) iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Annadale Technologies Limited -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
It is kind of sad that this discussion has become CAs should not revoke certificates when the private keys are exposed because Java cannot handle CRLs reliably. That says more about the failures of Java than it does failures in PKIX. --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
A better solution would be to authenticate the user as well as is possible. After successful authentication through a web ID portal (which would identify itself through an non-personal) org-cert the user would be redirected to the actual app using SAML. If the user has a personal certificate it would only be trusted by the ID portal so there is no problem that the user would be able to conduct any business on his/her own, the ID-portal has it all. If there is a need to identify machines, it would not be through the browser but through the network connection. That's at least how most other people deal with this particular problem. VPN is an obvois solution here. ActiveX? I would not. Anders - Original Message - From: Denis McCarthy dmccar...@annadaletech.com To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Friday, January 30, 2009 17:07 Subject: Re: X509 per machine (not per user) - or equivalent needed Getting back to your question. You want the server to also collect the browser's machine location ... Presumably you have already looked at all the browser headers and decided that the IP address isn't good enough. The problem with the IP address is that it does not necessarily identify the user. For example, many ISP's (in the UK at least) will identify web traffic from a single browser as being from an arbitrary address from a block that they own. This can change at any time, and therefore cannot be used as a way to uniquely identify a browser. Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The reason why we want certificates involved is because in general we don't trust the user to do the right thing outside of working hours. This is the real digression we have between standard usage of X.509 and our required usage. We don't want to issue John Doe who just got a job in Kwik-e-Mart with a personal certificate to transact business on behalf of his employer: we want to give him a username and password that will allow him to transact business through our application running on an already authenticated PC under the control of the Kwik-e-Mart IT department. Then, the X.509 installation (and therefore the knowledge of the pass phrase to accomplish such an installation) can be performed by a trusted individual within the Kwik-e-Mart organisation, rather than John Doe (who might get criminal notions and put through transactions using his X509 certificate under his own name from his ADSL connection at home). Regards Denis On Fri, Jan 30, 2009 at 2:59 PM, Ian G i...@iang.org wrote: On 30/1/09 15:07, Denis McCarthy wrote: One thing we are investigating is the possibility of writing an ActiveX component to access the computer account to pull the certificate information from there for a browser (we'd probably need to glue the ActiveX component together with some sort of Firefox plugin to get this to work in Firefox, but I think it should be do-able) Can't you install a client-side cert in each browser, and then use client-side SSL? From inside your server-side application you can then read out the client-side certificate info. (The only thing here is, because of design decisions, it is more or less business-wise impractical to mix client-side certificate SSL with non-client-side SSL.) Ian, I think you may have misunderstood what I meant by 'transaction' (nothing to be ashamed of, as I can't think of any word with more meanings). When I said 'transaction', I wasn't implying transactional integrity or something like that, I was referring to the process one of our users goes through on our web application to process the financial transaction: i.e., fill in the various fields that need to be filled in on the html page, press submit, and get the confirmation. Sure, no misunderstanding here. The user is doing a thing called a transaction which includes collecting a bunch of info, entering it, and hitting the GO button. ( The word transaction derives from accounting, not tech. The tech people had to wrestle with this thing and discovered they kept mucking it up, and decided that transactions had to have something called integrity. ACID and all that ... Actually they needed lots of other things as well, but it kept the tech people happy to think of transactions as their integrity things. ) Getting back to your question. You want the server to also collect the browser's machine location ... Presumably you have already looked at all the browser headers and decided that the IP address isn't good enough. Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The application itself is already built and in pilot - we just need to find a balanced security model for a subset of our
Re: X509 per machine (not per user) - or equivalent needed
After reading the other postings on this thread, I think I
see what you're getting at. You need a combination of two
items and a 2-phase authentication process to get the
assurance you're seeking:
1) A token-based credential per user, using a smartcard and
a digital certificate for Client-Auth. Your application
will use this to establish an SSL session in phase 1; and
2) A GPS card in the PC which your application will interact
with to get its physical GPS coordinates and then relay
this as a signed message in phase 2 of the auth process.
The message will be signed by the private key of the user
who just established the SSL session with the application,
which will corroborate the phase-1 authentication.
Your application would receive the latitude/longitude values
and verify that these coordinates matched up with the list
of authorized PC's to establish an authenticated session.
This mechanism can still be attacked because the smallest
GPS measurement - a second - equates to approximately 100
feet. So, someone could move the GPS card from one PC to
another in the same location and then log in from that PC
(which might defeat what you're attempting to achieve).
This is about the closest you can get without the use of a TPM
chip. What the TPM gives you is a keystore that is embedded on
the motherboard by the manufacturer and which cannot be moved
from one PC to another.
Hope that helps.
Arshad Noor
StrongAuth, Inc.
Denis McCarthy wrote:
Hello Arshad,
Thanks for the email. I suppose the one thing I'd like to stress again
is that we wish to authenticate a machine, not a user. Many users may
log in to a certain machine (via a username and password that we would
issue). What we need to do on our system is to ensure that the user
logging is valid to log in on that particular computer ('terminal' as
our customer calls them). The terminal itself is connected to the
company that the user works for in our database.
Regards
Denis
On Fri, Jan 30, 2009 at 12:08 AM, Arshad Noor
arshad.n...@strongauth.com wrote:
Denis,
You have already made the appropriate leap to this conclusion.
I was going to suggest that there is something atypical about
your application architecture if you're relying on authentication
of the *machine* without the use of a hardware token - such as a
smartcard, TPM chip, etc.
What you want are FIPS 140-2 Level 2 (or above) certified crypto
tokens that generate keys on-board and store the certificate of
the user on the token (in addition to the browser). The private
key, however, never leaves the token, thus ensuring its security.
Once your customers are issued these tokens with their personal
certificates, they can use it on any PC they desire (assuming
that the PC has been configured with the appropriate CA cert-
chain).
If you absolutely need to rely on authenticating the PC, then
the only option you have is the TPM chip, because it is built
with the chip on the motherboard by the manufacturer.
As an aside, StrongAuth, Inc., the company I represent has been
in the business of architecting, building operating some of the
largest closed-PKIs in the world for enterprises, with the use of
crypto-tokens. Most recently, we built a PKI for a bio-technology
company that embedded secure processors with digital certificates
into three different parts of their product, so that they may
strongly authenticate to each other before being used. This was
designed to deter counterfeiters from cloning the consumable part
of their product. The device is currently awaiting FDA approval
before coming to market.
Feel free to get in touch with us, if we can be of any help to you.
Arshad Noor
StrongAuth, Inc.
Denis McCarthy wrote:
Thanks for the suggestion David. Unfortunately we are not connecting
to an active directory domain - our application has to go out over the
internet. I did a bit of fiddling with the certificates snap ins, but
Microsoft only makes certificates installed in the user account
available to IE. One other thing I've been mulling over - is it
possible to get a cheap piece of hardware (i.e. a dongle of some sort)
that you can put an X509 certificate on? If so, could anyone point me
in the direction of a company that provides such a product?
Regards
Denis
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
On 30/1/09 17:07, Denis McCarthy wrote: Is there a reason why you want certificates involved? Why can't the machine's website just have a drop-down or cookie or something that says what store it is in? The reason why we want certificates involved is because in general we don't trust the user to do the right thing outside of working hours. This is the real digression we have between standard usage of X.509 and our required usage. No, this is nothing to do with X.509. That's just a framework for public key cryptography and some static claims. Which is little to do with what you are after. We don't want to issue John Doe who just got a job in Kwik-e-Mart with a personal certificate to transact business on behalf of his employer: we want to give him a username and password that will allow him to transact business through our application running on an already authenticated PC under the control of the Kwik-e-Mart IT department. What you want is for the transactions only to be doable on designated PCs. This sort of thing is normally considered to be a VPN question. The reason it is considered a VPN question is because the use of certs keys passwords is too brittle. The protection has to be outside, not inside. Consider that a private key is little more than a password (and in this context it is no more than a password). a. PC has a password b. user has a password c. PC authenticates itself to the system d. user authenticates herself to the system e. user authorises a transaction f. system accepts as authentic the transaction That's it! The problem of course here is that if the user wants to go loopy and do business on own-account, she just takes the PC password home and uses that (or if she is smart, she takes all the PC passwords, and compromises a friend's password, and does the business in a way that leads people to think it was a hacker...). (The difference between the passphrase password and the X.509 password is pretty meaningless here.) Then, the X.509 installation (and therefore the knowledge of the pass phrase to accomplish such an installation) can be performed by a trusted individual within the Kwik-e-Mart organisation, rather than John Doe (who might get criminal notions and put through transactions using his X509 certificate under his own name from his ADSL connection at home). Um. OK, I see it. Well, X.509 won't solve that. I don't mean to be rude, but what you need is architecture, not crypto or PKI or tech of any form. This is not really the place for architecture (I wish it were! but it ain't). What you need likely is some help in the general topics of authentication and authorisation and so forth. If anyone mentions X.509 or public key or protocols to you, you are in the *wrong place*. Apologies :) iang Can't you install a client-side cert in each browser, and then use client-side SSL? From inside your server-side application you can then read out the client-side certificate info. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS Diffie Hellman
Nelson B Bolyard wrote: Sreedhar Kamishetti wrote on 2009-01-29 16:28 PST: I just started to use JSS/NSS. So, if hope some one will reply to this post. We use SSL_DH_anon_WITH_3DES_EDE_CBC_SHA” as cipher suite for communication between SSL Peers. Client is in Java and Server is in C (uses OpenSSL). I am trying to use JSS/NSS for Client side SSL Provider for supporting FIPS, but I am not able to do it easily as Diffie Hellman protocol for Key exchange is not implemented by JSS/NSS. That's not exactly correct. NSS implements DH for SSL clients, but it does not implement *anonymous* cipher suites at all, not for Diffie Hellman or any other flavor of key agreement algorithm. We are having problems communicating to Server by writing Java SSL Client from scratch using JSS API. Can I use the Sun JSSE provider along with Mozilla-JSS provider so that my existing code will not change except for initializing the Mozilla-JSS provider so that SSL Context from Sun JSSE provider internally uses all the services of Mozilla-JSS provider? Which Cipher suite is recommended with minimal changes to use between JSS/NSS client and OpenSSL Server. I think that any cipher suites that are supported by both NSS/JSS and Java's SSL classes will require about the same amount of adaptation to switch from one implementation to the other. But I don't know how much that will be. Hopefully one of this list's Java gurus can help answer that. You'll find the list of cipher suites supported by NSS at http://mxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#48 JSS supports all NSS ciphersuites. For recommend ciphersuites, how about: TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA There is a sample JSSE Server using Mozilla-JSS test in our automated tinderbox QA. To see the output search for JSSE Server using Mozilla-JSS http://tinderbox.mozilla.org/showlog.cgi?tree=NSSerrorparser=unixlogfile=1233326113.122216.20828.gzbuildtime=1233326113buildname=trunk%20standard%20dositups%20SunOS%2fi386%2064bit%20OPTfulltext=1 The above link will expire, but you get the link by going to the http://tinderbox.mozilla.org/showlog.cgi?tree=NSS selecting a succesful green run, and viewing the Full log. Test: http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JSSE_SSLServer.java http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JSSE_SSLClient.java The above code is test/sample code. Cleanup or additional functionality contributions are welcomed. -glen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: JSS Diffie Hellman
On Fri, Jan 30, 2009 at 9:32 AM, Glen Beasley glen.beas...@sun.com wrote: For recommend ciphersuites, how about: TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA I concur. Note that TLS_RSA_WITH_AES_128_CBC_SHA is the mandatory cipher suite in TLS 1.2 (http://www.ietf.org/rfc/rfc5246.txt, Section 9, page 65). Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
Denis McCarthy wrote: On Fri, Jan 30, 2009 at 2:15 PM, Michael Ströder mich...@stroeder.com wrote: Ian G wrote: X.509 is a user concept, not a transaction concept. Hmm, X.509 certs are simply a strong binding between a name of an entity and a public key. Machines can be entities too like with server certs. Still I'd agree that the original poster should rethink his concept. I'd probably prefer the X.509-based user authc and lookup the machine on which the transaction was performed based on other data. While I agree that it would make sense for us to not be swimming upstream regarding our usage of X.509 certs, alas we are not in a position to change the fundamental model, as this is the way our customer does its business. My understanding was that the customer already has issued roaming user certs for his users. If that's the case these X.509 certs probably have a common naming scheme. So you can find out which customer it was. In a former customer project I made a similar concept for a point-of-sale (POS) project with external partners hosting the POS client machine. Your situation seems even easier because 1. your customer's users already have certs and 2. you seem to have a web application running. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: X509 per machine (not per user) - or equivalent needed
This is very much akin to needing to authenticate that a machine used
to perform the transaction submission was, indeed, configured by the
information technology staff. This is a very important concept that
cannot be discounted or ignored.
Essentially, what you need is a two-stage authentication process:
1) Authenticate that the machine connecting to your TLS server is
acceptable (via unique identification of the machine -- the function
of a per-machine X.509 certificate that the OP wants), then
2) identify the user on the machine to verify that he's really
authorized to perform the task that he's trying to do.
I would recommend the following approach:
1) Per-machine keys/certificates, embedded into the machine's TPM or a
hardware dongle that cannot be removed from the machine, issued by a
particular CA name (referred to here as MachineCA)
2) Per-user keys/certificates, stored normally, and issued by any other CA name.
On the TLS server side, you would first send a ClientAuthRequest with
the acceptable CA name list only including MachineCA.
If the client cannot authenticate, terminate the connection.
If the client authentication violates policy (working after hours,
for example), terminate the connection. (I would be VERY careful
about this one, though, since there are any number of reasons why
someone would want/need to work after hours.)
If the client can authenticate, then immediately send another
ClientAuthRequest with an empty CA name list such that the user could
select the client certificate to use.
If the client sends the MachineCA certificate again, fail the connection.
Otherwise, proceed.
If you want to reduce the chance that the user will send the MachineCA
certificate twice in a row (thus failing the connection), compile a
list of CA names that the clients use, and add them all to the second
ClientAuthRequest (without mentioning MachineCA in that list).
(This is permitted by TLS, as well as SSL all the way back to SSLv2.)
People, remember: not every situation fits into your narrowly-defined
Holy Writ worldview. I've been trying to get this through your
collective heads for a while now. This is a situation that does not,
and the fact that you're trying to reinforce the dominant paradigm
without realizing that the standards allow for a LOT more leeway than
you're giving them credit for is only a testament to your
closed-minded dogmatic expertise.
-Kyle H
On Fri, Jan 30, 2009 at 1:36 AM, Denis McCarthy
dmccar...@annadaletech.com wrote:
Hello Arshad,
Thanks for the email. I suppose the one thing I'd like to stress again
is that we wish to authenticate a machine, not a user. Many users may
log in to a certain machine (via a username and password that we would
issue). What we need to do on our system is to ensure that the user
logging is valid to log in on that particular computer ('terminal' as
our customer calls them). The terminal itself is connected to the
company that the user works for in our database.
Regards
Denis
On Fri, Jan 30, 2009 at 12:08 AM, Arshad Noor
arshad.n...@strongauth.com wrote:
Denis,
You have already made the appropriate leap to this conclusion.
I was going to suggest that there is something atypical about
your application architecture if you're relying on authentication
of the *machine* without the use of a hardware token - such as a
smartcard, TPM chip, etc.
What you want are FIPS 140-2 Level 2 (or above) certified crypto
tokens that generate keys on-board and store the certificate of
the user on the token (in addition to the browser). The private
key, however, never leaves the token, thus ensuring its security.
Once your customers are issued these tokens with their personal
certificates, they can use it on any PC they desire (assuming
that the PC has been configured with the appropriate CA cert-
chain).
If you absolutely need to rely on authenticating the PC, then
the only option you have is the TPM chip, because it is built
with the chip on the motherboard by the manufacturer.
As an aside, StrongAuth, Inc., the company I represent has been
in the business of architecting, building operating some of the
largest closed-PKIs in the world for enterprises, with the use of
crypto-tokens. Most recently, we built a PKI for a bio-technology
company that embedded secure processors with digital certificates
into three different parts of their product, so that they may
strongly authenticate to each other before being used. This was
designed to deter counterfeiters from cloning the consumable part
of their product. The device is currently awaiting FDA approval
before coming to market.
Feel free to get in touch with us, if we can be of any help to you.
Arshad Noor
StrongAuth, Inc.
Denis McCarthy wrote:
Thanks for the suggestion David. Unfortunately we are not connecting
to an active directory domain - our application has to go out over the
internet. I did a bit of fiddling with the certificates snap ins, but
Re: Policy: revoke on private key exposure
The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. in other words, it's the implementation's fault, not the standard's. (Yes, a standard has the responsibility to make it *possible* to implement it properly, but if other PKIX implementations can handle it and Java cannot, then the problem is squarely in Java's court, and can only be appropriately dealt with there.) -Kyle H On Fri, Jan 30, 2009 at 8:39 AM, Paul Hoffman phoff...@proper.com wrote: It is kind of sad that this discussion has become CAs should not revoke certificates when the private keys are exposed because Java cannot handle CRLs reliably. That says more about the failures of Java than it does failures in PKIX. --Paul Hoffman -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Jean-Marc Desperrier wrote, On 2009-01-30 03:25: Paul Hoffman wrote: [...] That feels insufficient to me. I also disagree that there are practical problems of revoking a very large number of certificates. The worst problem is that the CRL will grow; that's no big deal, it is supposed to grow. You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Ah, yes, the proverbial 35 Megabyte CRL, which even at T1 speeds takes 3.5 minutes (211 seconds) to download. Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. Years ago, NSS used a general purpose BER/DER decoder everywhere. It was used to decode a single 35 MB CRL (from the DoD, as I recall), and IIRC it took 24 hours to decode it and used some large portion of a gigabyte of RAM to do so. The problem was that it allocated space for and copied the value of every component, and every subcomponent of every constructed (structured) member of the document. So, Julien wrote a new DER-only decoder that uses the same templates as the old decoder, specifically motivated to handle that whopping CRL. It does not make unnecessary copies. Today, NSS uses that Quick DER Decoder for anything that is DER encoded. I just ran it against that 35 MB CRL cited above. It took less than 2 seconds to parse the whole thing. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA Keygen problem
Jean-Daniel wrote, On 2009-01-22 14:06: Everything is green. The new asm file does not try to determine at runtime if SSE2 is present, but it does it at compile time. By default the Apple GCC version define __SSE2__, so the default is to use it on Mac. And as mention before, all supported Mac have a processor with SSE2 available, so it should be fine. Else, this is a simple copy/paste of the Linux version (without the .type lines, as the Darwin assembler does not like them). I filed bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=474904 requesting that this patch be applied for NSS builds on Darwin (OSX). But when I tested it, the builds failed. Please see the bug for details. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
