Re: [Auth]Okay, so how about some code...

[John]

Mason-
The problem is who encrypts. As I noted in the FrePort spec, the user
agent must send the data and metadata to the auth syatem and not give
that provider a key to decrypt it, otherwise both the data an metadata
can be mined. It's not ONLY the "flow through the system" that must be
secured, it's the repositories at either end with one crucial
difference: the Customer (user) must be able to decrypt, the Provider
must NOT be able to decrypt, otherwise privacy from mining is not
guaranteed.

John Le'Brecage

John Le'Brecage

Mason Ham wrote:
> 
> Yeah, you guys are right about the LDAP issue. That was one in the plus for
> DBs :-)
> As for the encrypt or not encrypt, again as with different parts of the
> system, we left it up the Auth. provider. If system uses encryption to store
> the data, there is actually a location to store member specific data
> encryption keys in the database. This key is then used to encrypt the data
> the user has. Then, it would be a no brainer for us to down the road write a
> "module" that will let us decrypt with the users private key and re-encrypt
> with the sites public key. This way the data can flow through and be secure
> as long as the system that is running the decrypt/re-encrypt module.
> On the note of the data being transmitted. The system actually assumes that
> the end user has gone in and given rights to the site to get the data. More
> specifically, the site specifies what data it is looking for (there is a
> grouping/role based request as well as individual item). This is also where
> the use of a database over say ldap came in. We have types that are stored
> in the database. Thus a site can no ahead of time that they want to put
> custom fields into a known server. The example here is that a site decides
> that it wants to use only a certain server for authentication. This server
> then can house different pieces based on the site that is being used. This
> is more of an "enterprise" feature when the web services is being used with
> a private uddi server.
> 
> Mason
> 
> PS I site not to me a web site, but
> 
> ----- Original Message -----
> From: "John" <address@hidden>
> To: "Norbert Bollow" <address@hidden>
> Cc: <address@hidden>; <address@hidden>
> Sent: Friday, October 05, 2001 8:09 AM
> Subject: Re: [Auth]Okay, so how about some code...
> 
> > Perhaps I'm seeing something that isn't there?
> >
> > > 5) bar encrypts the information with foo's public key. and "transmits"
> the
> > > data to bob to be redirected.
> >
> > If bar is encrypting the data it retrieves from LCRS to send to Bob,
> > then the implication is that the data is stored unencrypted, else there
> > is no need to re-encrypt it? There's no spec here of how LCRS stores
> > data, but if it's based on LDAP, we should note that though one can
> > store encrypted data in LDAP, LDAP is not specifically designed to hide
> > metadata (ie the name of the data to be retrieved) from the sysadmin.
> >
> > Hmmmm... hmmm... that give me another idea for Freport. A way to solve
> > the public terminal problem, maybe...
> >
> > Anyhow, I'm just guessing from inference here. Maybe I'm missing
> > something also. Mason?
> >
> > John Le'Brecage
> >
> > Norbert Bollow wrote:
> > >
> > > John Le'Brecage wrote:
> > >
> > > > This still does not prevent the data or metadata from being mined by
> B,
> > > > which was another requirement of the DotGNU design. Wasn't it?
> > >
> > > John is right.  Data mining must not be possible as long as
> > > people use software that is officially released by the DotGNU
> > > project.  I believe that this is a non-negotiable requirement.
> > >
> > > But I don't understand Mason's design well enough to see whether
> > > this is indeed a problem with his approach... Mason, maybe you
> > > could clarify this?
> > >
> > > Greetings, Norbert.
> > >
> > > --
> > > A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
> > > Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
> > > Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
> > > Your own domain with all your Mailman lists: $15/month  http://cisto.com
> > > _______________________________________________
> > > Auth mailing list
> > > address@hidden
> > > http://subscribe.dotgnu.org/mailman/listinfo/auth
> > _______________________________________________
> > Auth mailing list
> > address@hidden
> > http://subscribe.dotgnu.org/mailman/listinfo/auth
> >
> 
> _______________________________________________
> Auth mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/auth