PKCS #15: An ICC File Structure Standard An RSA Laboratories Technical Note Version 1.0 - DRAFT - September 18, 1998 Editor's note: This is a working public draft of PKCS#15 v1.0. Please send comments and questions, both editorial and technical, to pkcs-tng@rsa.com or pkcs-editor@rsa.com. Copyright (C) 1998 RSA Laboratories, a division of RSA Data Security, Inc. License to copy this document is granted provided that it is identified as "RSA Data Security, Inc. Public-Key Cryptography Standards (PKCS)" in all material mentioning or referencing this document. 000-000000-000-000-000 1. Scope The purpose of this standard is to define a file and directory format for Integrated Circuit Cards (Smart Cards or ICCs). Its intended use is to allow for card interoperability between card-aware applications making use of public-key technology for user identification purposes. The format builds on the PKCS#11 standard. 2. References TBD - ISO, PKCS, IETF 3. Definitions TBD 4. Symbols and Abbreviations DF Dedicated File. See ISO 7816-4. EF Elementary File. See ISO 7816-4. MF Master File. See ISO 7816-4. [More TBD] 5. General Overview This document describes the PKCS#15 Smart Card File Format. The format is a detailed description on how keys, certificates and other application-specific data may be stored on an ISO-7816 compliant smart card. The format has the following characteristics: -Supports storage of any PKCS#11 objects (keys, certificates and data) -Supports multiple applications -Dynamic structure makes it possible to implement on a wide variety of cards, including so-called stored value cards (cards without provisions for doing RSA calculations themselves) -Straightforward to implement a PKCS#11 interface for it In general, an attempt has been made to be flexible enough to allow for many different smart card types, while still preserving the requirements for interoperability. A key factor in this is the Object Directory File (See below) which provides a layer of indirection between the objects on the card and the actual format. 6. Card File Format 6.1 Overview In general, a smart card format is nothing but a specification on how certain abstract, higher level elements such as keys and certificates is to be represented in terms of more lower level elements such as smart card files and directory structures. The format also describes how and under which circumstances these higher level objects may be accessed by external sources and how these access rules are to be implemented in the underlying representation (i.e. the card's operating system). Since this standard is intended to be independent of particular smart card brands and models, we define 'generic' smart card access rules which should be straightforward to map to actual smart card operating system-native commands (assuming the card is an ISO-7816 compliant smart card). 6.2 Card requirements This standard requires that compliant cards supports ISO 7816-3, ISO 7816-4 and ISO 7816-5. 6.3 General characteristics 6.3.1 Card Layout A card supporting this standard should have the following layout: MF (File Id: 3F 00) __________________________________ / \ \ \ \ / \ \ \ \ DF(PKCS15) EF(PAN) EF(PIN) ...(Other DFs, EFs) Figure 1. PKCS#15 Card Layout. 6.4 File Structure The general file structure is shown in Figure 1. The contents of the PKCS#15 Application Directory is a bit dependent on the type of smart card , but the following file structure is believed to be the most common: DF(PKCS15) ________________________________________ / \ \ \ \ / \ \ \ \ EF(ODF) EF(Prk(1)) EF(Cert(1)) EF(Data(1) ...(PKCS#11 Object Files) Figure 2. Contents of DF(PKCS15). The contents and purpose of each file and directory is described below. 6.4.1 MF directory contents This section describes the EFs of the MF directory. 6.4.1.1 EF(PAN) This optional file shall, if present, contain the ICC number as printed on the surface of the card. The ICC number shall be set in accordance with ISO/IEC 7812-1 and stored in the data object Primary Account Number (PAN) as defined in ISO/IEC 7816-6. The structures shall be in accordance with ISO 7813 and the coding in accordance with ISO 8583. An example of coding of the EF(PAN) is given in section 10. 6.4.1.2 EF(PIN) This mandatory file shall contain the master Personal Identification Number (PIN), which can be used by any application on the card, at the application provider's discretion. The structure of this file is card-type dependent. 6.4.2 PKCS#15 Application Directory Contents This section describes the EFs of the PKCS#15 application directory, DF(PKCS15). 6.4.2.1 EF(ODF) The mandatory Object Directory File (ODF) shall contain information about the objects -such as keys and certificates- on the card. This also includes information not present in PKCS#11 v2.01 such as PIN policies and file pointers. The intent is that the file shall be read by host applications to decide how to use and access the security services on the card. The contents of the ODF is described in detail in section 6.7. 6.4.2.2 EF(Prk(n)) The format of the optional private key files is card-specific and outside the scope of this standard - it will not affect interoperability. They are to be used when the card indeed supports on-chip RSA encryption. In that case there is no need for external visibility of the private key. 6.4.2.3 EF(Cert(n)) The optional EF(Cert(n)) files shall contain X.509 DER-encoded certificates. 6.4.2.4 Other elementary files in the PKCS#15 directory These files can contain public keys, secret keys and application specific data. [Define format for public/secret keys and PKCS15 data?] 6.5 File Identifiers The following file identifiers are defined for the PKCS15 files. Note that the RID (see ISO/IEC 7816-5) is A0 00 00 00 ?? [To be registered]. File DF Identifier ----------------------------------- MF x 0x3F00 PAN 0x1000 PIN Smart Card specific PKCS15 x RID || "PKCS15-10" (The 16 bit file identifier shall be 0x5015) ODF 0x4F44 Table 1: File Identifiers 6.6 File Access Conditions The access conditions for the files can be set up differently depending on if the card is to be read-only or read-write. A read-only card might be desired for high-security purposes, for example when it has been issued using a secure issuing process, and it is to be certain that it can not be manipulated afterwards. The following is a table of different possible access conditions. These are generic conditions, which should be possible to implement on all different smart card types. The exact access conditions, and their meaning, varies for each smart card type. File type Access type Meaning ---------------------------------------- DF Create Allows new files, both EFs and DFs to to be created in the DF. Delete Allows files in the DF to be deleted. Relevant only for cards which support deletion. EF Read The file contents is allowed to be read. Update The file contents is allowed to be updated. Crypt Encryption is allowed to be done with the file. Relevant only for private and secret key files. Table 2: File access types Note that it is the access control rules in the directory, and not on the files itself, which decide if files in the directory are allowed to be created or deleted. Each access condition can have the following prerequisites. These are also generic and should be possible to implement on all smart card types. Type Meaning ----------------- NEV The operation is never allowed, not even after a PIN verification. ALW The operation is always allowed, without PIN verification. PIN The operation is allowed after a successful PIN verification. SYS The operation is allowed after a system key presentation, typically available only to the card issuer (The Security Officer case) Table 3: Possible access conditions The following access conditions are set for the files. File DF R/O card R/W card --------------------------------------------------------- MF X Create: SYS, Delete: SYS Same as for R/O card. PAN Read: ALW, Update: NEV Same as for R/O card. PIN Read: NEV, Update: NEV Same as for R/O card. PKCS15 X Create: SYS, Delete: SYS Create: PIN, Delete: PIN ODF Read: ALW, Update: SYS Read: ALW, Update: PIN PrK(n) Read: NEV,Update:NEV, Crypt:PIN Read: NEV, Update: PIN, Crypt: PIN CERT(n) Read: ALW, Update: NEV Read: ALW, Update: PIN Other EFs Read: ALW/PIN, Update: NEV Read: ALW/PIN, Update: PIN Crypt: PIN (if applicable) Crypt: PIN (if applicable) Table 4: Access conditions for the files The difference between a read-only and a read-write (R-W) card is basically that for a R-W card, after correct PIN presentation, new files are allowed to be created (to allow addition of new objects) and the ODF file is allowed to be written (to allow adding info about new keys and certs). It is also allowed (after correct PIN presentation) to replace files on a R-W card. It is recommended that all cards be personalized with the read-write access control settings, unless they are issued for an environment with very high security requirements. 6.7 The ODF The purpose and general contents of the ODF were defined in 6.4.2.1. As mentioned, it will contain pointers and references to all PKCS#11 objects present on the card. The detailed structure and contents of the ODF is defined below in ASN.1. The file shall be DER-encoded before stored on the card. A complete example of an ODF is given in section 10.2. ODFContents ::= SEQUENCE { version INTEGER, PINInfo PINInfo OPTIONAL, privateKeys PrivateKeys, publicKeys PublicKeys, secretKeys SecretKeys, certificates Certificates, dataObjects DataObjects, } For this version of this standard, the version number shall be 0x10. Regarding the other fields, see the sections below. Note: As the ODF is used to represent PKCS#15 Objects, it makes sense to define the following ASN.1 classes: PKCS15-OBJECT ::= TYPE IDENTIFIER PKCS15-KEY ::= PKCS15-OBJECT PKCS15-CERTIFICATE ::= PKCS15-OBJECT PKCS15-DATUM ::= PKCS15-OBJECT 6.7.1 The PIN Information Field This data structure contains information about the PIN codes of the card. It is optional, since a card is not required to be protected with a PIN. It is defined as follows: PINInfo ::= BIT STRING { case-sensitive(0), pad-with-one(1) } The steps taken to transform the user-supplied PIN to something presented to the card shall be as follows: a) The PIN entered by the user shall, to eliminate various locale-dependent problems always be transformed to UNICODE first: x = UNICODE(PIN) b) If the case-sensitive flag is off, convert x to uppercase: x = NLSUPPERCASE(x) (NLSUPPERCASE = locale dependent uppercase) c) If the pad-with-one flag is set, pad x with binary '1' to maximum length: x = PADONE(x). Otherwise, pad x with binary '0' to maximum length: x = PADZERO(x).) 6.7.2 The privateKeys field This data structure contains information pertaining to the private key objects on the card. PrivateKeys ::= SEQUENCE OF PKCS15PrivateKey PKCS15PrivateKey ::= SEQUENCE { key INSTANCE OF PKCS15-KEY, pKCS15CommonObjectAttributes PKCS15CommonObjectAttributes, pKCS15CommonKeyAttributes PKCS15CommonKeyAttributes, pkCS15CommonPrivateKeyAttributes PKCS15CommonPrivateKeyAttributes } Each private key object contains the common attributes defined in PKCS#11, and in addition to this, an instance of a PKCS15-KEY: pKCS15PrivateRSAKey PKCS15-KEY ::= {PKCS15PrivateRSAKey IDENTIFIED BY id-oc-PKCS15PrivateRSAKey} PKCS15PrivateRSAKey ::= SEQUENCE { modulusLength INTEGER, subjKeyHash OCTET STRING, path [1] IMPLICIT PKCS15Path OPTIONAL, value [2] IMPLICIT PKCS15RSAPrivateKey OPTIONAL } (WITH COMPONENTS {..., path PRESENT, value ABSENT} | WITH COMPONENTS {..., path ABSENT, value PRESENT}) The motivation for these fields is as follows: -modulusLength: On many cards, you must be able to format data to be signed prior to sending the data to the card. In order to be able to format the data in a correct manner the length of the key must be known. -subjKeyHash: When receiving for example a enveloped message together with the public key used for encrypting the message's session key, the application must be able to deduce which of the private keys present on the card that should be used for decrypting the session key. This can be accomplished by calculating a hash for the public key in the certificate and then compare this hash with the hash stored on the card. The hash is done on the complete DER encoding of the subjectPublicKey for this private key, including tag and length. [Example? Is this useful on this card?] -path: This field will, if applicable, contain the file identifier (and, optionally, an index into that file) for the file where the private key is stored. Depending on the type of card, this file may either be supplied in a 'CRYPT' command to the card or used in a 'READ BINARY' command (If the card doesn't have RSA encryption capabilities). The field can optionally contain an url to the object in question. Although this is unlikely in the case of a private key it is more probable in the case of a certificate (see below). -value: This field will probably be present only for stored-value cards when there is a desire to store the key in the ODF itself. At least one of the 'path' and 'value' fields must be present, as indicated. PKCS15Path ::= SEQUENCE { path [APPLICATION 1] IMPLICIT OCTET STRING index INTEGER OPTIONAL url [1] IMPLICIT IA5String OPTIONAL } {WITH COMPONENTS (..., path PRESENT, url ABSENT)| WITH COMPONENTS (..., path ABSENT, url PRESENT)} -path is the 'Path' type specified in ISO 7816-5 and defined in ISO 7816-4. A path can be either relative or absolute, where 'absolute' means that the path starts with the file identifier for the MF (3F00). If the path starts with any other file identifier, it is to be regarded as a relative path. A relative path in the context of this standard is always relative to the PKCS15 DF. Based on ISO 7816-4, the relative path is then required to start with either the identifier for DF(PKCS15) (0x5015) or 0x3FFF. -index is an optional index into the file pointed to by the 'path' field. The index, if present, specifies the position relative to the beginning of the file (number of bytes for binary files, record number for linear files) where the particular object resides. This is to allow for several objects in one file, should it be necessary (There are of course some drawbacks to this, e.g. updates will be more difficult) [Use 'length' variable as well?]. -url is an alternative way of pointing to the particular object. The url should be in accordance with RFC 2396. PKCS15RSAPrivateKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent [1] IMPLICIT INTEGER OPTIONAL, -- e privateExponent INTEGER, -- d prime1 [2] IMPLICIT INTEGER OPTIONAL, -- p prime2 [3] IMPLICIT INTEGER OPTIONAL, -- q exponent1 [4] IMPLICIT INTEGER OPTIONAL, -- d mod (p-1) exponent2 [5] IMPLICIT INTEGER OPTIONAL, -- d mod (q-1) coefficient [6] IMPLICIT INTEGER OPTIONAL -- (inverse of q) mod p} } The reason for not choosing to represent the private key value in a PKCS#1 RSAPrivateKey structure is that PKCS#11 dictates that not all fields must be present - only the modulus and privateExponent fields are mandatory. The common object attributes, present for all objects, Is represented by: PKCS15CommonObjectAtttributes ::= SEQUENCE { label BMPString, flags PKCS15CommonObjectFlags } PKCS15CommonObjectFlags ::= BIT STRING { private (0), modifiable (1) } With interpretation as in PKCS#11. Note that the label is chosen to be a BMPString - this simplifies user interface interactions in different locales. The common key attributes, present for all key objects, is represented by: PKCS15CommonKeyAttributes ::= SEQUENCE { iD OCTET STRING, startDate [1] IMPLICIT GENERALIZED TIME OPTIONAL endDate [2] IMPLICIT GENERALIZED TIME OPTIONAL flags PKCS15CommonKeyFlags } PKCS15CommonKeyFlags ::= BIT STRING { derive (0), local (1) } The meaning of each of these fields is as in PKCS#11. Note that, as recommended in PKCS#11, the 'iD' identifier should, if applicable, be identical to the 'iD' identifier for any associated certificates. This enables fast lookup of corresponding private key - certificate pairs. The common private key attributes, present for all private key objects, is represented by: PKCS15CommonPrivateKeyAtttributes ::= SEQUENCE { flags PKCS15CommonPrivateKeyFlags } PKCS15CommonPrivateKeyFlags ::= BIT STRING { sensitive (0), encrypt (1), decrypt (2), sign (3), verify (4), wrap (5), unwrap (6), extractable (7), alwaysSensitive (8), neverExtractable(9) [x509 keyUsage instead?] } The interpretation is as described in PKCS#11. 6.7.3 The certificates field This data structure contains information pertaining to the certificate objects on the card. Certificates ::= SEQUENCE OF PKCS15Certificate PKCS15Certificate ::= { certificate INSTANCE OF PKCS15-CERTIFICATE, pKCS15CommonObjectAttributes PKCS15CommonObjectAttributes, pKCS15CommonCertificateAttributes PKCS15CommonCertificateAttributes } PKCS15CommonCertificateAttributes ::= SEQUENCE { iD OCTET STRING } The 'iD' attribute is only present for X509 certificates in PKCS#11, but has for been 'promoted' to a common certificate attribute in this standard. Each certificate object contains the common attributes defined in PKCS#11, and in addition to this, an instance of a PKCS15-CERTIFICATE: pKCS15X509Certificate PKSC15-CERTIFICATE ::= {PKCS15X509Certificate IDENTIFIED BY id-oc-PKCS15X509Certificate} PKCS15X509Certificate ::= SEQUENCE { subject [1] IMPLICIT Name OPTIONAL, issuer [2] IMPLICIT Name OPTIONAL, serialNumber [3] IMPLICIT CertificateSerialNumber OPTIONAL, path [4] IMPLICIT PKCS15Path OPTIONAL, value [5] IMPLICIT OCTET STRING OPTIONAL } {WITH COMPONENTS {..., path PRESENT, value ABSENT} | WITH COMPONENTS {..., path ABSENT, value PRESENT}) The reason for making the 'subject', 'issuer' and 'serialNumber' field optional is to provide some space-efficiency; these fields are already present in the certificate itself. The 'path' field will, if applicable, contain the file identifier (and, optionally, an index within that file) for the file where the certificate is stored. Depending on the type of card, this file may either be supplied in a 'READ RECORD' command or a 'READ BINARY' command to the card. Alternatively, it can contain an URL for/to the certificate. The 'value' field will probably be present only when there is a desire to store the certificate in the ODF itself. At least one of the 'path' and 'value' fields must be present, as indicated. It should contain a DER-encoded X.509 certificate. 6.7.4 The publicKeys field TBD 6.7.5 The secretKeys field TBD 6.7.6 The dataObjects field TBD 7 PKCS#15 Application Selection 7.1 AID for the PKCS#15 application The Application Identifier (AID) data element consists of 5-16 bytes and it's contents is defined below. The AID is used as the filename for DF(PKCS15) in order to facilitate selection of the PKCS#15 application on multi-application cards. The AID is composed of RID || PIX, where '||' denotes concatenation. RID is the 5 byte globally Registered Identifier as specified in ISO/IEC 7816-5. RID shall be set to A0 00 00 00 ?? [TBD] for the purposes of this standard. PIX (Proprietary application Identifier eXtension) shall be set to "PKCS15-xx" where 'xx' denotes the version of this standard. For this version, the value is '10' (Version 1.0). The full AID for the current version of this standard is thus A0 00 00 00 ?? 50 4B 43 53 31 35 2D 31 30. PKCS#15 compliant IC cards should support direct application selection as defined in ISO/IEC 7816-4 section 9 and ISO/IEC 7816-5, section 6. The full AID is to be used as parameter for a 'Select File' command. The operating system of the card shall keep track of the currently selected application and only allow the commands applicable to that particular application while it is selected. 8. ASN.1 Module This section includes all of the ASN1 type, value and information object class definitions contained in this standard, in the form of the ASN.1 module PKCS15Framework. PKCS15Framework {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 15} DEFINITIONS ::= BEGIN -- EXPORTS All -- -- All types and values defined in this module is exported for use in other -- ASN.1 modules. IMPORTS informationFramework, authenticationFramework FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0) 3} Name, ATTRIBUTE FROM InformationFramework informationFramework CertificateSerialNumber FROM AuthenticationFramework authenticationFramework; --The Object Directory File definition ODFContents ::= SEQUENCE { version INTEGER PINInfo PINInfo OPTIONAL, privateKeys PrivateKeys, publicKeys PublicKeys, secretKeys SecretKeys, certificates Certificates, dataObjects DataObjects, } PINInfo ::= BIT STRING { case-sensitive(0), pad-with-one(1) } PrivateKeys ::= SEQUENCE OF PKCS15PrivateKey PublicKeys ::= SEQUENCE OF PKCS15PublicKey SecretKeys ::= SEQUENCE OF PKCS15SecretKey Certificates ::= SEQUENCE OF PKCS15Certificate DataObjects ::= SEQUENCE OF PKCS15Data -- PKCS15 Objects and Attributes pKCS15PrivateKey PKCS15-OBJECT ::= {PKCS15PrivateKey IDENTIFIED BY id-oc-PKCS15PrivateKey} PKCS15PrivateKey ::= SEQUENCE { key INSTANCE OF PKCS15-KEY, pKCS15CommonObjectAttributes PKCS15CommonObjectAttributes, pKCS15CommonKeyAttributes PKCS15CommonKeyAttributes, pkCS15CommonPrivateKeyAttributes PKCS15CommonPrivateKeyAttributes } pKCS15PrivateRSAKey PKCS15-KEY ::= {PKCS15PrivateRSAKey IDENTIFIED BY id-oc-PKCS15PrivateRSAKey} -- Other PKCS15-KEYS can be defined later on PKCS15PrivateRSAKey ::= SEQUENCE { modulusLength INTEGER, subjKeyHash OCTET STRING, path [1] IMPLICIT PKCS15Path OPTIONAL, value [2] IMPLICIT PKCS15RSAPrivateKey OPTIONAL } (WITH COMPONENTS {..., path PRESENT, value ABSENT} | WITH COMPONENTS {..., path ABSENT, value PRESENT}) PKCS15Path ::= SEQUENCE { path [APPLICATION 1] IMPLICIT OCTET STRING --See ISO 7816-5 index INTEGER OPTIONAL url [1] IMPLICIT IA5String OPTIONAL } {WITH COMPONENTS {..., path PRESENT, url ABSENT)| WITH COMPONENTS (..., path ABSENT, url PRESENT)} PKCS15RSAPrivateKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent [1] IMPLICIT INTEGER OPTIONAL, -- e privateExponent INTEGER, -- d prime1 [2] IMPLICIT INTEGER OPTIONAL, -- p prime2 [3] IMPLICIT INTEGER OPTIONAL, -- q exponent1 [4] IMPLICIT INTEGER OPTIONAL, -- d mod (p-1) exponent2 [5] IMPLICIT INTEGER OPTIONAL, -- d mod (q-1) coefficient [6] IMPLICIT INTEGER OPTIONAL -- (inverse of q) mod p } pKCS15CommonObjectAttributes PKCS15-ATTRIBUTE ::= {PKCS15CommonObjectAttributes IDENTIFIED BY id-at-PKCS15} PKCS15CommonObjectAtttributes ::= SEQUENCE { label BMPString, flags PKCS15CommonObjectFlags } PKCS15CommonObjectFlags ::= BIT STRING { private (0), modifiable (1) } pKCS15CommonKeyAttributes PKCS15-ATTRIBUTE ::= {PKCS15CommonKeyAttributes IDENTIFIED BY id-at-PKCS15Key} PKCS15CommonKeyAttributes ::= SEQUENCE { iD OCTET STRING, startDate [1] IMPLICIT GENERALIZED TIME OPTIONAL endDate [2] IMPLICIT GENERALIZED TIME OPTIONAL flags PKCS15CommonKeyFlags } PKCS15CommonKeyFlags ::= BIT STRING { derive (0), local (1) } pKCS15CommonPrivateKeyAttributes PKCS15-ATTRIBUTE ::= { PKCS15CommonPrivateKeyAttributes IDENTIFIED BY id-at-PKCS15PrivateKey} PKCS15CommonPrivateKeyAtttributes ::= SEQUENCE { flags PKCS15CommonPrivateKeyFlags } PKCS15CommonPrivateKeyFlags ::= BIT STRING { sensitive (0), encrypt (1), decrypt (2), sign (3), verify (4), wrap (5), unwrap (6), extractable (7), alwaysSensitive (8), neverExtractable(9) } pKCS15PublicKey PKCS15-OBJECT ::= {PKCS15PublicKey IDENTIFIED BY id-oc-PKCS15PublicKey} PKCS15PublicKey ::=... pKCS15SecretKey PKCS15-OBJECT ::= {PKCS15SecretKey IDENTIFIED BY id-oc-PKCS15SecretKey} PKCS15SecretKey ::= ... pKCS15Certificate PKCS15-OBJECT ::= {PKCS15Certificate IDENTIFIED BY id-oc-PKCS15Certificate} } PKCS15Certificate ::= { certificate INSTANCE OF PKCS15-CERTIFICATE, pKCS15CommonObjectAttributes PKCS15CommonObjectAttributes, pKCS15CommonCertificateAttributes PKCS15CommonCertificateAttributes } pKCS15X509Certificate PKSC15-CERTIFICATE ::= {PKCS15X509Certificate IDENTIFIED BY id-oc-PKCS15X509Certificate} PKCS15X509Certificate ::= SEQUENCE { subject [1] IMPLICIT Name OPTIONAL, issuer [2] IMPLICIT Name OPTIONAL, serialNumber [3] IMPLICIT CertificateSerialNumber OPTIONAL, path [4] IMPLICIT PKCS15Path OPTIONAL, value [5] IMPLICIT OCTET STRING OPTIONAL -- BER encoding of the actual certificate } {WITH COMPONENTS {..., path PRESENT, value ABSENT} | WITH COMPONENTS {..., path ABSENT, value PRESENT}) pKCS15CommonCertificateAttributes PKCS15-ATTRIBUTE ::= { PKCS15CommonCertificateAttributes IDENTIFIED BY id-at-PKCS15Certificate } PKCS15CommonCertificateAttributes ::= SEQUENCE { iD OCTET STRING } pKCS15Datum PKCS15-OBJECT ::= {PKCS15Datum IDENTIFIED BY id-oc-PKCS15Datum} PKCS15Datum ::= {...} -- Information object classes PKCS15-OBJECT ::= TYPE IDENTIFIER PKCS15-ATTRIBUTE ::= TYPE-IDENTIFIER PKCS15-KEY ::= PKCS15-OBJECT PKCS15-CERTIFICATE ::= PKCS15-OBJECT PKCS15-DATUM ::= PKCS15-OBJECT -- Object Identifier assignments id-pkcs15 OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 15 1} pkcs15-objects OBJECT IDENTIFIER ::= {id-pkcs15 1} pkcs15-attributes OBJECT IDENTIFIER ::= {id-pkcs15 2} id-oc-PKCS15PrivateKey OBJECT IDENTIFIER ::= {pkcs15-objects 1} id-oc-PKCS15PublicKey OBJECT IDENTIFIER ::= {pkcs15-objects 2} id-oc-PKCS15SecretKey OBJECT IDENTIFIER ::= {pkcs15-objects 3} id-oc-PKCS15Certificate OBJECT IDENTIFIER ::= {pkcs15-objects 4} id-oc-PKCS15Datum OBJECT IDENTIFIER ::= {pkcs15-objects 5} id-oc-PKCS15PrivateRSAKey OBJECT IDENTIFIER ::= {id-oc-PKCS15PrivateKey 1} id-oc-PKCS15X509Certificate OBJECT IDENTIFIER ::= {id-oc-PKCS15Certificate 1} id-at-PKCS15 OBJECT IDENTIFIER ::= {pkcs15-attributes 1} id-at-PKCS15Key OBJECT IDENTIFIER ::= {pkcs15-attributes 2} id-at-PKCS15PrivateKey OBJECT IDENTIFIER ::= {pkcs15-attributes 3} id-at-PKCS15PublicKey OBJECT IDENTIFIER ::= {pkcs15-attributes 4} id-at-PKCS15SecretKey OBJECT IDENTIFIER ::= {pkcs15-attributes 5} id-at-PKCS15Certificate OBJECT IDENTIFIER ::= {pkcs15-attributes 6} id-at-PKCS15Datum OBJECT IDENTIFIER ::= {pkcs15-attributes 7} END 10. Examples of DER encoding of some PKCS#15 EFs 10.1 Example of DER encoding of EF(PAN) The following example shows the coding of the mandatory PAN file, containing the card serial number as printed on the front of the card. Each digit in the card serial number is encoded as a BCD digit, with two BCD digits in one byte. 5A 09 -- [Application 26] Tag for -- Primary Account Number (ISO 7816-6) 15 97 52 22 25 15 40 12 30 -- Card number (9752 2225 1540 124) -- preceded by decimal length field. 10.2 Example of DER encoding of EF(ODF) This example shows the coding of the mandatory ODF for a card with two private RSA keys and one x.509 certificate for each key. 30 82 01 16 -- SEQUENCE (ODF) 02 01 10 -- INTEGER (Version 1.0 (0x10)) 03 02 07 80 -- BIT STRING (PINInfo: case-sensitive) 30 81 96 -- SEQUENCE OF (privateKeys) 30 51 -- SEQUENCE (1st private key) 08 32 -- SEQUENCE (INSTANCE OF) 06 0C 2A 86 48 86 F7 0D 01 0F 01 01 01 01 -- OBJECT IDENTIFIER -- (id-oc-PKCS15PrivateRSAKey) A0 22 30 1F -- [0] SEQUENCE (PKCS15PrivateRSAKey) 02 02 04 00 -- INTEGER (modulusLength (1024)) 04 10 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 -- OCTET STRING (subjKeyHash) A1 08 -- IMPLICIT SEQUENCE (PKCS15Path) 51 06 3F 00 50 15 53 31 -- [APPLICATION 1] (Path: -- 3F00/5015/5331) 30 0E -- SEQUENCE (Common Object Attributes) 1E 08 00 4B 00 45 00 59 00 31 -- BMPString (Label: "KEY1") 03 02 06 C0 -- BIT STRING (private & modifiable) 30 05 -- SEQUENCE (Common Key Attributes) 04 01 31 -- OCTET STRING (id: '1') 03 00 -- BIT STRING (Neither 'local' -- or 'derive') 30 04 -- SEQUENCE (Common Private -- Key Attributes) 03 02 04 F0 -- BIT STRING (sensitive, -- encrypt, decrypt and sign) 30 51 -- SEQUENCE (2nd private key) 08 32 -- SEQUENCE (INSTANCE OF) 06 0C 2A 86 48 86 F7 0D 01 0F 01 01 01 01 -- OBJECT IDENTIFIER -- (id-oc-PKCS15PrivateRSAKey) A0 22 30 1F -- [0] SEQUENCE (PKCS15PrivateRSAKey) 02 02 04 00 -- INTEGER (modulusLength (1024)) 04 10 12 12 12 12 12 12 12 12 12 12 22 22 22 22 22 22 -- OCTET STRING (subjKeyHash) A1 08 -- SEQUENCE (PKCS15Path) 51 06 3F 00 50 15 53 32 -- [APPLICATION 1] (Path: -- 3F00/5015/5332) 30 0E -- SEQUENCE (Common Object Attributes) 1E 08 00 4B 00 45 00 59 00 32 -- BMPString (Label: "KEY2") 03 02 06 C0 -- BIT STRING (private & modifiable) 30 05 -- SEQUENCE (Common Key Attributes) 04 01 32 -- OCTET STRING (id: '2') 03 00 -- BIT STRING (Neither 'local' -- or 'derive') 30 04 -- SEQUENCE (Common Private -- Key Attributes) 03 02 04 F0 -- BIT STRING (sensitive, -- encrypt, decrypt and sign) 30 00 -- SEQUENCE OF (publicKeys, empty) 30 00 -- SEQUENCE OF (secretKeys, empty) 30 6E -- SEQUENCE OF (certificates) 30 35 -- SEQUENCE (1st certificate) 08 1C -- SEQUENCE (INSTANCE OF) 06 0C 2A 86 48 86 f& 0D 01 0F 01 01 02 01 -- OBJECT IDENTIFIER -- (id-oc-PKCS15X509Certificate) A0 0C 30 0A -- [0] SEQUENCE (PKCS15X509Certificate) A4 08 -- [4] IMPLICIT SEQUENCE (PKCS15Path) 51 06 3F 00 50 15 43 31 -- [APPLICATION 1] (Path: -- 3F00/5015/4331) 30 10 -- SEQUENCE (Common Object Attributes) 1E 0A 00 43 00 45 00 52 00 54 00 31 -- BMPString (Label: "CERT1") 03 02 06 40 -- BIT STRING (modifiable) 30 03 -- SEQUENCE (Common -- Certificate Attributes) 04 01 31 -- OCTET STRING (id: '1') 30 35 -- SEQUENCE (2nd certificate) 08 1C -- SEQUENCE (INSTANCE OF) 06 0C 2A 86 48 86 f& 0D 01 0F 01 01 02 01 -- OBJECT IDENTIFIER -- (id-oc-PKCS15X509Certificate) A0 0C 30 0A -- [0] SEQUENCE (PKCS15X509Certificate) A4 08 -- [4] IMPLICIT SEQUENCE (PKCS15Path) 51 06 3F 00 50 15 43 32 -- [APPLICATION 1] (Path: -- 3F00/5015/4332) 30 10 -- SEQUENCE (Common Object Attributes) 1E 0A 00 43 00 45 00 52 00 54 00 32 -- BMPString (Label: "CERT2") 03 02 06 40 -- BIT STRING (modifiable) 30 03 -- SEQUENCE (Common -- Certificate Attributes) 04 01 31 -- OCTET STRING (id: '2') 30 00 -- SEQUENCE OF (DataObjects, empty) 11. Revision History $Log: pkcs-15v01.txt,v $ Revision 1.3 1998/09/18 17:10:22 magnus 1st draft for external review. Revision 1.2 1998/09/14 19:35:32 magnus 1st draft version for internal review. Revision 1.1 1998/09/04 20:24:47 magnus 1st version, just an outline. Author's address RSA Laboratories (415) 595-7703 20 Crosby Drive (781) 687-7213 Bedford, MA 01730 USA pkcs-editor@rsa.com