Movatterモバイル変換


[0]ホーム

URL:


Skip to main content

PKCS #15 Updates
draft-gutmann-pkcs15-04

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process.
DocumentTypeActive Internet-Draft (individual)
AuthorPeter Gutmann
Last updated 2026-02-10
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state(No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Email authors IPR References Referenced by Nits Search email archive
draft-gutmann-pkcs15-04
Network Working Group                                         P. GutmannInternet-Draft                                    University of AucklandIntended status: Informational                          10 February 2026Expires: 14 August 2026                            PKCS #15 Updates                        draft-gutmann-pkcs15-04Abstract   This document describes updates to the PKCS #15 standard made since   the original publication of the standard.Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions of BCP 78 and BCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is at https://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on 14 August 2026.Copyright Notice   Copyright (c) 2026 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents (https://trustee.ietf.org/   license-info) in effect on the date of publication of this document.   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.  Code Components   extracted from this document must include Revised BSD License text as   described in Section 4.e of the Trust Legal Provisions and are   provided without warranty as described in the Revised BSD License.   This document may contain material from IETF Documents or IETF   Contributions published or made publicly available before November   10, 2008.  The person(s) controlling the copyright in some of thisGutmann                  Expires 14 August 2026                 [Page 1]Internet-Draft              PKCS #15 Updates               February 2026   material may not have granted the IETF Trust the right to allow   modifications of such material outside the IETF Standards Process.   Without obtaining an adequate license from the person(s) controlling   the copyright in such materials, this document may not be modified   outside the IETF Standards Process, and derivative works of it may   not be created outside the IETF Standards Process, except to format   it for publication as an RFC or to translate it into languages other   than English.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   2.  ValidFrom/ValidTo Dates . . . . . . . . . . . . . . . . . . .   2   3.  Key Identifiers . . . . . . . . . . . . . . . . . . . . . . .   3   4.  Authenticated-Enveloped-Data  . . . . . . . . . . . . . . . .   4   5.  Public/Private Key Binding  . . . . . . . . . . . . . . . . .   5   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   71.  Introduction   After the publication of the original PKCS #15 standard [PKCS15v1] it   saw minor updates that were only published as drafts and circulated   informally among implementers [PKCS15v1_1][PKCS15v1_2], but never   finalised due to the dissolution of the organisation that published   the standards.  Since the standard, including the updates, remains in   active use today, this document gathers the updates in a single   location for reference by implementers.   The updates cover the extension of the original PKCS #15 identifiers   to handle validFrom/validTo dates for certificates and PGP/OpenPGP   keys and email addresses, the addition of support for CMS   Authenticated-Enveloped-Data, and support for cryptographic binding   of public-key components to private-key ones.   Since names and definitions have changed across the different drafts   (for example v1.0 used PKCS15XXXAttributes while v1.1 and later used   XXXXAttributes), this document uses the v1.1 ASN.1 module pkcs-   15v1_1.asn as its baseline.2.  ValidFrom/ValidTo Dates   PKCS #15 v1.0 didn't support the validFrom/validTo dates that are   required for certificates, these were added in the PKCS #15 v1.2   draft and extend the CommonCertificateAttributes to add:Gutmann                  Expires 14 August 2026                 [Page 2]Internet-Draft              PKCS #15 Updates               February 2026           validFrom               GeneralizedTime OPTIONAL,           validTo         [4] GeneralizedTime OPTIONAL,   For context, the full CommonCertificateAttributes are then:        CommonCertificateAttributes ::= SEQUENCE {                iD                      Identifier,                authority       BOOLEAN DEFAULT FALSE,                identifier      CredentialIdentifier {{KeyIdentifiers}} OPTIONAL,                certHash        [0] OOBCertHash OPTIONAL,                ...,                trustedUsage [1] Usage OPTIONAL,                identifiers     [2] SEQUENCE OF CredentialIdentifier{{KeyIdentifiers}} OPTIONAL,                implicitTrust [3] BOOLEAN DEFAULT FALSE,                validFrom       GeneralizedTime OPTIONAL,                validTo         [4] GeneralizedTime OPTIONAL,                }3.  Key Identifiers   PKCS #15 v1.0, designed for use with smart cards, didn't support PGP/   OpenPGP or email use, making it difficult to implement PKCS #11 with   PKCS #15 as the storage format.  The PKCS #15 v1.2 draft extended   CredentialIdentifier to include these additional IDs, which extend   the existing KeyIdentifiers values to add pgp, openPGP, and uri   identifiers:Gutmann                  Expires 14 August 2026                 [Page 3]Internet-Draft              PKCS #15 Updates               February 2026        KeyIdentifiers KEY-IDENTIFIER ::= {                issuerAndSerialNumber |                issuerAndSerialNumberHash |                subjectKeyId |                subjectKeyHash |                issuerKeyHash |                issuerNameHash |                subjectNameHash |                pgp |                openPGP |                uri                ...        }        pgp KEY-IDENTIFIER ::=                {SYNTAX OCTET STRING SIZE(8) IDENTIFIED BY 8}                -- RFC 4880 V3 (PGP 2.x) key ID        openPGP KEY-IDENTIFIER ::=                {SYNTAX OCTET STRING SIZE(8) IDENTIFIED BY 9}                -- RFC 4880 V4 key ID        uri KEY-IDENTIFIER ::=                {SYNTAX UTF8String IDENTIFIED BY 10}                -- Typically email address but may be a more general URI4.  Authenticated-Enveloped-Data   PKCS #15 v1.0 predates the existence of CMS Authenticated-Enveloped-   Data, which was added in the PKCS #15 v1.2 draft by extending the   ObjectValue/ PathOrObjects CHOICE to include a new content type   AuthEnvelopedData alongside the existing EnvelopedData.  For   ObjectValue this is:           direct-protected-auth [4] AuthEnvelopedData {Type},   For PathOrObjects this is:        direct-protected-auth [4] AuthEnvelopedData {SEQUENCE OF ObjectType},   Note that the tags jump from the v1.1 'direct-protected [2]   EnvelopedData' to 'direct-protected-auth [4] AuthEnvelopedData', the   [3] tag was used for another object type whose purpose is now lost.   For context, the full ObjectValue / PathOrObjects are then:Gutmann                  Expires 14 August 2026                 [Page 4]Internet-Draft              PKCS #15 Updates               February 2026        ObjectValue { Type } ::= CHOICE {                indirect                        ReferencedValue {Type},                direct                          [0] Type,                indirect-protected      [1] ReferencedValue {EnvelopedData {Type}},                direct-protected        [2] EnvelopedData {Type},                direct-protected-auth [4] AuthEnvelopedData {Type}                }        PathOrObjects {ObjectType} ::= CHOICE {                path                            Path,                objects                         [0] SEQUENCE OF ObjectType,                ...,                indirect-protected      [1] ReferencedValue {EnvelopedData {SEQUENCE OF ObjectType}},                direct-protected        [2] EnvelopedData {SEQUENCE OF ObjectType}                direct-protected-auth [4] AuthEnvelopedData {SEQUENCE OF ObjectType},                }5.  Public/Private Key Binding   An update to the PKCS #15 v1.2 draft provided for cryptographic   binding between the private key and public key data.  This protects   the otherwise typically unprotected public-key objects from   undetectable manipulation.  This cryptographic binding is added by   extending the existing privateXXXKey types with new privateXXXKeyExt   types that include the cryptographic binding:        PrivateKeyType ::= CHOICE {                privateRSAKey   PrivateKeyObject {PrivateRSAKeyAttributes},                privateECKey    [0] PrivateKeyObject {PrivateECKeyAttributes},                privateDHKey    [1] PrivateKeyObject {PrivateDHKeyAttributes},                privateDSAKey   [2] PrivateKeyObject {PrivateDSAKeyAttributes},                privateKEAKey   [3] PrivateKeyObject {PrivateKEAKeyAttributes},                privateRSAKeyExt [4] PrivateKeyObject {PrivateRSAKeyAttributesExt},                privateECKeyExt [5] PrivateKeyObject {PrivateECKeyAttributesExt},                privateDSAKeyExt [6] PrivateKeyObject {PrivateDSAKeyAttributesExt},                ...                }   The Ext variants wrap the original XXXPrivateKeyObject in an   additional SEQUENCE that adds an [ESSCertIDv2] field, with the   ESSCertIDv2 restricted to contain only a SHA-2 hash of the public key   data in SubjectPublicKeyInfo form.  In other words the ESSCertIDv2:        ESSCertIDv2 ::= SEQUENCE {                hashAlgorithm   AlgorithmIdentifier DEFAULT {algorithm id-sha256},                certHash                Hash,                issuerSerial    IssuerSerial OPTIONAL                }Gutmann                  Expires 14 August 2026                 [Page 5]Internet-Draft              PKCS #15 Updates               February 2026   is present as:           ESSCertIDv2 ::=  SEQUENCE {                   certHash                OCTET STRING SIZE(32),                   }   The resulting XXXPrivateKeyObject is then, in an ASN.1-like notation:           XXXPrivateKeyObject ::= SEQUENCE {                   spkiHash                ESSCertIDv2,                   -- Followed by the original PrivateXXXKeyObject                   }   For example for an ECC private key the original:           ECPrivateKey ::= INTEGER   would become in extended form with cryptographic binding:           ECPrivateKeyExt ::= SEQUENCE {                   spkiHash                ESSCertIDv2,                   value                   INTEGER                   }   For an RSA private key the original:        RSAPrivateKeyObject ::= SEQUENCE {                modulus                 [0] INTEGER OPTIONAL, -- n                ...                coefficient             [7] INTEGER OPTIONAL -- inv(q) mod p                }   would become in extended form with cryptographic binding:        RSAPrivateKeyObjectExt ::= SEQUENCE {                spkiHash                ESSCertIDv2,                value                   SEQUENCE {                        modulus         [0] INTEGER OPTIONAL, -- n                        ...                        coefficient     [7] INTEGER OPTIONAL -- inv(q) mod p                        }                }6.  IANA Considerations   This document has no IANA actions.Gutmann                  Expires 14 August 2026                 [Page 6]Internet-Draft              PKCS #15 Updates               February 20267.  Security Considerations   This document serves to document minor updates to the original PKCS   #15 standard, there are no security considerations present beyond   those in the original standard.8.  Normative References   [ESSCertIDv2]              Schaad, J., "Enhanced Security Services (ESS) Update:              Adding CertID Algorithm Agility", RFC 5035, August 2007,              <http://www.ietf.org/rfc/rfc5035.txt>.   [PKCS15v1] Laboratories, R., "PKCS #15 v1.0: Cryptographic Token              Information Format Standard", PKCS 15, April 1999.   [PKCS15v1_1]              Laboratories, R., "PKCS #15 v1.1: Cryptographic Token              Information Syntax Standard (draft)", PKCS 15, December              1999.   [PKCS15v1_2]              Laboratories, R., "PKCS #15 v1.2: Cryptographic Token              Information Syntax Standard (draft)", PKCS 15, March 2010.Author's Address   Peter Gutmann   University of Auckland   Department of Computer Science   Auckland   New Zealand   Email: pgut001@cs.auckland.ac.nzGutmann                  Expires 14 August 2026                 [Page 7]

[8]ページ先頭

©2009-2026 Movatter.jp