Subject: Re: [websec] Digest URI scheme

From: Tobias Gondrom <[email-masked]>
Date: Sun, 02 Oct 2011 23:25:21 +0100

Hi guys,
a big +1 for the "do it once". ;-)

Whether DECADE or WEBSEC - think that is something we can sort out in 
Taipei or shortly afterwards.

As we already have several ideas on that, it seems interesting enough to 
discuss at the websec meeting in Taipei? Any volunteers for a short 
presentation/discussion slot on this bit?
(if yes, please drop a quick email to Alexey, Yoav and me so we can 
adjust the agenda...)

Kind regards, Tobias

On 30/09/11 15:40, [email-masked] wrote:
> Hiya,
>
>> Come to think of it, didn't you send this to us when we first proposed
>> the ODI thing in CAA v1.0?
> Could be. When my little brain sees a good idea, it tends to repeat
> it:-)
>
>> I really don't care about the specifics of the design half so much as
>> we end up with having one, not three.
> Strongly agree. I think a URI for naming things with digests should
> have broad applicability.
>
>> 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.
> 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...
>
>> Clearly, your scheme is a better way to reference external content in
>> a resolvable format. I have to go look at the URN and URI specs again
>> in detail.
> I also thought about URNs but was told (by PSA I think) that those
> are intended for managed name spaces and not things like this.
>
>> 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.
> 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.
>
>> You want to share your design issue here or should we go offline, rev
>> the proposal and come back?
> I'm not bothered by where or how we progress this, so long as we do
> the right thing and do it once:-)
>
> I need to check with co-authors about what DECADE want, but this I-D
> could be worked there or here in WEBSEC. I'm very happy to have more
> help as well if it gets us closer to doing this once only.
>
> FWIW, we're part of a project that is coding this up, and will
> almost certainly release a library with a reasonable license in a
> few months.
>
> Cheers,
> S.
>
>> On Thu, Sep 29, 2011 at 6:00 PM,<[email-masked]>  wrote:
>>> <no hats>
>>>
>>> I agree with the motivation but not the design. A while ago
>>> I posted my idea for a design for this. [1] It may become a
>>> work item for the DECADE WG, ... or not, we'll see.
>>>
>>> S.
>>>
>>> [1] http://tools.ietf.org/html/draft-farrell-ni-00
>>>
>>>
>>>> As I mentioned previously, the need to refer to a static data object
>>>> by means of a digest comes up frequently. Rather than re-invent the
>>>> mechanism for creating a reference each time we need one, it would be
>>>> better if we had a single format that could be re-used.
>>>>
>>>> We used to have this back in the days when we trusted MD5 since we
>>>> used that everywhere as a 'fingerprint'. Then things got muddy after
>>>> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
>>>> will be very muddy.
>>>>
>>>> This would be relevant to the cert pinning debate.
>>>>
>>>>
>>>> I wrote a draft making the proposal:
>>>>
>>>> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt
>>>>
>>>>
>>>> On the digest front the objective would be to make it possible to use
>>>> the URI format with any digest at all in theory but strongly encourage
>>>> people to only use the digests IETF is confident in. Use of OIDs as
>>>> the identifier has the nice property that anyone can get an identifier
>>>> to distinguish their algorithm from other people's but getting an OID
>>>> does not produce any paper trail that can be used to imply an IETF
>>>> endorsement.
>>>>
>>>> We could add in support for the text based identifiers as well, but
>>>> since the only identifiers that I would want to encourage are SHA2 and
>>>> SHA3, I don't see a need. For all applications that make sense it is
>>>> going to be perfectly OK to simply generate the prefix for the
>>>> identifier part as a static array of octets and append / verify it as
>>>> such whenever it is needed. I do not see any need to write ASN.1
>>>> handling code for these apps :-)
>>>>
>>>>
>>>> The basic idea here is that we need to allow for algorithm agility and
>>>> to prevent a content substitution attack. So imagine that we have web
>>>> page A linking to some off site static content via a digest. Site A
>>>> regards the static content as a PNG and has checked out the page and
>>>> it works fine. What they don't know is that buried in the PNG there is
>>>> some malicious Jscript and if the content server delivers it as
>>>> application/script the result will be a series of syntax errors (that
>>>> are silently ignored because the app is stupid)  and then it finds the
>>>> malicious code... ooops.
>>>>
>>>> OK, so maybe not an attack that you find to be a worry in every
>>>> circumstance, but it is definitely an attack vector we should address
>>>> in a general purpose crypto building block.
>>>>
>>>>
>>>> Having produced a static building block like this it is very easy to
>>>> generate a fingerprint for a static data object in a cut and paste
>>>> ready format. I don't need a separate tool to generate digest
>>>> identifiers for WebSec vs other applications. In terms of ease of use
>>>> we get back to what things were like when we used MD5 fingerprints.
>>>>
>>>> It is also quite easy to make use of truncated fingerprints should
>>>> that be necessary. For example, to put on a business card.
>>>>
>>>> --
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> websec mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/websec
>>>>
>>>
>>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 03 Oct 2011 16:29:21 +0900

