Commits
Comments (0)
Files changed (28)

+21 0docs/source/jose.rst

+87 0docs/source/jwa.rst

+15 0docs/source/jwa/1.rst

+7 0docs/source/jwa/2.rst

+51 0docs/source/jwa/3.1.rst

+37 0docs/source/jwa/3.2.rst

+36 0docs/source/jwa/3.3.rst

+12 0docs/source/jwa/3.4.rst

+53 0docs/source/jwa/3.rst

+8 0docs/source/jwa/4.1.rst

+14 0docs/source/jwa/4.2.rst

+64 0docs/source/jwa/4.rst

+10 0docs/source/jwa/5.rst

+49 0docs/source/jwa/8.1.rst

+33 0docs/source/jwa/8.2.rst

+2 0docs/source/jwa/8.rst

+4 0docs/source/jwa/abstract.rst

+67 0docs/source/jwa/appendix.a.rst

+60 0docs/source/jwa/appendix.b.rst

+7 1docs/source/jwk.rst

+14 2docs/source/jwk/1.rst

+1 1docs/source/jwk/2.rst

+1 1docs/source/jwk/4.2.1.rst

+6 3docs/source/jwk/5.rst

+1 0docs/source/jwk/9.1.rst

+0 0src/jose/jwa/__init__.py

+0 0src/jose/jwk/__init__.py

