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

[Mark Baugher]

I used "DMCA" in this note when I meant "DMCA anti-circumvention provisions."

Mark
>Date: Wed, 15 Aug 2001 15:13:19 -0700
>To: Nicko van Someren <nicko@ncipher.com>
>From: Mark Baugher <mbaugher@cisco.com>
>Subject: Re: [IDRM] Will the DMCA make our work more difficult?
>Cc: Thomas Hardjono <thardjono@verisign.com>, ietf-idrm@lists.elistx.com
>
>Hi Nicko
>At 10:24 PM 8/15/2001 +0100, 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"
>
>Either you misunderstood what I said or I misunderstood what I said.
>
>>and "evolve the internet infrastructure".  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.
>
>I don't think so.  At any rate, I'd rather leave DMCA issues to the EFF
>and organizations that are competent in this area.  The IETF is not.
>
>
>> >                              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?
>
>I am saying that I don't expect that we will be specifying technology
>that will encounter problems in the DMCA.  Perhaps I'm wrong.
>Perhaps we'll revisit this topic when we have something real to
>consider.  I'm open to that.
>
>
>> > 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
>
>I don't think we are talking about security.  Once you put secrets on
>a device and put that device in the home of a determined attacker
>trying to reveal those secrets, we are no longer talking about security.
>
>>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.
>
>I don't see any problem with pointing out useless technologies.  Nor
>do I see any value of describing how to alter the verance watermark
>or defeat CPRM in an RFC.
>
>If you have something you wish to publish under the auspices of IDRM
>that may have DMCA issues associated with it, then please let me
>know.  I don't see the point of debating this in the abstract.  What else
>can we do?
>
>thanks, Mark
>
>
>>         Nicko