]> CryptoNext Security

daniel.vangeest@cryptonext-security.com

Red Hound Software, Inc.

carl@redhoundsoftware.com

Public Key Infrastructure ASN.1 SIGNED type This document updates some ASN.1 modules which conform to the syntax of the 2002 version of ASN.1 but feature constraints that are no longer consistent with usage of the associated structures. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax to better align with current practices. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The data structures used in public key infrastructures (PKIs) were originally defined using the 1988 version of Abstract Syntax Notation One (ASN.1). uses the 1988 syntax, despite ITU's adoption of later ASN.1 versions () in their corresponding specifications. and were written to provide ASN.1 modules that conform to the 2002 version of the syntax for a variety of IETF RFCs. During the migration, various constraint mechanisms that were available in the 2002 syntax were used as an aid to developers. For example, the PKIX-CommonTypes-2009 ASN.1 module of defines the SIGNATURE-ALGORITHM ASN.1 information object class and the SIGNED{ToBeSigned} ASN.1 type. SIGNATURE-ALGORITHM has an optional field, &Value, containing the type definition for the value structure of the signature. If this field is absent, comments in the PKIX1Explicit-2009 module state that no ASN.1 encoding is performed on the value. In , the SIGNED{ToBeSigned} type has a non-optional field, signature, with a CONTAINING clause referring to SIGNATURE-ALGORITHM.&Value. However, it is not valid ASN.1 for a CONTAINING clause to refer to a type which is absent. An ASN.1 syntax checker and compiler may accept this situation (since the type may also be present), but when an encoded ASN.1 information object with an absent &Value field is decoded, the decoder will return an error. This was not the intention of the PKIX1Explicit-2009 module, the intention was that the unencoded signature contents would be used. While the presence of extensibility markers in the corresponding information object sets may have masked problems with the missing field in the object class instantiations in some products, this document aims to remove ambiguities. At time of writing, there are many signature algorithms defining instantiations of the SIGNATURE-ALGORITHM class which don't include the &Value field, namely RSASSA-PSS , RSA PKCS v1.5 , Ed25519 , HSS-LMS , XMSS , SLH-DSA , ML-DSA , sa-unsigned , and Composite ML-DSA . On the other hand, there are fewer signature algorithms instantiating the SIGNATURE-ALGORITHM class which include the &Value field, namely DSA , ECDSA , and sa-noSignature . The ASN.1 module defined in will allow ASN.1 decoders to process signature algorithms from the former set, as well as future SIGNATURE-ALGORITHM instantiations without the &Value field defined. Signature algorithms with the &Value field defined can also use this module, but will not have compiler-assisted constraints applied. This document updates the following RFCs to define ASN.1 modules without ASN.1 CONTAINING clauses that refer to optional information object class fields:

• RFC 5912, New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) . , "ASN.1 Module for RFC 5280, Explicit and Implicit" is updated. Only the explicit module is updated.
• RFC 5958, Asymmetric Key Packages . A commented-out alternative representation of OneAsymmetricKey is removed.

All other definitions, including those with CONTAINING clauses that do not rely on optional information object class fields, remain unchanged.