On 2011/09/30 23:40, [email-masked] answered Phillip 

>> 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.

> 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.

> are intended for managed name spaces and not things like this.

This recently came up on the urn mailing list. Please e.g. see
http://www.ietf.org/mail-archive/web/urn/current/msg01616.html.

>> 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 :-).

> 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?

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 03 Oct 2011 16:47:44 +0900

On 2011/09/30 1:33, Phillip Hallam-Baker wrote:

> OK, I will rev the draft to make it text identifiers.

Great!

> I will also check up on the uri syntax issues. Base64 uses two non
> ascii characters and these need to be checked for legality.

These are '+' and '/'. As for '+', this is a sub-delim in RFC 3986, but 
I don't see any problem in using it, unless you create a query-part 
syntax and expect users to enter it in HTML forms (In which case you 
would get hit by the space->'+' conversion).

The '/' is somewhat different, because it's heavily involved in 
resolution of relative references,... But even there, I don't see a 
problem if we never have a '/' (or worse, two or more) after the initial 
colon. And relative references won't make sense for digests anyway, as 
far as I understand.

> We might also reduce the length of the scheme name maybe? digest is 6
> chars, do we need them all?

The shortest you could go is just one character, 'd'. But frankly, I 
don't understand why we need to be short and opaque. This would be 
another thing if the term we started was 10 or 20 characters long.

> I would also like to see if we can ditch
> the urn: prefix legally, it was bogus from the start, names and
> locators are not disjoint categories.

Just go ahead and ditch it.

Regards,    Martin.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 03 Oct 2011 10:46:49 +0200

On 2011-10-03 09:29, "Martin J. Dürst" 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.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 09:30:18 -0400

On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst"
<[email-masked]> wrote:
> 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.

> 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.

> 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.

> 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).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 10:13:07 -0400

> 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.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Oct 2011 08:00:55 -0700

On Oct 3, 2011, at 1:46 AM, Julian Reschke 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's silly for this case. The proposed URL scheme has no hierarchy scheme, nor is it even resolvable because there is no host. I know Phill has already responded that he intends to use an encoding that changes Base64 for the reason you give; I believe that will lead to likely lack of interop due to complexity.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 12:22:24 -0400

> That's silly for this case. The proposed URL scheme has no hierarchy scheme, nor is it even resolvable because there is no host. I know Phill has already responded that he intends to use an encodin…

Complexity, shmexity. We have a case where Julian has pointed out that
failing to properly address these cases will lead to interop failures.
I don't see how using the URI-safe encoding in a URI is more complex
than using the one we already know to be broken.

URLs are used in cases where hierarchy is assumed. Thus there is code
to attempt to apply relative naming to identifiers that are put in URI
slots. Julian is completely right on this.

This is a known issue and the IETF already has a standards based fix for it.

There is a fine line between simple and simplistic. Using the +/
encoding would be simplistic and definitely not simple.

Interop issues due to incompetent programmers not reading the spec
will on average be detected in (64/2) / ((4/3)*(256/8))  trials, that
is 0.75. We can even choose test vectors that ensure that these issues
are exposed.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Oct 2011 10:05:51 -0700

