On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke <[email protected]> wrote: > On 2011-10-03 09:29, "Martin J. Dürst" wrote: >> >> On 2011/09/30 23:40, [email protected] answered Phillip >> Hallam-Baker: >> >>>> Only real issue for me is that it has to fit in URI type slots. The >>>> scheme I was thinking of would be a pure URN scheme, your proposal >>>> includes URL like things. >> >> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at >> all; in RFC 3986, I think slashes would even be allowed if they don't >> appear directly after the first ':'), then you can define an URI scheme >> without including host-like stuff and you don't have to use "urn:" as a >> prefix. >> >>> Yep. We have use-cases for that. Note though that the authority >>> part is optional, so a fairly bare digest is quite possible and >>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... >> >> The triple slash at the beginning is a bad idea. There should only be >> slashes if the scheme conforms to the generic syntax (i.e. a double >> slash, something like a host name, and then slashes for something >> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. > >> ... > > Also keep in mind that if you use "/" for a different purpose than > hierarchy, surprising things will happen when relative references are > resolved. It's good to avoid them in this case.
That is probably the killer argument here. I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet: http://tools.ietf.org/html/rfc4648#page-7 This would mean using the characters - and _ for char codes 63 and 64 and dropping the padding completely. There is a great summary table here that folk can choose from http://en.wikipedia.org/wiki/Base64 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 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. Other protocol tags can be specified to support alternative protocols. Stephen's DECADE application then becomes a special case of the general form of the identifier. It is essentially a different lookup protocol. Some additional tweakage: For certain applications the full 256 bits of the content URL are unnecessary. If an encryption key is in use then the encryption key can be used to form part of the identifier for the purpose of distinguishing identifiers. For example: let the plaintext be p and the encryption key be k. The identifier might be digest:sha-2-128:Ry_yKcfFmWj4cs9ucvm10Q?enc=aes&key=491X0pTnLkJHFN_AVctJUA Where sha-2-128 is SHA256 truncated to 128 bits as per NIST instructions. 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. -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
