[mdx] Joe on 3.1.1

[Ian Young]

Joe:

> -- 3.1.1, Transforms: are the identifiers case sensitive? That is,
>   'md5' is mentioned as is 'sha1' -- is that equivalent to 
>   'mD5' and 'Md5' and 'MD5', for example?

I think the current wording implies that the defined indicators are lower case, because they are only included there as literals:

> Responders MUST support the MD5 (transformation indicator 'md5') and
> SHA-1 (transformation indicator 'sha1')


There was some discussion on whether this was desirable.  Leif wanted case-insensitivity, for robustness, but Scott disagreed:

> I'd prefer not. URLs are case sensitive, and I'd rather not introduce
> folding requirements.

My remarks: I side with Scott on this one and unless Leif has strong feelings I think we'll take that as it stands.

I'll accept suggestions as to whether that should be further clarified and if so how.

I would also note that having the spec say that the spec-defined indicators MUST be accepted as literally 'md5' and 'sha1' does not preclude an implementation providing additional indicators with the same meaning, for example by case folding.

>   As a wanna-be crypto guy, I also have some concern about 
>   a newish spec specifying deprecated hashes (e.g., MD5 should
>   really not be re the required "lowest common denominator"
>   required transform for this or any other purpose)

Scott (and this was also my position):

> We're not using the hashes for security here, so I doubt there's much
> concern.

Leif:

> Not sure I agree - we're using hashes to lookup security-critical
> objects. We need to be sure of this if we decide to keep md5

My remarks:

I think at the very least that if we're going to make use of anything that people normally think of as cryptographic primitives, we need to include something in our Security Considerations section to say what the implications are, even if we think it's not a problem. If someone wanted to volunteer some text here as a starter, that would be helpful.

The other observation I'd make is that there's no justification in the present text for making two transformation indicators MTI. I guess one might have a very small performance benefit over the other, but if there is no security implication then why wouldn't every client just pick the shorter/faster one?  Likewise if there is no visible performance benefit but a security consideration why wouldn't every client just pick the more secure one?

I'd also like to raise a specific *disadvantage* of having two MTI algorithms, which is that it means that a system which caches results (whether in the conventional sense or just by pre-computing signed documents and stashing them in files called md5-f3678248a29ab8e8e5b1b00bee4060e0.xml) has to construct two indices, or alias one set of keys to the other.

Without some guidance as to how to pick which of the two MTI algorithms, I propose that we should in fact just pick one algorithm. Please comment on this idea, along with which algorithm you think we should pick if you think we should pick just one.

If we were picking just one, of course, there's no rule that says that we'd have to pick either MD5 or SHA-1. If we thought that there was a potential security issue being surfaced, we could also just pick SHA-256.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20130926/08bb88be/smime-0001.p7s>