RFC 5934
Trust Anchor Management Protocol (TAMP)
5. Status Codes
The Trust Anchor Update Confirm, the Apex Trust Anchor Update Confirm, the Community Update Confirm, the Sequence Number Adjust Confirm, and the TAMP Error messages include status codes. The syntax for the status codes is: StatusCode ::= ENUMERATED { success (0), decodeFailure (1), badContentInfo (2), badSignedData (3), badEncapContent (4), badCertificate (5), badSignerInfo (6), badSignedAttrs (7), badUnsignedAttrs (8), missingContent (9), noTrustAnchor (10),
notAuthorized (11),
badDigestAlgorithm (12),
badSignatureAlgorithm (13),
unsupportedKeySize (14),
unsupportedParameters (15),
signatureFailure (16),
insufficientMemory (17),
unsupportedTAMPMsgType (18),
apexTAMPAnchor (19),
improperTAAddition (20),
seqNumFailure (21),
contingencyPublicKeyDecrypt (22),
incorrectTarget (23),
communityUpdateFailed (24),
trustAnchorNotFound (25),
unsupportedTAAlgorithm (26),
unsupportedTAKeySize (27),
unsupportedContinPubKeyDecryptAlg (28),
missingSignature (29),
resourcesBusy (30),
versionNumberMismatch (31),
missingPolicySet (32),
revokedCertificate (33),
unsupportedTrustAnchorFormat (34),
improperTAChange (35),
malformed (36),
cmsError (37),
unsupportedTargetIdentifier (38),
other (127) }
The various values of StatusCode are used as follows:
o success is used to indicate that an update, portion of an update,
or adjust was processed successfully.
o decodeFailure is used to indicate that the trust anchor store was
unable to successfully decode the provided message. The specified
content type and the provided content do not match.
o badContentInfo is used to indicate that the ContentInfo syntax is
invalid or that the contentType carried within the ContentInfo is
unknown or unsupported.
o badSignedData is used to indicate that the SignedData syntax is
invalid, the version is unknown or unsupported, or more than one
entry is present in digestAlgorithms.
o badEncapContent is used to indicate that the
EncapsulatedContentInfo syntax is invalid. This error can be
generated due to problems located in SignedData.
o badCertificate is used to indicate that the syntax for one or more
certificates in CertificateSet is invalid.
o badSignerInfo is used to indicate that the SignerInfo syntax is
invalid, or the version is unknown or unsupported.
o badSignedAttrs is used to indicate that the signedAttrs syntax
within SignerInfo is invalid.
o badUnsignedAttrs is used to indicate that the unsignedAttrs syntax
within SignerInfo is invalid.
o missingContent is used to indicate that the OPTIONAL eContent is
missing in EncapsulatedContentInfo, which is REQUIRED in this
specification. This error can be generated due to problems
located in SignedData.
o noTrustAnchor is used to indicate one of two possible error
situations. In one case, the subjectKeyIdentifier does not
identify the public key of a trust anchor or a certification path
that terminates with an installed trust anchor. In the other
case, the issuerAndSerialNumber is used to identify the TAMP
message signer, which is prohibited by this specification.
o notAuthorized is used to indicate one of two possible error
situations. In one case, the sid within SignerInfo leads to an
installed trust anchor, but that trust anchor is not an authorized
signer for the received TAMP message content type. Identity trust
anchors are not authorized signers for any of the TAMP message
content types. In the other case, the signer of a Trust Anchor
Update message is not authorized to manage the to-be-updated trust
anchor as determined by a failure of the subordination processing
in Section 7.
o badDigestAlgorithm is used to indicate that the digestAlgorithm in
either SignerInfo or SignedData is unknown or unsupported.
o badSignatureAlgorithm is used to indicate that the
signatureAlgorithm in SignerInfo is unknown or unsupported.
o unsupportedKeySize is used to indicate that the signatureAlgorithm
in SignerInfo is known and supported, but the TAMP message digital
signature could not be validated because an unsupported key size
was employed by the signer.
o unsupportedParameters is used to indicate that the
signatureAlgorithm in SignerInfo is known, but the TAMP message
digital signature could not be validated because unsupported
parameters were employed by the signer.
o signatureFailure is used to indicate that the signatureAlgorithm
in SignerInfo is known and supported, but the digital signature in
the signature field within SignerInfo could not be validated.
o insufficientMemory indicates that the update could not be
processed because the trust anchor store did not have sufficient
memory to store the resulting trust anchor configuration or
community identifier.
o unsupportedTAMPMsgType indicates that the TAMP message could not
be processed because the trust anchor store does not support the
provided TAMP message type. This code will be used if the
id-ct-TAMP-communityUpdate content type is provided and the trust
anchor store does not support the Community Update message. This
status code will also be used if the contentType value within
eContentType is not one that is defined in this specification.
o apexTAMPAnchor indicates that the update could not be processed
because the Trust Anchor Update message tried to remove the apex
trust anchor.
o improperTAAddition indicates that a trust anchor update is trying
to add a new trust anchor that may already exist, but some
attributes of the to-be-added trust anchor are being modified in
an improper manner. The desired trust anchor configuration may be
attainable with a change operation instead of an add operation.
o seqNumFailure indicates that the TAMP message could not be
processed because the processing of the sequence number, which is
described in Section 6, resulted in an error.
o contingencyPublicKeyDecrypt indicates that the update could not be
processed because an error occurred while decrypting the
contingency public key.
o incorrectTarget indicates that the query, update, or adjust
message could not be processed because the trust anchor store is
not the intended recipient.
o communityUpdateFailed indicates that the community update
requested the addition of a community identifier or the removal of
a community identifier, but the request could not be honored.
o trustAnchorNotFound indicates that a change to a trust anchor was
requested, but the referenced trust anchor is not represented in
the trust anchor store.
o unsupportedTAAlgorithm indicates that an update message would
result in the trust anchor with a public key associated with a
digital signature validation algorithm that is not implemented.
In addition, this status code is used if the algorithm is
supported, but the parameters associated with the algorithm are
not supported.
o unsupportedTAKeySize indicates that the trust anchor would include
a public key of a size that is not supported.
o unsupportedContinPubKeyDecryptAlg indicates that the decryption
algorithm for the apex trust anchor contingency public key is not
supported.
o missingSignature indicates that an unsigned TAMP message was
received, but the received TAMP message type MUST be signed.
o resourcesBusy indicates that the resources necessary to process
the TAMP message are not available at the present time, but the
resources might be available at some point in the future.
o versionNumberMismatch indicates that the version number in a
received TAMP message is not acceptable.
o missingPolicySet indicates that the policyFlags associated with a
trust anchor are set in a fashion that requires the policySet to
be present, but the policySet is missing.
o revokedCertificate indicates that one or more of the certificates
needed to properly process the TAMP message have been revoked.
o unsupportedTrustAnchorFormat indicates that an unsupported trust
anchor format was presented or the version is unknown or
unsupported.
o improperTAChange indicates that a trust anchor update is trying to
change a new trust anchor using a format different than the format
of the existing trust anchor.
o malformed indicates an error in the composition of the CMS
structure encapsulating a TAMP message.
o cmsError indicates an error processing a CMS structure that
encapsulated a TAMP message, such as an error processing
ContentType or MessageDigest attributes.
o unsupportedTargetIdentifier indicates that a msgRef with an
unsupported TargetIdentifier option was encountered.
o other indicates that the update could not be processed, but the
reason is not covered by any of the assigned status codes. Use of
this status code SHOULD be avoided.
6. Sequence Number Processing
The sequence number processing facilities in TAMP represent a balance
between replay protection, operational considerations, and trust
anchor store memory management. The goal is to provide replay
protection without making TAMP difficult to use, creating an
environment where surprising error conditions occur on a regular
basis, or imposing onerous memory management requirements on
implementations. This balance is achieved by performing sequence
number checking on TAMP messages that are validated directly using a
trust anchor, and allowing these checks to be skipped whenever the
TAMP message originator is not represented by a trust anchor.
Implementations MUST perform sequence number checking on TAMP
messages that are validated directly using a trust anchor and MAY
perform sequence number checking for TAMP messages validated using a
certification path.
The TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update,
Community Update, and Sequence Number Adjust messages include a
sequence number. This single-use identifier is used to match a TAMP
message with the response to that TAMP message. When the TAMP
message is validated directly using a trust anchor, the sequence
number is also used to detect TAMP message replay.
To provide replay protection, each TAMP message originator MUST treat
the sequence number as a monotonically increasing non-negative
integer. The sequence number counter is associated with the signing
operation performed by the private key. The trust anchor store MUST
ensure that a newly received TAMP message that is validated directly
by a trust anchor public key contains a sequence number that is
greater than the most recent successfully processed TAMP message from
that originator. Note that the Sequence Number Adjust message is
considered valid if the sequence number is greater than or equal to
the most recent successfully processed TAMP message from that
originator. If the sequence number in a received TAMP message does not meet these conditions, then the trust anchor store MUST reject the TAMP message, returning a sequence number failure (seqNumFailure) error. Whenever a trust anchor is authorized for TAMP messages, either as a newly installed trust anchor or as a modification to an existing trust anchor, if a sequence number value is not provided in the Trust Anchor Update message, memory MUST be allocated for the sequence number and set to zero. The first TAMP message received that is validated using that trust anchor is not rejected based on sequence number checks, and the sequence number from that first TAMP message is stored. The TAMP message recipient MUST maintain a database of the most recent sequence number from a successfully processed TAMP message from a trust anchor. The index for this database is the trust anchor public key. This could be the apex trust anchor operational public key or a management trust anchor public key. In the first case, the apex trust anchor operational public key is used directly to validate the TAMP message digital signature. In the second case, a management trust anchor public key is used directly to validate the TAMP message digital signature. Sequence number values MUST be 64-bit non-negative integers. Since ASN.1 encoding of an INTEGER always includes a sign bit, a TAMP message signer can generate 9,223,372,036,854,775,807 TAMP messages before exhausting the 64-bit sequence number space, before which the TAMP message signer MUST transition to a different public/private key pair. The ability to reset a sequence number provided by the Trust Anchor Update and Sequence Number Adjust messages is not intended to avoid the transition to a different key pair; rather, it is intended to aid recovery from operational errors. A relatively small non- volatile storage requirement is imposed on the trust anchor store for the apex trust anchor and each management trust anchor authorized for TAMP messages. When the apex trust anchor or a management trust anchor is replaced or removed from the trust anchor store, the associated sequence number storage SHOULD be reclaimed.7. Subordination Processing
When a TAMP update message is processed, several checks are performed: o TAMP message authentication is checked including, if necessary, building and validating a certification path to the signer.
o The signer's authorization is checked, including authorization to
manage trust anchors included in the update message.
o Calculation of the trust anchor information to be stored.
This section describes how to perform the second and third steps.
Section 1.2 discusses authentication of TAMP messages. Where a trust
anchor is represented as a certificate and the calculation of the
trust anchor information to be stored is different than the
information in the certificate, the TAMP update fails. The TAMP
message signer may then wrap the certificate inside a TrustAnchorInfo
structure to assert the intended information.
The apex trust anchor is unconstrained, which means that
subordination checking need not be performed on Trust Anchor Update
messages signed with the apex trust anchor operational public key and
that trust anchor information can be stored as it appears in the
update message. Subordination checking is performed as part of the
validation process of all other Trust Anchor Update messages.
For a Trust Anchor Update message that is not signed with the apex
trust anchor operational public key to be valid, the digital
signature MUST be validated using an authorized trust anchor, either
directly or via an X.509 certification path originating with the apex
trust anchor operational public key or an authorized management trust
anchor. The following subordination checks MUST also be performed as
part of validation of the update message.
Each Trust Anchor Update message contains one or more individual
updates, each of which is used to add, modify, or remove a trust
anchor. For each individual update, the constraints of the TAMP
message signer MUST be greater than or equal to the constraints of
the trust anchor in the update. Specifically, constraints included
in the CertPathControls field of a TrustAnchorInfo object (or
equivalent extensions in Certificate or TBSCertificate objects) must
be checked as described below. [RFC5280] describes how the
intersection and union operations referenced below are performed.
o The values of the policy flags stored with a trust anchor as the
result of a TAMPUpdate are either true or equal to the value of
the policy flags associated with the TAMP message signer, i.e., an
update may set a flag to false only if the value associated with
the TAMP message signer is false. The policy flags associated
with the TAMP message signer are read from the policyFlags field
or policyConstraints and inhibitAnyPolicy extensions if the signer
is represented as a trust anchor or from the explicit_policy,
policy_mapping, and inhibit_anyPolicy state variables following
path validation if the signer is not represented as a trust
anchor.
o The certificate policies stored with a trust anchor as the result
of a TAMPUpdate are equal to the intersection of the value of the
certificate policies associated with the TAMP message signer and
the value of the policySet field or certificatePolicies extension
from the update. The certificate policies associated with the
TAMP message signer are read from the policySet field in a
TrustAnchorInfo or certificatePolicies extension in a Certificate
or TBSCertificate if the signer is represented as a trust anchor
or from the valid_policy_tree returned following path validation
if the signer is not represented by a trust anchor. Where the
TAMP message signer is represented as a trust anchor, no policy
mapping is performed. If the intersection is NULL and the
to-be-stored requireExplicitPolicy value is true, the TAMP update
fails.
o The excluded names stored with a trust anchor as the result of a
TAMPUpdate are equal to the union of the excluded names associated
with the TAMP message signer and the value from the nameConstr
field or nameConstraints extension from the update. The name
constraints associated with the TAMP message signer are read from
the nameConstr field in a TrustAnchorInfo or nameConstraints
extension in a Certificate or TBSCertificate if the signer is a
trust anchor or from the excludedSubtrees state variable following
path validation if the signer is not a trust anchor. The name of
the trust anchor included in the update MUST NOT fall within the
excluded name space of the TAMP signer. If the name of the trust
anchor falls within the excluded name space of the TAMP signer,
the TAMP update fails.
o The permitted names stored with a trust anchor as the result of a
TAMPUpdate are equal to the intersection of the permitted names
associated with the TAMP message signer and the value from the
nameConstr field or nameConstraints extension from the update.
The name constraints associated with the TAMP message signer are
read from the nameConstr field in a TrustAnchorInfo or
nameConstraints extension in a Certificate or TBSCertificate if
the signer is a trust anchor or from the permittedSubtrees state
variable following path validation if the signer is not a trust
anchor. The name of the trust anchor included in the update MUST
fall within the permitted name space of the TAMP signer. If the
name of the trust anchor does not fall within the permitted name
space of the TAMP signer, the TAMP update fails. If the
intersection is NULL for all name forms, the TAMP update fails.
No other extensions defined in [RFC5280] must be processed as part of subordination processing. Other extensions may define subordination rules.8. Implementation Considerations
A public key identifier is used to identify a TAMP message signer. Since there is no guarantee that the same public key identifier is not associated with more than one public key, implementations MUST be prepared for one or more trust anchors to have the same public key identifier. In practical terms, this means that when a digital signature validation fails, the implementation MUST see if there is another trust anchor with the same public key identifier that can be used to validate the digital signature. While duplicate public key identifiers are expected to be rare, implementations MUST NOT fail to find the correct trust anchor when they do occur. An X.500 distinguished name is used to identify certificate issuers and certificate subjects. The same X.500 distinguished name can be associated with more than one trust anchor. However, the trust anchor public key will be different. The probability that two trust anchors will have the same X.500 distinguished name and the same public key identifier but a different public key is diminishingly small. Therefore, the authority key identifier certificate extension can be used to resolve X.500 distinguished name collisions. TAMP assumes a reliable underlying transport protocol.9. Wrapped Apex Contingency Key Certificate Extension
An apex trust anchor MAY contain contingency key information using the WrappedApexContingencyKey extension. The extension uses the ApexContingencyKey structure as defined below. ApexContingencyKey ::= SEQUENCE { wrapAlgorithm AlgorithmIdentifier OPTIONAL, wrappedContinPubKey OCTET STRING OPTIONAL } The fields of ApexContingencyKey are used as described below. When one field is present, both MUST be present. When one field is absent, both MUST be absent. The fields are allowed to be absent to enable usage of this extension as a means of indicating that the corresponding public key is recognized as an apex trust anchor by some relying parties. o wrapAlgorithm identifies the symmetric algorithm used to encrypt the apex trust anchor contingency public key. If this public key is ever needed, the symmetric key needed to decrypt it will be
provided in the message that is to be validated using it. The
algorithm identifier is an AlgorithmIdentifier, which contains an
object identifier and OPTIONAL parameters. The object identifier
indicates the syntax of the parameters, if present.
o wrappedContinPubKey is the encrypted apex trust anchor contingency
public key. Once decrypted, it yields the PublicKeyInfo
structure, which consists of the algorithm identifier followed by
the public key itself. The algorithm identifier is an
AlgorithmIdentifier that contains an object identifier and
OPTIONAL parameters. The object identifier indicates the format
of the public key and the syntax of the parameters, if present.
The public key is encoded as a BIT STRING.
The WrappedApexContingencyKey certificate extension MAY be critical,
and it MUST appear at most one time in a set of extensions. The apex
trust anchor info extension is identified by the
id-pe-wrappedApexContinKey object identifier:
id-pe-wrappedApexContinKey OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) pe(1) 20 }
10. Security Considerations
The majority of this specification is devoted to the syntax and
semantics of TAMP messages. It relies on other specifications,
especially [RFC5914], [RFC3852], and [RFC5280], for the syntax and
semantics of trust anchors, intermediate CMS content types, and X.509
certificates, respectively. Since TAMP messages that change the
trust anchor state of a trust anchor store are always signed by a
Trust Anchor Manager, no further data integrity or data origin
authentication mechanisms are needed; however, no confidentiality for
these messages is provided. Similarly, certificates are digitally
signed, and no additional data integrity or data origin
authentication mechanisms are needed. Trust anchor configurations,
Trust Anchor Manager certificates, and trust anchor store
certificates are not intended to be sensitive. As a result, this
specification does not provide for confidentiality of TAMP messages.
Security factors outside the scope of this specification greatly
affect the assurance provided. The procedures used by certification
authorities (CAs) to validate the binding of the subject identity to
their public key greatly affect the assurance associated with the
resulting certificate. This is particularly important when issuing
certificates to other CAs. In the context of TAMP, the issuance of
an end entity certificate under a management trust anchor is an act
of delegation. However, such end entities cannot further delegate.
On the other hand, issuance of a CA certificate under a management trust anchor is an act of delegation where the CA can perform further delegation. The scope of the delegation can be constrained by including appropriate certificate extensions in a CA certificate. X.509 certification path construction involves comparison of X.500 distinguished names. Inconsistent application of name comparison rules can result in acceptance of invalid X.509 certification paths or rejection of valid ones. Name comparison can be extremely complex. To avoid imposing this complexity on trust anchor stores, any certificate profile used with TAMP SHOULD employ simple name structures and impose rigorous restrictions on acceptable distinguished names, including the way that they are encoded. The goal of that certificate profile should be to enable simple binary comparison. That is, case conversion, character set conversion, white space compression, and leading and trailing white space trimming SHOULD be avoided. Some digital signature algorithms (DSAs) require the generation of random one-time values. For example, when generating a DSA digital signature, the signer MUST generate a random k value [DSS]. Also, the generation of public/private key pairs relies on random numbers. The use of an inadequate random number generator (RNG) or an inadequate pseudo-random number generator (PRNG) to generate such cryptographic values can result in little or no security. An attacker may find it much easier to reproduce the random number generation environment, searching the resulting small set of possibilities, rather than brute-force searching the whole space. Compromise of an identity trust anchor private key permits unauthorized parties to issue certificates that will be acceptable to all trust anchor stores configured with the corresponding identity trust anchor. The unauthorized private key holder will be limited by the certification path controls associated with the identity trust anchor. For example, clearance constraints in the identity trust anchor will determine the clearances that will be accepted in certificates that are issued by the unauthorized private key holder. Compromise of a management trust anchor private key permits unauthorized parties to generate signed messages that will be acceptable to all trust anchor stores configured with the corresponding management trust anchor. All devices that include the compromised management trust anchor can be configured as desired by the unauthorized private key holder within the limits of the subordination checks described in Section 7. If the management trust anchor is associated with content types other than TAMP, then the unauthorized private key holder can generate signed messages of that
type. For example, if the management trust anchor is associated with firmware packages, then the unauthorized private key holder can install different firmware. Compromise of the apex trust anchor operational private key permits unauthorized parties to generate signed messages that will be acceptable to all trust anchor stores configured with the corresponding apex trust anchor. All devices that include that apex trust anchor can be configured as desired by the unauthorized private key holder, and the unauthorized private key holder can generate signed messages of any content type. The optional contingency private key offers a potential way to recover from such a compromise. The compromise of a CA's private key leads to the same type of problems as the compromise of an identity or a management trust anchor private key. The unauthorized private key holder will be limited by the certification path controls and extensions associated with the trust anchor. The compromise of an end entity private key leads to the same type of problems as the compromise of an identity or a management trust anchor private key, except that the end entity is unable to issue any certificates. The unauthorized private key holder will be limited by the certification path controls and extensions associated with the trust anchor. Compromise of a trust anchor store's digital signature private key permits unauthorized parties to generate signed TAMP response messages, masquerading as the trust anchor store. Premature disclosure of the key-encryption key used to encrypt the apex trust anchor contingency public key may result in early exposure of the apex trust anchor contingency public key. TAMP implementations need to be able to parse messages and certificates. Care must be taken to ensure that there are no implementation defects in the TAMP message parser or the processing that acts on the message content. A validation suite is one way to increase confidence in the parsing of TAMP messages, CMS content types, attributes, certificates, and extensions. TrustAnchorList messages do not provide a replay detection mechanism. Where TrustAnchorList messages are accepted as an alternative means of adding trust anchors to a trust anchor store, applications may require additional mechanisms to address the risks associated with replay of old TrustAnchorList messages.
As sequence number values are used to detect replay attempts, trust anchor store managers must take care to maintain their own sequence number state, i.e., knowledge of which sequence number to include in the next TAMP message generated by the trust anchor store manager. Loss of sequence number state can result in generation of TAMP messages that cannot be processed due to seqNumFailure. In the event of loss, sequence number state can be restored by inspecting the most recently generated TAMP message, provided the messages are logged, or in collaboration with a trust anchor store manager who can successfully issue a TAMPStatusQuery message.11. IANA Considerations
The details of TAMP requests and responses are communicated using object identifiers (OIDs). The objects are defined in an arc delegated by IANA to the PKIX working group. This document also includes eleven media type registrations in Appendix B. No further action by IANA is necessary for this document or any anticipated updates.12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010. [X.680] "ITU-T Recommendation X.680 - Information Technology - Abstract Syntax Notation One", 1997. [X.690] "ITU-T Recommendation X.690 - Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 1997.12.2. Informative References
[DSS] "FIPS Pub 186: Digital Signature Standard", May 1994. [PKCS#6] "PKCS #6: Extended-Certificate Syntax Standard, Version 1.5", November 1993. [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [RFC4049] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005. [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005. [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010. [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010. [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010. [TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", Work in Progress, March 2010.
(next page on part 4)
