[IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt

[Sam X. Sun (@S2000)]

Mark,

These are very good points, and my comments are below...

----- Original Message -----
From: "Mark Baugher" <mbaugher@cisco.com>
To: <ietf-idrm@lists.elistx.com>
Cc: <ssun@cnri.reston.va.us>; <llannom@cnri.reston.va.us>
Sent: Friday, May 25, 2001 12:36 AM
Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt


> Here are the remaining questions and comments from the
> draft-irtf-idrm-handle-system-00.txt.  Regarding my previous comments,is
it
> accurate to say that the Handle System protocols could in principle be
used
> with a variety of different servers/resolvers including DDDS?
>
> I have five points.
>
> 1)  Section 1, under "Secured Named Service" describes specific
> cryptographic mechanisms but "Distributed Administration Service" does
> not.  By briefly mentioning specific security and cryptographic mechanisms
> in this document, rather than in the later documents where they are
> specified, I think you raise more questions than you can answer in an
> Overview document.

This is good. I will add that to the next version of the draft.

>
> 2)  Section 2, para 2, suggests that a persistent name can never be moved
> between naming authorities.  If all rights to a content work were
> completely transferred from a corporation operating naming authority x, to
> one operating naming authority y, then the content work will still have x
> in its name.  This seems like a problem to me.  The DOI Handbook makes a
> point about handles being "dumb numbers," but these handles reveal
> information that will persist even when no longer valid.
>

Larry has addressed this, and I will follow up on that thread in a separate
message...

> 3) Section 4, para 3, last sentence, defines an enormous PKI for a global
> namespace and I have some doubts about providing a security service for
> referencing potentially any content item in the world.  It is a
scalability
> issue if the handle system is not designed for smaller-scale and private
> use or if the trust and security mechanisms cannot be tailored to the
needs
> of individual organizations and national considerations.  There are large
> political issues here.  This is the main problem I have with the Handle
> System.  We may have an opportunity to consider this at length when
> discussing the next two drafts.

Would you be more specific on those doubts so that we can discuss them here?
Basically, the whole section is to outline the handle system security
service, and the paragraph (para 3) outlines how service integrity and
client authentication are carried out. It is stated in the protocol draft
that each local handle service (hosted by individual organization) can add
additional local policy regarding access control. However, how it is done is
to be decided by each individual deployment. We expect that to be something
conforming to KeyNote (also called PolicyMaker earlier). Are you suggesting
that we should point that out here? Also, I'm not understanding the
political issues here, could you elaborate?

It might be worth noting that handle system security is only to address the
transport security, i.e. the secure data transport between the handle system
client and server. It does leave the hook for checking out content
credentials, but that's for applications to take advantage of. The handle
system is not a PKI framework by itself, but we think applications can be
built on top of it to make PKI deployment easier.


> 4) Section 4, para 5, should discuss the assets to be protected (e.g.
> handle metadata), the risks to those assets (e.g. corruption of handle
> metadata), and the sources of threats (e.g. hackers seeking fame or
> criminals seeking fortune).  I believe the sentence "To trust a Local
> Handle Service means to trust that it will correctly respond with data
that
> was entered by the administrator" is a too general to be useful.
>

What I will do is to make a separate section to address "security
considerations" as you mentioned earlier, and add these into it. Could you
help coming up with the words? I will rephrase the sentence "to trust a ..."
to make it more specific.


> 5) The document needs a security section and should follow the other
> guidelines for formatting and mandatory sections of RFC 2223.
>

Section 4 was intended to cover this. I will make a separate section to
address this specifically.


Thanks,
Sam