ASN.1 Module for RFC 5280, Explicit SIGNED{ToBeSigned} is updated to a version with an ASN.1 "User-defined constraint" (see section 9 of ). The SIGNATURE-ALGORITHM.&Value field is optional, and it was not valid for the previous version of the SIGNED{ToBeSigned} signature CONTAINING constraint to reference a non-existent field. This is the only change compared to the PKIX1Explicit-2009 module in . The new SIGNED{ToBeSigned} definition is: The full ASN.1 module is: PKIX1Explicit-2026 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-03(TBD1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS Extensions{}, EXTENSION, ATTRIBUTE, SingleAttribute{} FROM PKIX-CommonTypes-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} AlgorithmIdentifier{}, PUBLIC-KEY, SIGNATURE-ALGORITHM FROM AlgorithmInformation-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58)} CertExtensions, CrlExtensions, CrlEntryExtensions FROM PKIX1Implicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} SignatureAlgs, PublicKeys FROM PKIXAlgs-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 56} SignatureAlgs, PublicKeys FROM PKIX1-PSS-OAEP-Algorithms-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54)} ORAddress FROM PKIX-X400Address-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-x400address-02(60)}; id-pkix OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)} -- PKIX arcs id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } -- arc for private certificate extensions id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } -- arc for policy qualifier types id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- arc for extended key purpose OIDs id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } -- arc for access descriptors -- policyQualifierIds for Internet policy qualifiers id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } -- OID for CPS qualifier id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } -- OID for user notice qualifier -- access descriptor definitions id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } -- attribute data types AttributeType ::= ATTRIBUTE.&id -- Replaced by SingleAttribute{} -- -- AttributeTypeAndValue ::= SEQUENCE { -- type ATTRIBUTE.&id({SupportedAttributes}), -- value ATTRIBUTE.&Type({SupportedAttributes}{@type}) } -- -- Suggested naming attributes: Definition of the following -- information object set may be augmented to meet local -- requirements. Note that deleting members of the set may -- prevent interoperability with conforming implementations. -- All attributes are presented in pairs: the AttributeType -- followed by the type definition for the corresponding -- AttributeValue. -- Arc for standard naming attributes id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } -- Naming attributes of type X520name id-at-name AttributeType ::= { id-at 41 } at-name ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-name } id-at-surname AttributeType ::= { id-at 4 } at-surname ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-surname } id-at-givenName AttributeType ::= { id-at 42 } at-givenName ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-givenName } id-at-initials AttributeType ::= { id-at 43 } at-initials ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-initials } id-at-generationQualifier AttributeType ::= { id-at 44 } at-generationQualifier ATTRIBUTE ::= { TYPE X520name IDENTIFIED BY id-at-generationQualifier } -- Directory string type -- DirectoryString{INTEGER:maxSize} ::= CHOICE { teletexString TeletexString(SIZE (1..maxSize)), printableString PrintableString(SIZE (1..maxSize)), bmpString BMPString(SIZE (1..maxSize)), universalString UniversalString(SIZE (1..maxSize)), uTF8String UTF8String(SIZE (1..maxSize)) } X520name ::= DirectoryString {ub-name} -- Naming attributes of type X520CommonName id-at-commonName AttributeType ::= { id-at 3 } at-x520CommonName ATTRIBUTE ::= {TYPE X520CommonName IDENTIFIED BY id-at-commonName } X520CommonName ::= DirectoryString {ub-common-name} -- Naming attributes of type X520LocalityName id-at-localityName AttributeType ::= { id-at 7 } at-x520LocalityName ATTRIBUTE ::= { TYPE X520LocalityName IDENTIFIED BY id-at-localityName } X520LocalityName ::= DirectoryString {ub-locality-name} -- Naming attributes of type X520StateOrProvinceName id-at-stateOrProvinceName AttributeType ::= { id-at 8 } at-x520StateOrProvinceName ATTRIBUTE ::= { TYPE DirectoryString {ub-state-name} IDENTIFIED BY id-at-stateOrProvinceName } X520StateOrProvinceName ::= DirectoryString {ub-state-name} -- Naming attributes of type X520OrganizationName id-at-organizationName AttributeType ::= { id-at 10 } at-x520OrganizationName ATTRIBUTE ::= { TYPE DirectoryString {ub-organization-name} IDENTIFIED BY id-at-organizationName } X520OrganizationName ::= DirectoryString {ub-organization-name} -- Naming attributes of type X520OrganizationalUnitName id-at-organizationalUnitName AttributeType ::= { id-at 11 } at-x520OrganizationalUnitName ATTRIBUTE ::= { TYPE DirectoryString {ub-organizational-unit-name} IDENTIFIED BY id-at-organizationalUnitName } X520OrganizationalUnitName ::= DirectoryString {ub-organizational-unit-name} -- Naming attributes of type X520Title id-at-title AttributeType ::= { id-at 12 } at-x520Title ATTRIBUTE ::= { TYPE DirectoryString { ub-title } IDENTIFIED BY id-at-title } -- Naming attributes of type X520dnQualifier id-at-dnQualifier AttributeType ::= { id-at 46 } at-x520dnQualifier ATTRIBUTE ::= { TYPE PrintableString IDENTIFIED BY id-at-dnQualifier } -- Naming attributes of type X520countryName (digraph from IS 3166) id-at-countryName AttributeType ::= { id-at 6 } at-x520countryName ATTRIBUTE ::= { TYPE PrintableString (SIZE (2)) IDENTIFIED BY id-at-countryName } -- Naming attributes of type X520SerialNumber id-at-serialNumber AttributeType ::= { id-at 5 } at-x520SerialNumber ATTRIBUTE ::= {TYPE PrintableString (SIZE (1..ub-serial-number)) IDENTIFIED BY id-at-serialNumber } -- Naming attributes of type X520Pseudonym id-at-pseudonym AttributeType ::= { id-at 65 } at-x520Pseudonym ATTRIBUTE ::= { TYPE DirectoryString {ub-pseudonym} IDENTIFIED BY id-at-pseudonym } -- Naming attributes of type DomainComponent (from RFC 2247) id-domainComponent AttributeType ::= { itu-t(0) data(9) pss(2342) ucl(19200300) pilot(100) pilotAttributeType(1) 25 } at-domainComponent ATTRIBUTE ::= {TYPE IA5String IDENTIFIED BY id-domainComponent } -- Legacy attributes pkcs-9 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } id-emailAddress AttributeType ::= { pkcs-9 1 } at-emailAddress ATTRIBUTE ::= {TYPE IA5String (SIZE (1..ub-emailaddress-length)) IDENTIFIED BY id-emailAddress } -- naming data types -- Name ::= CHOICE { -- only one possibility for now -- rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF SingleAttribute { {SupportedAttributes} } -- These are the known name elements for a DN SupportedAttributes ATTRIBUTE ::= { at-name | at-surname | at-givenName | at-initials | at-generationQualifier | at-x520CommonName | at-x520LocalityName | at-x520StateOrProvinceName | at-x520OrganizationName | at-x520OrganizationalUnitName | at-x520Title | at-x520dnQualifier | at-x520countryName | at-x520SerialNumber | at-x520Pseudonym | at-domainComponent | at-emailAddress, ... } -- -- Certificate- and CRL-specific structures begin here -- Certificate ::= SIGNED{TBSCertificate} TBSCertificate ::= SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, ... , [[2: -- If present, version MUST be v2 issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL ]], [[3: -- If present, version MUST be v3 -- extensions [3] Extensions{{CertExtensions}} OPTIONAL ]], ... } Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore Time, notAfter Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier{PUBLIC-KEY, {PublicKeyAlgorithms}}, subjectPublicKey BIT STRING } -- CRL structures CertificateList ::= SIGNED{TBSCertList} TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, MUST be v2 signature AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE SIZE (1..MAX) OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, ... , [[2: -- if present, version MUST be v2 crlEntryExtensions Extensions{{CrlEntryExtensions}} OPTIONAL ]], ... } OPTIONAL, ... , [[2: -- if present, version MUST be v2 crlExtensions [0] Extensions{{CrlExtensions}} OPTIONAL ]], ... } -- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure -- -- The two object sets below should be expanded to include -- those algorithms which are supported by the system. -- -- For example: -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { -- PKIXAlgs-2008.SignatureAlgs, ..., -- - - RFC 3279 provides the base set -- PKIX1-PSS-OAEP-ALGORITHMS.SignatureAlgs | -- - - RFC 4055 provides extension algs -- OtherModule.SignatureAlgs -- - - RFC XXXX provides additional extension algs -- } SignatureAlgorithms SIGNATURE-ALGORITHM ::= { PKIXAlgs-2009.SignatureAlgs, ..., PKIX1-PSS-OAEP-Algorithms-2009.SignatureAlgs } PublicKeyAlgorithms PUBLIC-KEY ::= { PKIXAlgs-2009.PublicKeys, ..., PKIX1-PSS-OAEP-Algorithms-2009.PublicKeys} -- Upper Bounds ub-state-name INTEGER ::= 128 ub-organization-name INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64 ub-title INTEGER ::= 64 ub-serial-number INTEGER ::= 64 ub-pseudonym INTEGER ::= 128 ub-emailaddress-length INTEGER ::= 255 ub-locality-name INTEGER ::= 128 ub-common-name INTEGER ::= 64 ub-name INTEGER ::= 32768 -- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets or twice the specified -- upper bound, whichever is the larger, should be allowed for -- TeletexString. For UTF8String or UniversalString, at least four -- times the upper bound should be allowed. -- Information object classes used in the definition -- of certificates and CRLs -- Parameterized Type SIGNED -- -- Four different versions of doing SIGNED: -- 1. Simple and close to the PKIX1Explicit93 (RFC 2459) version -- -- SIGNED{ToBeSigned} ::= SEQUENCE { -- toBeSigned ToBeSigned, -- algorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM, -- {SignatureAlgorithms}}, -- signature BIT STRING -- } -- -- 2. From Authenticated Framework -- -- SIGNED{ToBeSigned} ::= SEQUENCE { -- toBeSigned ToBeSigned, -- COMPONENTS OF SIGNATURE{ToBeSigned} -- } -- SIGNATURE{ToBeSigned} ::= SEQUENCE { -- algorithmIdentifier AlgorithmIdentifier, -- encrypted ENCRYPTED-HASH{ToBeSigned} -- } -- ENCRYPTED-HASH{ToBeSigned} ::= -- BIT STRING -- (CONSTRAINED BY { -- shall be the result of applying a hashing procedure to -- the DER-encoded (see 4.1) octets of a value of -- ToBeSigned and then applying an encipherment procedure -- to those octets -- }) -- -- -- 3. A more complex version, but one that automatically ties -- together both the signature algorithm and the -- signature value for automatic decoding. -- This is removed in this document. -- -- SIGNED{ToBeSigned} ::= SEQUENCE { -- toBeSigned ToBeSigned, -- algorithmIdentifier SEQUENCE { -- algorithm SIGNATURE-ALGORITHM. -- &id({SignatureAlgorithms}), -- parameters SIGNATURE-ALGORITHM. -- &Params({SignatureAlgorithms} -- {@algorithmIdentifier.algorithm}) -- OPTIONAL -- }, -- signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value( -- {SignatureAlgorithms} -- {@algorithmIdentifier.algorithm})) -- } -- -- 4. Similar to option 1, with ASN.1 user-defined constraints and -- textual descriptions of the signature encodings. SIGNED{ToBeSigned} ::= SEQUENCE { toBeSigned ToBeSigned, algorithmIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgorithms}}, signature BIT STRING (CONSTRAINED BY { ToBeSigned -- with the following processing: -- if -- SIGNATURE-ALGORITHM.&Value { -- @algorithm.algorithm } -- is specified, -- then -- the content of the BIT STRING -- is the DER-encoded &Value type -- representing the calculated -- signature over a DER-encoded value -- of a ToBeSigned (i.e., equivalent to -- a (CONTAINING &Value ENCODED BY der) -- clause) -- Otherwise if &Value is unspecified, -- the content is the array of octets -- representing the opaque (i.e., not -- ASN1) encoded signature with no -- leading type or length }) } END ]]>

