Message-Id: <199409291654.KAA00857@idaknow.acl.lanl.gov>
To: "Daniel W. Connolly" <connolly@hal.com>
Subject: Re: URC usage scenarios
In-Reply-To: Your message of "Wed, 28 Sep 94 18:10:01 CDT."
<9409282310.AA04630@ulua.hal.com>
Date: Thu, 29 Sep 94 10:54:30 -0600
From: rdaniel@acl.lanl.gov
> OK. So we agree. I think this brings out a new requirement:
>
> From a URN, we must be able to determine the name
> of a principal in an authentication framework.
Yes, I think so. This seems to be a requirement on URNs more than on
URCs. Larry and Karen - care to comment about jamming it into the URN
requirements?
> > URC.0 {
> > URN: IANA:senate.gov:voting_records/1994/joebob
> > Location {
> > URL: http://www.senate.gov/voting_records/1994/joebob.txt
> > Signature.RSA: sdlkfjopivoverdfdhefhwofhwpofhwpfhwefh
> > }
> > Signature.RSA: jfwe423njcvdihw4nsdciouh24njwdouiekjlfd98u023rj
> > }
>
> It's still not clear to me: what do the signatures certify?
> The "jfwe..." signature can't certify the whole URC: you'd have
> to (1) write down the URC, (2) compute the MD5 checksum, and (3)
> encrypt it with the secret key, and (4) stick the signature back
> in the URC. Step 4 would invalidate the signature.
Yes and no. A signature can't be over itself. However, when you sign
mail messages, the signature is not considered part of the mail message,
even though they all come bundled together. All we need is a means for
breaking out Signatures from the top level scope of the URC. Signatures
of the URC are computed over everything except Signatures of the URC.
Perhaps the syntax of the URC should be changed to be of the form:
URC.version {
elements
}
signatures
I will have a better handle on that as I implement the parser for the
URC structure.
> And what does the "sdlk" signature certify? I suggest that
> it should certify:
>
> "P says B represents N from t0 to t1"
> where P is the certifying principal,
> B is the body of data (actually its MD5 digest)
> (t0, t1) is the lifetime of the certificate.
...
> Before you sign something, you have to write it down as a very precise
> sequence of bytes so that the verifier can take that sequence of bytes
> and compute its MD5 checksum.
>
> So the syntax of these URC's must be decided before folks can start
> signing them.
Right. One of the new requirements for URCs is a "consistent external
representation" and it is motivated by just this need. (It should also
make parsing easier).
As for the specific proposal of ((P, N, F, c, t0, t1), S), this is reasonable.
I just think that it goes into a URC service specification, not the
URC requirements.
> I'd rather not have folks sign URCs. They'll change too much, I
> think.
I disagree and will tell you why in a minute.
> I'd rather have them certify that the data itself is an
> accurate representation of the named resource.
This is necessary for both users and providers. It may even be sufficent
for users. I don't think it is sufficent for providers.
> Hmm... on the other hand, if a URC contains an abstract, you might
> want to be sure the abstract is authentic.
This is one example of a USER wanting to make sure the URC info is
authentic. PROVIDERS will also want to make sure the URC info is authentic,
especially once people start paying for resources with digital cash.
Consider this scenario - A net.pirate sees that the new Tom Clancey
novel is just coming out for network publication. The pirate grabs a
copy and puts it on a http server. The pirate then starts the standard
denial-of-service attack on one of the URC servers for the publisher.
When they can, they send back a URC that has the real publisher's Location
and payment information changed so people pay the pirate and not the
publisher. This attack will only succeed 1% of the time. I don't know
about you, but I wouldn't mind having 1% of gross sales of Tom Clancey's
novels. That's probably a lot better deal than he gets.
If the URC is signed with the private key of the publisher, the consumer
can detect that the URC has been modified. They won't know how, but they
will know it has happened. Most browsers will (at least) warn people that
it is not a good idea to spend money on the basis of a known-bogus URC.
> Hmmm... an RSA signature is fundamentally different from MD5, DSS, and
> gnu-cksum, in that it includes a secret.
To be retentive, DSS is very much like RSA. SHS is the one
that is like MD-5.
But yes, you are right that RSA is fundamentally different than MD-5
or some other things. If a person could modify a URC, MD-5 or gnu-cksum or
other things provide no additional security. RSA and DSS do. However,
this additional security comes at a cost. There is the computational cost
of the public key algorithms. They are slow enough to be noticable if
they were always inserted in the course of normal browsing. Second, there
is the cost of the public-key retrieval. This will certainly take time,
and it may actually cost money to get a public key. It will almost
certainly cost money to put your public key out using one of the upcoming
commercial infrastructures.
Some resources do not justify these costs. I might provide several signatures
for a resource. One might be a quick and easy thing to check, another might
utilize public-key crypto for the maximum in security.
> > However, I think that is too detailed
> > for the scenarios document.
>
> IMHO, nothing is too detailed for the scenarios document. The more
> concrete you make it, the more clear things become, and the more
> issues you flesh out. The whole point of the scenarios document is to
> walk through the process step by step and examine the interactions and
> make sure all the right info gets to all the right places.
I think it all gets down to the intended use of the scenarios. These are
intended to illustrate how the system might be used and to obtain requirements
that any detailed proposal must satisfy. I am trying to set forth these
abstract requirements without pre-empting possible implementations. For
instance, I have answered some questions by showing a sample URC, using
the syntax that I am developing. This is not the syntax that Michael
Mealling favors. He would certainly cry "foul" if this syntax became a
requirement before we had a bake-off to compare the alternatives.
This is a pretty clear example of specifying too much too soon. Other places
the line is not so clear. I will expand on the verification scenarios, and
try to emphasize that the scenarios are descriptive not prescriptive. If
someone feels their ox is gored by the requirements that end up being
derived from the scenarios, let me know. We will be mailing the draft to
the list before submitting it as an I-D.
Ron