Draft: draft-ietf-cose-msg

Commentary: Add text dealing with expert reviews and with application profiling .
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  As
the IV is authenticated by the encryption process, it can be
placed in the unprotected header bucket.
Some applications may also use this value for doing replay
protection.  When this is done, the value will normally be defined
by the application to be increasing in value for every message.
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  The
IV used for the cryptographic computation is constructed by
concatenating the fixed portion of the IV and the changing portion
of the IV in order.  (The partial IV being treated as a binary
string for this purpose.)  As the IV is authenticated by the
encryption process, this value can be placed in the unprotected
header bucket.
Some applications may also use this value for doing replay
protection.  When this is done, the value will normally be defined
by the application to be increasing in value for every message.
Encoding it as an integer value makes it easier to do this
comparison.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF8] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.
It is expected that COSE is going to be used in a wide variety of
applications and on a wide variety of devices.  Many of the
constrained devices are going to be setup to use a small fixed set of
algorithms, and this set of algorithms may not match those available
on a device.  We therefore have deferred to the application protocols
the decision of what to specify for mandatory algorithms.
This document is designed to provide a set of security services, but
not to provide 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 is deferred to each application.
Applications are therefore intended to profile the usage of this
document.  This section provides a set of guidelines and topics that
applications need to consider when using this document.
Applications need to determine the set of messages defined in this
document that it 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.
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.
Advertising in the certificate (capabilities extension)
RFC4262.
Minimum requirements for the S/MIME, which have been updated
over time RFC5751.
It is requested that IANA create a new registry entitled "COSE Header
Parameters".  The registery is to be created as Expert Review
Required.
It is requested that IANA create a new registry entitled "COSE Header
Algorithm Labels".  The registery is to be created as Expert Review
Required.
It is requested that IANA create a new registry entitled "COSE
Algorithm Registry".  The registery is to be created as Expert Review
Required.
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 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
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
first come, first served.  Integer values in the range -1 to
-65536 are delegated to the "COSE Header Algorithm Label"
registry.  Integer values beyond -65536 are marked as private use.
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 Track Document
required.  Integer values from -65536 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 first come, first served.  Integer values beyond
-65536 are marked as private use.
It is requested that IANA create a new registry entitled "COSE Key
Common Parameter" Registry.  The registery is to be created as Expert
Review Required.
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 Track Document required.
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
first come, first served.  Integer values in the range -1 to
-65536 are used for key parameters specific to a single algorithm
delegated to the "COSE Key Parameter Label" registry.  Integer
values beyond -65536 are marked as private use.
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 Track Document required.
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
first come, first served.  Integer values in the range -1 to
-65536 are used for key parameters specific to a single algorithm
delegated to the "COSE Key Type Parameter Label" registry.
Integer values beyond -65536 are marked as private use.
It is requested that IANA create a new registry "COSE Key Type
Parameters".  The registery is to be created as Expert Review
Required.
It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters".  The registery is to be created as Expert Review
Required.
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.
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 should not be assigned for
testing.
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 inoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what point is
being used for.
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.  Some
of the ranges are restricted in range, items which are not
expected to be common or are not expected to be used in restricted
environments should be assigned to values which will encode to
longer byte strings.
When algorithms are registered, vanity registrations should be
discouraged.  One way to do this is to require applications to
provide additional documentation on security analysis of
algorithms.  Another thing that should be considered is to request
for an opinion on the algorithm from the Cryptographic Forum
Research Group.  Algorithm which do not meet the security
requirements of the community and the messages structures should
not be registered.