- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 11 Apr 2014 18:25:33 +0200
- To: "David I. Lehn" <dil@lehn.org>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYhKDcpj-pOwX9Vn8b7sxyOi4ei5fWJVdukFN1NYOJ32W7g@mail.gmail.com>
On 11 April 2014 17:27, David I. Lehn <dil@lehn.org> wrote: > 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. > Thanks for the response. How about making it a string OR int? ie have both xsd in the range, I think that's allowed, similar to how currency is defined? > > -dave >
Received on Friday, 11 April 2014 16:26:02 UTC