On Mon, Oct 3, 2011 at 9:07 PM, "Martin J. Dürst" <[email protected]> wrote: > On 2011/10/03 23:13, Phillip Hallam-Baker wrote:
>> I suggest that we use Base 64 Encoding with URL and Filename Safe >> Alphabet: >> >> http://tools.ietf.org/html/rfc4648#page-7 > > Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a > better pointer. The other name for this scheme is 'filesafe'. While it is not particularly relevant to our current use cases, the ability to convert the stem portion of the URI into a filename directly is going to be very useful for DECADE and for many other purposes. >> This would mean using the characters - and _ for char codes 63 and 64 >> and dropping the padding completely. > > Yes. I wish RFC 4648 would say this upfront, and move the reasons why other > characters such as '.' and '~' were not chosen later. And the character > numbers, in RFC 4648 terminology, are the 62:nd and 63:rd character. Yes, that is right. >> I am strongly tending towards: >> >> "digest:" algorithm ':' base64(content) ['?' tag '=' value [ '&' tag >> '=' value]* ] >> >> Where: >> >> algorithm - is from the IANA registry discussed earlier >> base64 - is the RFC 4648 file and url safe version >> content is the referenced content >> tag is taken from the URL encoding precedent >> value is taken from the URL encoding precedent >> >> >> If people need a locator then it would be formed from a tag/value pair >> as follows: >> >> tag = "http" >> value = domain name > > Can you explain why we need a domain name as a locator? Wouldn't We don't need it, but the DECADE folk need to have it in somewhere. There are two basic options: 1) Use the authority slot. This results in a URL with the form ni:///alg/digest 2) Use a parameter on the query slot. The advantage of 1 is mostly familiarity. The disadvantage is that it suggests that the 'authority' controlling the interpretation of the name is the domain and the whole point of the digest schemes is that the place you get the bits from becomes irrelevant. The advantage of 2 is that there can be multiple locators. I think we need comments from the DECADE folk on that to know what to do. > tag = "uri" > value = URI > > be much more general? Actually this is actually a very useful case that is worth calling out separately. Again this is something that I had thought about but not put in the draft because I did not want to add in functionality that went too far beyond what DECADE and WEBSEC might require. Larry Masinter suggested a URI scheme that was something like this but focused on just that use case. This creates a URI whose semantics are roughly speaking 'content retrieved from the URI=foo. It would be best paired with a date parameter. This does not remove the need for the locator however. For example, let us say that you want to create a link to the text of rfc 822 which you have retrieved on a particular date and pickled somewhere. The digest URI might look something like: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? http=di.example.com&uri=http://www.ietf.org/rfc/rfc822.txt&date=2011-10-3:21:00 This being a strong reference to the content that was downloaded from the uri specified on the date specified and a hint that it can be found in the specified content registry(s) >> The corresponding url would be formed as: >> >> "http://"; + domain-name + "/.well-known/digest/" + algorithm + "/" + >> base64(content) >> >> This can then be transformed inside the Web Server as is necessary to >> support the constraints of the local file system. > > Sorry, but I'm much more an URI expert than a security expert. Can you > explain what all that is about? What would be at that location? Why all this > hard-coded stuff? The alternative would be to bloat the identifier used as the reference in documents and protocols with a second set of information to allow it to be retrieved from the specified repositories. > >> Other protocol tags can be specified to support alternative protocols. > > So it would be possible to use all the URI scheme names as tag names? Like > tag = "https" > tag = "ftp" No, not unless there was an explicit mapping defined for that protocol. Now clearly, if an 'ftp' parameter tag was defined it should only be for something involving ftp as the transport. But there would have to be a document to specify the protocol mapping. >> For certain applications the full 256 bits of the content URL are >> unnecessary. > > Which 256 bits exactly? Sorry the content digest. >> The collision resistant digest identifier for the content is then formed >> as: >> >> digest + E ( digest, key ) >> >> "Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q", >> "491X0pTnLkJHFN_AVctJUA") >> >> The result is an identifier of 256 bits that has 128 bits worth of >> authentication security, 128 bits worth of confidentiality security >> and 128 bits worth of birthday attack collision resistance. >> >> >> For the current WebSec use cases, only the digest is actually >> required. I am not entirely convinced, but I suspect that for our use >> cases the truncated identifier would be sufficient since we rely only >> on the 2nd preimage resistance property. > > If that kind of security magic works, then it's great if we can express it > in the URI. I think it should work. There are some corner issues to deal with like where to stick the IV (it can be prepended to the cipherstream). I have a rough cut in the draft. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
