[IETF-IDRM] RE: [IDRM] Disband or recharter IDRM?

[Thomas Hardjono]

Hi Jessica,


At 12/11/2002||01:56 PM, staddon@parc.com wrote:
>I've only joined the mailing list recently and am still a bit fuzzy on the 
>goals of IRTF working groups in general.

That's fine:  we're all rather fuzzy as the group has been dormant for over 
a year:)


>That said, I think there are a number of interesting areas in which new 
>(crypto) technology is needed and that could be taken up as part of Gord's 
>option #3. One easy example if copy protection for digital tv. Perhaps the 
>group could recommend approaches that allow for normal use (e.g. the 
>ability to view recorded programs on any of a user's players) but make 
>large-scale piracy difficult.

This seems like a topic that falls into the "terminal protection" area, ala 
MPEG4-IPMP.  In fact, I think its is the goal of many PVR makers to ensure 
that this function is available and difficult to copy.  Many also want to 
provide "mobility" of content, meaning that the user can easily move 
content from one tamper-proof storage to another (but never to the user's PC).



>In addition, with the activity around microbroadcasters this past summer, 
>there also seems to be a need for technology that can better measure the 
>audience size of content distributors. Such technology could potentially 
>protect small distributors by keeping their licensing fees low but still 
>be fair DRM-wise (Rob Johnson and I did some work in this area but I think 
>there's still much to be done).


Actually, this is an issue that no one has brought-up in the IETF, but 
would be of interest to folks in the IETF who do traffic shaping and 
traffic management.

cheers,

thomas
------


>These are very much off the top of my head and I'm sure there are more and 
>better candidates. In any case, I would like to see the group resume activity.
>
>Jessica Staddon
>
>-----Original Message-----
>From: Paul Judge [mailto:judge@cc.gatech.edu]
>Sent: Wednesday, December 11, 2002 1:21 PM
>To: Thomas Hardjono
>Cc: glarose@info-mech.com; ietf-idrm@lists.elistx.com
>Subject: Re: [IDRM] Disband or recharter IDRM?
>
>
>
>On Wed, 11 Dec 2002, Thomas Hardjono wrote:
> >
> > Right. So one of the notions we put forward in the IETF was:  is it at all
> > possible to create "open-source DRM technologies", so that small
> > mom-and-pop publishers need not pay $$$ for proprietary solutions.  The
> > analogy is that with Linux and the Apache webserver, which are available
> > for around $30.
> > Another useful comparison in the RSA encryption algorithm, which is good
> > technology, well understood, standardized and now finally over the patent
> > hurdle.
>
>I think that this is a reasonable strategy and a worthy goal. We were
>working on some content protection architectures here that have very
>similiar motivations. An open-source standards-based DRM system would
>enable the small content providers as well as provide an alternative to
>multiple proprietary formats and systems.
>
> > >On a philosophical level then, I say there is a need for smart people to
> > >build workable DRM that citizens can live with.
> > >
> > >The point issue of this technical group's mandate is much clearer IMO. The
> > >core
> > >technology challenges for DRM are terminal node challenges, not network
> > >challenges. Sure, a network is usually involved, but DRM is nothing 
> special
> > >for the network. DRM's basic network needs are nothing harder than
> > >http/https over tcp/ip. And the terminal mode challenges are largely about
> > >things like tamper-resistance, which are proprietary and not very amenable
> > >to
> > >standardization. It's not something where an IETF group adds much value.
> >
> > Right.  This is where the word "DRM" is I think a misnomer for the IETF
> > efforts.  You are absolutely right, that DRM is indeed "terminal node
> > challenges" (ie. development of rights-enforcing terminals), which is not
> > the traditional area of work for the IETF.
> >
> > However, there some network issues that is part of what I call the "DRM
> > macrocosm", which included functions relating to look-ups, secure network
> > storage, transaction clearinghouse, etc.  These would appear to be suitable
> > for work items in the IETF.
>
>The way that I've been thinking about this is that DRM tries to solve
>three problems: 1) secure distribution/conditional access, 2) protected
>storage, and 3) output protection. True, #3 is largely about 'terminal
>node challenges', but #1 and #2 largely include distribution architectures
>and supporting systems. I believe that there is room in these areas for
>IETF work.
>
> > Thus, one possible change to IDRM is a new name that is less likely to be
> > controversial.
>
>Couldn't hurt. Even if it doesn't reduce the controversy, it may reduce
>the confusion since DRM is such an overloaded term. If the focus becomes
>protected distribution and protected storage areas, then how about a name
>to describe that as opposed to the output protection area.
>
> >>3) Find specific technical problems that are obstacles to good (i.e.
> >>effective but not Orwellian) DRM, which are going begging, and in scope,
> >>and work on solutions.
> >>
> >>I don't have a top-of-mind suggestion for #3, but it sounds like the
>most
> >>fun!
>
> >>Yes, the keyword is "fun".  Perhaps others on the list may have specific
> >>suggestions?
>
>based on what i've worked on before, there are a few things that come to
>mind. there are a few components that must exist in a protected
>distribution/storage environment: secure content objects, content object
>importation system, ACL servers (1 that assigns rights and 1 that can be
>used to lookup rights based on a user, role, or object), authorization
>protocols, etc.
>
>with that said, my two cents is: 'recharter'.
>
>Regards,
>Paul
>
>___________________________
>Paul Judge, Ph.D. Candidate
>Georgia Tech
>judge@cc.gatech.edu