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 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 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
