Re: [websec] Digest URI scheme

[[e-mail]]

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,  <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/websec
>>>
>>
>>
>>
>
>
>
> --
> Website: http://hallambaker.com/
>