doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6507.txt b/doc/rfc/rfc6507.txt
new file mode 100644
index 0000000..c1150e1
--- /dev/null
+++ b/doc/rfc/rfc6507.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Groves
+Request for Comments: 6507                                          CESG
+Category: Informational                                    February 2012
+ISSN: 2070-1721
+
+
+            Elliptic Curve-Based Certificateless Signatures
+                 for Identity-Based Encryption (ECCSI)
+
+Abstract
+
+   Many signature schemes currently in use rely on certificates for
+   authentication of identity.  In Identity-based cryptography, this
+   adds unnecessary overhead and administration.  The Elliptic Curve-
+   based Certificateless Signatures for Identity-based Encryption
+   (ECCSI) signature scheme described in this document is
+   certificateless.  This scheme has the additional advantages of low
+   bandwidth and low computational requirements.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Not all documents approved by the
+   IESG are a candidate for any level of Internet Standard; see Section
+   2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6507.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Groves                        Informational                     [Page 1]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Terminology ...................................3
+   2. Architecture ....................................................3
+   3. Notation ........................................................5
+      3.1. Arithmetic .................................................5
+      3.2. Representations ............................................6
+      3.3. Format of Material .........................................6
+   4. Parameters ......................................................7
+      4.1. Static Parameters ..........................................7
+      4.2. Community Parameters .......................................8
+   5. Algorithms ......................................................8
+      5.1. User Key Material ..........................................8
+           5.1.1. Algorithm for Constructing (SSK,PVT) Pair ...........8
+           5.1.2. Algorithm for Validating a Received SSK .............9
+      5.2. Signatures .................................................9
+           5.2.1. Algorithm for Signing ...............................9
+           5.2.2. Algorithm for Verifying ............................10
+   6. Security Considerations ........................................11
+   7. References .....................................................13
+      7.1. Normative References ......................................13
+      7.2. Informative References ....................................13
+   Appendix A. Test Data..............................................14
+
+1.  Introduction
+
+   Digital signatures provide authentication services across a wide
+   range of applications.  A chain of trust for such signatures is
+   usually provided by certificates.  However, in low-bandwidth or other
+   resource-constrained environments, the use of certificates might be
+   undesirable.  This document describes an efficient scheme, ECCSI, for
+   elliptic curve-based certificateless signatures, primarily intended
+   for use with Identity-Based Encryption (IBE) schemes such as
+   described in [RFC6508].  As certificates are not needed, the need to
+   transmit or store them to authenticate each communication is
+   obviated.  The algorithm has been developed by drawing on ideas set
+   out by Arazi [BA] and is originally based upon the Elliptic Curve
+   Digital Signature Algorithm [ECDSA], one of the most commonly used
+   signature algorithms.
+
+   The algorithm is for use in the following context:
+
+      *  where there are two parties, a Signer and a Verifier;
+
+      *  where short unambiguous Identifier strings are naturally
+         associated to each of these parties;
+
+
+
+
+Groves                        Informational                     [Page 2]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      *  where a message is to be signed and then verified (e.g., for
+         authenticating the initiating party during an Identity-based
+         key establishment);
+
+      *  where a common Key Management Service (KMS) provides a root of
+         trust for both parties.
+
+   The scheme does not rely on any web of trust between users.
+
+   Authentication is provided in a single simplex transmission without
+   per-session reference to any third party.  Thus, the scheme is
+   particularly suitable in situations where the receiving party need
+   not be active (or even enrolled) when the message to be authenticated
+   is sent, or where the number of transmissions is to be minimized for
+   efficiency.
+
+   Instead of having a certificate, the Signer has an Identifier, to
+   which his Secret Signing Key (SSK) (see Section 2) will have been
+   cryptographically bound by means of a Public Validation Token (PVT)
+   (see Section 2) by the KMS.  Unlike a traditional public key, this
+   PVT requires no further explicit certification.
+
+   The verification primitive within this scheme can be implemented
+   using projective representation of elliptic curve points, without
+   arithmetic field divisions, and without explicitly using the size of
+   the underlying cryptographic group.
+
+1.1.  Requirements Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Architecture
+
+   A KMS provisions key material for a set of communicating devices (a
+   "user community").  Each device within the user community MUST have
+   an Identifier (ID), which can be formed by its peers.  These
+   Identifiers MUST be unique to devices (or users), and MAY change over
+   time.  As such, all applications of this signature scheme MUST define
+   an unambiguous format for Identifiers.  We consider the situation
+   where one device (the Signer) wishes to sign a message that it is
+   sending to another (the Verifier).  Only the Signer's ID is used in
+   the signature scheme.
+
+
+
+
+
+
+
+Groves                        Informational                     [Page 3]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+   In advance, the KMS chooses its KMS Secret Authentication Key (KSAK),
+   which is the root of trust for all other key material in the scheme.
+   From this, the KMS derives the KMS Public Authentication Key (KPAK),
+   which all devices will require in order to verify signatures.  This
+   will be the root of trust for verification.
+
+   Before verification of any signatures, members of the user community
+   are supplied with the KPAK.  The supply of the KPAK MUST be
+   authenticated by the KMS, and this authentication MUST be verified by
+   each member of the user community.  Confidentiality protection MAY
+   also be applied.
+
+   In the description of the algorithms in this document, it is assumed
+   that there is one KMS, one user community, and hence one KPAK.
+   Applications MAY support multiple KPAKs, and some KPAKs could in fact
+   be "private" to certain communities in certain circumstances.  The
+   method for determining which KPAK to use (when more than one is
+   available) is out of scope.
+
+   The KMS generates and provisions key material for each device.  It
+   MUST supply an SSK along with a PVT to all devices that are to send
+   signed messages.  The mechanism by which these SSKs are provided MUST
+   be secure, as the security of the authentication provided by ECCSI
+   signatures is no stronger than the security of this supply channel.
+
+   Before using the supplied key material (SSK, KPAK) to form
+   signatures, the Sender MUST verify the key material (SSK) against the
+   root of trust (KPAK) and against its own ID and its PVT, using the
+   algorithm defined in Section 5.1.2.
+
+   During the signing process, once the Signer has formed its message,
+   it signs the message using its SSK.  It transmits the Signature
+   (including the PVT), and MAY also transmit the message (in cases
+   where the message is not known to the Verifier).  The Verifier MUST
+   then use the message, Signature, and Sender ID in verification
+   against the KPAK.
+
+   This document specifies
+
+      *  an algorithm for creating a KPAK from a KSAK, for a given
+         elliptic curve;
+
+      *  a format for transporting a KPAK;
+
+      *  an algorithm for creating an SSK and a PVT from a Signer's ID,
+         using the KSAK;
+
+
+
+
+
+Groves                        Informational                     [Page 4]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      *  an algorithm for verifying an SSK and a PVT against a Signer's
+         ID and KPAK;
+
+      *  an algorithm for creating a Signature from a message, using a
+         Signer's ID with a matching SSK and PVT;
+
+      *  a format for transporting a Signature;
+
+      *  an algorithm for verifying a Signature for a message, using a
+         Signer's ID with the matching KPAK.
+
+   This document does not specify (but comments on)
+
+      *  how to choose a valid and secure elliptic curve;
+
+      *  which hash function to use;
+
+      *  how to format a Signer's ID;
+
+      *  how to format a message for signing;
+
+      *  how to manage and install a KPAK;
+
+      *  how to transport or install an SSK.
+
+   As used in [RFC6509], the elliptic curve and hash function are
+   specified in Section 2.1.1 of [RFC6509], the format of Identifiers is
+   specified in Section 3.2 of [RFC6509], and messages for signing are
+   formatted as specified in [RFC3830].
+
+3.  Notation
+
+3.1.  Arithmetic
+
+   ECCSI relies on elliptic curve arithmetic.  If P and Q are two
+   elliptic curve points, their addition is denoted P + Q.  Moreover,
+   the addition of P with itself k times is denoted [k]P.
+
+   F_p denotes the finite field of p elements, where p is prime.  All
+   elliptic curve points will be defined over F_p.
+
+   The curve is defined by the equation y^2 = x^3 - 3*x + B modulo p,
+   where B is an element of F_p.  Elliptic curve points, other than the
+   group identity (0), are represented in the format P = (Px,Py), where
+   Px and Py are the affine coordinates in F_p satisfying the above
+   equation.  In particular, a point P = (Px,Py) is said to lie on an
+   elliptic curve if Py^2 - Px^3 + 3*Px - B = 0 modulo p.  The identity
+   point 0 will require no representation.
+
+
+
+Groves                        Informational                     [Page 5]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+3.2.  Representations
+
+   This section provides canonical representations of values that MUST
+   be used to ensure interoperability of implementations.  The following
+   representations MUST be used for input into hash functions and for
+   transmission.  In this document, concatenation of octet strings s and
+   t is denoted s || t.  The logarithm base 2 of a real number a is
+   denoted lg(a).
+
+   Integers           Integers MUST be represented as an octet string,
+                      with bit length a multiple of 8.  To achieve this,
+                      the integer is represented most significant bit
+                      first, and padded with zero bits on the left until
+                      an octet string of the necessary length is
+                      obtained.  This is the octet string representation
+                      described in Section 6 of [RFC6090].  There will
+                      be no need to represent negative integers.  When
+                      transmitted or hashed, such octet strings MUST
+                      have length N = Ceiling(lg(p)/8).
+
+   F_p elements       Elements of F_p MUST be represented as integers in
+                      the range 0 to p-1 using the octet string
+                      representation defined above.  For use in ECCSI,
+                      such octet strings MUST have length N =
+                      Ceiling(lg(p)/8).
+
+   Points on E        Elliptic curve points MUST be represented in
+                      uncompressed form ("affine coordinates") as
+                      defined in Section 2.2 of [RFC5480].  For an
+                      elliptic curve point (x,y) with x and y in F_p,
+                      this representation is given by 0x04 || x' || y',
+                      where x' is the N-octet string representing x and
+                      y' is the N-octet string representing y.
+
+3.3.  Format of Material
+
+   This section describes the subfields of the different objects used
+   within the protocol.
+
+   Signature = r || s || PVT   where r and s are octet strings of length
+                               N = Ceiling(lg(p)/8) representing
+                               integers, and PVT is an octet string of
+                               length 2N+1 representing an elliptic
+                               curve point, yielding a total signature
+                               length of 4N+1 octets.  (Note that r and
+
+
+
+
+
+
+Groves                        Informational                     [Page 6]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+                               s represent integers rather than elements
+                               of F_p, and therefore it is possible that
+                               either or both of them could equal or
+                               exceed p.)
+
+4.  Parameters
+
+4.1.  Static Parameters
+
+   The following static parameters are fixed for each implementation.
+   They are not intended to change frequently, and MUST be specified for
+   each user community.  Note that these parameters MAY be shared across
+   multiple KMSs.
+
+      n                  A security parameter; the size in bits of the
+                         prime p over which elliptic curve cryptography
+                         is to be performed.
+
+      N = Ceiling(n/8)   The number of octets used to represent fields r
+                         and s in a Signature.  Also the number of
+                         octets output by the hash function (see below).
+
+      p                  A prime number of size n bits.  The finite
+                         field with p elements is denoted F_p.
+
+      E                  An elliptic curve defined over F_p, having a
+                         subgroup of prime order q.
+
+      B                  An element of F_p, where E is defined by the
+                         formula y^2 = x^3 - 3*x + B modulo p.
+
+      G                  A point on the elliptic curve E that generates
+                         the subgroup of order q.
+
+      q                  The prime q is defined to be the order of G in
+                         E over F_p.
+
+      Hash               A cryptographic hash function mapping arbitrary
+                         strings to strings of N octets.  If a, b, c,
+                         ... are strings, then hash( a || b || c || ...)
+                         denotes the result obtained by hashing the
+                         concatenation of these strings.
+
+      Identifiers        The method for deriving user Identifiers.  The
+                         format of Identifiers MUST be specified by each
+                         implementation.  It MUST be possible for each
+                         device to derive the Identifier for every
+                         device with which it needs to communicate.  In
+
+
+
+Groves                        Informational                     [Page 7]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+                         this document, ID will denote the correctly
+                         formatted Identifier string of the Signer.
+                         ECCSI makes use of the Signer Identifier only,
+                         though an implementation MAY make use of other
+                         Identifiers when constructing the message to be
+                         signed.  Identifier formats MAY include a
+                         timestamp to allow for automatic expiration of
+                         key material.
+
+   It is RECOMMENDED that p, E, and G are chosen to be standardized
+   values.  In particular, it is RECOMMENDED that the curves and base
+   points defined in [FIPS186-3] be used.
+
+4.2.  Community Parameters
+
+   The following community parameter MUST be supplied to devices each
+   time the root of trust is changed.
+
+      KPAK  The KMS Public Authentication Key (KPAK) is the root of
+            trust for authentication.  It is derived from the KSAK in
+            the KMS.  This value MUST be provisioned in a trusted
+            fashion, such that each device that receives it has
+            assurance that it is the genuine KPAK belonging to its KMS.
+            Before use, each device MUST check that the supplied KPAK
+            lies on the elliptic curve E.
+
+   The KMS MUST fix the KPAK to be KPAK = [KSAK]G, where the KSAK MUST
+   be chosen to be a random secret non-zero integer modulo q.  The value
+   of the KSAK MUST be kept secret to the KMS.
+
+5.  Algorithms
+
+5.1.  User Key Material
+
+   To create signatures, each Signer requires a Secret Signing Key (SSK)
+   and a Public Validation Token (PVT).  The SSK is an integer, and the
+   PVT is an elliptic curve point.  The SSK MUST be kept secret (to the
+   Signer and KMS), but the PVT need not be kept secret.  A different
+   (SSK,PVT) pair will be needed for each Signer ID.
+
+5.1.1.  Algorithm for Constructing (SSK,PVT) Pair
+
+   The KMS constructs a (SSK,PVT) pair from the Signer's ID, the KMS
+   secret (KSAK), and the root of trust (KPAK).  To do this, the KMS
+   MUST perform the following procedure:
+
+
+
+
+
+
+Groves                        Informational                     [Page 8]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      1) Choose v, a random (ephemeral) non-zero element of F_q;
+
+      2) Compute PVT = [v]G (this MUST be represented canonically -- see
+         Section 3.2);
+
+      3) Compute a hash value HS = hash( G || KPAK || ID || PVT ),
+         an N-octet integer;
+
+      4) Compute SSK = ( KSAK + HS * v ) modulo q;
+
+      5) If either the SSK or HS is zero modulo q, the KMS MUST erase
+         the SSK and abort or restart the procedure with a fresh value
+         of v;
+
+      6) Output the (SSK,PVT) pair.  The KMS MUST then erase the value
+         v.
+
+   The method for transporting the SSK to the legitimate Signer device
+   is out of scope for this document, but the SSK MUST be provisioned by
+   the KMS using a method that protects its confidentiality.
+
+   If necessary, the KMS MAY create multiple (SSK,PVT) pairs for the
+   same Identifier.
+
+5.1.2.  Algorithm for Validating a Received SSK
+
+   Every SSK MUST be validated before being installed as a signing key.
+   The Signer uses its ID and the KPAK to validate a received (SSK,PVT)
+   pair.  To do this validation, the Signer MUST perform the following
+   procedure, passing all checks:
+
+      1) Validate that the PVT lies on the elliptic curve E;
+
+      2) Compute HS = hash( G || KPAK || ID || PVT ), an N-octet
+         integer.  The integer HS SHOULD be stored with the SSK for
+         later use;
+
+      3) Validate that KPAK = [SSK]G - [HS]PVT.
+
+5.2.  Signatures
+
+5.2.1.  Algorithm for Signing
+
+   To sign a message (M), the Signer requires
+
+      *  the KMS Public Authentication Key, KPAK;
+
+      *  the Signer's own Identifier, ID;
+
+
+
+Groves                        Informational                     [Page 9]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      *  its Secret Signing Key, SSK;
+
+      *  its Public Validation Token, PVT = (PVTx,PVTy).
+
+   These values, with the exception of ID, MUST have been provided by
+   the KMS.  The value of ID is derived by the Signer using the
+   community-defined method for formatting Identifiers.
+
+   The following procedure MUST be used by the Signer to compute the
+   signature:
+
+      1) Choose a random (ephemeral) non-zero value j in F_q;
+
+      2) Compute J = [j]G (this MUST be represented canonically).
+         Viewing J in affine coordinates J = (Jx,Jy), assign to r the
+         N-octet integer representing Jx;
+
+      3) Recall (or recompute) HS, and use it to compute a hash value
+         HE = hash( HS || r || M );
+
+      4) Verify that HE + r * SSK is non-zero modulo q; if this check
+         fails, the Signer MUST abort or restart this procedure with a
+         fresh value of j;
+
+      5) Compute s' = ( (( HE + r * SSK )^-1) * j ) modulo q; the Signer
+         MUST then erase the value j;
+
+      6) If s' is too big to fit within an N-octet integer, then set the
+         N-octet integer s = q - s'; otherwise, set the N-octet integer
+         s = s' (note that since p is less than 2^n, by Hasse's theorem
+         on elliptic curves, q < 2^n + 2^(n/2 + 1) + 1.  Therefore, if
+         s' > 2^n, we have q - s' < 2(n/2 + 1) + 1.  Thus, s is
+         guaranteed to fit within an N-octet integer);
+
+      7) Output the signature as Signature = ( r || s || PVT ).
+
+   Note that step 6) is necessary because it is possible for q (and
+   hence for elements of F_q) to be too big to fit within N octets.  The
+   Signer MAY instead elect to set s to be the least integer of s' and
+   q - s', represented in N octets.
+
+5.2.2.  Algorithm for Verifying
+
+   The algorithm provided assumes that the Verifier computes points on
+   elliptic curves using affine coordinates.  However, the Verifier MAY
+   perform elliptic curve operations using any appropriate
+   representation of points that achieves the equivalent operations.
+
+
+
+
+Groves                        Informational                    [Page 10]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+   To verify a Signature ( r || s || PVT ) against a Signer's Identifier
+   (ID), a message (M), and a pre-installed root of trust (KPAK), the
+   Verifier MUST perform a procedure equivalent to the following:
+
+      1) The Verifier MUST check that the PVT lies on the elliptic
+         curve E;
+
+      2) Compute HS = hash( G || KPAK || ID || PVT );
+
+      3) Compute HE = hash( HS || r || M );
+
+      4) Y = [HS]PVT + KPAK;
+
+      5) Compute J = [s]( [HE]G + [r]Y );
+
+      6) Viewing J in affine coordinates (Jx,Jy), the Verifier MUST
+         check that Jx = r modulo p, and that Jx modulo p is non-zero,
+         before accepting the Signature as valid.
+
+   It is anticipated that the ID, message (M), and KPAK will be
+   implicitly understood due to context, but any of these values MAY
+   also be included in signaling.
+
+   Note that the parameter q is not needed during verification.
+
+6.  Security Considerations
+
+   The ECCSI cryptographic algorithm is based upon [ECDSA].  In fact,
+   step 5) in the verification algorithm above is the same as the
+   verification stage in ECDSA.  The only difference between ECDSA and
+   ECCSI is that in ECCSI the 'public key', Y, is derived from the
+   Signer ID by the Verifier (whereas in ECDSA the public key is fixed).
+   It is therefore assumed that the security of ECCSI depends entirely
+   on the secrecy of the secret keys.  In addition, to recover secret
+   keys, one will need to perform computationally intensive
+   cryptanalytic attacks.
+
+   The KSAK provides the security for each device provisioned by the
+   KMS.  It MUST NOT be revealed to any entity other than the KMS that
+   holds it.  Each user's SSK authenticates the user as being associated
+   with the ID to which the SSK is assigned by the KMS.  This key MUST
+   NOT be revealed to any entity other than the KMS and the authorized
+   user.
+
+   The order of the base point G used in ECCSI MUST be a large prime q.
+   If k bits of symmetric security are needed, Ceiling(lg(q)) MUST be at
+   least 2*k.
+
+
+
+
+Groves                        Informational                    [Page 11]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+   It is RECOMMENDED that the curves and base points defined in
+   [FIPS186-3] be used, since these curves are suitable for
+   cryptographic use.  However, if other curves are used, the security
+   of the curves MUST be assessed.
+
+   In order to ensure that the SSK is only received by an authorized
+   device, it MUST be provided through a secure channel.  The strength
+   of the authentication offered by this signature scheme is no greater
+   than the security provided by this delivery channel.
+
+   Identifiers MUST be defined unambiguously by each application of
+   ECCSI.  Note that it is not necessary to use a hash function to
+   compose an Identifier string.  In this way, any weaknesses that might
+   otherwise be caused by collisions in hash functions can be avoided
+   without reliance on the structure of the Identifier format.
+   Applications of ECCSI MAY include a time/date component in their
+   Identifier format to ensure that Identifiers (and hence SSKs) are
+   only valid for a fixed period of time.
+
+   The use of the ephemeral value r in the hash HE significantly reduces
+   the scope for offline attacks, improving the overall security, as
+   compared to [ECDSA].  Furthermore, if Identifiers are specified to
+   contain date-stamps, then all Identifiers, SSKs, signatures, and hash
+   values will periodically become deprecated automatically, reducing
+   the need for revocation and other additional management methods.
+
+   The randomness of values stipulated to be selected at random, as
+   described in this document, is essential to the security provided by
+   ECCSI.  If the value of the KSAK can be predicted, then any
+   signatures can be forged.  Similarly, if the value of v used by the
+   KMS to create a user's SSK can be predicted, then the value of the
+   KSAK could be recovered, which would allow signatures to be forged.
+   If the value of j used by a user is predictable, then the value of
+   his SSK could be recovered.  This would allow that user's signatures
+   to be forged.  Guidance on the generation of random values for
+   security can be found in [RFC4086].
+
+   Note that in most instances, the value s in the Signature can be
+   replaced by q - s.  Thus, the malleability of ECCSI signatures is
+   similar to that in [ECDSA]; malleability is available but also very
+   limited.
+
+
+
+
+
+
+
+
+
+
+Groves                        Informational                    [Page 12]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+7.  References
+
+7.1.  Normative References
+
+   [ECDSA]      X9.62-2005, "Public Key Cryptography for the Financial
+                Services Industry: The Elliptic Curve Digital Signature
+                Algorithm (ECDSA)", November 2005.
+
+   [FIPS186-3]  Federal Information Processing Standards Publication
+                (FIPS PUB) 186-3, "Digital Signature Standard (DSS)",
+                June 2009.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5480]    Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+                Polk, "Elliptic Curve Cryptography Subject Public Key
+                Information", RFC 5480, March 2009.
+
+   [RFC6090]    McGrew, D., Igoe, K., and M. Salter, "Fundamental
+                Elliptic Curve Cryptography Algorithms", RFC 6090,
+                February 2011.
+
+7.2.  Informative References
+
+   [BA]         Arazi, Benjamin, "Certification of DL/EC Keys", paper
+                submitted to P1363 meeting, August 1998,
+                <http://grouper.ieee.org/groups/1363/StudyGroup/
+                contributions/arazi.doc>.
+
+   [FIPS180-3]  Federal Information Processing Standards Publication
+                (FIPS PUB) 180-3, "Secure Hash Standard (SHS)",
+                October 2008.
+
+   [RFC3830]    Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
+                K. Norrman, "MIKEY: Multimedia Internet KEYing",
+                RFC 3830, August 2004.
+
+   [RFC4086]    Eastlake 3rd, D., Schiller, J., and S. Crocker,
+                "Randomness Requirements for Security", BCP 106,
+                RFC 4086, June 2005.
+
+   [RFC6508]    Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)",
+                RFC 6508, February 2012.
+
+   [RFC6509]    Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption
+                in Multimedia Internet KEYing (MIKEY)", RFC 6509,
+                February 2012.
+
+
+
+Groves                        Informational                    [Page 13]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+Appendix A.  Test Data
+
+   This appendix provides test data built from the NIST P-256 curve and
+   base point.  SHA-256 (as defined in [FIPS180-3]) is used as the hash
+   function.  The keys and ephemerals -- KSAK, v, and j -- are arbitrary
+   and for illustration only.
+
+      // --------------------------------------------------------
+      // Global parameters
+
+      n       := 256;
+
+      N       := 32;
+
+      p       := 0x   FFFFFFFF 00000001 00000000 00000000
+                      00000000 FFFFFFFF FFFFFFFF FFFFFFFF;
+
+      Hash    := SHA-256;
+
+      // --------------------------------------------------------
+      // Community parameters
+
+      B       := 0x   5AC635D8 AA3A93E7 B3EBBD55 769886BC
+                      651D06B0 CC53B0F6 3BCE3C3E 27D2604B;
+
+      q       := 0x   FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+                      BCE6FAAD A7179E84 F3B9CAC2 FC632551;
+
+      G       := 0x   04
+                      6B17D1F2 E12C4247 F8BCE6E5 63A440F2
+                      77037D81 2DEB33A0 F4A13945 D898C296
+                      4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
+                      2BCE3357 6B315ECE CBB64068 37BF51F5;
+
+      KSAK    := 0x   12345;
+
+      KPAK    := 0x   04
+                      50D4670B DE75244F 28D2838A 0D25558A
+                      7A72686D 4522D4C8 273FB644 2AEBFA93
+                      DBDD3755 1AFD263B 5DFD617F 3960C65A
+                      8C298850 FF99F203 66DCE7D4 367217F4;
+
+      // --------------------------------------------------------
+      // Signer ID
+
+      ID      := "2011-02\0tel:+447700900123\0",
+               = 0x   3230 31312D30 32007465 6C3A2B34
+                      34373730 30393030 31323300;
+
+
+
+Groves                        Informational                    [Page 14]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      // --------------------------------------------------------
+      // Creating SSK and PVT
+
+      v       := 0x   23456;
+
+      PVT     := 0x   04
+                      758A1427 79BE89E8 29E71984 CB40EF75
+                      8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                      A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                      A464AE49 34663C52 65BA7018 BA091F79;
+
+      HS      := hash( 0x 04
+                          6B17D1F2 E12C4247 F8BCE6E5 63A440F2
+                          77037D81 2DEB33A0 F4A13945 D898C296
+                          4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
+                          2BCE3357 6B315ECE CBB64068 37BF51F5
+                          04
+                          50D4670B DE75244F 28D2838A 0D25558A
+                          7A72686D 4522D4C8 273FB644 2AEBFA93
+                          DBDD3755 1AFD263B 5DFD617F 3960C65A
+                          8C298850 FF99F203 66DCE7D4 367217F4
+                          32303131 2D303200 74656C3A 2B343437
+
+                          37303039 30303132 3300
+                          04
+                          758A1427 79BE89E8 29E71984 CB40EF75
+                          8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                          A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                          A464AE49 34663C52 65BA7018 BA091F79 ),
+
+               = 0x       490F3FEB BC1C902F 6289723D 7F8CBF79
+                          DB889308 49D19F38 F0295B5C 276C14D1;
+
+      SSK     := 0x       23F374AE 1F4033F3 E9DBDDAA EF20F4CF
+                          0B86BBD5 A138A5AE 9E7E006B 34489A0D;
+
+      // --------------------------------------------------------
+      // Creating a Signature
+
+      M       := "message\0",
+               = 0x   6D657373 61676500;
+
+      j       := 0x   34567;
+
+
+
+
+
+
+
+
+Groves                        Informational                    [Page 15]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      J       := 0x   04
+                      269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81
+                      6DDA6A13 10F4B067 BD5DABDA D741B7CE
+                      F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
+
+      r       := 0x   269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81;
+
+      HE      := hash( 0x
+                      490F3FEB BC1C902F 6289723D 7F8CBF79
+                      DB889308 49D19F38 F0295B5C 276C14D1
+                      269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81
+                      6D657373 61676500 ),
+
+               = 0x   111F90EA E8271C96 DF9B3D67 26768D9E
+                      E9B18145 D7EC152C FA9C23D1 C4F02285;
+
+      s'      := 0x   E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
+                      EC9FC682 52CEBB67 9F413484 6940CCFD;
+
+      s       := 0x   E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
+                      EC9FC682 52CEBB67 9F413484 6940CCFD;
+
+      Sig     := 0x   269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81
+                      E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
+                      EC9FC682 52CEBB67 9F413484 6940CCFD
+                      04
+
+                      758A1427 79BE89E8 29E71984 CB40EF75
+                      8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
+                      A79D2476 92F4EDA3 A6BDAB77 D6AA6474
+                      A464AE49 34663C52 65BA7018 BA091F79;
+
+      // --------------------------------------------------------
+      // Verifying a Signature
+
+      Y       := 0x   04
+                      833898D9 39C0013B B0502728 6F95CCE0
+                      37C11BD2 5799423C 76E48362 A4959978
+                      95D0473A 1CD6186E E9F0C104 B472499E
+                      1A24D6CE 3D85173F 02EBBD94 5C25F604;
+
+
+
+
+
+
+
+Groves                        Informational                    [Page 16]
+
+RFC 6507           ECCSI for Identity-Based Encryption     February 2012
+
+
+      J       := 0x   04
+                      269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81
+                      6DDA6A13 10F4B067 BD5DABDA D741B7CE
+                      F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
+
+      Jx      := 0x   269D4C8F DEB66A74 E4EF8C0D 5DCC597D
+                      DFE6029C 2AFFC493 6008CD2C C1045D81;
+
+      Jx = r  modulo p
+
+      // --------------------------------------------------------
+
+Author's Address
+
+   Michael Groves
+   CESG
+   Hubble Road
+   Cheltenham
+   GL51 8HJ
+   UK
+
+   EMail: Michael.Groves@cesg.gsi.gov.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Groves                        Informational                    [Page 17]
+