- From: David I. Lehn <dil@lehn.org>
- Date: Fri, 11 Apr 2014 11:27:46 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Web Payments <public-webpayments@w3.org>
On Sat, Apr 5, 2014 at 3:34 PM, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > According to the security vocab the range of a nonce is set to xsd : String > > https://web-payments.org/vocabs/security#nonce > > However wikipedia describes a nonce as a number, and we certainly use it > that way in bitcoin > > http://en.wikipedia.org/wiki/Cryptographic_nonce > > Would it make sense to remove this constraint from the range of Nonce? Wikipedia itself is inconsistent, and probably not a good authoritative source for definitions. Their "Nonce" page that refers to the above page has a more flexible definition: "Cryptographic nonce, a number or bit string used only once, in security engineering". And they link to a Salt page that says "random data", and link to RFC 2617 that defines a nonce param as a quoted-string. https://en.wikipedia.org/wiki/Nonce https://en.wikipedia.org/wiki/Salt_(cryptography) https://tools.ietf.org/html/rfc2617 In this case, it is defined as a string because that's how we are using the property for signatures. I don't think we actually define how we make signatures anywhere, which obviously must be done at some point. It's just in code right now. We'll need to be explicit about how the nonce parameter is used. The xsd:string type is a sequence of unicode characters but we need to be explicit on how we encode that into bytes for use during the signing process. Ie, that we use the bytes of the UTF-8 encoding of the nonce or whatever is appropriate. http://www.w3.org/TR/xmlschema-2/#string http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-character If the nonce were declared as a number type of some sort, we'd also need to be explicit about how that is converted into bytes used for signing. For instance, the HTTP Signature Nonce spec, for reasons I don't remember, is saying the nonce param is base 10 representation of a 32 bit unsigned integer. This should maybe better reflect RFC 2617 or similar nonce definitions and usage. https://web-payments.org/specs/source/http-signature-nonces/ And just to make sure we are all over the map on this topic, the Secure Messaging spec says a nonce is a string with a suggested format including a random string. https://web-payments.org/specs/source/secure-messaging/#message-signature-algorithm So the best answer here is "it's a complicated work in progress". Conceptually, a nonce can be any bit string. In our algorithms we'll likely need to specify how to encode the param into a byte string. We could also accept numbers but they would probably need to be limited to a certain bit width and we would still need to specify how to encode them to byte sequences for use with signatures. A more full featured spec using strings seems to be the best choice as far as security and flexibility goes. -dave
Received on Friday, 11 April 2014 15:28:15 UTC