On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote:

> URLs are used in cases where hierarchy is assumed.

I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 13:12:02 -0400

> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal.

As Julian correctly pointed out, a generic URI will be used in
situations where the application will (correctly) assume that anything
in URI syntax that has a slash character in it will be hierarchical.

Thus a URI scheme that does not intend to indicate hierarchy MUST NOT
include a slash character in that part of the identifier.

Plus it is essential to ensure that anything that is to fit in a URI
slot is compatible with code for making entries URI-safe. A URI that
contains a + character is likely to end up being mangled.

This issue has already been litigated in the IETF and the result of
that consensus was RFC 4648. I see no reason to re-open that
discussion in case someone does not bother to test their code.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Oct 2011 10:23:53 -0700

> in URI syntax that has a slash character in it will be hierarchical.

Did Julian say that? The one thing that I saw him say was "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."

I don't see how the digest URL you propose has either "relative references" nor "resolved". More detail in your next draft would be valuable.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 13:30:48 -0400

>From RFC 4395:

2.2.  Syntactic Compatibility

   RFC 3986 [5] defines the generic syntax for all URI schemes, along
   with the syntax of common URI components that are used by many URI
   schemes to define hierarchical identifiers.  All URI scheme
   specifications MUST define their own syntax such that all strings
   matching their scheme-specific syntax will also match the
   <absolute-URI> grammar described in Section 4.3 of RFC 3986.

   New URI schemes SHOULD reuse the common URI components of RFC 3986
   for the definition of hierarchical naming schemes.  However, if there
   is a strong reason for a URI scheme not to use the hierarchical
   syntax, then the new scheme definition SHOULD follow the syntax of
   previously registered schemes.

   URI schemes that are not intended for use with relative URIs SHOULD
   avoid use of the forward slash "/" character, which is used for
   hierarchical delimiters, and the complete path segments "." and ".."
   (dot-segments).

Question closed in my view.

I don't see any point in responding to further comments that simply
repeat the original statement. There is a clear requirement that URI
schemes are required to meet stated in the URI standards documents.

The rules were developed from long experience and are designed to
encourage interoperability. I don't see any reason to second guess
that reasoning on the basis of the vague and unsubstantiated concerns
you have raised.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 03 Oct 2011 19:36:43 +0200

* Paul Hoffman wrote:
>I don't see how the digest URL you propose has either "relative
>references" nor "resolved". More detail in your next draft would be
>valuable.

Resolving a relative reference with respect to a base reference is some-
thing you can do regardless of the scheme. Scheme definitions don't need
to discuss relative references at all, there are always relative forms,
and anything that can be said about them is already defined in RFC 3986.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 03 Oct 2011 19:42:14 +0200

>I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet:

How about Base 16 instead? Like we use it for checksums everywhere else?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 13:50:20 -0400

That adds significantly to the size of the identifiers.

For my application the amount of space that is available to transport
the identifiers will be constrained. Thus if X bytes permits 100 sites
to be secured using a base64 encoding, use of base16 will drop that to
60 or so.

There is already an IETF specification and precedent that covers this issue.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 04 Oct 2011 01:17:08 +0200

>to be secured using a base64 encoding, use of base16 will drop that to

So? Maybe for my application I want people to easily compare the URI
with the output from GNU sha256sum which does not have an option for
your particular Base 64 dialect, and maybe you should use Base 256
without a "digest:" prefix if size is so important?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 19:23:36 -0400

I have implemented Base64 from scratch many times. It takes about 30
lines. If that is too hard it is easy enough to swap the characters
over.

Base 256 would use a whole rack of characters that are illegal in URIs.

Isn't the alleged point of free software that it is easy to add in features?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 04 Oct 2011 01:49:22 +0200

>Isn't the alleged point of free software that it is easy to add in features?

You started this thread saying "it would be better if we had a single
format". How about you abandon this idea, you call your scheme "d64:"
to keep things concise, and the rest of us develop our own format?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 20:03:46 -0400

> to keep things concise, and the rest of us develop our own format?

