RFC 8152
CBOR Object Signing and Encryption (COSE)
13. Key Object Parameters
The COSE_Key object defines a way to hold a single key object. It is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types. For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. Private members allow for the archival of keys by individuals. However, there are some circumstances in which private keys may be distributed to entities in a protocol. Examples include: entities that have poor random number generation, centralized key creation for multi-cast type operations, and protocols in which a shared secret is used as a bearer token for authorization purposes. Key types are identified by the 'kty' member of the COSE_Key object. In this document, we define four values for the member: +-----------+-------+-----------------------------------------------+ | Name | Value | Description | +-----------+-------+-----------------------------------------------+ | OKP | 1 | Octet Key Pair | | EC2 | 2 | Elliptic Curve Keys w/ x- and y-coordinate | | | | pair | | Symmetric | 4 | Symmetric Keys | | Reserved | 0 | This value is reserved | +-----------+-------+-----------------------------------------------+ Table 21: Key Type Values
13.1. Elliptic Curve Keys
Two different key structures are defined for elliptic curve keys. One version uses both an x-coordinate and a y-coordinate, potentially with point compression ('EC2'). This is the traditional EC point representation that is used in [RFC5480]. The other version uses only the x-coordinate as the y-coordinate is either to be recomputed or not needed for the key agreement operation ('OKP'). Applications MUST check that the curve and the key type are consistent and reject a key if they are not. +---------+-------+----------+------------------------------------+ | Name | Value | Key Type | Description | +---------+-------+----------+------------------------------------+ | P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 | | P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 | | P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 | | X25519 | 4 | OKP | X25519 for use w/ ECDH only | | X448 | 5 | OKP | X448 for use w/ ECDH only | | Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only | | Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only | +---------+-------+----------+------------------------------------+ Table 22: Elliptic Curves13.1.1. Double Coordinate Curves
The traditional way of sending ECs has been to send either both the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended in the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful. For EC keys with both coordinates, the 'kty' member is set to 2 (EC2). The key parameters defined in this section are summarized in Table 23. The members that are defined for this key type are: crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 22. Other curves may be registered in the future, and private curves can be used as well. x: This contains the x-coordinate for the EC point. The integer is converted to an octet string as defined in [SEC1]. Leading zero octets MUST be preserved.
y: This contains either the sign bit or the value of the
y-coordinate for the EC point. When encoding the value y, the
integer is converted to an octet string (as defined in [SEC1])
and encoded as a CBOR bstr. Leading zero octets MUST be
preserved. The compressed point encoding is also supported.
Compute the sign bit as laid out in the Elliptic-Curve-Point-to-
Octet-String Conversion function of [SEC1]. If the sign bit is
zero, then encode y as a CBOR false value; otherwise, encode y
as a CBOR true value. The encoding of the infinity point is not
supported.
d: This contains the private key.
For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present
in the structure. For private keys, it is REQUIRED that 'crv' and
'd' be present in the structure. For private keys, it is RECOMMENDED
that 'x' and 'y' also be present, but they can be recomputed from the
required elements and omitting them saves on space.
+-------+------+-------+--------+-----------------------------------+
| Key | Name | Label | CBOR | Description |
| Type | | | Type | |
+-------+------+-------+--------+-----------------------------------+
| 2 | crv | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry |
| 2 | x | -2 | bstr | x-coordinate |
| 2 | y | -3 | bstr / | y-coordinate |
| | | | bool | |
| 2 | d | -4 | bstr | Private key |
+-------+------+-------+--------+-----------------------------------+
Table 23: EC Key Parameters
13.2. Octet Key Pair
A new key type is defined for Octet Key Pairs (OKP). Do not assume
that keys using this type are elliptic curves. This key type could
be used for other curve types (for example, mathematics based on
hyper-elliptic surfaces).
The key parameters defined in this section are summarized in
Table 24. The members that are defined for this key type are:
crv: This contains an identifier of the curve to be used with the
key. The curves defined in this document for this key type can
be found in Table 22. Other curves may be registered in the
future and private curves can be used as well.
x: This contains the x-coordinate for the EC point. The octet
string represents a little-endian encoding of x.
d: This contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure. For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure. For private keys, it is RECOMMENDED that
'x' also be present, but it can be recomputed from the required
elements and omitting it saves on space.
+------+-------+-------+--------+-----------------------------------+
| Name | Key | Label | Type | Description |
| | Type | | | |
+------+-------+-------+--------+-----------------------------------+
| crv | 1 | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Key Common Parameters" |
| | | | | registry |
| x | 1 | -2 | bstr | x-coordinate |
| d | 1 | -4 | bstr | Private key |
+------+-------+-------+--------+-----------------------------------+
Table 24: Octet Key Pair Parameters
13.3. Symmetric Keys
Occasionally it is required that a symmetric key be transported
between entities. This key structure allows for that to happen.
For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The
member that is defined for this key type is:
k: This contains the value of the key.
This key structure does not have a form that contains only public
members. As it is expected that this key structure is going to be
transmitted, care must be taken that it is never transmitted
accidentally or insecurely. For symmetric keys, it is REQUIRED that
'k' be present in the structure.
+------+----------+-------+------+-------------+
| Name | Key Type | Label | Type | Description |
+------+----------+-------+------+-------------+
| k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+
Table 25: Symmetric Key Parameters
14. CBOR Encoder Restrictions
There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. We have managed to narrow it down to the following restrictions: o The restriction applies to the encoding of the Sig_structure, the Enc_structure, and the MAC_structure. o The rules for "Canonical CBOR" (Section 3.9 of RFC 7049) MUST be used in these locations. The main rule that needs to be enforced is that all lengths in these structures MUST be encoded such that they are using definite lengths, and the minimum length encoding is used. o Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse and process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application, and the application can perform the check for duplicate keys.15. Application Profiling Considerations
This document is designed to provide a set of security services, but not implementation requirements for specific usage. The interoperability requirements are provided for how each of the individual services are used and how the algorithms are to be used for interoperability. The requirements about which algorithms and which services are needed are deferred to each application. An example of a profile can be found in [OSCOAP] where two profiles are being developed. One is for carrying content by itself, and the other is for carrying content in combination with CoAP headers. It is intended that a profile of this document be created that defines the interoperability requirements for that specific application. This section provides a set of guidelines and topics that need to be considered when profiling this document. o Applications need to determine the set of messages defined in this document that they will be using. The set of messages corresponds fairly directly to the set of security services that are needed and to the security levels needed.
o Applications may define new header parameters for a specific
purpose. Applications will often times select specific header
parameters to use or not to use. For example, an application
would normally state a preference for using either the IV or the
Partial IV parameter. If the Partial IV parameter is specified,
then the application would also need to define how the fixed
portion of the IV would be determined.
o When applications use externally defined authenticated data, they
need to define how that data is encoded. This document assumes
that the data will be provided as a byte stream. More information
can be found in Section 4.3.
o Applications need to determine the set of security algorithms that
are to be used. When selecting the algorithms to be used as the
mandatory-to-implement set, consideration should be given to
choosing different types of algorithms when two are chosen for a
specific purpose. An example of this would be choosing HMAC-
SHA512 and AES-CMAC as different MAC algorithms; the construction
is vastly different between these two algorithms. This means that
a weakening of one algorithm would be unlikely to lead to a
weakening of the other algorithms. Of course, these algorithms do
not provide the same level of security and thus may not be
comparable for the desired security functionality.
o Applications may need to provide some type of negotiation or
discovery method if multiple algorithms or message structures are
permitted. The method can be as simple as requiring
preconfiguration of the set of algorithms to providing a discovery
method built into the protocol. S/MIME provided a number of
different ways to approach the problem that applications could
follow:
* Advertising in the message (S/MIME capabilities) [RFC5751].
* Advertising in the certificate (capabilities extension)
[RFC4262].
* Minimum requirements for the S/MIME, which have been updated
over time [RFC2633] [RFC5751] (note that [RFC2633] has been
obsoleted by [RFC5751]).
16. IANA Considerations
16.1. CBOR Tag Assignment
IANA has assigned the following tags from the "CBOR Tags" registry. The tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 were assigned in the 1 to 23 value range (one byte long when encoded). The tags for COSE_Sign, COSE_Encrypt, and COSE_Mac were assigned in the 24 to 255 value range (two bytes long when encoded). The tags assigned are in Table 1.16.2. COSE Header Parameters Registry
IANA has created a new registry titled "COSE Header Parameters". The registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of the registry are: Name: The name is present to make it easier to refer to and discuss the registration entry. The value is not used in the protocol. Names are to be unique in the table. Label: This is the value used for the label. The label can be either an integer or a string. Registration in the table is based on the value of the label requested. Integer values between 1 and 255 and strings of length 1 are designated as "Standards Action". Integer values from 256 to 65535 and strings of length 2 are designated as "Specification Required". Integer values of greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values in the range -1 to -65536 are "delegated to the COSE Header Algorithm Parameters registry". Integer values less than -65536 are marked as private use. Value Type: This contains the CBOR type for the value portion of the label. Value Registry: This contains a pointer to the registry used to contain values where the set is limited. Description: This contains a brief description of the header field.
Reference: This contains a pointer to the specification defining the
header field (where public).
The initial contents of the registry can be found in Tables 2 and 27.
All of the entries in the "References" column of this registry point
to this document.
Additionally, the label of 0 is to be marked as 'Reserved'.
16.3. COSE Header Algorithm Parameters Registry
IANA has created a new registry titled "COSE Header Algorithm
Parameters". The registry uses the "Expert Review Required"
registration procedure. Expert review guidelines are provided in
Section 16.11.
The columns of the registry are:
Name: The name is present to make it easier to refer to and discuss
the registration entry. The value is not used in the protocol.
Algorithm: The algorithm(s) that this registry entry is used for.
This value is taken from the "COSE Algorithms" registry. Multiple
algorithms can be specified in this entry. For the table, the
algorithm/label pair MUST be unique.
Label: This is the value used for the label. The label is an
integer in the range of -1 to -65536.
Type: This contains the CBOR type for the value portion of the
label.
Description: This contains a brief description of the header field.
Reference: This contains a pointer to the specification defining the
header field (where public).
The initial contents of the registry can be found in Tables 13, 14,
and 19. All of the entries in the "References" column of this
registry point to this document.
16.4. COSE Algorithms Registry
IANA has created a new registry titled "COSE Algorithms". The
registry has been created to use the "Expert Review Required"
registration procedure. Guidelines for the experts are provided in
Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of the registry are: Name: A value that can be used to identify an algorithm in documents for easier comprehension. The name SHOULD be unique. However, the 'Value' field is what is used to identify the algorithm, not the 'name' field. Value: The value to be used to identify this algorithm. Algorithm values MUST be unique. The value can be a positive integer, a negative integer, or a string. Integer values between -256 and 255 and strings of length 1 are designated as "Standards Action". Integer values from -65536 to 65535 and strings of length 2 are designated as "Specification Required". Integer values greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as private use. Description: A short description of the algorithm. Reference: A document where the algorithm is defined (if publicly available). Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'. The initial contents of the registry can be found in Tables 5, 6, 7, 8, 9, 10, 11, 15, 16, 17, 18, and 20. All of the entries in the "References" column of this registry point to this document. All of the entries in the "Recommended" column are set to "Yes". Additionally, the label of 0 is to be marked as 'Reserved'. NOTE: The assignment of algorithm identifiers in this document was done so that positive numbers were used for the first layer objects (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and COSE_Mac0). Negative numbers were used for second layer objects (COSE_Signature and COSE_recipient). Expert reviewers should consider this practice, but are not expected to be restricted by this precedent.
16.5. COSE Key Common Parameters Registry
IANA has created a new registry titled "COSE Key Common Parameters". The registry has been created to use the "Expert Review Required" registration procedure. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of the registry are: Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding. Label: The value to be used to identify this algorithm. Key map labels MUST be unique. The label can be a positive integer, a negative integer, or a string. Integer values between 0 and 255 and strings of length 1 are designated as "Standards Action". Integer values from 256 to 65535 and strings of length 2 are designated as "Specification Required". Integer values of greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values in the range -65536 to -1 are "used for key parameters specific to a single algorithm delegated to the COSE Key Type Parameters registry". Integer values less than -65536 are marked as private use. CBOR Type: This field contains the CBOR type for the field. Value Registry: This field denotes the registry that values come from, if one exists. Description: This field contains a brief description for the field. Reference: This contains a pointer to the public specification for the field if one exists. This registry has been initially populated by the values in Table 3. All of the entries in the "References" column of this registry point to this document.16.6. COSE Key Type Parameters Registry
IANA has created a new registry titled "COSE Key Type Parameters". The registry has been created to use the "Expert Review Required" registration procedure. Expert review guidelines are provided in Section 16.11.
The columns of the table are:
Key Type: This field contains a descriptive string of a key type.
This should be a value that is in the "COSE Key Common Parameters"
registry and is placed in the 'kty' field of a COSE Key structure.
Name: This is a descriptive name that enables easier reference to
the item. It is not used in the encoding.
Label: The label is to be unique for every value of key type. The
range of values is from -65536 to -1. Labels are expected to be
reused for different keys.
CBOR Type: This field contains the CBOR type for the field.
Description: This field contains a brief description for the field.
Reference: This contains a pointer to the public specification for
the field if one exists.
This registry has been initially populated by the values in Tables
23, 24, and 25. All of the entries in the "References" column of
this registry point to this document.
16.7. COSE Key Types Registry
IANA has created a new registry titled "COSE Key Types". The
registry has been created to use the "Expert Review Required"
registration procedure. Expert review guidelines are provided in
Section 16.11.
The columns of this table are:
Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the
encoding.
Value: This is the value used to identify the curve. These values
MUST be unique. The value can be a positive integer, a negative
integer, or a string.
Description: This field contains a brief description of the curve.
References: This contains a pointer to the public specification for
the curve if one exists.
This registry has been initially populated by the values in Table 21. The specification column for all of these entries will be this document.16.8. COSE Elliptic Curves Registry
IANA has created a new registry titled "COSE Elliptic Curves". The registry has been created to use the "Expert Review Required" registration procedure. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of the table are: Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding. Value: This is the value used to identify the curve. These values MUST be unique. The integer values from -256 to 255 are designated as "Standards Action". The integer values from 256 to 65535 and -65536 to -257 are designated as "Specification Required". Integer values over 65535 are designated as "Expert Review". Integer values less than -65536 are marked as private use. Key Type: This designates the key type(s) that can be used with this curve. Description: This field contains a brief description of the curve. Reference: This contains a pointer to the public specification for the curve if one exists. Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'. This registry has been initially populated by the values in Table 22. All of the entries in the "References" column of this registry point to this document. All of the entries in the "Recommended" column are set to "Yes".
16.9. Media Type Registrations
16.9.1. COSE Security Message
This section registers the 'application/cose' media type in the "Media Types" registry. These media types are used to indicate that the content is a COSE message. Type name: application Subtype name: cose Required parameters: N/A Optional parameters: cose-type Encoding considerations: binary Security considerations: See the Security Considerations section of RFC 8152. Interoperability considerations: N/A Published specification: RFC 8152 Applications that use this media type: IoT applications sending security content over HTTP(S) transports. Fragment identifier considerations: N/A Additional information: * Deprecated alias names for this type: N/A * Magic number(s): N/A * File extension(s): cbor * Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG
Provisional registration? No
16.9.2. COSE Key Media Type
This section registers the 'application/cose-key' and 'application/
cose-key-set' media types in the "Media Types" registry. These media
types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object.
The template for registering 'application/cose-key' is:
Type name: application
Subtype name: cose-key
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations section
of RFC 8152.
Interoperability considerations: N/A
Published specification: RFC 8152
Applications that use this media type: Distribution of COSE based
keys for IoT applications.
Fragment identifier considerations: N/A
Additional information:
* Deprecated alias names for this type: N/A
* Magic number(s): N/A
* File extension(s): cbor
* Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG
Provisional registration? No
The template for registering 'application/cose-key-set' is:
Type name: application
Subtype name: cose-key-set
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations section
of RFC 8152.
Interoperability considerations: N/A
Published specification: RFC 8152
Applications that use this media type: Distribution of COSE based
keys for IoT applications.
Fragment identifier considerations: N/A
Additional information:
* Deprecated alias names for this type: N/A
* Magic number(s): N/A
* File extension(s): cbor
* Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG
Provisional registration? No
16.10. CoAP Content-Formats Registry
IANA has added the following entries to the "CoAP Content-Formats"
registry.
+--------------------------------------+----------+-----+-----------+
| Media Type | Encoding | ID | Reference |
+--------------------------------------+----------+-----+-----------+
| application/cose; cose-type="cose- | | 98 | [RFC8152] |
| sign" | | | |
| application/cose; cose-type="cose- | | 18 | [RFC8152] |
| sign1" | | | |
| application/cose; cose-type="cose- | | 96 | [RFC8152] |
| encrypt" | | | |
| application/cose; cose-type="cose- | | 16 | [RFC8152] |
| encrypt0" | | | |
| application/cose; cose-type="cose- | | 97 | [RFC8152] |
| mac" | | | |
| application/cose; cose-type="cose- | | 17 | [RFC8152] |
| mac0" | | | |
| application/cose-key | | 101 | [RFC8152] |
| application/cose-key-set | | 102 | [RFC8152] |
+--------------------------------------+----------+-----+-----------+
Table 26: CoAP Content-Formats for COSE
16.11. Expert Review Instructions
All of the IANA registries established in this document are defined
as expert review. This section gives some general guidelines for
what the experts should be looking for, but they are being designated
as experts for a reason, so they should be given substantial
latitude.
Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered, and that the point is likely to be used in
deployments. The zones tagged as private use are intended for
testing purposes and closed environments; code points in other
ranges should not be assigned for testing.
o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that
size.
o When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of the
algorithm. Another thing that should be considered is requesting
an opinion on the algorithm from the Crypto Forum Research Group
(CFRG). Algorithms that do not meet the security requirements of
the community and the messages structures should not be
registered.
17. Security Considerations
There are a number of security considerations that need to be taken
into account by implementers of this specification. The security
considerations that are specific to an individual algorithm are
placed next to the description of the algorithm. While some
considerations have been highlighted here, additional considerations
may be found in the documents listed in the references.
Implementations need to protect the private key material for any
individuals. There are some cases in this document that need to be
highlighted on this issue.
o Using the same key for two different algorithms can leak
information about the key. It is therefore recommended that keys
be restricted to a single algorithm.
o Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm exposes the direct key to the second
recipient.
o Several of the algorithms in this document have limits on the
number of times that a key can be used without leaking information
about the key.
The use of ECDH and direct plus KDF (with no key wrap) will not
directly lead to the private key being leaked; the one way function
of the KDF will prevent that. There is, however, a different issue
that needs to be addressed. Having two recipients requires that the
CEK be shared between two recipients. The second recipient therefore
has a CEK that was derived from material that can be used for the
weak proof of origin. The second recipient could create a message
using the same CEK and send it to the first recipient; the first
recipient would, for either static-static ECDH or direct plus KDF,
make an assumption that the CEK could be used for proof of origin
even though it is from the wrong entity. If the key wrap step is
added, then no proof of origin is implied and this is not an issue.
Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak
information about a key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems. Key
creators and key consumers are strongly encouraged not only to create
new keys for each different algorithm, but to include that selection
of algorithm in any distribution of key material and strictly enforce
the matching of algorithms in the key structure to algorithms in the
message structure. In addition to checking that algorithms are
correct, the key form needs to be checked as well. Do not use an
'EC2' key where an 'OKP' key is expected.
Before using a key for transmission, or before acting on information
received, a trust decision on a key needs to be made. Is the data or
action something that the entity associated with the key has a right
to see or a right to request? A number of factors are associated
with this trust decision. Some of the ones that are highlighted here
are:
o What are the permissions associated with the key owner?
o Is the cryptographic algorithm acceptable in the current context?
o Have the restrictions associated with the key, such as algorithm
or freshness, been checked and are they correct?
o Is the request something that is reasonable, given the current
state of the application?
o Have any security considerations that are part of the message been
enforced (as specified by the application or 'crit' parameter)?
There are a large number of algorithms presented in this document
that use nonce values. For all of the nonces defined in this
document, there is some type of restriction on the nonce being a
unique value either for a key or for some other conditions. In all
of these cases, there is no known requirement on the nonce being both
unique and unpredictable; under these circumstances, it's reasonable
to use a counter for creation of the nonce. In cases where one wants
the pattern of the nonce to be unpredictable as well as unique, one
can use a key created for that purpose and encrypt the counter to
produce the nonce value.
One area that has been starting to get exposure is doing traffic
analysis of encrypted messages based on the length of the message.
This specification does not provide for a uniform method of providing
padding as part of the message structure. An observer can
distinguish between two different strings (for example, 'YES' and
'NO') based on the length for all of the content encryption
algorithms that are defined in this document. This means that it is
up to the applications to document how content padding is to be done
in order to prevent or discourage such analysis. (For example, the
strings could be defined as 'YES' and 'NO '.)
(page 90 continued on part 6)