+3 2src/jose/jwt/tokens.py
docs/source/jwa.rst
docs/source/jwa/1.rst
+to be used with the JSON Web Signature (JWS) [:term:`JWS`] and JSON Web Encryption (JWE) [:term:`JWE`] specifications.
+This specification also describes the semantics and operations that are specific to these algorithms and algorithm families.
docs/source/jwa/3.1.rst
+The :term:`alg` (algorithm) header parameter values :term:`HS256`, :term:`HS384`, and :term:`HS512`
+ 1. Apply the :term:`HMAC SHA256` algorithm to the UTF8 representation of the :term:`JWS Secured Input`
+ 1. Apply the :term:`HMAC SHA256` algorithm to the UTF8 representation of the :term:`JWS Secured Input`
+Securing content with the :term:`HMAC SHA384` and :term:`HMAC SHA512` algorithms is performed identically
+to the procedure for :term:`HMAC SHA256`  just with correspondingly longer key and result values.
docs/source/jwa/3.2.rst
+The :term:`RSASSAPKCS1v1_5` algorithm is described in FIPS 1863 [:term:`FIPS.186‑3`], Section 5.5,
+and the :term:`SHA256`, :term:`SHA384`, and :term:`SHA512` cryptographic hash functions are defined
+The :term:`alg` (algorithm) header parameter values RS256, RS384, and RS512 are used in the :term:`JWS Header`
+to indicate that the :term:`Encoded JWS Signature` contains a :term:`base64url` encoded RSA digital signature
+Signing with the RSA SHA384 and RSA SHA512 algorithms is performed identically to the procedure for RSA SHA256  just with correspondingly longer key and result values.
docs/source/jwa/3.3.rst
+
+The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by FIPS 1863 [FIPS.186‑3]. ECDSA provides for the use of Elliptic Curve cryptography, which is able to provide equivalent security to RSA cryptography but using shorter key lengths and with greater processing speed. This means that ECDSA digital signatures will be substantially smaller in terms of length than equivalently strong RSA digital signatures.
+This specification defines the use of ECDSA with the P256 curve and the SHA256 cryptographic hash function, ECDSA with the P384 curve and the SHA384 hash function, and ECDSA with the P521 curve and the SHA512 hash function. The P256, P384, and P521 curves are also defined in FIPS 1863. The alg (algorithm) header parameter values ES256, ES384, and ES512 are used in the JWS Header to indicate that the Encoded JWS Signature contains a base64url encoded ECDSA P256 SHA256, ECDSA P384 SHA384, or ECDSA P521 SHA512 digital signature, respectively.
+ 1. Take the Encoded JWS Signature and base64url decode it into a byte array. If decoding fails, the JWS MUST be rejected.
+ The first array will be R and the second S. Remember that the byte arrays are in big endian byte order;
+The ECDSA validator will then determine if the digital signature is valid, given the inputs. Note that ECDSA digital signature contains a value referred to as K, which is a random number generated for each digital signature instance. This means that two ECDSA digital signatures using exactly the same input parameters will output different signature values because their K values will be different. The consequence of this is that one must validate an ECDSA digital signature by submitting the previously specified inputs to an ECDSA validator.
+Signing with the ECDSA P384 SHA384 and ECDSA P521 SHA512 algorithms is performed identically to the procedure for ECDSA P256 SHA256  just with correspondingly longer key and result values.
docs/source/jwa/3.4.rst
+New :term:`alg` header parameter values SHOULD either be defined in the :term:`IANA JSON Web Signature Algorithms` registry
+it is permissible to use the algorithm identifiers defined in XML DSIG [:term:`RFC3275`] and related specifications as alg values.
docs/source/jwa/3.rst
+The table below Table 1 is the set of alg (algorithm) header parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections:
+used in this specification with the equivalent identifiers used by other standards and software packages.
+implementations also support the :term:`RSA` :term:`SHA256` and :term:`ECDSA` :term:`P256` :term:`SHA256` algorithms.
docs/source/jwa/4.2.rst
+New alg and enc header parameter values SHOULD either be defined in the :term:`IANA JSON Web Encryption Algorithms` registry
+it is permissible to use the algorithm identifiers defined in XML Encryption [:term:`W3C.REC‑xmlenc‑core‑20021210`],
docs/source/jwa/4.rst
+JWE uses cryptographic algorithms to encrypt the :term:`Content Encryption Key` (:term:`CEK`) and the :term:`Plaintext`.
+The table below Table 2 is the set of alg (algorithm) header parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CEK, which produces the JWE Encrypted Key.
+  Advanced Encryption Standard (AES) Key Wrap Algorithm using 128 bit keys, as defined in RFC 3394 [RFC3394]
+  Advanced Encryption Standard (AES) Key Wrap Algorithm using 256 bit keys, as defined in RFC 3394 [RFC3394]
+  Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
+  Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
+The table below Table 3 is the set of enc (encryption method) header parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the Plaintext, which produces the Ciphertext.
+  Advanced Encryption Standard (AES) using 128 bit keys in Cipher Block Chaining mode, as defined in [FIPS‑197] and [NIST‑800‑38A]
+  Advanced Encryption Standard (AES) using 256 bit keys in Cipher Block Chaining mode, as defined in [FIPS‑197] and [NIST‑800‑38A]
+  Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
+  Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode, as defined in [FIPS‑197] and [NIST‑800‑38D]
+alg (encryption method) values used in this specification with the equivalent identifiers used by other standards and software packages.
+Of these algorithms, only :term:`RSAPKCS11.5` with 2048 bit keys, AES128CBC, and AES256CBC MUST be implemented by conforming JWE implementations.
+It is RECOMMENDED that implementations also support ECDHES with 256 bit keys, AES128GCM, and AES256GCM. Support for other algorithms and key sizes is OPTIONAL.
docs/source/jwa/5.rst
+A new IANA registry entitled "JSON Web Signature Algorithms" for values of the JWS alg (algorithm) header parameter is defined in Section 3.4. Inclusion in the registry is RFC Required in the RFC 5226 [RFC5226] sense. The registry will just record the alg value and a pointer to the RFC that defines it. This specification defines inclusion of the algorithm values defined in Table 1.
+A new IANA registry entitled "JSON Web Encryption Algorithms" for values used with the JWE alg (algorithm) and enc (encryption method) header parameters is defined in Section 4.2. Inclusion in the registry is RFC Required in the RFC 5226 [RFC5226] sense. The registry will record the alg or enc value and a pointer to the RFC that defines it. This specification defines inclusion of the algorithm values defined in Table 2 and Table 3.
docs/source/jwa/8.1.rst
+ National Institute of Standards and Technology (NIST), “Advanced Encryption Standard (AES),” FIPS PUB 197, November 2001.
+ National Institute of Standards and Technology, “Secure Hash Standard (SHS),” FIPS PUB 1803, October 2008.
+ National Institute of Standards and Technology, “Digital Signature Standard (DSS),” FIPS PUB 1863, June 2009.
+ National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation,” NIST PUB 80038A, December 2001.
+ National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,” NIST PUB 80038D, December 2001.
+ National Institute of Standards and Technology (NIST), “Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),” NIST PUB 80056A, March 2007.
+ Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: KeyedHashing for Message Authentication,” RFC 2104, February 1997 (TXT).
+ Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
+ Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” RFC 3394, September 2002 (TXT).
+ Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” RFC 3447, February 2003 (TXT).
+ Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
+ McGrew, D., Igoe, K., and M. Salter, “Fundamental Elliptic Curve Cryptography Algorithms,” RFC 6090, February 2011 (TXT).
docs/source/jwa/8.2.rst
+ Rescorla, E. and J. Hildebrand, “JavaScript Message Security Format,” draftrescorlajsms00 (work in progress), March 2011 (TXT).
+ Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XMLSignature Syntax and Processing,” RFC 3275, March 2002 (TXT).
+ Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, “XML Encryption Syntax and Processing Version 1.1,” World Wide Web Consortium CR CRxmlenccore120110303, March 2011 (HTML).
+ Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing,” World Wide Web Consortium Recommendation RECxmlenccore20021210, December 2002 (HTML).
docs/source/jwa/appendix.a.rst
+================================================================================================================
+This appendix contains a table crossreferencing the digital signature and HMAC alg (algorithm) values used in this specification with the equivalent identifiers used by other standards and software packages. See XML DSIG [RFC3275] and Java Cryptography Architecture [JCA] for more information about the names defined by those documents.
docs/source/jwa/appendix.b.rst
+This appendix contains a table crossreferencing the alg (algorithm) and enc (encryption method) values used in this specification with the equivalent identifiers used by other standards and software packages. See XML Encryption [W3C.REC‑xmlenc‑core‑20021210], XML Encryption 1.1 [W3C.CR‑xmlenc‑core1‑20110303], and Java Cryptography Architecture [JCA] for more information about the names defined by those documents.
docs/source/jwk.rst
Based on Mike Jones' `draftjonesjsonwebkey03 <http://selfissued.info/docs/draftjonesjsonwebkey.html>`_ .
docs/source/jwk/1.rst
+using the :term:`jku` (JSON Key URL) and :term:`epk` (:term:`Ephemeral` Public Key) header parameters.
docs/source/jwk/4.2.1.rst
In this case, the alg member value MUST be EC. Furthermore, these additional members MUST be present:
docs/source/jwk/5.rst
+this specification mandates that :term:`base64url encoding` when used with JWKs MUST NOT use padding.
+Notes on implementing :term:`base64url encoding` can be found in the JWS [:term:`JWS`] specification.
src/jose/jwa/__init__.py
Empty file added.
src/jose/jwk/__init__.py
Empty file added.