idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-10.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 (August 4, 2010) is 5014 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 1315 -- Looks like a reference, but probably isn't: '1' on line 1316 -- Looks like a reference, but probably isn't: '2' on line 1317 -- Looks like a reference, but probably isn't: '3' on line 1318 -- Looks like a reference, but probably isn't: '4' on line 1319 -- Looks like a reference, but probably isn't: '5' on line 1320 == Missing Reference: 'RFCXXXX' is mentioned on line 991, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAPENREG' -- Possible downref: Non-RFC (?) normative reference: ref. 'LUHN' ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) ** Downref: Normative reference to an Informational RFC: RFC 5911 ** Downref: Normative reference to an Informational RFC: RFC 5912 -- Possible downref: Non-RFC (?) normative reference: ref. 'OATHMAN' == Outdated reference: A later version (-09) exists of draft-ietf-keyprov-pskc-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-67' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSCHEMA' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KEYPROV Working Group Sean Turner 2 Internet Draft IECA 3 Intended Status: Standards Track Russ Housley 4 Expires: February 4, 2010 Vigil Security 5 August 4, 2010 7 Symmetric Key Package Content Type 8 draft-ietf-keyprov-symmetrickeyformat-10.txt 10 Abstract 12 This document defines the symmetric key format content type. It is 13 transport independent. The Cryptographic Message Syntax can be used 14 to digitally sign, digest, authenticate, or encrypt this content 15 type. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on February 4, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction...................................................3 58 1.1. Requirements Terminology..................................3 59 1.2. ASN.1 Syntax Notation.....................................3 60 2. Symmetric Key Package Content Type.............................3 61 3. PSKC Attributes................................................5 62 3.1. PSKC Key Package Attributes...............................5 63 3.1.1. Device Information Attributes........................5 64 3.1.2. Cryptographic Module Information Attributes..........8 65 3.2. PSKC Key Attributes.......................................9 66 3.2.1. Key Identifier.......................................9 67 3.2.2. Algorithm............................................9 68 3.2.3. Issuer...............................................9 69 3.2.4. Key Profile Identifier..............................10 70 3.2.5. Key Reference Identifier............................10 71 3.2.6. Friendly Name.......................................10 72 3.2.7. Algorithm Parameters................................11 73 3.2.8. Counter.............................................13 74 3.2.9. Time................................................13 75 3.2.10. Time Interval......................................13 76 3.2.11. Time Drift.........................................14 77 3.2.12. Value MAC..........................................14 78 3.2.13. Key User Id........................................14 79 3.3. Key Policy Attributes....................................15 80 3.3.1. Key Start Date......................................15 81 3.3.2. Key Expiry Date.....................................15 82 3.3.3. Number of Transactions..............................16 83 3.3.4. Key Usage...........................................16 84 3.3.5. PIN Policy..........................................17 85 4. Key Encoding..................................................18 86 4.1. AES Key Encoding.........................................18 87 4.2. Triple DES Key Encoding..................................19 89 5. Security Considerations.......................................19 90 6. IANA Considerations...........................................20 91 7. References....................................................20 92 7.1. Normative References.....................................20 93 7.2. Informative References...................................22 94 APPENDIX A: ASN.1 Module.........................................22 95 A.1. Symmetric Key Package ASN.1 Module.......................22 96 A.2. PSKC ASN.1 Module........................................24 98 1. Introduction 100 This document defines the symmetric key format content type. It is 101 transport independent. The Cryptographic Message Syntax (CMS) 102 [RFC5652] can be used to digitally sign, digest, authenticate, or 103 encrypt this content type. 105 The use cases that motivated the attributes in this work are 106 elaborated in [PSKC]. They are omitted to avoid duplication. 108 This document also includes Abstract Syntax Notation One (ASN.1) 109 definitions of the Extensible Markup Language (XML) element and 110 attributes defined in [PSKC]. 112 1.1. Requirements Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 1.2. ASN.1 Syntax Notation 120 The key package is defined using the ASN.1 [X.680], [X.681], [X.682], 121 and [X.683]. 123 2. Symmetric Key Package Content Type 125 The symmetric key package content type is used to transfer one or 126 more plaintext symmetric keys from one party to another. A symmetric 127 key package MAY be encapsulated in one or more CMS protecting content 128 types. This content type MUST be Distinguished Encoding Rules (DER) 129 encoded [X.690]. 131 The symmetric key package content type has the following syntax: 133 ct-symmetric-key-package CONTENT-TYPE ::= 134 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 136 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 137 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 138 smime(16) ct(1) 25 } 140 SymmetricKeyPackage ::= SEQUENCE { 141 version KeyPkgVersion DEFAULT v1, 142 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 143 {{ SKeyPkgAttributes }} OPTIONAL, 144 sKeys SymmetricKeys, 145 ... } 147 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 149 OneSymmetricKey ::= SEQUENCE { 150 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 151 {{ SKeyAttributes }} OPTIONAL, 152 sKey OCTET STRING OPTIONAL } 153 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 154 WITH COMPONENTS { ..., sKey PRESENT } ) 156 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 158 The SymmetricKeyPackage fields are used as follows: 160 - version identifies version of the symmetric key package content 161 structure. For this version of the specification, the default 162 value, v1, MUST be used. 164 - sKeyPkgAttrs optionally provides attributes that apply to all of 165 the symmetric keys in the package. The SKeyPkgAttributes 166 information object set restricts the attributes allowed in 167 sKeyPkgAttrs. If an attribute appears here, then it MUST NOT also 168 be included in sKeyAttrs. 170 - sKeys contains a sequence of OneSymmetricKey values. This 171 structure is discussed below. 173 The OneSymmetricKey fields are used as follows: 175 - sKeyAttrs optionally provides attributes that apply to one 176 symmetric key. The SKeyAttributes information object set 177 restricts the attributes permitted in sKeyAttrs. If an attribute 178 appears here, then it MUST NOT also be included in sKeyPkgAttrs. 180 - sKey optionally contains the key value encoded as an OCTET STRING. 182 The OneSymmetricKey field MUST include either sKeyAttrs, or sKey, or 183 sKeyAttrs and sKey. 185 3. PSKC Attributes 187 The following attributes are defined to assist those using the 188 symmetric key package defined in this document as part of a Dynamic 189 Symmetric Key Provision Protocol (DSKPP) [DSKPP] with Portable 190 Symmetric Key Container (PSKC) attributes. [PSKC] should be 191 consulted for the definitive attribute descriptions. The attributes 192 fall in to three categories. The first category includes attributes 193 that apply to a key package, and these attributes will generally 194 appear in sKeyPkgAttrs. The second category includes attributes that 195 apply to a particular key, and these attributes will generally appear 196 in sKeyAttrs. The third category includes attributes that apply to a 197 key policy. Of the attributes defined, only the Key Identifier 198 (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be 199 included. All other attributes are OPTIONAL. 201 Like PSKC, the Symmetric Key Content Type supports extensibility. 202 Primarily this is accomplished through the definition and inclusion 203 of new attributes, but in some instances where the attribute contains 204 more than one type the ASN.1 "..." extensibility mechanism is 205 employed. 207 A straightforward approach to conversion from XML types to ASN.1 is 208 employed. The type converts to UTF8String; the XML 209 type converts to GeneralizedTime; and the XML integer 210 types convert to INTEGER or BinaryTime [RFC4049]. 212 3.1. PSKC Key Package Attributes 214 PSKC key package attributes apply to an entire key package. These 215 attributes can be categorized by two different attribute collections: 216 device information and cryptographic module attributes. All of these 217 key package attributes are OPTIONAL. 219 3.1.1. Device Information Attributes 221 Device Information attributes when taken together MUST uniquely 222 identify a device to which the Symmetric Key Package is provisioned. 224 3.1.1.1. Manufacturer 226 The Manufacturer attribute indicates the manufacturer of the device. 227 Values for Manufacturer MUST be taken from either [OATHMAN] prefixes 228 (i.e., the left column) or from IANA Private Enterprise Number 229 Registry [IANAPENREG], using the Organisation value. When the value 230 is taken from [OATHMAN] "oath." MUST be prepended to the value (e.g., 231 "oath."). When the value is taken from 232 [IANAPENREG] "iana." MUST be prepended to the value (e.g., 233 "iana."). The attribute 234 definition is as follows: 236 at-pskc-manufacturer ATTRIBUTE ::= { 237 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 239 id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } 241 3.1.1.2. Serial Number 243 The Serial Number attribute indicates the serial number of the 244 device. The attribute definition is as follows: 246 at-pskc-serialNo ATTRIBUTE ::= { 247 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 249 id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } 251 3.1.1.3. Model 253 The Model attribute indicates the model of the device. The attribute 254 definition is as follows: 256 at-pskc-model ATTRIBUTE ::= { 257 TYPE UTF8String IDENTIFIED BY id-pskc-model } 259 id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } 261 3.1.1.4. Issue Number 263 The Issue Number attribute contains an issue number to distinguish 264 between two devices with the same serial number. The attribute 265 definition is as follows: 267 at-pskc-issueNo ATTRIBUTE ::= { 268 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 270 id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } 272 3.1.1.5. Device Binding 274 The Device Binding attribute provides an opaque identifier that 275 allows keys to be bound to the device or to a class of devices. 277 When loading keys into a device, the attribute's value MUST be 278 checked against information provided to the user via out-of-band 279 mechanisms. The implementation then ensures that the correct device 280 or class of device is being used with respect to the provisioned key. 282 at-pskc-deviceBinding ATTRIBUTE ::= { 283 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 285 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } 287 3.1.1.6. Device Start Date 289 When included in sKeyPkgAttrs, the Device Start Date attribute 290 indicates the start date for a device. The date MUST be represented 291 in a form that matches the dateTime production from [XMLSCHEMA]. The 292 date MUST be expressed in canonical form with no time zone component. 293 Implementations SHOULD NOT rely on time resolution finer than 294 milliseconds and MUST NOT generate time instants that specify leap 295 seconds. Keys that are on the device SHOULD only be used when the 296 current date is on or after the device start date. The attribute 297 definition is as follows: 299 at-pskc-deviceStartDate ATTRIBUTE ::= { 300 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 302 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 304 Note that usage enforcement of the keys with respect to the dates MAY 305 only happen on the validation server as some devices such as smart 306 cards do not have an internal clock. Systems thus SHOULD NOT rely 307 upon the device to enforce key usage date restrictions. 309 3.1.1.7. Device Expiry Date 311 When included in sKeyPkgAttrs, the Device Expiry Date attribute 312 indicates the expiry date for a device. The date MUST be represented 313 in a form that matches the dateTime production from [XMLSCHEMA]. The 314 date MUST be expressed in canonical form with no time zone component. 315 Implementations SHOULD NOT rely on time resolution finer than 316 milliseconds and MUST NOT generate time instants that specify leap 317 seconds. Keys that are on the device SHOULD only be used when the 318 current date is before the device expiry date. The attribute 319 definition is as follows: 321 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 322 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 324 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 326 Note that usage enforcement of the keys with respect to the dates MAY 327 only happen on the validation server as some devices such as smart 328 cards do not have an internal clock. Systems thus SHOULD NOT rely 329 upon the device to enforce key usage date restrictions. 331 3.1.1.8. Device User Id 333 The Device User Id attribute indicates the user with whom the device 334 is associated with using a distinguished name, as defined in 335 [RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute 336 definition is as follows: 338 at-pskc-deviceUserId ATTRIBUTE ::= { 340 TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId } 342 id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 } 344 As specified in [PSKC], there are no semantics associated with this 345 element, i.e., there are no checks enforcing that only a specific 346 user can use this device. As such, this element is for informational 347 purposes only. 349 3.1.2. Cryptographic Module Information Attributes 351 Cryptographic Module attributes uniquely identify a cryptographic 352 module. This is useful when the device contains more than one 353 cryptographic module. At this time only one attribute is defined. 355 3.1.2.1. Cryptographic Module Identifier 357 When included in sKeyPkgAttrs, the Cryptographic Module Identifier 358 attribute uniquely identifies the cryptographic module to which the 359 key is being or was provisioned. The attribute definition is as 360 follows: 362 at-pskc-moduleId ATTRIBUTE ::= { 363 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 365 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 367 3.2. PSKC Key Attributes 369 PSKC key attributes apply to a specific key. As noted earlier, the 370 Key Identifier (Sec 3.2.1) and Algorithm (Sec 3.2.2) key attributes 371 are REQUIRED. All other attributes are OPTIONAL. 373 3.2.1. Key Identifier 375 When included in sKeyAttrs, the Key Identifier attribute identifies 376 the key in the context of key provisioning exchanges between two 377 parties. This means that if PSKC is used in multiple interactions 378 between a sending and receiving party, using different containers 379 referencing the same keys, the KeyId MUST use the same KeyId values 380 (e.g. after initial provisioning, if a system wants to update key 381 meta data values in the other system the KeyId value of the key where 382 the meta data is to be updates MUST be the same as the original KeyId 383 value provisioned). The attribute definition is as follows: 385 at-pskc-keyId ATTRIBUTE ::= { 386 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 388 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 390 3.2.2. Algorithm 392 The Algorithm attribute uniquely identifies the PSKC algorithm 393 profile. [PSKC] defines two algorithm profiles "HOTP" and "PIN". 394 The attribute definition is as follows: 396 at-pskc-algorithm ATTRIBUTE ::= { 397 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 399 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 401 3.2.3. Issuer 403 The Issuer attribute names the entity that issued the key. The 404 attribute definition is as follows: 406 at-pskc-issuer ATTRIBUTE ::= { 407 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 409 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 411 3.2.4. Key Profile Identifier 413 The Key Profile Identifier attribute carries a unique identifier used 414 between the sending and receiving parties to establish a set of key 415 attribute values that are not transmitted within the container but 416 agreed between the two parties out of band. This attribute will then 417 represent the unique reference to a set of key attribute values. 419 at-pskc-keyProfileId ATTRIBUTE ::= { 420 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 422 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 424 3.2.5. Key Reference Identifier 426 The Key Reference attribute refers to an external key to be used with 427 a key derivation scheme and no specific key value (secret) is 428 transported but only the reference to the external master key is used 429 (e.g., the PKCS#11 key label). 431 at-pskc-keyReference ATTRIBUTE ::= { 432 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 434 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 436 3.2.6. Friendly Name 438 The Friendly Name attribute contains a human readable name for the 439 secret key. The attribute definition is as follows: 441 at-pskc-friendlyName ATTRIBUTE ::= { 442 TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName } 444 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 446 The Friendly Name attribute has the following syntax: 448 FriendlyName ::= SEQUENCE { 449 friendlyName UTF8String, 450 friendlyNameLangTag UTF8String OPTIONAL } 452 The text is encoded in UTF-8 [RFC3629], which accommodates most of 453 the world's writing systems. The friendlyNameLangTag field 454 identifies the language used to express the friendlyName. When 455 friendlyNameLangTag is absent, English, whose associated language tag 456 is "en", is used. The value of the friendlyNameLangTag MUST be a 457 language tag as described in [RFC5646]. 459 3.2.7. Algorithm Parameters 461 The Algorithm Parameters attribute contains parameters that influence 462 the result of the algorithmic computation, for example response 463 truncation and format in One-Time Password (OTP) and Challenge- 464 Response (CR) algorithms. 466 at-pskc-algorithmParameters ATTRIBUTE ::= { 467 TYPE PSKCAlgorithmParameters 468 IDENTIFIED BY id-pskc-algorithmParams } 470 id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 } 472 The Algorithm Parameters attribute has the following syntax: 474 PSKCAlgorithmParameters ::= CHOICE { 475 suite UTF8String OPTIONAL, 476 challengeFormat [0] ChallengeFormat, 477 responseFormat [1] ResponseFormat, 478 ... } 480 ChallengeFormat ::= SEQUENCE { 481 encoding Encoding, 482 checkDigit BOOLEAN DEFAULT FALSE, 483 min INTEGER (0..MAX), 484 max INTEGER (0..MAX), 485 ... } 487 Encoding ::= UTF8STRING ("DECIMAL" | "HEXADECIMAL" | 488 "ALPHANUMERIC" |"BASE64" |"BINARY") 490 ResponseFormat ::= SEQUENCE { 491 encoding Encoding, 492 length INTEGER (0..MAX), 493 checkDigit BOOLEAN DEFAULT FALSE, 494 ... } 496 The fields in PSKCAlgorithmParameters have the following meanings: 498 o Suite defines additional characteristics of the algorithm used, 499 which are algorithm specific. For example in HMAC based OTP 500 algorithm it could designate the strength of the hash algorithm 501 used (SHA1, SHA256, etc). Please refer to algorithm profile 502 specification [PSKC] for the exact semantic of the value for each 503 algorithm profile. 505 o ChallengeFormat defines the characteristics of the challenge in a 506 CR usage scenario whereby the following fields are defined: 508 o encoding specifies the encoding of the challenge accepted by 509 the device and MUST be one of the following values: DECIMAL, 510 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64 511 encoding is done as in Section 4 of [RFC4648]. 513 o checkDigit indicates whether a device needs to check the 514 appended Luhn check digit, as defined in [LUHN], contained in a 515 challenge. The checkDigit MUST NOT be present if the encoding 516 value is anything other than 'DECIMAL'. A value of TRUE 517 indicates that the device will check the appended Luhn check 518 digit in a provided challenge. A value of FALSE indicates that 519 the device will not check the appended Luhn check digit in the 520 challenge. 522 o min defines the minimum size of the challenge accepted by the 523 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 524 'ALPHANUMERIC' this value indicates the minimum number of 525 digits/characters. If encoding is 'BASE64' or 'BINARY', this 526 value indicates the minimum number of bytes of the unencoded 527 value. 529 o max defines the maximum size of the challenge accepted by the 530 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 531 'ALPHANUMERIC' this value indicates the maximum number of 532 digits/characters. If the encoding is 'BASE64' or 'BINARY', 533 this value indicates the maximum number of bytes of the 534 unencoded value. 536 o ResponseFormat defines the characteristics of the result of a 537 computation and defines the format of the OTP or the response to 538 a challenge. For cases where the key is a personal 539 identification number (PIN) value, this element contains the 540 format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit 541 PIN). The following fields are defined: 543 o encoding specifies the encoding of the response generated by 544 the device and MUST be one of the following values: DECIMAL, 545 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is 546 defined as in Section 4 of [RFC4648]. 548 o length defines the length of the response generated by the 549 device. If encoding is 'DECIMAL', 'HEXADECIMAL' or 550 'ALPHANUMERIC' this value indicates the number of 551 digits/characters. If encoding is 'BASE64' or 'BINARY', this 552 value indicates the number of bytes of the unencoded value. 554 o checkDigit indicates whether the device needs to append a Luhn 555 check digit, as defined in [LUHN], to the response. This is 556 only valid if encoding attribute is 'DECIMAL'. If the value is 557 TRUE then the device will append a Luhn check digit to the 558 response. If the value is FALSE, then the device will not 559 append a Luhn check digit to the response. 561 3.2.8. Counter 563 The Counter attribute contains the event counter for event-based OTP 564 algorithms. The attribute definition is as follows: 566 at-pskc-counter ATTRIBUTE ::= { 567 TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter } 569 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 571 3.2.9. Time 573 The Time attribute conveys the time for time-based OTP algorithms. 574 If the Time Interval attribute is included, then this element carries 575 the number of time intervals passed for a specific start point. If 576 time interval is used, then this element carries the number of time 577 intervals passed from a specific start point, normally algorithm 578 dependent. It uses the BinaryTime syntax from [RFC4049]. The 579 attribute definition is as follows: 581 at-pskc-time ATTRIBUTE ::= { 582 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 584 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 586 3.2.10. Time Interval 588 The Time Interval attribute conveys the time interval value for time- 589 based OTP algorithms in seconds (e.g., a value of 30 for this would 590 indicate a time interval of 30 seconds). It is an integer. The 591 attribute definition is as follows: 593 at-pskc-timeInterval ATTRIBUTE ::= { 594 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 596 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 598 3.2.11. Time Drift 600 The Time Drift attribute contains the device clock drift value for 601 time-based OTP algorithms. It is an integer either positive or 602 negative that indicates the number of time intervals that a 603 validation server has established the device clock drifted after the 604 last successful authentication. The attribute definition is as 605 follows: 607 at-pskc-timeDrift ATTRIBUTE ::= { 608 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 610 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 612 3.2.12. Value MAC 614 The Value MAC attribute is a Message Authentication Code (MAC) 615 generated from the encrypted value in case the encryption algorithm 616 does not support integrity checks (e.g., AES-CBC does not provide 617 integrity while AES Key Wrap with MLI does). The attribute definition 618 is as follows: 620 at-pskc-valueMAC ATTRIBUTE ::= { 621 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 623 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 625 ValueMac ::= SEQUENCE { 626 macAlgorithm UTF8String, 627 mac UTF8String } 629 The fields in ValueMac have the following meanings: 631 o macAlgorithm identifies the MAC algorithm used to generate the 632 value placed in digest. 634 o mac is the base64 encoded, as specified in Section 4 of [RFC4648], 635 mac value. 637 3.2.13. Key User Id 639 The Key User Id attribute indicates the user with whom the key is 640 associated using a distinguished name, as defined in [RFC4514]. For 641 example: UID=jsmith,DC=example,DC=net. The attribute definition is as 642 follows: 644 at-pskc-keyUserId ATTRIBUTE ::= { 645 TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId } 647 id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 } 649 As specified in [PSKC], there are no semantics associated with this 650 element, i.e., there are no checks enforcing that only a specific 651 user can use this key. As such, this element is for informational 652 purposes only. 654 3.3. Key Policy Attributes 656 Key policy attributes indicate a policy that can be attached to a 657 key. These attributes are defined in the subsections that follow. 659 3.3.1. Key Start Date 661 When included in sKeyAttrs, the Key Start Date attribute indicates 662 the start of the key's validity period. The date MUST be represented 663 in a form that matches the dateTime production from [XMLSCHEMA]. The 664 date MUST be expressed in canonical form with no time zone component. 665 Implementations SHOULD NOT rely on time resolution finer than 666 milliseconds and MUST NOT generate time instants that specify leap 667 seconds. The attribute definition is as follows: 669 at-pskc-keyStartDate ATTRIBUTE ::= { 671 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 673 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 675 3.3.2. Key Expiry Date 677 When included in sKeyAttrs, the Key Expiry Date attribute indicates 678 the end of the key's validity period. The date MUST be represented 679 in a form that matches the dateTime production from [XMLSCHEMA]. The 680 date MUST be expressed in canonical form with no time zone component. 681 Implementations SHOULD NOT rely on time resolution finer than 682 milliseconds and MUST NOT generate time instants that specify leap 683 seconds. The attribute definition is as follows: 685 at-pskc-keyExpiryDate ATTRIBUTE ::= { 686 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 688 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 690 3.3.3. Number of Transactions 692 The Number of Transactions attribute indicates the maximum number of 693 times a key carried within the package can be used. When this 694 element is omitted there is no restriction regarding the number of 695 times a key can be used. The attribute definition is as follows: 697 at-pskc-noOfTransactions ATTRIBUTE ::= { 698 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions } 700 id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 702 3.3.4. Key Usage 704 The Key Usage attribute constrains the intended usage of the key. 705 The recipient MUST enforce the key usage. The attribute definition 706 is as follows: 708 at-pskc-keyUsage ATTRIBUTE ::= { 709 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 711 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 713 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 715 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 716 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 717 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 719 The fields in PSKCKeyUsage have the following meanings: 721 o OTP: The key MUST only be used for OTP generation. 723 o CR: The key MUST only be used for Challenge/Response purposes. 725 o Encrypt: The key MUST only be used for data encryption purposes. 727 o Integrity: The key MUST only be used to generate a keyed message 728 digest for data integrity or authentication purposes. 730 o Verify: The key MUST only be used to verify a keyed message 731 digest for data integrity or authentication purposes (is converse 732 of Integrity). 734 o Unlock: The key MUST only be used for an inverse challenge 735 response in the case where a user has locked the device by 736 entering a wrong PIN too many times (for devices with PIN-input 737 capability). 739 o Decrypt: The key MUST only be used for data decryption purposes. 741 o KeyWrap: The key MUST only be used for key wrap purposes. 743 o Unwrap: The key MUST only be used for key unwrap purposes. 745 o Derive: The key MUST only be used with a key derivation function 746 to derive a new key (see also Section 8.2.4 of [NIST800-57]). 748 o Generate: The key MUST only be used to generate a new key based 749 on a random number and the previous value of the key (see also 750 Section 8.1.5.2.1 of [NIST800-57]). 752 3.3.5. PIN Policy 754 The PIN Policy attribute allows policy about the PIN usage to be 755 associated with the key. The attribute definition is as follows: 757 at-pskc-pinPolicy ATTRIBUTE ::= { 758 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 760 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 762 PINPolicy ::= SEQUENCE { 763 pinKeyId [0] UTF8String OPTIONAL, 764 pinUsageMode [1] PINUsageMode, 765 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 766 minLength [3] INTEGER (0..MAX) OPTIONAL, 767 maxLength [4] INTEGER (0..MAX) OPTIONAL, 768 pinEncoding [5] Encoding OPTIONAL } 770 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" | 771 "Algorithmic") 773 The fields in PIN Policy have the following meanings: 775 o pinKeyId uniquely identifies the key held within this container 776 that contains the value of the PIN that protects the key. 778 o pinUsageMode indicates the way the PIN is used during the 779 usage of the key. The following values are defined in [PSKC]: 780 Local, Prepend, Append, Algorithmic. 782 o maxFailedAttempts indicates the maximum number of times the PIN 783 may be entered wrongly before it MUST NOT be possible to use the 784 key anymore (reasonable values are in the positive integer range 785 of at least 2 and no more than 10). 787 o minLength indicates the minimum length of a PIN that can be set to 788 protect the associated key. It MUST NOT be possible to set a PIN 789 shorter than this value. If pinEncoding is 'DECIMAL', 790 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 791 digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this 792 value indicates the number of bytes of the unencoded value. 794 o maxLength indicates the maximum length of a PIN that can be set to 795 protect this key. It MUST NOT be possible to set a PIN longer 796 than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL' or 797 'ALPHANUMERIC' this value indicates the number of 798 digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', 799 this value indicates the number of bytes of the unencoded value. 801 o pinEncoding is based on Encoding, which is defined in Section 802 3.2.6, and specifies encoding of the PIN and MUST be one of the 803 following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or 804 BINARY. 806 If pinUsageMode is set to "Local" then the device MUST enforce the 807 restriction indicated in maxFailedAttempts, minLength, maxLength and 808 pinEncoding, otherwise it MUST be enforced on the server side. 810 4. Key Encoding 812 Two parties receiving the same key as an sKey OCTET STRING must make 813 use of the key in exactly the same way in order to interoperate. To 814 ensure that, it is necessary to define a correspondence between the 815 abstract syntax of sKey and the notation in the standard algorithm 816 description that defines how the key is used. The next sections 817 establish that correspondence for the algorithms AES [FIPS197] and 818 TDEA [SP800-67]. 820 4.1. AES Key Encoding 822 [FIPS197] section 5.2, titled Key Expansion, uses the input key as an 823 array of bytes indexed starting at 0. The first octet of sKey SHALL 824 become the key byte in AES labeled index 0 in [FIPS197]; the 825 succeeding octets of sKey SHALL become key bytes in AES in increasing 826 index order. 828 Proper parsing and key load of the contents of sKey for AES SHALL be 829 determined by using the following sKey octet string to generate and 830 match the key expansion test vectors in [FIPS197] Appendix A for AES 831 Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 833 Tag Length Value 834 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 836 4.2. Triple DES Key Encoding 838 A Triple-DES key consists of three keys for the cryptographic engine 839 (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 840 parity bits); the three keys are also collectively referred to as a 841 key bundle [SP800-67]. A key bundle may employ either two or three 842 independent keys. When only two independent keys are employed 843 (called two-key Triple DES), then the same value is used for Key1 and 844 Key3. 846 Each key in a Triple-DES key bundle is expanded into a key schedule 847 according to a procedure defined in [SP800-67] Appendix A. That 848 procedure numbers the bits in the key from 1 to 64, with number 1 849 being the left-most, or most significant bit (MSB). The first octet 850 of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. 851 The second octet of sKey SHALL be bits 9 through 16 of Key1, and so 852 forth, so that the trailing octet of sKEY SHALL be bits 57 through 64 853 of Key3 (or Key2 for two-key Triple DES). 855 Proper parsing and key load of the contents of sKey for Triple-DES 856 SHALL be determined by using the following sKey octet string to 857 generate and match the key expansion test vectors in [SP800-67] 858 appendix B for the key bundle: 860 Key1 = 0123456789ABCDEF 862 Key2 = 23456789ABCDEF01 864 Key3 = 456789ABCDEF0123 866 Tag Length Value 867 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123 869 5. Security Considerations 871 Implementers of this protocol are strongly encouraged to consider 872 generally accepted principles of secure key management when 873 integrating this capability within an overall security architecture. 875 The symmetric key package contents are not protected. This content 876 type can be combined with a security protocol to protect the contents 877 of the package. One possibility is to include this content type in 878 place of a PSKC package in [DSKPP] exchanges. In this case, the 879 algorithm requirements are found in those documents. Another 880 possibility is to encapsulate this content type in a CMS [RFC5652] 881 protecting content type. 883 6. IANA Considerations 885 This document makes use of object identifiers to identify a CMS 886 content type (Appendix A.1), the ASN.1 version of the PSKC attributes 887 (Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2. 888 All OIDs are registered in an arc delegated by RSADSI to the SMIME 889 Working Group. The current contents of the arc are located here: 891 http://www.imc.org/ietf-smime/sm-oid.asn 893 They were obtained by sending a request to 894 ietf-smime-oid-reg@imc.org. When the SMIME WG closes, this arc and 895 registration procedures will be transferred to IANA. No further 896 action by IANA is necessary for this document or any anticipated 897 updates. 899 7. References 901 7.1. Normative References 903 [FIPS197] National Institute of Standards. "FIPS Pub 197: 904 Advanced Encryption Standard (AES)", 26 November 2001. 906 [IANAPENREG] IANA, "IANA Private Enterprise Number Registry", 907 . 909 [LUHN] ISO/IEC 7812-1:2006 Identification cards - 910 Identification of issuers - Part 1: Numbering system. 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, March 1997. 915 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 916 10646", STD 63, RFC 3629, November 2003. 918 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 919 Representing Date and Time in ASN.1", RFC 4049, April 920 2005. 922 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 923 (LDAP): String Representation of Distinguished Names", 924 RFC 4514, June 2006. 926 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 927 Encodings", RFC 4648, October 2006. 929 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 930 Languages", BCP 47, RFC 5646, September 2009. 932 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 933 Cryptographic Message Syntax (CMS) and S/MIME", RFC 934 5911, June 2010. 936 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 937 Public Key Infrastructure Using X.509 (PKIX)", RFC 938 5912, June 2010. 940 [OATHMAN] OATH Manufacturer prefixes: 941 http://www.openauthentication.org/oath-id/prefixes/ 943 [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 944 Key Container (PSKC), draft-ietf-keyprov-pskc-07.txt, 945 work-in-progress. 947 //** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is 948 the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and 949 elsewhere in the document. **// 951 [SP800-67] National Institute of Standards and Technology, "NIST 952 Special Publication 800-67 Version 1.1: Recommendation 953 for the Triple Data Encryption Algorithm (TDEA) Block 954 Cipher", NIST Special Publication 800-67, May 2008. 956 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 957 1:2002. Information Technology - Abstract Syntax 958 Notation One. 960 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- 961 2:2002. Information Technology - Abstract Syntax 962 Notation One: Information Object Specification. 964 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 965 3:2002. Information Technology - Abstract Syntax 966 Notation One: Constraint Specification. 968 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 969 4:2002. Information Technology - Abstract Syntax 970 Notation One: Parameterization of ASN.1 Specifications. 972 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 973 1:2002. Information Technology - ASN.1 encoding rules: 974 Specification of Basic Encoding Rules (BER), Canonical 975 Encoding Rules (CER) and Distinguished Encoding Rules 976 (DER). 978 [XMLSCHEMA] Biron, P., and A. Malhotra, "XML Schema Part 2: 979 Datatypes Second Edition", 980 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, 981 2004. 983 7.2. Informative References 985 [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, 986 "Dynamic Symmetric Key Provisioning Protocol", Internet 987 Draft Informational, URL: http://www.ietf.org/internet- 988 drafts/draft-ietf-keyprov-dskpp-10.txt, work in 989 progress. 991 //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 992 the draft-ietf-keyprov-dskpp's RFC #. Make the replacements here and 993 elsewhere in the document. **// 995 [NIST800-57] National Institute of Standards and Technology, "NIST 996 Special Publication 800-57, Recommendation for Key 997 Management - Part 1: General (Revised)", NIST Special 998 Publication 800-57, March 2007. 1000 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 1001 5652, September 2009. 1003 APPENDIX A: ASN.1 Module 1005 This appendix provides the normative ASN.1 definitions for the 1006 structures described in this specification using ASN.1 as defined in 1007 [X.680], [X.681], [X.682], and [X.683]. 1009 A.1. Symmetric Key Package ASN.1 Module 1011 SymmetricKeyPackageModulev1 1012 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1013 smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) } 1015 DEFINITIONS IMPLICIT TAGS ::= 1017 BEGIN 1019 -- EXPORTS ALL 1021 IMPORTS 1023 -- From New PKIX ASN.1 [RFC5912] 1025 ATTRIBUTE 1026 FROM PKIX-CommonTypes-2009 1027 { iso(1) identified-organization(3) dod(6) internet(1) 1028 security(5) mechanisms(5) pkix(7) id-mod(0) 1029 id-mod-pkixCommon-02(57) } 1031 -- From New SMIME ASN.1 [RFC5911] 1033 CONTENT-TYPE, Attribute{} 1034 FROM CryptographicMessageSyntax-2009 1035 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1036 smime(16) modules(0) id-mod-cms-2004-02(41) } 1038 ; 1040 ContentSet CONTENT-TYPE ::= { 1041 ct-symmetric-key-package, 1042 ... -- Expect additional content types -- 1043 } 1045 ct-symmetric-key-package CONTENT-TYPE ::= 1046 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 1048 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 1049 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1050 smime(16) ct(1) 25 } 1052 SymmetricKeyPackage ::= SEQUENCE { 1053 version KeyPkgVersion DEFAULT v1, 1054 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 1055 {{ SKeyPkgAttributes }} OPTIONAL, 1056 sKeys SymmetricKeys, 1057 ... } 1059 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 1060 OneSymmetricKey ::= SEQUENCE { 1061 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 1062 {{ SKeyAttributes }} OPTIONAL, 1063 sKey OCTET STRING OPTIONAL } 1064 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 1065 WITH COMPONENTS { ..., sKey PRESENT } ) 1067 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 1069 SKeyPkgAttributes ATTRIBUTE ::= { ... } 1071 SKeyAttributes ATTRIBUTE ::= { ... } 1073 END 1075 A.2. PSKC ASN.1 Module 1077 PSKCAttributesModule 1078 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1079 smime(16) modules(0) id-mod-pskcAttributesModule(53) } 1081 DEFINITIONS IMPLICIT TAGS ::= 1083 BEGIN 1085 -- EXPORTS ALL 1087 IMPORTS 1089 -- From New PKIX ASN.1 [RFC5912] 1091 ATTRIBUTE 1092 FROM PKIX-CommonTypes-2009 1093 { iso(1) identified-organization(3) dod(6) internet(1) 1094 security(5) mechanisms(5) pkix(7) id-mod(0) 1095 id-mod-pkixCommon-02(57) } 1097 -- From BinaryTime [RFC4049] 1099 BinaryTime 1100 FROM BinarySigningTimeModule 1101 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1102 smime(16) modules(0) id-mod-binarySigningTime(27) } 1104 -- From New SMIME ASN.1 [RFC5911] 1106 id-smime 1107 FROM SecureMimeMessageV3dot1-2009 1108 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1109 smime(16) modules(0) id-mod-msg-v3dot1-02(39) } 1111 ; 1113 -- 1114 -- PSKC Attributes OIDs are taken from the SMIME Arc. 1115 -- 1117 id-pskc OBJECT IDENTIFIER ::= { id-smime 12 } 1119 -- 1120 -- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs 1121 -- 1123 SKeyPkgAttributes ATTRIBUTE ::= { 1124 at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model | 1125 at-pskc-issueNo | at-pskc-deviceBinding | 1126 at-pskc-deviceStartDate | at-pskc-deviceExpiryDate | 1127 at-pskc-moduleId | at-deviceUserId, ... } 1129 -- 1130 -- Merge SKeyAttributes to the set of attributes for sKeyAttrs 1131 -- 1133 SKeyAttributes ATTRIBUTE ::= { 1134 at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer | 1135 at-pskc-keyProfileId | at-pskc-keyReference | 1136 at-pskc-friendlyName | at-pskc-algorithmParameters | 1137 at-pskc-counter | at-pskc-time | at-pskc-timeInterval | 1138 at-pskc-timeDrift | at-pskc-valueMAC | at-keyUserId | 1139 at-pskc-keyStartDate | at-pskc-keyExpiryDate | 1140 at-pskc-numberOfTransactions | at-pskc-keyUsage | 1141 at-pskc-pinPolicy,... } 1143 at-pskc-manufacturer ATTRIBUTE ::= { 1144 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 1146 id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } 1148 at-pskc-serialNo ATTRIBUTE ::= { 1149 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 1151 id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } 1153 at-pskc-model ATTRIBUTE ::= { 1154 TYPE UTF8String IDENTIFIED BY id-pskc-model } 1156 id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } 1158 at-pskc-issueNo ATTRIBUTE ::= { 1159 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 1161 id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } 1163 at-pskc-deviceBinding ATTRIBUTE ::= { 1164 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 1166 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } 1168 at-pskc-deviceStartDate ATTRIBUTE ::= { 1169 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 1171 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 1173 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 1174 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 1176 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 1178 at-pskc-moduleId ATTRIBUTE ::= { 1179 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 1181 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 1183 at-pskc-deviceUserId ATTRIBUTE ::= { 1184 TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId } 1186 id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 } 1188 at-pskc-keyId ATTRIBUTE ::= { 1189 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 1191 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 1193 at-pskc-algorithm ATTRIBUTE ::= { 1194 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 1196 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 1197 at-pskc-issuer ATTRIBUTE ::= { 1198 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 1200 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 1202 at-pskc-keyProfileId ATTRIBUTE ::= { 1203 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 1205 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 1207 at-pskc-keyReference ATTRIBUTE ::= { 1208 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 1210 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 1212 at-pskc-friendlyName ATTRIBUTE ::= { 1213 TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName } 1215 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 1217 FriendlyName ::= SEQUENCE { 1218 friendlyName UTF8String, 1219 friendlyNameLangTag UTF8String OPTIONAL } 1221 at-pskc-algorithmParameters ATTRIBUTE ::= { 1222 TYPE PSKCAlgorithmParameters 1223 IDENTIFIED BY id-pskc-algorithmParameters } 1225 id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 } 1227 PSKCAlgorithmParameters ::= CHOICE { 1228 suite UTF8String OPTIONAL, 1229 challengeFormat [0] ChallengeFormat, 1230 responseFormat [1] ResponseFormat, 1231 ... } 1233 ChallengeFormat ::= SEQUENCE { 1234 encoding Encoding, 1235 checkDigit BOOLEAN DEFAULT FALSE, 1236 min INTEGER (0..MAX), 1237 max INTEGER (0..MAX), 1238 ... } 1240 Encoding ::= UTF8String ("DECIMAL" | "HEXADECIMAL" | 1241 "ALPHANUMERIC" | "BASE64" | "BINARY" ) 1243 ResponseFormat ::= SEQUENCE { 1244 encoding Encoding, 1245 length INTEGER (0..MAX), 1246 checkDigit BOOLEAN DEFAULT FALSE, 1247 ... } 1249 at-pskc-counter ATTRIBUTE ::= { 1250 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-counter } 1252 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 1254 at-pskc-time ATTRIBUTE ::= { 1255 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1257 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 1259 at-pskc-timeInterval ATTRIBUTE ::= { 1260 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 1262 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 1264 at-pskc-timeDrift ATTRIBUTE ::= { 1265 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 1267 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 1269 at-pskc-valueMAC ATTRIBUTE ::= { 1270 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 1272 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 1274 ValueMac ::= SEQUENCE { 1275 macAlgorithm UTF8String, 1276 mac UTF8String } 1278 at-pskc-keyUserId ATTRIBUTE ::= { 1279 TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId } 1281 id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 } 1283 at-pskc-keyStartDate ATTRIBUTE ::= { 1284 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 1286 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 1288 at-pskc-keyExpiryDate ATTRIBUTE ::= { 1289 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 1291 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 1293 at-pskc-numberOfTransactions ATTRIBUTE ::= { 1294 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-numberOfTransactions } 1296 id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 1298 at-pskc-keyUsage ATTRIBUTE ::= { 1299 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 1301 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 1303 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 1305 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 1306 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 1307 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 1309 at-pskc-pinPolicy ATTRIBUTE ::= { 1310 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 1312 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 1314 PINPolicy ::= SEQUENCE { 1315 pinKeyId [0] UTF8String OPTIONAL, 1316 pinUsageMode [1] PINUsageMode, 1317 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 1318 minLength [3] INTEGER (0..MAX) OPTIONAL, 1319 maxLength [4] INTEGER (0..MAX) OPTIONAL, 1320 pinEncoding [5] Encoding OPTIONAL } 1322 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append"| 1323 "Algorithmic") 1325 END 1327 Authors' Addresses 1329 Sean Turner 1330 IECA, Inc. 1331 3057 Nutley Street, Suite 106 1332 Fairfax, VA 22031 1333 USA 1335 EMail: turners@ieca.com 1337 Russ Housley 1338 Vigil Security, LLC 1339 918 Spring Knoll Drive 1340 Herndon, VA 20170 1341 USA 1343 EMail: housley@vigilsec.com