- From: Steve Harris <steve.harris@garlik.com>
- Date: Fri, 30 Sep 2011 11:18:45 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg@w3.org
On 2011-09-29, at 17:30, Andy Seaborne wrote: > >>> Proposal 5: >>> MD5 >>> SHA1 >>> SHA256 >>> SHA512 >>> SHA384 >>> SHA512 >>> >>> (i.e. remove SHA224, but that's the problmeatic one for the commenter >>> (Jeen) because it's not in the core Java runtime). >> >> You also include SHA512 twice, making the list look longer! :-) > > Two independent implementations, just to be sure. > >> Also, I was advised against including MD5 -- as the earlier xmldsig >> advises -- because of known security problems with it. I guess the >> theory is that it's important to steer people away from technology that >> looks secure but isn't. (The counter-argument is that some people >> still use it. But maybe should let that be entirely on them.) > > Yes - it's not recommended for weak for SSL certificates or digital signatures (hence xmldsig). > > MD5 has it's place as for error-checking: > > http://en.wikipedia.org/wiki/MD5#Applications Yes, agreed, and it's still widely used. We also use it to create persistent, but non-human readable URIs where security isn't an issue, SHA1 is significantly longer. We do it in the application layer, but you could do it in SPARQL 1.1: URI(CONCAT("http://garlik.com/id/", MD5(CONCAT(?email, " ", ?date)))) or similar Come to think of it, a UUID() function might be useful too, but that can wait for SPARQL 1.2 :) - Steve -- Steve Harris, CTO, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Friday, 30 September 2011 10:19:22 UTC