On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst" <[email protected]> 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.
I think that 'some' structure would be useful. I don't see that keeping the Base64 character scheme needs to be a priority. There have been plenty of alternatives that don't use a slash as one of the two extra chars. >> 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. That was Stephen, not me. I was also somewhat surprised by the tripple slash. It is the sort of thing that could break assumptions. One of the things I was thinking about was that for our case the essence of the digest is really the digest part. The domain is really just a location hint. Why stick at just one domain? If the same content is present at foo.com and bar.com why not have an identifier that can specify both: dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain Now I know that we do not need this for our particular application, but if we are going to come up with a common scheme with DECADE we have to meet their use cases as well as out own. I have some other ideas that would be interesting in the DECADE context. Right back in 1995 Rohit Khare and myself were fooling about with identifiers that had decryption keys built in. For their particular application, the ability to send a single identifier that allows the content to be uniquely identified, authenticated and located would be quite interesting I think. Adding a symmetric decryption key means that the set of people who can read the plaintext is precisely the set of people with access to the plaintext plus the people who can access the identifier. The host on which confidential content resides is thus moved outside the zone where security concerns apply. >>> I note that you have a content type, which I have but someone here was >>> objecting to. I consider the content type to be essential meta-data >>> for obvious security reasons. > > I don't think Paul Hoffman, who brought this up, was objecting. He just > wanted to know what it's good for. Some security reasons may be obvious for > you, but not for everybody :-). Since we already had this discussion at great length in another place I think that he just does not understand the security issue and never will. >> Our use-case for that is for cases where the named object actually >> arrives in some wrapped form (e.g. encrypted) and you need to know >> the "inner" content type. However, I could see it being used otherwise >> or being dropped as things progress. > > Just curious: Why would you need to know the inner content type? Wouldn't > the wrapper contain that information? Probably so that they can perform negotiation. If the consumer is a video player, it wants to be able to select content that it knows how to play. In most cases the player will be grabbing the bits and negotiating the decryption capability in parallel. In my case the concern is that it should be possible to use the generalized form of this identifier as a secure URL for referencing static content from a secure Web page. So imagine that we have anybank.com that has its main pages on HTTPS but has the images etc. on a separate server that really does not need SSL for any purpose other than authenticating the source. It would be a trivial matter to write a script that could transform such Web pages into Web pages with 'hardened' URLs of the digest form being discussed here. This would in turn provide a long term answer to the problem of efficiently supporting the strict security concerns we discuss here without the overhead of SSL everywhere. The only problem with that being that the content-type is actually a security sensitive piece of meta-data and manipulation of content-types is a major attack vector (probably the fastest growing at the mo). -- Website: http://hallambaker.com/ _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
