OK here is my concept of where things are and how to fix the
SMIMECaptabliites naming problem:
1. The OID should be refered to by the smimeCapibilities name. (Like
Blake I want to spite the standard, but I don't want to live with the
result.)
This changes appendix A.5 to
smimeCapabilities OBJECT IDENTIFIER ::= ....
2. The ASN structures is referenced by the name SMIMECapabilities
This changes appendix A to
SMIMECapabilities := SEQUENCE OF SMIMECapability
3. The Attribute (which is the combination of the capabilities and the
OID) is referenced by the name S/MIME Capabilities Attribute.
The attribute name references is consistant with what is done in section
2.5.1 with the Signing-Time Attrbute (neither the OID or the ASN is
specified here). It also seperates the pair of items from the indivual
items.
Thus 2.5.2 becomes (note that I have done more changes than just
changing sMIMECapabilies to S/MIME Capabilies, I have also adjusted some
wording as well).
2.5.2 S/MIME Capabilities Attribute
The S/MIME capabilities attribute includes signature algorithms (such as
"md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and
key
encipherment algorithms (such as "rsaEncryption"). It also includes a
non-algorithm capability which is the preference for signedData.
SMIMECapabilities was
designed to be flexible and extensible so that, in
the future, a means of identifying other capabilities and preferences
such
as certificates can be added in a way that will not cause current
clients
to break.
The semantics of the S/MIME capabilites attribute specify a partial list
as
to what the client announcing the SMIMECapabilites can support. A client
does not have to list every capability it supports, and probably should
not
list all its capabilities so that the capabilities list doesn't get too
long. In an SMIMECapabilities encoding, the OIDs are listed in order of
their preference, but SHOULD be logically separated along the lines of
their categories (signature algorithms, symmetric algorithms, key
encipherment algorithms, etc.)
The structure of SMIMECapabilities was designed to facilitate simple
table lookups and binary comparisons in order to determine matches. For
instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST
be
identically encoded regardless of the implementation.
In the case of symmetric algorithms, the associated parameters for the
OID
MUST specify all of the parameters necessary to differentiate between
two
instances of the same algorithm. For instance, the number of rounds and
block size for RC5 must be specified in addition to the key length.
There is a list of OIDs (the registered SMIMECapability list) that is
centrally maintained and is separate from this draft. The list of OIDs
is
maintained by the Internet Mail Consortium at
<http://www.imc.org/ietf-smime/oids.html>.
The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is
ambiguous
from the OID. For instance, in an earlier draft, rsaEncryption was
ambiguous because it could refer to either a signature algorithm or a
key
encipherment algorithm. In the event that an OID is ambiguous, it needs
to
be arbitrated by the maintainer of the registered S/MIME capabilities
list as
to which type of algorithm will use the OID, and a new OID MUST be
allocated under the smimeCapabilities OID to satisfy the other use of
the
OID.
The registered S/MIME capabilities list specifies the parameters for
OIDs
that need them, most notably key lengths in the case of variable-length
symmetric ciphers. In the event that there are no differentiating
parameters for a particular OID, the parameters MUST be omitted, and
MUST
NOT be encoded as NULL.
Additional values for SMIMECapability may be defined in the
future. Receiving agents MUST handle a SMIMECapabilities object that has
values that it does not recognize in a graceful manner.