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

[Paul Judge]

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