ASN.1 Module for RFC 5958 The only change for this module from the AsymmetricKeyPackageModuleV1 module in is to remove the commented-out alternative representation of OneAsymmetricKey which made full use of ASN.1 constraints. The PUBLIC-KEY.&PrivateKey field is optional, and it was not valid for the OneAsymmetricKey privateKey CONTAINING constraint to reference a non-existent field. For an ASN.1 compiler, there is no difference between the AsymmetricKeyPackageModuleV1 and AsymmetricKeyPackageModuleV1-2026 modules. AsymmetricKeyPackageModuleV1-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-asymmetricKeyPkgV1-2026(TBD2) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL IMPORTS -- FROM New SMIME ASN.1 [RFC5911] Attribute{}, CONTENT-TYPE FROM CryptographicMessageSyntax-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } -- From New PKIX ASN.1 [RFC5912] ATTRIBUTE FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } -- From New PKIX ASN.1 [RFC5912] AlgorithmIdentifier{}, ALGORITHM, PUBLIC-KEY, CONTENT-ENCRYPTION FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; ContentSet CONTENT-TYPE ::= { ct-asymmetric-key-package, ... -- Expect additional content types -- } ct-asymmetric-key-package CONTENT-TYPE ::= { AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage } id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) key-package-content-types(78) 5 } AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey OneAsymmetricKey ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] Attributes OPTIONAL, ..., [[2: publicKey [1] PublicKey OPTIONAL ]], ... } PrivateKeyInfo ::= OneAsymmetricKey -- PrivateKeyInfo is used by [P12]. If any items tagged as version -- 2 are used, the version must be v2, else the version should be -- v1. When v1, PrivateKeyInfo is the same as it was in [RFC5208]. Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2) PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier { PUBLIC-KEY, { PrivateKeyAlgorithms } } PrivateKey ::= OCTET STRING -- Content varies based on type of key. The -- algorithm identifier dictates the format of -- the key. PublicKey ::= BIT STRING -- Content varies based on type of key. The -- algorithm identifier dictates the format of -- the key. Attributes ::= SET OF Attribute { { OneAsymmetricKeyAttributes } } OneAsymmetricKeyAttributes ATTRIBUTE ::= { ... -- For local profiles } EncryptedPrivateKeyInfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmIdentifier, encryptedData EncryptedData } EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier { CONTENT-ENCRYPTION, { KeyEncryptionAlgorithms } } EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo PrivateKeyAlgorithms ALGORITHM ::= { ... -- Extensible } KeyEncryptionAlgorithms ALGORITHM ::= { ... -- Extensible } END ]]>

