W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2014

Re: Range of Security : Nonce

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 11 Apr 2014 18:25:33 +0200
Message-ID: <CAKaEYhKDcpj-pOwX9Vn8b7sxyOi4ei5fWJVdukFN1NYOJ32W7g@mail.gmail.com>
To: "David I. Lehn" <dil@lehn.org>
Cc: Web Payments <public-webpayments@w3.org>
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

> -dave
Received on Friday, 11 April 2014 16:26:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:36 UTC