draft-ietf-jose-json-web-algorithms-03.txt   draft-ietf-jose-json-web-algorithms-04.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track July 6, 2012 Intended status: Standards Track July 16, 2012
Expires: January 7, 2013 Expires: January 17, 2013
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-03 draft-ietf-jose-json-web-algorithms-04
Abstract Abstract
The JSON Web Algorithms (JWA) specification enumerates cryptographic The JSON Web Algorithms (JWA) specification enumerates cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. specifications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2013. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 52 skipping to change at page 2, line 52
or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 16 or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 16
4.13. Additional Encryption Algorithms and Parameters . . . . . 17 4.13. Additional Encryption Algorithms and Parameters . . . . . 17
5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 18 5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 18
5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 18 5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 18
5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 18 5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 18
5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 18 5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 18
5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 19 5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 19
5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 19 5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 19
5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 19 5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 19
5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 19 5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 19
5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 19 5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 20
5.4. Additional Key Algorithm Families and Parameters . . . . . 19 5.4. Additional Key Algorithm Families and Parameters . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. JSON Web Signature and Encryption Algorithms Registry . . 20 6.1. JSON Web Signature and Encryption Algorithms Registry . . 21
6.1.1. Registration Template . . . . . . . . . . . . . . . . 21 6.1.1. Registration Template . . . . . . . . . . . . . . . . 21
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22
6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 26 6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 26
6.2.1. Registration Template . . . . . . . . . . . . . . . . 26 6.2.1. Registration Template . . . . . . . . . . . . . . . . 27
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27
6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 27 6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 28
6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 27 6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Digital Signature/MAC Algorithm Identifier Appendix A. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . 32 Cross-Reference . . . . . . . . . . . . . . . . . . . 33
Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 34 Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 35
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 36 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Appendix D. Document History . . . . . . . . . . . . . . . . . . 36 Appendix D. Document History . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The JSON Web Algorithms (JWA) specification enumerates cryptographic The JSON Web Algorithms (JWA) specification enumerates cryptographic
algorithms and identifiers to be used with the JSON Web Signature algorithms and identifiers to be used with the JSON Web Signature
(JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK)
[JWK] specifications. This specification also describes the [JWK] specifications. All these specifications utilize JavaScript
semantics and operations that are specific to these algorithms and Object Notation (JSON) [RFC4627] based data structures. This
algorithm families. specification also describes the semantics and operations that are
specific to these algorithms and algorithm families.
Enumerating the algorithms and identifiers for them in this Enumerating the algorithms and identifiers for them in this
specification, rather than in the JWS, JWE, and JWK specifications, specification, rather than in the JWS, JWE, and JWK specifications,
is intended to allow them to remain unchanged in the face of changes is intended to allow them to remain unchanged in the face of changes
in the set of required, recommended, optional, and deprecated in the set of required, recommended, optional, and deprecated
algorithms over time. algorithms over time.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 47 skipping to change at page 4, line 48
JWS Header A string representing a JavaScript Object Notation (JSON) JWS Header A string representing a JavaScript Object Notation (JSON)
[RFC4627] object that describes the digital signature or MAC [RFC4627] object that describes the digital signature or MAC
operation applied to create the JWS Signature value. operation applied to create the JWS Signature value.
JWS Payload The bytes to be secured - a.k.a., the message. The JWS Payload The bytes to be secured - a.k.a., the message. The
payload can contain an arbitrary sequence of bytes. payload can contain an arbitrary sequence of bytes.
JWS Signature A byte array containing the cryptographic material JWS Signature A byte array containing the cryptographic material
that secures the contents of the JWS Header and the JWS Payload. that secures the contents of the JWS Header and the JWS Payload.
Base64url Encoding The URL- and filename-safe Base64 encoding
described in RFC 4648 [RFC4648], Section 5, with the (non URL-
safe) '=' padding characters omitted, as permitted by Section 3.2.
(See Appendix C of [JWS] for notes on implementing base64url
encoding without padding.)
Encoded JWS Header Base64url encoding of the bytes of the UTF-8 Encoded JWS Header Base64url encoding of the bytes of the UTF-8
[RFC3629] representation of the JWS Header. [RFC3629] representation of the JWS Header.
Encoded JWS Payload Base64url encoding of the JWS Payload. Encoded JWS Payload Base64url encoding of the JWS Payload.
Encoded JWS Signature Base64url encoding of the JWS Signature. Encoded JWS Signature Base64url encoding of the JWS Signature.
JWS Secured Input The concatenation of the Encoded JWS Header, a JWS Secured Input The concatenation of the Encoded JWS Header, a
period ('.') character, and the Encoded JWS Payload. period ('.') character, and the Encoded JWS Payload.
Base64url Encoding For the purposes of this specification, this term
always refers to the URL- and filename-safe Base64 encoding
described in RFC 4648 [RFC4648], Section 5, with the (non URL-
safe) '=' padding characters omitted, as permitted by Section 3.2.
(See Appendix C of [JWS] for notes on implementing base64url
encoding without padding.)
Collision Resistant Namespace A namespace that allows names to be Collision Resistant Namespace A namespace that allows names to be
allocated in a manner such that they are highly unlikely to allocated in a manner such that they are highly unlikely to
collide with other names. For instance, collision resistance can collide with other names. For instance, collision resistance can
be achieved through administrative delegation of portions of the be achieved through administrative delegation of portions of the
namespace or through use of collision-resistant name allocation namespace or through use of collision-resistant name allocation
functions. Examples of Collision Resistant Namespaces include: functions. Examples of Collision Resistant Namespaces include:
Domain Names, Object Identifiers (OIDs) as defined in the ITU-T Domain Names, Object Identifiers (OIDs) as defined in the ITU-T
X.660 and X.670 Recommendation series, and Universally Unique X.660 and X.670 Recommendation series, and Universally Unique
IDentifiers (UUIDs) [RFC4122]. When using an administratively IDentifiers (UUIDs) [RFC4122]. When using an administratively
delegated namespace, the definer of a name needs to take delegated namespace, the definer of a name needs to take
skipping to change at page 10, line 41 skipping to change at page 10, line 41
defined in [DSS]. The "alg" (algorithm) header parameter values defined in [DSS]. The "alg" (algorithm) header parameter values
"ES256", "ES384", and "ES512" are used in the JWS Header to indicate "ES256", "ES384", and "ES512" are used in the JWS Header to indicate
that the Encoded JWS Signature contains a base64url encoded ECDSA that the Encoded JWS Signature contains a base64url encoded ECDSA
P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 digital P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 digital
signature, respectively. signature, respectively.
The ECDSA P-256 SHA-256 digital signature is generated as follows: The ECDSA P-256 SHA-256 digital signature is generated as follows:
1. Generate a digital signature of the bytes of the ASCII 1. Generate a digital signature of the bytes of the ASCII
representation of the JWS Secured Input using ECDSA P-256 SHA-256 representation of the JWS Secured Input using ECDSA P-256 SHA-256
with the desired private key. The output will be the EC point with the desired private key. The output will be the pair (R,
(R, S), where R and S are unsigned integers. S), where R and S are 256 bit unsigned integers.
2. Turn R and S into byte arrays in big endian order, with each 2. Turn R and S into byte arrays in big endian order, with each
array being be 32 bytes long. array being be 32 bytes long. The array representations MUST not
be shortened to omit any leading zero bytes contained in the
values.
3. Concatenate the two byte arrays in the order R and then S. (Note 3. Concatenate the two byte arrays in the order R and then S. (Note
that many ECDSA implementations will directly produce this that many ECDSA implementations will directly produce this
concatenation as their output.) concatenation as their output.)
4. Base64url encode the resulting 64 byte array. 4. Base64url encode the resulting 64 byte array.
The output is the Encoded JWS Signature for the JWS. The output is the Encoded JWS Signature for the JWS.
The ECDSA P-256 SHA-256 digital signature for a JWS is validated as The ECDSA P-256 SHA-256 digital signature for a JWS is validated as
skipping to change at page 11, line 39 skipping to change at page 11, line 41
instance. This means that two ECDSA digital signatures using exactly instance. This means that two ECDSA digital signatures using exactly
the same input parameters will output different signature values the same input parameters will output different signature values
because their K values will be different. A consequence of this is because their K values will be different. A consequence of this is
that one cannot validate an ECDSA signature by recomputing the that one cannot validate an ECDSA signature by recomputing the
signature and comparing the results. signature and comparing the results.
Signing with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 Signing with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512
algorithms is performed identically to the procedure for ECDSA P-256 algorithms is performed identically to the procedure for ECDSA P-256
SHA-256 - just using the corresponding hash algorithm with SHA-256 - just using the corresponding hash algorithm with
correspondingly larger result values. For ECDSA P-384 SHA-384, R and correspondingly larger result values. For ECDSA P-384 SHA-384, R and
S will be 48 bytes each, resulting in a 96 byte array. For ECDSA S will be 384 bits each, resulting in a 96 byte array. For ECDSA
P-521 SHA-512, R and S will be 66 bytes each (so they can represent a P-521 SHA-512, R and S will be 521 bits each, resulting in a 132 byte
521-bit integer), resulting in a 132 byte array. array.
3.5. Using the Algorithm "none" 3.5. Using the Algorithm "none"
JWSs MAY also be created that do not provide integrity protection. JWSs MAY also be created that do not provide integrity protection.
Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the
"alg" value "none", and are formatted identically to other JWSs, but "alg" value "none", and are formatted identically to other JWSs, but
with an empty JWS Signature value. with an empty JWS Signature value.
3.6. Additional Digital Signature/MAC Algorithms and Parameters 3.6. Additional Digital Signature/MAC Algorithms and Parameters
skipping to change at page 19, line 12 skipping to change at page 19, line 12
The "crv" (curve) member identifies the cryptographic curve used with The "crv" (curve) member identifies the cryptographic curve used with
the key. Curve values from [DSS] used by this specification are: the key. Curve values from [DSS] used by this specification are:
o "P-256" o "P-256"
o "P-384" o "P-384"
o "P-521" o "P-521"
Additional "crv" values MAY be used, provided they are understood by Additional "crv" values MAY be used, provided they are understood by
implementations using that Elliptic Curve key. The "crv" value is implementations using that Elliptic Curve key. The "crv" value is a
case sensitive. Its value MUST be a string. case sensitive string.
5.2.2. "x" (X Coordinate) Parameter 5.2.2. "x" (X Coordinate) Parameter
The "x" (x coordinate) member contains the x coordinate for the The "x" (x coordinate) member contains the x coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the coordinate's big endian representation. the coordinate's big endian representation as a byte array. The
array representation MUST not be shortened to omit any leading zero
bytes contained in the value. For instance, when representing 521
bit integers, the byte array to be base64url encoded MUST contain 66
bytes, including any leading zero bytes.
5.2.3. "y" (Y Coordinate) Parameter 5.2.3. "y" (Y Coordinate) Parameter
The "y" (y coordinate) member contains the y coordinate for the The "y" (y coordinate) member contains the y coordinate for the
elliptic curve point. It is represented as the base64url encoding of elliptic curve point. It is represented as the base64url encoding of
the coordinate's big endian representation. the coordinate's big endian representation as a byte array. The
array representation MUST not be shortened to omit any leading zero
bytes contained in the value. For instance, when representing 521
bit integers, the byte array to be base64url encoded MUST contain 66
bytes, including any leading zero bytes.
5.3. JWK Parameters for RSA Keys 5.3. JWK Parameters for RSA Keys
JWKs can represent RSA [RFC3447] keys. In this case, the "alg" JWKs can represent RSA [RFC3447] keys. In this case, the "alg"
member value MUST be "RSA". Furthermore, these additional members member value MUST be "RSA". Furthermore, these additional members
MUST be present: MUST be present:
5.3.1. "mod" (Modulus) Parameter 5.3.1. "mod" (Modulus) Parameter
The "mod" (modulus) member contains the modulus value for the RSA The "mod" (modulus) member contains the modulus value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation. value's unsigned big endian representation as a byte array. The
array representation MUST not be shortened to omit any leading zero
bytes. For instance, when representing 2048 bit integers, the byte
array to be base64url encoded MUST contain 256 bytes, including any
leading zero bytes.
5.3.2. "exp" (Exponent) Parameter 5.3.2. "exp" (Exponent) Parameter
The "exp" (exponent) member contains the exponent value for the RSA The "exp" (exponent) member contains the exponent value for the RSA
public key. It is represented as the base64url encoding of the public key. It is represented as the base64url encoding of the
value's unsigned big endian representation. value's unsigned big endian representation as a byte array. The
array representation MUST utilize the minimum number of bytes to
represent the value. For instance, when representing the value
65537, the byte array to be base64url encoded MUST consist of the
three bytes [1, 0, 1].
5.4. Additional Key Algorithm Families and Parameters 5.4. Additional Key Algorithm Families and Parameters
Public keys using additional algorithm families MAY be represented Public keys using additional algorithm families MAY be represented
using JWK data structures with corresponding "alg" (algorithm family) using JWK data structures with corresponding "alg" (algorithm family)
parameter values being defined to refer to them. New "alg" parameter parameter values being defined to refer to them. New "alg" parameter
values SHOULD either be registered in the IANA JSON Web Key Algorithm values SHOULD either be registered in the IANA JSON Web Key Algorithm
Families registry Section 6.2 or be a URI that contains a Collision Families registry Section 6.2 or be a URI that contains a Collision
Resistant Namespace. Resistant Namespace.
skipping to change at page 21, line 9 skipping to change at page 21, line 28
registered multiple times, provided that the sets of usage locations registered multiple times, provided that the sets of usage locations
are disjoint. The implementation requirements of an algorithm may be are disjoint. The implementation requirements of an algorithm may be
changed over time by the Designated Experts(s) as the cryptographic changed over time by the Designated Experts(s) as the cryptographic
landscape evolves, for instance, to change the status of an algorithm landscape evolves, for instance, to change the status of an algorithm
to DEPRECATED, or to change the status of an algorithm from OPTIONAL to DEPRECATED, or to change the status of an algorithm from OPTIONAL
to RECOMMENDED or REQUIRED. to RECOMMENDED or REQUIRED.
6.1.1. Registration Template 6.1.1. Registration Template
Algorithm Name: Algorithm Name:
The name requested (e.g., "example"). The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted.
Algorithm Usage Location(s): Algorithm Usage Location(s):
The algorithm usage, which must be one or more of the values The algorithm usage, which must be one or more of the values
"alg", "enc", "int", or "kdf". "alg", "enc", "int", or "kdf".
Implementation Requirements: Implementation Requirements:
The algorithm implementation requirements, which must be one the The algorithm implementation requirements, which must be one the
words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally,
the word may be followed by a "+" or "-". The use of "+" the word may be followed by a "+" or "-". The use of "+"
indicates that the requirement strength is likely to be increased indicates that the requirement strength is likely to be increased
skipping to change at page 26, line 31 skipping to change at page 27, line 9
This specification establishes the IANA JSON Web Key Algorithm This specification establishes the IANA JSON Web Key Algorithm
Families registry for values of the JWK "alg" (algorithm family) Families registry for values of the JWK "alg" (algorithm family)
parameter. The registry records the "alg" value and a reference to parameter. The registry records the "alg" value and a reference to
the specification that defines it. This specification registers the the specification that defines it. This specification registers the
values defined in Section 5.1. values defined in Section 5.1.
6.2.1. Registration Template 6.2.1. Registration Template
"alg" Parameter Value: "alg" Parameter Value:
The name requested (e.g., "example"). The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted.
Change Controller: Change Controller:
For standards-track RFCs, state "IETF". For others, give the name For standards-track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
e-mail address, home page URI) may also be included. e-mail address, home page URI) may also be included.
Implementation Requirements: Implementation Requirements:
The algorithm implementation requirements, which must be one the The algorithm implementation requirements, which must be one the
words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally,
the word may be followed by a "+" or "-". The use of "+" the word may be followed by a "+" or "-". The use of "+"
skipping to change at page 29, line 22 skipping to change at page 30, line 4
send certificates with keys that would result in excessive send certificates with keys that would result in excessive
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
8. Open Issues 8. Open Issues
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
The following items remain to be considered or done in this draft: The following items remain to be considered or done in this draft:
o Should we use the "alg" value as the AlgorithmID input to the o Should we use the "alg" value as the AlgorithmID input to the
Concat KDF when doing key agreement? Or is an AlgorithmID value Concat KDF when doing key agreement? Or is an AlgorithmID value
unnecessary in the way that we are using Concat? unnecessary in the way that we are using Concat for key agreement?
o Should we use the "enc" and "int" values as AlgorithmID inputs to o Similarly, should we use a combination of the "enc" and "int"
the Concat KDF when doing key derivation? Or is an AlgorithmID values as the AlgorithmID input to the Concat KDF when doing key
value unnecessary in the way that we are using Concat? derivation? Or is an AlgorithmID value unnecessary in the way
that we are using Concat for key derivation?
o Do we need non-empty PartyUInfo and PartyVInfo values when using
the Concat KDF for key agreement? Or given that we already
require the use of a random unique Ephemeral Public Key (EPK), is
this superfluous, as duplicate keys will not be generated unless a
duplicate EPK is used? If we do decide we need PartyUInfo and
PartyVInfo values, how can we dynamically generate them from
information already carried in the header, rather than requiring
that they be explicitly passed as header parameters?
o Similarly, do we need non-empty PartyUInfo and PartyVInfo values
when using the Concat KDF for key derivation? Or given that we
already require the use of a random unique Content Master Key
(CMK), is this superfluous, as duplicate keys will not be
generated unless a duplicate CMK is used? If we do decide we need
PartyUInfo and PartyVInfo values, how can we dynamically generate
them from information already carried in the header, rather than
requiring that they be explicitly passed as header parameters?
o Do we want to add AES ECB as a (non-authenticated) key wrap o Do we want to add AES ECB as a (non-authenticated) key wrap
algorithm? algorithm? Is there any problem with doing key wrap without an
integrity check, given that a separate integrity check already
covers the wrapped key?
o Do we want to add the ability to perform symmetric encryption
directly with a shared key, without using a CMK? This would save
space and time in the single recipient case. It would also be
parallel to the current treatment of key agreement, which doesn't
use a CMK.
9. References 9. References
9.1. Normative References 9.1. Normative References
[AES] National Institute of Standards and Technology (NIST), [AES] National Institute of Standards and Technology (NIST),
"Advanced Encryption Standard (AES)", FIPS PUB 197, "Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001. November 2001.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
skipping to change at page 31, line 50 skipping to change at page 33, line 7
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Reagle, J., Solo, D., Datta, P., Hirsch, F., Eastlake, D., Reagle, J., Hirsch, F., Cantor, S., Roessler, T.,
Roessler, T., Cantor, S., and K. Yiu, "XML Signature Eastlake, D., Yiu, K., Solo, D., and P. Datta, "XML
Syntax and Processing Version 2.0", World Wide Web Signature Syntax and Processing Version 2.0", World Wide
Consortium CR CR-xmldsig-core2-20120124, January 2012, Web Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.CR-xmlenc-core1-20120313] [W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler,
"XML Encryption Syntax and Processing Version 1.1", World "XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium CR CR-xmlenc-core1-20120313, Wide Web Consortium CR CR-xmlenc-core1-20120313,
March 2012, March 2012,
<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
[W3C.REC-xmlenc-core-20021210] [W3C.REC-xmlenc-core-20021210]
skipping to change at page 36, line 41 skipping to change at page 38, line 9
and JavaScript Message Security Format [I-D.rescorla-jsms], all of and JavaScript Message Security Format [I-D.rescorla-jsms], all of
which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y. which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y.
Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made
significant contributions to the design of this specification and its significant contributions to the design of this specification and its
related specifications. related specifications.
Appendix D. Document History Appendix D. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-04
o Added text requiring that any leading zero bytes be retained in
base64url encoded key value representations for fixed-length
values.
o Added this language to Registration Templates: "This name is case
sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted."
o Described additional open issues.
o Applied editorial suggestions.
-03 -03
o Always use a 128 bit "authentication tag" size for AES GCM, o Always use a 128 bit "authentication tag" size for AES GCM,
regardless of the key size. regardless of the key size.
o Specified that use of a 128 bit IV is REQUIRED with AES CBC. It o Specified that use of a 128 bit IV is REQUIRED with AES CBC. It
was previously RECOMMENDED. was previously RECOMMENDED.
o Removed key size language for ECDSA algorithms, since the key size o Removed key size language for ECDSA algorithms, since the key size
is implied by the algorithm being used. is implied by the algorithm being used.
 End of changes. 30 change blocks. 
53 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/