Laszlo, First, let me re-iterate, kudos for the effort of bringing up these issues and continuing the discussions.
I don't quite understand your comment yet. It seems that you are suggesting that there is an authorization/authentication environment that P1619 was designed for. In particular that the various agents have no media access control limits (other than the keys). Is this your point? There are specification environments that reach for everything between the BIOS and the applications (TCG), but I don't think this specification can go there. There are places for targeted encryption, authentication, and authorization specifications. And it is useful to describe what limits or lack of limits are presupposed by any of these so that secure ecosystems can be constructed. I think you are reaching for an expression of these limits or lack of limits in the scope. Am I hearing you? I hope you agree that authorization and authentication protocols will not be developed and defined in this encryption specification. John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 10:39 AM To: SISWG Subject: RE: glossary term for 1619: shared media > "The LRW-AES transform and the key-export format are only a portion of a > secure shared storage media solution. Authentication and authorization > protocols are beyond the scope of this specification." It implicitly implies that LRW-AES is the right transform, even if authentication and authorization (access control) is provided by other means. There have been no such claims. In fact, P1619 assumes that an unauthenticated, unauthorized person can access the ciphertext, that is, no access control is present. In this light, (the lack of) authentication and authorization is and has been in the scope of this specification. > -------- Original Message -------- > Subject: RE: glossary term for 1619: shared media > From: "Robert Snively" <[EMAIL PROTECTED]> > Date: Wed, May 24, 2006 1:14 pm > To: "John Geldman" <[EMAIL PROTECTED]>, "SISWG" > <[EMAIL PROTECTED]> > > John Geldman writes: > > Something that continues to come up in these discussions is > authorization, authentication and policies. As in permission for read > access of private data (for me, this is a concern before blind > manipulation) as well as permission to overwrite or delete. > > It is my understanding that these concerns are outside of the scope of > this specification. It is also my expectation that those who haven't > been following the discussion won't simply know that. > > This seems like an opportunity for a little more in the scope following > the proposed sentences: > > "The LRW-AES transform and the key-export format are only a portion of a > secure shared storage media solution. Authentication and authorization > protocols are beyond the scope of this specification." > > RNS: This looks like the right idea to me.