Operational Considerations Code generated using the SIGNED{ToBeSigned} or OneAsymmetricKey definitions featuring a CONTAINING clause may differ from code generated using the definitions provided in this document. The lower level structures previously identified by the information object set used by the CONTAINING clause will not longer be automatically parsed and there will be no automatic affirmation that the field contains a valid and expected type. Library or application code will need to account for these changes to retain the desired functionality.

Security Considerations Even though all the RFCs in this document are security-related, the document itself does not have any security considerations. The ASN.1 modules keep the same bits-on-the-wire as the modules that they replace.

IANA Considerations IANA is requested to allocate a value from the "SMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0)" registry for the ASN.1 module in .

• Decimal: IANA Assigned - Replace TBD1
• Description: PKIX1Explicit-2026 - id-mod-pkix1-explicit-03

IANA is requested to allocate a value from the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry for the ASN.1 module in .

• Decimal: IANA Assigned - Replace TBD2
• Description: AsymmetricKeyPackageModuleV1-2026 - id-mod-asymmetricKeyPkgV1-2026

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] Informative References The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described. This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or as part of a Key Derivation Function (KDF). This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. This document obsoletes RFC 8708. This document specifies algorithm identifiers and ASN.1 encoding formats for the following stateful Hash-Based Signature (HBS) schemes: Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS). This specification applies to the Internet X.509 Public Key Infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). SLH-DSA is a stateless hash-based signature algorithm. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK] This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification. This document describes a syntax for private-key information. This memo provides information for the Internet community. ITU-T ITU-T RSA Laboratories Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable.

Acknowledgments Thanks goes to Pierce Leonberger who submitted an errata for SIGNED{ToBeSigned} in 2014 which didn't get the attention it deserved. Thanks to Josef Frühwirth who brought up the issue again more recently. Thanks to Michael StJohns for working with the authors to try to find an alternate solution which could keep the ASN.1 constraints. Ultimately there was no such solution, but the investigation was valuable. Thanks to the authors of and . This document is just a small update on their work.