On 2011/10/03 23:13, Phillip Hallam-Baker wrote:
On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke<[email protected]> wrote:
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.
It's not a killer argument, because these URIs aren't going to be used
in a relative form (except potentially leaving out the scheme, which is
irrelevant), and aren't going to be used as base URIs (same irrelevant
exception again). Paul is actually right on that one.
But it's okay to stay on the safe side, and to comply with a SHOULD in
RFC 3986.
However, there's no reason for shouting about this on either side, or
for coming up with MUSTs where there are none (only SHOULDs).
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.
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.
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
tag = "uri"
value = URI
be much more general?
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?
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"
...
Then we'd get collisions between URI schemes and other tag uses.
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.
Which 256 bits exactly?
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.
If that kind of security magic works, then it's great if we can express
it in the URI.
Regards, Martin.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
