[IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?

[Thomas Hardjono]

Hi Nicko,

Let me try to explain my view of the slides at IDRM.


At 8/15/2001||10:24 PM, Nicko van Someren wrote:
>Mark Baugher wrote:
>...
> > If we're going to investigate technical protection systems such as
> > HDCP, CPRM, or some vendor's implementation of an IPMP tool,
> > then this is a problem for us.  I never imagined IDRM will want to
> > do that.  Individual participants of the RG may want to do so, but
> > not under the auspices of IDRM.
>
>Mark,
>         Your own slides from London say that we must carry out this
>sort of investigation.  You say things like "understand the landscape"
>and "evolve the internet infrastructure".

What I understand as "landscape" is the existing work that has been
published/presented in various organizations/standards-bodies,
conferences and vendor-specific events.


>How on earth can we do
>these without exposing issues surrounding what's already there?  If,
>for instance, XrML or XMCL had accidentally chosen to sign the wrong
>parts of their message structures then the act of standing up and
>saying so at an IDRM meeting could, based on the action against Prof.
>Felton and USENIX, leave the IETF as liable at the person presenting.


My understanding is that the DMCA is targeted to people who
purposely circumvent the copy-protection mechanisms in DRM-enabled
devices/systems.  Yes, granted, the lawyers can stretch it to cover
a vast reach (and they have, as in the case of Felten).
And yes, I do see you point about DMCA's reach to the point of preventing
meaningful technology development.

However, when a technology is presented at the IETF for standardization,
the assumption is that there is no IP/patent restrictions to its use.
The IETF is certainly not going to give a specification "Standards Track"
approval if the IP issues have not been clarified/resolved.
This implies that anyone can stand-up and say that something is broken
in the specification.  If a person cannot do that, then that proposed
specification will simply be thrown out of the IETF.

This is also why technologies such as HDCP and CPRM will not find its
way into the IETF.  The folks behind such technologies are typically
not open to standards over which they have no direct control.

This is also why IDRM is focusing on Infrastructure Support for DRM
systems (e.g. trust, PKIs, key management, etc) as opposed to
bit-level protection.



> >                              I don't expect anyone to craft a
> > technical protection measure that gets embedded in some home
> > computing device that is invulnerable to compromise (e.g., lose one or
> > more secret keys).
>
>Nor do I, but is it not a goal to come up with a sound framework
>into which others can insert their systems?  If so, do we not need
>to understand the systems that might be fitted in?  If we find a
>fundamental flaw in those third party's systems must we not say so,
>so that those flaws are not perpetuated in whatever the IETF turn
>into an RFC?

Well, the IDRM group can develop a framework, but the real question
is wether vendors are going to "insert their system", at which
point they will have to answer the IP issues.  If they cannot even
answer the IP issues, then DMCA will never come up as an issue (as
we would not have made it to that point).



> > So I don't see the point of engaging in this
> > kind of work.
>
>In security it does not matter if the flaw lies in the framework or
>in the implementation, either way it weakens the system.  I understand
>that IDRM aims are oriented towards frameworks at this stage but you
>said we need to "Identify useful component technologies" and I don't
>see any reliable way of doing this without pointing out the useLESS
>ones.

The notion of "component technologies" is a high-level view of the pieces
of a (open) DRM system (assuming an "open" DRM system is even possible,
where "open" means that all the mechanics are published and well-understood).

Initially IDRM is only going to focus on existing technologies in
the IETF and other open organizations.  As usual, the framework
will evolve and we will see if the notion of Infrastructure Support for DRM
is a viable concept (e.g. naming/resolution infrastructure, trust
infrastructure, etc).

Perhaps when the dust settles and enough DRM vendors get de-listed
from Nasdaq, the notion of "open standards as a good thing" will emerge
again.

thomas
------