<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc tocdepth='5'?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >

<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" ipr="pre5378Trust200902" docName="draft-gutmann-pkcs15-04">

  <!-- ======================================================================== -->
  <front>
    <title>PKCS #15 Updates</title>
    <author initials="P" surname="Gutmann" fullname="Peter Gutmann">
      <organization abbrev="University of Auckland">University of Auckland</organization>
      <address>
        <postal>
          <street>Department of Computer Science</street>
          <city>Auckland</city>
          <country>New Zealand</country>
        </postal>
        <email>pgut001@cs.auckland.ac.nz</email>
      </address>
    </author>
    <date year="2026"/>
    <area>Security Area</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>

This document describes updates to the PKCS #15 standard made since the
original publication of the standard.

      </t>
    </abstract>

  </front>
  <!-- ======================================================================== -->
  <middle>

    <!-- ====================================================================== -->
    <section anchor="introduction" title="Introduction">
      <t>

After the publication of the original PKCS #15 standard
<xref target="PKCS15v1"/> it saw minor updates that were only published as
drafts and circulated informally among implementers
<xref target="PKCS15v1_1"/><xref target="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.

      </t>
      <t>

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.

      </t>
      <t>

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.

      </t>
    </section>
    <!-- ====================================================================== -->
    <section anchor="dates" title="ValidFrom/ValidTo Dates">
      <t>

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:

	<artwork><![CDATA[
	validFrom		GeneralizedTime OPTIONAL,
	validTo		[4] GeneralizedTime OPTIONAL,
	]]></artwork>

For context, the full CommonCertificateAttributes are then:

	<artwork><![CDATA[
	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,
		}
	]]></artwork>

      </t>
	</section>
    <!-- ====================================================================== -->
    <section anchor="keyids" title="Key Identifiers">
      <t>

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:

	<artwork><![CDATA[
	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 URI
	]]></artwork>

      </t>
	</section>
    <!-- ====================================================================== -->
    <section anchor="authenv" title="Authenticated-Enveloped-Data">
      <t>

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:

	<artwork><![CDATA[
	direct-protected-auth [4] AuthEnvelopedData {Type},
	]]></artwork>

For PathOrObjects this is:

	<artwork><![CDATA[
	direct-protected-auth [4] AuthEnvelopedData {SEQUENCE OF ObjectType},
	]]></artwork>

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:

	<artwork><![CDATA[
	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},
		}
	]]></artwork>

      </t>
	</section>
    <!-- ====================================================================== -->
    <section anchor="pubkey-binding" title="Public/Private Key Binding">
      <t>

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:

	<artwork><![CDATA[
	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},
		...
		}
	]]></artwork>

The Ext variants wrap the original XXXPrivateKeyObject in an additional
SEQUENCE that adds an <xref target="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:

	<artwork><![CDATA[
	ESSCertIDv2 ::= SEQUENCE {
		hashAlgorithm	AlgorithmIdentifier DEFAULT {algorithm id-sha256},
		certHash		Hash,
		issuerSerial	IssuerSerial OPTIONAL
		}
	]]></artwork>

is present as:

	<artwork><![CDATA[
	ESSCertIDv2 ::=  SEQUENCE {
		certHash		OCTET STRING SIZE(32),
		}
	]]></artwork>

The resulting XXXPrivateKeyObject is then, in an ASN.1-like notation:

	<artwork><![CDATA[
	XXXPrivateKeyObject ::= SEQUENCE {
		spkiHash		ESSCertIDv2,
		-- Followed by the original PrivateXXXKeyObject
		}
	]]></artwork>

For example for an ECC private key the original:

	<artwork><![CDATA[
	ECPrivateKey ::= INTEGER
	]]></artwork>

would become in extended form with cryptographic binding:

	<artwork><![CDATA[
	ECPrivateKeyExt ::= SEQUENCE {
		spkiHash		ESSCertIDv2,
		value			INTEGER
		}
	]]></artwork>

For an RSA private key the original:

	<artwork><![CDATA[
	RSAPrivateKeyObject ::= SEQUENCE {
		modulus			[0] INTEGER OPTIONAL, -- n
		...
		coefficient		[7] INTEGER OPTIONAL -- inv(q) mod p
		}
	]]></artwork>

would become in extended form with cryptographic binding:

	<artwork><![CDATA[
	RSAPrivateKeyObjectExt ::= SEQUENCE {
		spkiHash		ESSCertIDv2,
		value			SEQUENCE {
			modulus		[0] INTEGER OPTIONAL, -- n
			...
			coefficient	[7] INTEGER OPTIONAL -- inv(q) mod p
			}
		}
	]]></artwork>

      </t>
	</section>
    <!-- ====================================================================== -->
    <section anchor="iana" title="IANA Considerations">
	  <t>

This document has no IANA actions.

      </t>
	</section>
    <!-- ====================================================================== -->
    <section anchor="security" title="Security Considerations">
	  <t>

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.

	  </t>
    </section>
    <!-- ====================================================================== -->

  </middle>
  <!-- ======================================================================== -->
  <back>

    <references title="Normative References">

      <reference anchor='ESSCertIDv2'>
        <front>
          <title>Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility</title>
          <author fullname="Jim Schaad" initials="J" surname="Schaad">
            <organization>Soaring Hawk Consulting</organization>
          </author>
          <date year='2007' month='August' />
        </front>
        <seriesInfo name='RFC' value='5035' />
        <format type='TXT' target='http://www.ietf.org/rfc/rfc5035.txt' />
      </reference>

      <reference anchor='PKCS15v1'>
        <front>
          <title>PKCS #15 v1.0: Cryptographic Token Information Format Standard</title>
          <author fullname="RSA Laboratories">
            <organization>RSA Data Security, Inc</organization>
          </author>
          <date year='1999' month='April' />
        </front>
        <seriesInfo name='PKCS' value='15' />
      </reference>

      <reference anchor='PKCS15v1_1'>
        <front>
          <title>PKCS #15 v1.1: Cryptographic Token Information Syntax Standard (draft)</title>
          <author fullname="RSA Laboratories">
            <organization>RSA Data Security, Inc</organization>
          </author>
          <date year='1999' month='December' />
        </front>
        <seriesInfo name='PKCS' value='15' />
      </reference>

      <reference anchor='PKCS15v1_2'>
        <front>
          <title>PKCS #15 v1.2: Cryptographic Token Information Syntax Standard (draft)</title>
          <author fullname="RSA Laboratories">
            <organization>RSA Data Security, Inc</organization>
          </author>
          <date year='2010' month='March' />
        </front>
        <seriesInfo name='PKCS' value='15' />
      </reference>

    </references>
    <!-- ====================================================================== -->
  </back>
</rfc>