Implicit in the idea of a single format is the notion that at least
some people will write code for it.

Compatibility with unix command line tools would rank really low in my
list of priorities if at all. They are easily written and easily added
to. That is the whole point of them.

I was planning to write a command line tool for supporting the format
anyway. There seems to be no man page entry for di.

How about something like:

di [-d <algorithm>] [-e <algorithm>] [-http domain]* input output

If someone wants to compare with a dumb string comparison they need do
the necessary case conversions and chop off the parameters part since
that is not canonical.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 04 Oct 2011 10:07:04 +0900

On 2011/10/03 23:13, Phillip Hallam-Baker wrote:
> On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke<[email-masked]>  wrote:

> 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).

> http://tools.ietf.org/html/rfc4648#page-7

Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a 
better pointer.

> 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.

> If people need a locator then it would be formed from a tag/value pair

Can you explain why we need a domain name as a locator? Wouldn't

tag = "uri"
value = URI

be much more general?

> 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.

> For certain applications the full 256 bits of the content URL are unnecessary.

Which 256 bits exactly?

> 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.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 04 Oct 2011 10:29:28 +0900

> dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain

The example here is a bit more explicit (and doesn't use 'http' as a tag 
name), so I'm asking again:

Why isn't this something like:

dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=http://foo.com/path/to/content.ext&loc=http://bar.com/path/to/content.ext&ct=text/plain

(the slashes here should be %-encoded, but I left them as is for easy 
readability)

> where security concerns apply.

I think I get the idea, but wouldn't that be quite similar to URIs 
including passwords? That has been widely frowned upon since quite some 
time, to the extent that it has been kicked out from the generic URI 
syntax (although it can be quite convenient on occasion).

> grabbing the bits and negotiating the decryption capability in

Ok. I was assuming that the 'outer' content is what's hashed, but it 
looks like the outer wrapping (compression or so) is only used on 
transport, and it's the 'inner' content that's hashed. Then that makes 
sense (using a digest of the outer content but having the content type 
apply to the inner content would be quite weird in my opinion).

> discuss here without the overhead of SSL everywhere.

So e.g. the Anybank logo is not a secret, so it can go over HTTP in the 
open, and we don't care about where it comes from (even from a bad guy) 
as long as it's the same logo, which we can check with the digest.

> content-types is a major attack vector (probably the fastest growing

So, just as a totally hypothetical example, the attacker sends exactly 
the same bits, but claims they are image/png instead of image/jpg, and 
the user sees something different (e.g. an 'okay' button instead of a 
'cancel' button).

For these cases of faking metadata, wouldn't it be better to have some 
general way of making the metadata part of the content that is hashed?

Regards,    Martin.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 21:51:21 -0400

> Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a

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.

> 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.

> 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.

> 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)

> 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.

> So it would be possible to use all the URI scheme names as tag names? Like

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

Sorry the content digest.

> 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.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Oct 2011 09:39:45 +0200

On 2011-10-03 19:12, Phillip Hallam-Baker wrote:
> On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman<[email-masked]>  wrote:

I wouldn't say "MUST NOT". It's just it's a source of confusion that can 
be avoided when defining new URI schemes.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 08:20:45 -0400

On Tue, Oct 4, 2011 at 3:39 AM, Julian Reschke <[email-masked]> wrote:
> I wouldn't say "MUST NOT". It's just it's a source of confusion that can be
> avoided when defining new URI schemes.

Ack,

In private conversation someone just pointed out that the data: uri
scheme has a semicolon that turns out to be necessary because parsers
make unjustified assumptions.

There is a SHOULD NOT in the URI spec and I think the onus is on folk
to demonstrate that base64url would cause actual problems.

The base64url scheme is used by Facebook so there is a huge amount of
existing code that can manage the format.

There is a page of implementations:

https://github.com/ptarjan/base64url

Using the base64url encoding makes use of an Apache server on UNIX
much easier since the di digest can be used as the filename. I can't
see that any of the purported conveniences of base64 outweigh that.

Base16 means longer identifiers and introduces a case sensitivity issue.