idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2010) is 5107 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1190 -- Looks like a reference, but probably isn't: '1' on line 1191 -- Looks like a reference, but probably isn't: '2' on line 1192 -- Looks like a reference, but probably isn't: '3' on line 1193 -- Looks like a reference, but probably isn't: '4' on line 1194 -- Looks like a reference, but probably isn't: '5' on line 1195 == Missing Reference: 'RFCXXXX' is mentioned on line 886, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'LUHN' ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'RFCTBD1') ** Downref: Normative reference to an Informational draft: draft-ietf-smime-new-asn1 (ref. 'RFCTBD2') == Outdated reference: A later version (-09) exists of draft-ietf-keyprov-pskc-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-67' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KEYPROV Working Group Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standards Track April 26, 2010 4 Expires: October 26, 2010 6 Symmetric Key Package Content Type 7 draft-ietf-keyprov-symmetrickeyformat-08.txt 9 Abstract 11 This document defines the symmetric key format content type. It is 12 transport independent. The Cryptographic Message Syntax can be used 13 to digitally sign, digest, authenticate, or encrypt this content 14 type. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 26, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction...................................................3 57 1.1. Requirements Terminology..................................3 58 1.2. ASN.1 Syntax Notation.....................................3 59 2. Symmetric Key Package Content Type.............................3 60 3. PSKC Attributes................................................5 61 3.1. PSKC Key Package Attributes...............................5 62 3.1.1. Device Information Attributes........................5 63 3.1.2. Cryptographic Module Information Attributes..........7 64 3.2. PSKC Key Attributes.......................................8 65 3.2.1. Key Identifier.......................................8 66 3.2.2. Algorithm............................................8 67 3.2.3. Issuer...............................................8 68 3.2.4. Key Profile Identifier...............................8 69 3.2.5. Key Reference Identifier.............................9 70 3.2.6. Friendly Name........................................9 71 3.2.7. Algorithm Parameters.................................9 72 3.2.8. Counter.............................................11 73 3.2.9. Time................................................12 74 3.2.10. Time Interval......................................12 75 3.2.11. Time Drift.........................................12 76 3.2.12. Value MAC..........................................12 77 3.3. Key Policy Attributes....................................13 78 3.3.1. Key Start Date......................................13 79 3.3.2. Key Expiry Date.....................................13 80 3.3.3. Number of Transactions..............................14 81 3.3.4. Key Usage...........................................14 82 3.3.5. PIN Policy..........................................15 83 4. Key Encoding..................................................16 84 4.1. AES Key Encoding.........................................16 85 4.2. Triple DES Key Encoding..................................17 86 5. Security Considerations.......................................17 87 6. IANA Considerations...........................................18 88 7. References....................................................18 89 7.1. Normative References.....................................18 90 7.2. Non-Normative References.................................20 92 APPENDIX A: ASN.1 Module.........................................20 93 A.1. Symmetric Key Package ASN.1 Module.......................20 94 A.2. PSKC ASN.1 Module........................................22 96 1. Introduction 98 This document defines the symmetric key format content type. It is 99 transport independent. The Cryptographic Message Syntax (CMS) 100 [RFC5652] can be used to digitally sign, digest, authenticate, or 101 encrypt this content type. 103 The use cases that motivated the attributes in this work are 104 elaborated in [PSKC]. They are omitted to avoid duplication. 106 This document also includes Abstract Syntax Notation One (ASN.1) 107 definitions of the Extensible Markup Language (XML) element and 108 attributes defined in [PSKC]. 110 1.1. Requirements Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 1.2. ASN.1 Syntax Notation 118 The key package is defined using the ASN.1 [X.680], [X.681], [X.682], 119 and [X.683]. 121 2. Symmetric Key Package Content Type 123 The symmetric key package content type is used to transfer one or 124 more plaintext symmetric keys from one party to another. A symmetric 125 key package MAY be encapsulated in one or more CMS protecting content 126 types. This content type MUST be Distinguished Encoding Rules (DER) 127 encoded [X.690]. 129 The symmetric key package content type has the following syntax: 131 ct-symmetric-key-package CONTENT-TYPE ::= 132 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 134 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 135 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 136 smime(16) ct(1) 25 } 138 SymmetricKeyPackage ::= SEQUENCE { 139 version KeyPkgVersion DEFAULT v1, 140 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 141 {{ SKeyPkgAttributes }} OPTIONAL, 142 sKeys SymmetricKeys, 143 ... } 145 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 147 OneSymmetricKey ::= SEQUENCE { 148 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 149 {{ SKeyAttributes }} OPTIONAL, 150 sKey OCTET STRING OPTIONAL } 151 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 152 WITH COMPONENTS { ..., sKey PRESENT } ) 154 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 156 The SymmetricKeyPackage fields are used as follows: 158 - version identifies version of the symmetric key package content 159 structure. For this version of the specification, the default 160 value, v1, MUST be used. 162 - sKeyPkgAttrs optionally provides attributes that apply to all of 163 the symmetric keys in the package. The SKeyPkgAttributes 164 information object set restricts the attributes allowed in 165 sKeyPkgAttrs. If an attribute appears here, then it MUST NOT also 166 be included in sKeyAttrs. 168 - sKeys contains a sequence of OneSymmetricKey values. This 169 structure is discussed below. 171 The OneSymmetricKey fields are used as follows: 173 - sKeyAttrs optionally provides attributes that apply to one 174 symmetric key. The SKeyAttributes information object set 175 restricts the attributes permitted in sKeyAttrs. If an attribute 176 appears here, then it MUST NOT also be included in sKeyPkgAttrs. 178 - sKey optionally contains the key value encoded as an OCTET STRING. 180 The OneSymmetricKey field MUST include either sKeyAttrs, or sKey, or 181 sKeyAttrs and sKey. 183 3. PSKC Attributes 185 The following attributes are defined to assist those using the 186 symmetric key package defined in this document as part of a Dynamic 187 Symmetric Key Provision Protocol (DSKPP) [DSKPP] with Portable 188 Symmetric Key Container (PSKC) attributes. [PSKC] should be 189 consulted for the definitive attribute descriptions. The attributes 190 fall in to three categories. The first category includes attributes 191 that apply to a key package, and these attributes will generally 192 appear in sKeyPkgAttrs. The second category includes attributes that 193 apply to a particular key, and these attributes will generally appear 194 in sKeyAttrs. The third category includes attributes that apply to a 195 key policy. Of the attributes defined, only the Key Identifier 196 (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be 197 included. All other attributes are OPTIONAL. 199 Like PSKC, the Symmetric Key Content Type supports extensibility. 200 Primarily this is accomplished through the definition and inclusion 201 of new attributes, but in some instances where the attribute contains 202 more than one type the ASN.1 "..." extensibility mechanism is 203 employed. 205 A straightforward approach to conversion from XML types to ASN.1 is 206 employed. The type converts to UTF8String; the XML 207 type converts to GeneralizedTime; and the XML integer 208 types convert to INTEGER or BinaryTime [RFC4049]. 210 3.1. PSKC Key Package Attributes 212 PSKC key package attributes apply to an entire key package. These 213 attributes can be categorized by two different attribute collections: 214 device information and cryptographic module attributes. All of these 215 key package attributes are OPTIONAL. 217 3.1.1. Device Information Attributes 219 Device Information attributes when taken together uniquely identify a 220 device to which the Symmetric Key Package is provisioned. 222 3.1.1.1. Manufacturer 224 The Manufacturer attribute indicates the manufacturer of the device. 225 The attribute definition is as follows: 227 at-pskc-manufacturer ATTRIBUTE ::= { 228 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 230 id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } 232 3.1.1.2. Serial Number 234 The Serial Number attribute indicates the serial number of the 235 device. The attribute definition is as follows: 237 at-pskc-serialNo ATTRIBUTE ::= { 238 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 240 id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } 242 3.1.1.3. Model 244 The Model attribute indicates the model of the device. The attribute 245 definition is as follows: 247 at-pskc-model ATTRIBUTE ::= { 248 TYPE UTF8String IDENTIFIED BY id-pskc-model } 250 id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } 252 3.1.1.4. Issue Number 254 The Issue Number attribute contains an issue number to distinguish 255 between two devices with the same serial number. The attribute 256 definition is as follows: 258 at-pskc-issueNo ATTRIBUTE ::= { 259 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 261 id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } 263 3.1.1.5. Device Binding 265 The Device Binding attribute provides an opaque identifier that 266 allows keys to be bound to the device or to a class of devices. 267 When loading keys into a device, the attribute's value MUST be 268 checked against information provided to the user via out-of-band 269 mechanisms. The implementation then ensures that the correct device 270 or class of device is being used with respect to the provisioned key. 272 at-pskc-deviceBinding ATTRIBUTE ::= { 273 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 275 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } 277 3.1.1.6. Device Start Date 279 When included in sKeyPkgAttrs, the Device Start Date attribute 280 indicates the start date for a device. The date MUST be expressed in 281 UTC form with no time zone component. Implementations SHOULD NOT 282 rely on time resolution finer than milliseconds and MUST NOT generate 283 time instants that specify leap seconds. The attribute definition is 284 as follows: 286 at-pskc-deviceStartDate ATTRIBUTE ::= { 287 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 289 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 291 3.1.1.7. Device Expiry Date 293 When included in sKeyPkgAttrs, the Device Expiry Date attribute 294 indicates the expiry date for a device. The date MUST be expressed 295 in UTC form with no time zone component. Implementations SHOULD NOT 296 rely on time resolution finer than milliseconds and MUST NOT generate 297 time instants that specify leap seconds. The attribute definition is 298 as follows: 300 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 301 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 303 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 305 3.1.2. Cryptographic Module Information Attributes 307 Cryptographic Module attributes uniquely identify a cryptographic 308 module. This is useful when the device contains more than one 309 cryptographic module. At this time only one attribute is defined. 311 3.1.2.1. Cryptographic Module Identifier 313 When included in sKeyPkgAttrs, the Cryptographic Module Identifier 314 attribute uniquely identifies the cryptographic module to which the 315 key is being or was provisioned. The attribute definition is as 316 follows: 318 at-pskc-moduleId ATTRIBUTE ::= { 319 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 321 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 323 3.2. PSKC Key Attributes 325 PSKC key attributes apply to a specific key. As noted earlier, the 326 Key Identifier (Sec 3.2.1) and Algorithm (Sec 3.2.2) key attributes 327 are REQUIRED. All other attributes are OPTIONAL. 329 3.2.1. Key Identifier 331 When included in sKeyAttrs, the Key Identifier attribute uniquely 332 identifies the key. The attribute definition is as follows: 334 at-pskc-keyId ATTRIBUTE ::= { 335 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 337 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 339 3.2.2. Algorithm 341 The Algorithm attribute uniquely identifies the PSKC algorithm 342 profile. [PSKC] defines two algorithm profiles "HOTP" and 343 "KEYPROV-PIN". The attribute definition is as follows: 345 at-pskc-algorithm ATTRIBUTE ::= { 346 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 348 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 350 3.2.3. Issuer 352 The Issuer attribute names the entity that issued the key. The 353 attribute definition is as follows: 355 at-pskc-issuer ATTRIBUTE ::= { 356 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 358 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 360 3.2.4. Key Profile Identifier 362 The Key Profile Identifier attribute carries a unique identifier used 363 between the sending and receiving parties to establish a set of key 364 attribute values that are not transmitted within the container but 365 agreed between the two parties out of band. This attribute will then 366 represent the unique reference to a set of key attribute values. 368 at-pskc-keyProfileId ATTRIBUTE ::= { 369 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 371 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 373 3.2.5. Key Reference Identifier 375 The Key Reference attribute refers to an external key to be used with 376 a key derivation scheme and no specific key value (secret) is 377 transported but only the reference to the external master key is used 378 (e.g., the PKCS#11 key label). 380 at-pskc-keyReference ATTRIBUTE ::= { 381 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 383 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 385 3.2.6. Friendly Name 387 The Friendly Name attribute contains a human readable name for the 388 secret key. The attribute definition is as follows: 390 at-pskc-friendlyName ATTRIBUTE ::= { 391 TYPE UTF8String IDENTIFIED BY id-pskc-friendlyName } 393 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 395 The text is encoded in UTF-8 [RFC3629], which accommodates most of 396 the world's writing systems. The friendlyNameLangTag field 397 identifies the language used to express the friendlyName. When 398 friendlyNameLangTag is absent, English is used. The value of the 399 friendlyNameLangTag should be a language tag as described in 400 [RFC5646]. 402 3.2.7. Algorithm Parameters 404 The Algorithm Parameters attribute contains parameters that influence 405 the result of the algorithmic computation, for example response 406 truncation and format in One-Time Password (OTP) and Challenge- 407 Response (CR) algorithms. 409 at-pskc-algorithmParameters ATTRIBUTE ::= { 410 TYPE PSKCAlgorithmParameters 411 IDENTIFIED BY id-pskc-algorithmParams } 413 id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 } 414 The Algorithm Parameters attribute has the following syntax: 416 PSKCAlgorithmParameters ::= CHOICE { 417 challengeFormat [0] ChallengeFormat, 418 responseFormat [1] ResponseFormat, 419 ... } 421 ChallengeFormat ::= SEQUENCE { 422 encoding Encoding, 423 checkDigit BOOLEAN DEFAULT FALSE, 424 min INTEGER (0..MAX), 425 max INTEGER (0..MAX), 426 ... } 428 Encoding ::= UTF8STRING ("DECIMAL" | "HEXADECIMAL" | 429 "ALPHANUMERIC" |"BASE64" |"BINARY") 431 ResponseFormat ::= SEQUENCE { 432 encoding Encoding, 433 length INTEGER (0..MAX), 434 checkDigit BOOLEAN DEFAULT FALSE, 435 ... } 437 The fields in PSKCAlgorithmParameters have the following meanings: 439 o ChallengeFormat defines the characteristics of the challenge in a 440 CR usage scenario whereby the following fields are defined: 442 o encoding specifies the encoding of the challenge accepted by 443 the device and MUST be one of the following values: DECIMAL, 444 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64 445 encoding is done as in Section 4 of [RFC4648]. 447 o checkDigit indicates whether a device needs to check the 448 appended Luhn check digit, as defined in [LUHN], contained in a 449 challenge. The checkDigit MUST NOT be present if the encoding 450 value is anything other than 'DECIMAL'. A value of TRUE 451 indicates that the device will check the appended Luhn check 452 digit in a provided challenge. A value of FALSE indicates that 453 the device will not check the appended Luhn check digit in the 454 challenge. 456 o min defines the minimum size of the challenge accepted by the 457 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 458 'ALPHANUMERIC' this value indicates the minimum number of 459 digits/characters. If encoding is 'BASE64' or 'BINARY', this 460 value indicates the minimum number of bytes of the unencoded 461 value. 463 o max defines the maximum size of the challenge accepted by the 464 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 465 'ALPHANUMERIC' this value indicates the maximum number of 466 digits/characters. If the encoding is 'BASE64' or 'BINARY', 467 this value indicates the maximum number of bytes of the 468 unencoded value. 470 o ResponseFormat defines the characteristics of the result of a 471 computation and defines the format of the OTP or the response to 472 a challenge. For cases where the key is a personal 473 identification number (PIN) value, this element contains the 474 format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit 475 PIN). The following fields are defined: 477 o encoding specifies the encoding of the response generated by 478 the device and MUST be one of the following values: DECIMAL, 479 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is 480 defined as in Section 4 of [RFC4648]. 482 o length defines the length of the response generated by the 483 device. If encoding is 'DECIMAL', 'HEXADECIMAL' or 484 'ALPHANUMERIC' this value indicates the number of 485 digits/characters. If encoding is 'BASE64' or 'BINARY', this 486 value indicates the number of bytes of the unencoded value. 488 o checkDigit indicates whether the device needs to append a Luhn 489 check digit, as defined in [LUHN], to the response. This is 490 only valid if encoding attribute is 'DECIMAL'. If the value is 491 TRUE then the device will append a Luhn check digit to the 492 response. If the value is FALSE, then the device will not 493 append a Luhn check digit to the response. 495 3.2.8. Counter 497 The Counter attribute contains the event counter for event-based OTP 498 algorithms. The attribute definition is as follows: 500 at-pskc-counter ATTRIBUTE ::= { 501 TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter } 503 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 505 3.2.9. Time 507 The Time attribute conveys the time for time-based OTP algorithms. 508 If the Time Interval attribute is included, then this element carries 509 the number of time intervals passed for a specific start point. It 510 uses the BinaryTime syntax from [RFC4049]. The attribute definition 511 is as follows: 513 at-pskc-time ATTRIBUTE ::= { 514 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 516 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 518 3.2.10. Time Interval 520 The Time Interval attribute conveys the time interval value for time- 521 based OTP algorithms. It is an integer. The attribute definition is 522 as follows: 524 at-pskc-timeInterval ATTRIBUTE ::= { 525 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 527 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 529 3.2.11. Time Drift 531 The Time Drift attribute contains the device clock drift value, the 532 number of seconds per day the device clocks drifts, for time-based 533 OTP algorithms. It is an integer. The attribute definition is as 534 follows: 536 at-pskc-timeDrift ATTRIBUTE ::= { 537 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 539 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 541 3.2.12. Value MAC 543 The Value MAC attribute is a Message Authentication Code (MAC) 544 generated from the encrypted value in case the encryption algorithm 545 does not support integrity checks (e.g., AES-CBC does not provide 546 integrity while AES Key Wrap with MLI does). The attribute definition 547 is as follows: 549 at-pskc-valueMAC ATTRIBUTE ::= { 550 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 552 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 554 ValueMac ::= SEQUENCE { 555 macAlgorithm UTF8String, 556 mac UTF8String } 558 The fields in ValueMac have the following meanings: 560 o macAlgorithm identifies the MAC algorithm used to generate the 561 value placed in digest. 563 o mac is the base64 encoded, as specified in Section 4 of [RFC4648], 564 mac value. 566 3.3. Key Policy Attributes 568 Key policy attributes indicate a policy that can be attached to a 569 key. These attributes are defined in the subsections that follow. 571 3.3.1. Key Start Date 573 When included in sKeyAttrs, the Key Start Date attribute indicates 574 the start of the keys validity. The date MUST be expressed in UTC 575 form with no time zone component. Implementations SHOULD NOT rely on 576 time resolution finer than milliseconds and MUST NOT generate time 577 instants that specify leap seconds. The attribute definition is as 578 follows: 580 at-pskc-keyStartDate ATTRIBUTE ::= { 582 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 584 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 586 3.3.2. Key Expiry Date 588 When included in sKeyAttrs, the Key Expiry Date attribute indicates 589 the end of the key's validity period. The date MUST be expressed in 590 UTC form with no time zone component. Implementations SHOULD NOT 591 rely on time resolution finer than milliseconds and MUST NOT generate 592 time instants that specify leap seconds. The attribute definition is 593 as follows: 595 at-pskc-keyExpiryDate ATTRIBUTE ::= { 596 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 598 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 600 3.3.3. Number of Transactions 602 The Number of Transactions attribute indicates the maximum number of 603 times a key carried within the package can be used. When this 604 element is omitted there is no restriction regarding the number of 605 times a key can be used. The attribute definition is as follows: 607 at-pskc-noOfTransactions ATTRIBUTE ::= { 608 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions } 610 id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 612 3.3.4. Key Usage 614 The Key Usage attribute constrains the intended usage of the key. 615 The recipient MUST enforce the key usage. The attribute definition 616 is as follows: 618 at-pskc-keyUsage ATTRIBUTE ::= { 619 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 621 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 623 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 625 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 626 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 627 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 629 The fields in PSKCKeyUsage have the following meanings: 631 o OTP: The key MUST only be used for OTP generation. 633 o CR: The key MUST only be used for Challenge/Response purposes. 635 o Encrypt: The key MUST only be used for data encryption purposes. 637 o Integrity: The key MUST only be used to generate a keyed message 638 digest for data integrity or authentication purposes. 640 o Verify: The key MUST only be used to verify a keyed message 641 digest for data integrity or authentication purposes (is converse 642 of Integrity). 644 o Unlock: The key MUST only be used for an inverse challenge 645 response in the case where a user has locked the device by 646 entering a wrong PIN too many times (for devices with PIN-input 647 capability). 649 o Decrypt: The key MUST only be used for data decryption purposes. 651 o KeyWrap: The key MUST only be used for key wrap purposes. 653 o Unwrap: The key MUST only be used for key unwrap purposes. 655 o Derive: The key MUST only be used with a key derivation function 656 to derive a new key (see also Section 8.2.4 of [NIST800-57]). 658 o Generate: The key MUST only be used to generate a new key based 659 on a random number and the previous value of the key (see also 660 Section 8.1.5.2.1 of [NIST800-57]). 662 3.3.5. PIN Policy 664 The PIN Policy attribute allows policy about the PIN usage to be 665 associated with the key. The attribute definition is as follows: 667 at-pskc-pinPolicy ATTRIBUTE ::= { 668 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 670 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 672 PINPolicy ::= SEQUENCE { 673 pinKeyId [0] UTF8String OPTIONAL, 674 pinUsageMode [1] PINUsageMode, 675 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 676 minLength [3] INTEGER (0..MAX) OPTIONAL, 677 maxLength [4] INTEGER (0..MAX) OPTIONAL, 678 pinEncoding [5] Encoding OPTIONAL } 680 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" | 681 "Algorithmic") 683 The fields in PIN Policy have the following meanings: 685 o pinKeyId uniquely identifies the key held within this container 686 that contains the value of the PIN that protects the key. 688 o pinUsageMode indicates the way the PIN is used during the 689 usage of the key. The following values are defined in [PSKC]: 690 Local, Prepend, Append, Algorithmic. 692 o maxFailedAttempts indicates the maximum number of times the PIN 693 may be entered wrongly before it MUST NOT be possible to use the 694 key anymore. 696 o minLength indicates the minimum length of a PIN that can be set to 697 protect the associated key. It MUST NOT be possible to set a PIN 698 shorter than this value. If pinEncoding is 'DECIMAL', 699 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 700 digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this 701 value indicates the number of bytes of the unencoded value. 703 o maxLength indicates the maximum length of a PIN that can be set to 704 protect this key. It MUST NOT be possible to set a PIN longer 705 than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL' or 706 'ALPHANUMERIC' this value indicates the number of 707 digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', 708 this value indicates the number of bytes of the unencoded value. 710 o pinEncoding is based on Encoding, which is defined in Section 711 3.2.6, and specifies encoding of the PIN and MUST be one of the 712 following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or 713 BINARY. 715 If pinUsageMode is set to "Local" then the device MUST enforce the 716 restriction indicated in maxFailedAttempts, minLength, maxLength and 717 pinEncoding, otherwise it MUST be enforced on the server side. 719 4. Key Encoding 721 Two parties receiving the same key as an sKey OCTET STRING must make 722 use of the key in exactly the same way in order to interoperate. To 723 ensure that, it is necessary to define a correspondence between the 724 abstract syntax of sKey and the notation in the standard algorithm 725 description that defines how the key is used. The next sections 726 establish that correspondence for the algorithms AES [FIPS197] and 727 TDEA [SP800-67]. 729 4.1. AES Key Encoding 731 [FIPS197] section 5.2, titled Key Expansion, uses the input key as an 732 array of bytes indexed starting at 0. The first octet of sKey SHALL 733 become the key byte in AES labeled index 0 in [FIPS197]; it SHALL be 734 the first octet of sKey, and the other key bytes SHALL follow in 735 index order. 737 Proper parsing and key load of the contents of sKey for AES SHALL be 738 determined by using the following sKey octet string to generate and 739 match the key expansion test vectors in [FIPS197] Appendix A for AES 740 Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 742 Tag Length Value 743 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 745 4.2. Triple DES Key Encoding 747 A Triple-DES key consists of three keys for the cryptographic engine 748 (Key1, Key2, and Key3) that are each 64 bits (even though only 56 are 749 used); the three keys are also referred to as a key bundle (KEY) 750 [SP800-67]. A key bundle may employ either two or three mutually 751 independent keys. When only two are employed (called two-key Triple 752 DES), then Key1 = Key3. 754 Each key in a Triple-DES key bundle is expanded into a key schedule 755 according to a procedure defined in [SP800-67] Appendix A. That 756 procedure numbers the bits in the key from 1 to 64, with number 1 757 being the left-most, or most significant bit (MSB). The first octet 758 of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. 759 The second octet of sKey SHALL be bits 9 through 16 of Key1, and so 760 forth, so that the trailing octet of sKEY SHALL be bits 57 through 64 761 of Key3 (or Key2 for two-key Triple DES). 763 Proper parsing and key load of the contents of sKey for Triple-DES 764 SHALL be determined by using the following sKey octet string to 765 generate and match the key expansion test vectors in [SP800-67] 766 appendix B for the key bundle: 768 Key1 = 0123456789ABCDEF 770 Key2 = 23456789ABCDEF01 772 Key3 = 456789ABCDEF0123 774 Tag Length Value 775 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123 777 5. Security Considerations 779 Implementers of this protocol are strongly encouraged to consider 780 generally accepted principles of secure key management when 781 integrating this capability within an overall security architecture. 783 The symmetric key package contents are not protected. This content 784 type can be combined with a security protocol to protect the contents 785 of the package. One possibility is to include this content type in 786 place of a PSKC package in [DSKPP] exchanges. In this case, the 787 algorithm requirements are found in those documents. Another 788 possibility is to encapsulate this content type in a CMS [RFC5652] 789 protecting content type. 791 6. IANA Considerations 793 This document makes use of object identifiers to identify a CMS 794 content type (Appendix A.1), the ASN.1 version of the PSKC attributes 795 (Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2. 796 All OIDs are registered in an arc delegated by IANA to the SMIME 797 Working Group. No further action by IANA is necessary for this 798 document or any anticipated updates. 800 7. References 802 7.1. Normative References 804 [FIPS197] National Institute of Standards. "FIPS Pub 197: 805 Advanced Encryption Standard (AES)", 26 November 2001. 807 [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048, August 808 1960, http://patft.uspto.gov/netacgi/nph- 809 Parser?patentnumber=2950048. 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 815 10646", STD 63, RFC 3629, November 2003. 817 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 818 Representing Date and Time in ASN.1", RFC 4049, April 819 2005. 821 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 822 Encodings", RFC 4648, October 2006. 824 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 825 Languages", BCP 47, RFC 5646, September 2009. 827 [RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for 828 PKIX", draft-ietf-pkix-new-asn1-08.txt, work-in- 829 progress. 831 //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 832 the draft-ietf-pkix-new-asn1's RFC #. Make the replacements here and 833 elsewhere in the document. **// 835 [RFCTBD2] Schaad, J., and P. Hoffman, "New ASN.1 Modules for 836 SMIME", draft-ietf-smime-new-asn1-07.txt, work-in- 837 progress. 839 //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 840 the draft-ietf-smime-new-asn1's RFC #. Make the replacements here 841 and elsewhere in the document. **// 843 [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 844 Key Container (PSKC), draft-ietf-keyprov-pskc-05.txt, 845 work-in-progress. 847 //** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is 848 the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and 849 elsewhere in the document. **// 851 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 852 1:2002. Information Technology - Abstract Syntax 853 Notation One. 855 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- 856 2:2002. Information Technology - Abstract Syntax 857 Notation One: Information Object Specification. 859 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 860 3:2002. Information Technology - Abstract Syntax 861 Notation One: Constraint Specification. 863 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 864 4:2002. Information Technology - Abstract Syntax 865 Notation One: Parameterization of ASN.1 Specifications. 867 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 868 1:2002. Information Technology - ASN.1 encoding rules: 869 Specification of Basic Encoding Rules (BER), Canonical 870 Encoding Rules (CER) and Distinguished Encoding Rules 871 (DER). 873 [SP800-67] National Institute of Standards and Technology, "NIST 874 Special Publication 800-67 Version 1.1: Recommendation 875 for the Triple Data Encryption Algorithm (TDEA) Block 876 Cipher", NIST Special Publication 800-67, May 2008. 878 7.2. Informative References 880 [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, 881 "Dynamic Symmetric Key Provisioning Protocol", Internet 882 Draft Informational, URL: http://www.ietf.org/internet- 883 drafts/draft-ietf-keyprov-dskpp-10.txt, work in 884 progress. 886 //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 887 the draft-ietf-keyprov-dskpp's RFC #. Make the replacements here and 888 elsewhere in the document. **// 890 [NIST800-57] National Institute of Standards and Technology, "NIST 891 Special Publication 800-57, Recommendation for Key 892 Management - Part 1: General (Revised)", NIST Special 893 Publication 800-57, March 2007. 895 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 896 5652, September 2009. 898 APPENDIX A: ASN.1 Module 900 This appendix provides the normative ASN.1 definitions for the 901 structures described in this specification using ASN.1 as defined in 902 [X.680] through [X.683]. 904 A.1. Symmetric Key Package ASN.1 Module 906 SymmetricKeyPackageModulev1 907 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 908 smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) } 910 DEFINITIONS IMPLICIT TAGS ::= 912 BEGIN 914 -- EXPORTS ALL 916 IMPORTS 918 -- From New PKIX ASN.1 [RFCTBD1] 920 ATTRIBUTE 921 FROM PKIX-CommonTypes-2009 922 { iso(1) identified-organization(3) dod(6) internet(1) 923 security(5) mechanisms(5) pkix(7) id-mod(0) 924 id-mod-pkixCommon-02(57) } 926 -- From New SMIME ASN.1 [RFCTBD2] 928 CONTENT-TYPE, Attribute{} 929 FROM CryptographicMessageSyntax-2009 930 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 931 smime(16) modules(0) id-mod-cms-2004-02(41) } 933 ; 935 ContentSet CONTENT-TYPE ::= { 936 ct-symmetric-key-package, 937 ... -- Expect additional content types -- 938 } 940 ct-symmetric-key-package CONTENT-TYPE ::= 941 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 943 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 944 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 945 smime(16) ct(1) 25 } 947 SymmetricKeyPackage ::= SEQUENCE { 948 version KeyPkgVersion DEFAULT v1, 949 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 950 {{ SKeyPkgAttributes }} OPTIONAL, 951 sKeys SymmetricKeys, 952 ... } 954 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 956 OneSymmetricKey ::= SEQUENCE { 957 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 958 {{ SKeyAttributes }} OPTIONAL, 959 sKey OCTET STRING OPTIONAL } 960 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 961 WITH COMPONENTS { ..., sKey PRESENT } ) 963 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 965 SKeyPkgAttributes ATTRIBUTE ::= { ... } 967 SKeyAttributes ATTRIBUTE ::= { ... } 969 END 971 A.2. PSKC ASN.1 Module 973 PSKCAttributesModule 974 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 975 smime(16) modules(0) id-mod-pskcAttributesModule(53) } 977 DEFINITIONS IMPLICIT TAGS ::= 979 BEGIN 981 -- EXPORTS ALL 983 IMPORTS 985 -- From New PKIX ASN.1 [RFCTBD1] 987 ATTRIBUTE 988 FROM PKIX-CommonTypes-2009 989 { iso(1) identified-organization(3) dod(6) internet(1) 990 security(5) mechanisms(5) pkix(7) id-mod(0) 991 id-mod-pkixCommon-02(57) } 993 -- From BinaryTime [RFC4049] 995 BinaryTime 996 FROM BinarySigningTimeModule 997 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 998 smime(16) modules(0) id-mod-binarySigningTime(27) } 1000 id-smime 1001 FROM SecureMimeMessageV3dot1-2009 1002 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1003 smime(16) modules(0) id-mod-msg-v3dot1-02(39) } 1005 ; 1007 -- 1008 -- PSKC Attributes OIDs are taken from the SMIME Arc. 1009 -- 1011 id-pskc OBJECT IDENTIFIER ::= { id-smime 12 } 1012 -- 1013 -- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs 1014 -- 1016 SKeyPkgAttributes ATTRIBUTE ::= { 1017 at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model | 1018 at-pskc-issueNo | at-pskc-deviceBinding | 1019 at-pskc-deviceStartDate | at-pskc-deviceExpiryDate | 1020 at-pskc-moduleId, ... } 1022 -- 1023 -- Merge SKeyAttributes to the set of attributes for sKeyAttrs 1024 -- 1026 SKeyAttributes ATTRIBUTE ::= { 1027 at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer | 1028 at-pskc-keyProfileId | at-pskc-keyReference | 1029 at-pskc-friendlyName | at-pskc-algorithmParameters | 1030 at-pskc-counter | at-pskc-time | at-pskc-timeInterval | 1031 at-pskc-timeDrift | at-pskc-valueMAC | at-pskc-keyStartDate | 1032 at-pskc-keyExpiryDate | at-pskc-numberOfTransactions | 1033 at-pskc-keyUsage | at-pskc-pinPolicy, ... } 1035 at-pskc-manufacturer ATTRIBUTE ::= { 1036 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 1038 id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } 1040 at-pskc-serialNo ATTRIBUTE ::= { 1041 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 1043 id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } 1045 at-pskc-model ATTRIBUTE ::= { 1046 TYPE UTF8String IDENTIFIED BY id-pskc-model } 1048 id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } 1050 at-pskc-issueNo ATTRIBUTE ::= { 1051 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 1053 id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } 1055 at-pskc-deviceBinding ATTRIBUTE ::= { 1056 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 1058 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } 1059 at-pskc-deviceStartDate ATTRIBUTE ::= { 1060 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 1062 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 1064 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 1065 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 1067 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 1069 at-pskc-moduleId ATTRIBUTE ::= { 1070 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 1072 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 1074 at-pskc-keyId ATTRIBUTE ::= { 1075 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 1077 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 1079 at-pskc-algorithm ATTRIBUTE ::= { 1080 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 1082 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 1084 at-pskc-issuer ATTRIBUTE ::= { 1085 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 1087 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 1089 at-pskc-keyProfileId ATTRIBUTE ::= { 1090 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 1092 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 1094 at-pskc-keyReference ATTRIBUTE ::= { 1095 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 1097 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 1099 at-pskc-friendlyName ATTRIBUTE ::= { 1100 TYPE UTF8String IDENTIFIED BY id-pskc-friendlyName } 1102 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 1103 at-pskc-algorithmParameters ATTRIBUTE ::= { 1104 TYPE PSKCAlgorithmParameters 1105 IDENTIFIED BY id-pskc-algorithmParameters } 1107 id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 } 1109 PSKCAlgorithmParameters ::= CHOICE { 1110 challengeFormat [0] ChallengeFormat, 1111 responseFormat [1] ResponseFormat, 1112 ... } 1114 ChallengeFormat ::= SEQUENCE { 1115 encoding Encoding, 1116 checkDigit BOOLEAN DEFAULT FALSE, 1117 min INTEGER (0..MAX), 1118 max INTEGER (0..MAX), 1119 ... } 1121 Encoding ::= UTF8String ("DECIMAL" | "HEXADECIMAL" | 1122 "ALPHANUMERIC" | "BASE64" | "BINARY" ) 1124 ResponseFormat ::= SEQUENCE { 1125 encoding Encoding, 1126 length INTEGER (0..MAX), 1127 checkDigit BOOLEAN DEFAULT FALSE, 1128 ... } 1130 at-pskc-counter ATTRIBUTE ::= { 1131 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-counter } 1133 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 1135 at-pskc-time ATTRIBUTE ::= { 1136 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1138 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 1140 at-pskc-timeInterval ATTRIBUTE ::= { 1141 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 1143 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 1145 at-pskc-timeDrift ATTRIBUTE ::= { 1146 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 1148 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 1149 at-pskc-valueMAC ATTRIBUTE ::= { 1150 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 1152 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 1154 ValueMac ::= SEQUENCE { 1155 macAlgorithm UTF8String, 1156 mac UTF8String } 1158 at-pskc-keyStartDate ATTRIBUTE ::= { 1160 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 1162 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 1164 at-pskc-keyExpiryDate ATTRIBUTE ::= { 1165 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 1167 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 1169 at-pskc-numberOfTransactions ATTRIBUTE ::= { 1170 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-numberOfTransactions } 1172 id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 1174 at-pskc-keyUsage ATTRIBUTE ::= { 1175 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 1177 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 1179 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 1181 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 1182 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 1183 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 1185 at-pskc-pinPolicy ATTRIBUTE ::= { 1186 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 1188 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 1189 PINPolicy ::= SEQUENCE { 1190 pinKeyId [0] UTF8String OPTIONAL, 1191 pinUsageMode [1] PINUsageMode, 1192 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 1193 minLength [3] INTEGER (0..MAX) OPTIONAL, 1194 maxLength [4] INTEGER (0..MAX) OPTIONAL, 1195 pinEncoding [5] Encoding OPTIONAL } 1197 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append"| 1198 "Algorithmic") 1200 END 1202 Authors' Addresses 1204 Sean Turner 1205 IECA, Inc. 1206 3057 Nutley Street, Suite 106 1207 Fairfax, VA 22031 1208 USA 1210 Email: turners@ieca.com 1212 Russ Housley 1213 Vigil Security, LLC 1214 918 Spring Knoll Drive 1215 Herndon, VA 20170 1216 USA 1218 EMail: housley@vigilsec.com