idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-11.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 9, 2010) is 5001 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 1311 -- Looks like a reference, but probably isn't: '1' on line 1312 -- Looks like a reference, but probably isn't: '2' on line 1313 -- Looks like a reference, but probably isn't: '3' on line 1314 -- Looks like a reference, but probably isn't: '4' on line 1315 -- Looks like a reference, but probably isn't: '5' on line 1316 == Missing Reference: 'RFCXXXX' is mentioned on line 989, 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 9, 2010 Vigil Security 5 August 9, 2010 7 Symmetric Key Package Content Type 8 draft-ietf-keyprov-symmetrickeyformat-11.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 9, 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.......................................8 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...............................9 70 3.2.5. Key Reference Identifier............................10 71 3.2.6. Friendly Name.......................................10 72 3.2.7. Algorithm Parameters................................10 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.........................................13 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..............................15 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..................................18 89 5. Security Considerations.......................................19 90 6. IANA Considerations...........................................19 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 in "canonical 292 representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time 293 resolution finer than milliseconds and MUST NOT generate time 294 instants that specify leap seconds. Keys that are on the device 295 SHOULD only be used when the current date is on or after the device 296 start date. The attribute definition is as follows: 298 at-pskc-deviceStartDate ATTRIBUTE ::= { 299 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 301 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 303 Note that usage enforcement of the keys with respect to the dates MAY 304 only happen on the validation server as some devices such as smart 305 cards do not have an internal clock. Systems thus SHOULD NOT rely 306 upon the device to enforce key usage date restrictions. 308 3.1.1.7. Device Expiry Date 310 When included in sKeyPkgAttrs, the Device Expiry Date attribute 311 indicates the expiry date for a device. The date MUST be represented 312 in a form that matches the dateTime production in "canonical 313 representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time 314 resolution finer than milliseconds and MUST NOT generate time 315 instants that specify leap seconds. Keys that are on the device 316 SHOULD only be used when the current date is before the device expiry 317 date. The attribute definition is as follows: 319 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 320 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 322 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 323 Note that usage enforcement of the keys with respect to the dates MAY 324 only happen on the validation server as some devices such as smart 325 cards do not have an internal clock. Systems thus SHOULD NOT rely 326 upon the device to enforce key usage date restrictions. 328 3.1.1.8. Device User Id 330 The Device User Id attribute indicates the user with whom the device 331 is associated with using a distinguished name, as defined in 332 [RFC4514]. For example: UID=jsmith,DC=example,DC=net. The attribute 333 definition is as follows: 335 at-pskc-deviceUserId ATTRIBUTE ::= { 337 TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId } 339 id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 } 341 As specified in [PSKC], there are no semantics associated with this 342 element, i.e., there are no checks enforcing that only a specific 343 user can use this device. As such, this element is for informational 344 purposes only. 346 3.1.2. Cryptographic Module Information Attributes 348 Cryptographic Module attributes uniquely identify a cryptographic 349 module. This is useful when the device contains more than one 350 cryptographic module. At this time only one attribute is defined. 352 3.1.2.1. Cryptographic Module Identifier 354 When included in sKeyPkgAttrs, the Cryptographic Module Identifier 355 attribute uniquely identifies the cryptographic module to which the 356 key is being or was provisioned. The attribute definition is as 357 follows: 359 at-pskc-moduleId ATTRIBUTE ::= { 360 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 362 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 364 3.2. PSKC Key Attributes 366 PSKC key attributes apply to a specific key. As noted earlier, the 367 Key Identifier (Sec 3.2.1) and Algorithm (Sec 3.2.2) key attributes 368 are REQUIRED. All other attributes are OPTIONAL. 370 3.2.1. Key Identifier 372 When included in sKeyAttrs, the Key Identifier attribute identifies 373 the key in the context of key provisioning exchanges between two 374 parties. This means that if PSKC is used in multiple interactions 375 between a sending and receiving party, using different containers 376 referencing the same keys, the KeyId MUST use the same KeyId values 377 (e.g. after initial provisioning, if a system wants to update key 378 meta data values in the other system the KeyId value of the key where 379 the meta data is to be updates MUST be the same as the original KeyId 380 value provisioned). The attribute definition is as follows: 382 at-pskc-keyId ATTRIBUTE ::= { 383 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 385 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 387 3.2.2. Algorithm 389 The Algorithm attribute uniquely identifies the PSKC algorithm 390 profile. [PSKC] defines two algorithm profiles "HOTP" and "PIN". 391 The attribute definition is as follows: 393 at-pskc-algorithm ATTRIBUTE ::= { 394 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 396 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 398 3.2.3. Issuer 400 The Issuer attribute names the entity that issued the key. The 401 attribute definition is as follows: 403 at-pskc-issuer ATTRIBUTE ::= { 404 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 406 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 408 3.2.4. Key Profile Identifier 410 The Key Profile Identifier attribute carries a unique identifier used 411 between the sending and receiving parties to establish a set of key 412 attribute values that are not transmitted within the container but 413 agreed between the two parties out of band. This attribute will then 414 represent the unique reference to a set of key attribute values. 416 at-pskc-keyProfileId ATTRIBUTE ::= { 417 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 419 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 421 3.2.5. Key Reference Identifier 423 The Key Reference attribute refers to an external key to be used with 424 a key derivation scheme and no specific key value (secret) is 425 transported but only the reference to the external master key is used 426 (e.g., the PKCS#11 key label). 428 at-pskc-keyReference ATTRIBUTE ::= { 429 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 431 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 433 3.2.6. Friendly Name 435 The Friendly Name attribute contains a human readable name for the 436 secret key. The attribute definition is as follows: 438 at-pskc-friendlyName ATTRIBUTE ::= { 439 TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName } 441 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 443 The Friendly Name attribute has the following syntax: 445 FriendlyName ::= SEQUENCE { 446 friendlyName UTF8String, 447 friendlyNameLangTag UTF8String OPTIONAL } 449 The text is encoded in UTF-8 [RFC3629], which accommodates most of 450 the world's writing systems. The friendlyNameLangTag field 451 identifies the language used to express the friendlyName. When 452 friendlyNameLangTag is absent, English, whose associated language tag 453 is "en", is used. The value of the friendlyNameLangTag MUST be a 454 language tag as described in [RFC5646]. 456 3.2.7. Algorithm Parameters 458 The Algorithm Parameters attribute contains parameters that influence 459 the result of the algorithmic computation, for example response 460 truncation and format in One-Time Password (OTP) and Challenge- 461 Response (CR) algorithms. 463 at-pskc-algorithmParameters ATTRIBUTE ::= { 464 TYPE PSKCAlgorithmParameters 465 IDENTIFIED BY id-pskc-algorithmParams } 467 id-pskc-algorithmParams OBJECT IDENTIFIER ::= { id-pskc 15 } 469 The Algorithm Parameters attribute has the following syntax: 471 PSKCAlgorithmParameters ::= CHOICE { 472 suite UTF8String OPTIONAL, 473 challengeFormat [0] ChallengeFormat, 474 responseFormat [1] ResponseFormat, 475 ... } 477 ChallengeFormat ::= SEQUENCE { 478 encoding Encoding, 479 checkDigit BOOLEAN DEFAULT FALSE, 480 min INTEGER (0..MAX), 481 max INTEGER (0..MAX), 482 ... } 484 Encoding ::= UTF8STRING ("DECIMAL" | "HEXADECIMAL" | 485 "ALPHANUMERIC" |"BASE64" |"BINARY") 487 ResponseFormat ::= SEQUENCE { 488 encoding Encoding, 489 length INTEGER (0..MAX), 490 checkDigit BOOLEAN DEFAULT FALSE, 491 ... } 493 The fields in PSKCAlgorithmParameters have the following meanings: 495 o Suite defines additional characteristics of the algorithm used, 496 which are algorithm specific. For example in HMAC based OTP 497 algorithm it could designate the strength of the hash algorithm 498 used (SHA1, SHA256, etc). Please refer to algorithm profile 499 specification [PSKC] for the exact semantic of the value for each 500 algorithm profile. 502 o ChallengeFormat defines the characteristics of the challenge in a 503 CR usage scenario whereby the following fields are defined: 505 o encoding specifies the encoding of the challenge accepted by 506 the device and MUST be one of the following values: DECIMAL, 507 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. The BASE64 508 encoding is done as in Section 4 of [RFC4648]. 510 o checkDigit indicates whether a device needs to check the 511 appended Luhn check digit, as defined in [LUHN], contained in a 512 challenge. The checkDigit MUST NOT be present if the encoding 513 value is anything other than 'DECIMAL'. A value of TRUE 514 indicates that the device will check the appended Luhn check 515 digit in a provided challenge. A value of FALSE indicates that 516 the device will not check the appended Luhn check digit in the 517 challenge. 519 o min defines the minimum size of the challenge accepted by the 520 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 521 'ALPHANUMERIC' this value indicates the minimum number of 522 digits/characters. If encoding is 'BASE64' or 'BINARY', this 523 value indicates the minimum number of bytes of the unencoded 524 value. 526 o max defines the maximum size of the challenge accepted by the 527 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 528 'ALPHANUMERIC' this value indicates the maximum number of 529 digits/characters. If the encoding is 'BASE64' or 'BINARY', 530 this value indicates the maximum number of bytes of the 531 unencoded value. 533 o ResponseFormat defines the characteristics of the result of a 534 computation and defines the format of the OTP or the response to 535 a challenge. For cases where the key is a personal 536 identification number (PIN) value, this element contains the 537 format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit 538 PIN). The following fields are defined: 540 o encoding specifies the encoding of the response generated by 541 the device and MUST be one of the following values: DECIMAL, 542 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. BASE64 is 543 defined as in Section 4 of [RFC4648]. 545 o length defines the length of the response generated by the 546 device. If encoding is 'DECIMAL', 'HEXADECIMAL' or 547 'ALPHANUMERIC' this value indicates the number of 548 digits/characters. If encoding is 'BASE64' or 'BINARY', this 549 value indicates the number of bytes of the unencoded value. 551 o checkDigit indicates whether the device needs to append a Luhn 552 check digit, as defined in [LUHN], to the response. This is 553 only valid if encoding attribute is 'DECIMAL'. If the value is 554 TRUE then the device will append a Luhn check digit to the 555 response. If the value is FALSE, then the device will not 556 append a Luhn check digit to the response. 558 3.2.8. Counter 560 The Counter attribute contains the event counter for event-based OTP 561 algorithms. The attribute definition is as follows: 563 at-pskc-counter ATTRIBUTE ::= { 564 TYPE INTEGER(0..MAX) IDENTIFIED BY id-pskc-counter } 566 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 568 3.2.9. Time 570 The Time attribute conveys the time for time-based OTP algorithms. 571 If the Time Interval attribute is included, then this element carries 572 the number of time intervals passed for a specific start point. If 573 time interval is used, then this element carries the number of time 574 intervals passed from a specific start point, normally algorithm 575 dependent. It uses the BinaryTime syntax from [RFC4049]. The 576 attribute definition is as follows: 578 at-pskc-time ATTRIBUTE ::= { 579 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 581 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 583 3.2.10. Time Interval 585 The Time Interval attribute conveys the time interval value for time- 586 based OTP algorithms in seconds (e.g., a value of 30 for this would 587 indicate a time interval of 30 seconds). It is an integer. The 588 attribute definition is as follows: 590 at-pskc-timeInterval ATTRIBUTE ::= { 591 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 593 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 595 3.2.11. Time Drift 597 The Time Drift attribute contains the device clock drift value for 598 time-based OTP algorithms. It is an integer either positive or 599 negative that indicates the number of time intervals that a 600 validation server has established the device clock drifted after the 601 last successful authentication. The attribute definition is as 602 follows: 604 at-pskc-timeDrift ATTRIBUTE ::= { 605 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 607 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 609 3.2.12. Value MAC 611 The Value MAC attribute is a Message Authentication Code (MAC) 612 generated from the encrypted value in case the encryption algorithm 613 does not support integrity checks (e.g., AES-CBC does not provide 614 integrity while AES Key Wrap with MLI does). The attribute definition 615 is as follows: 617 at-pskc-valueMAC ATTRIBUTE ::= { 618 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 620 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 622 ValueMac ::= SEQUENCE { 623 macAlgorithm UTF8String, 624 mac UTF8String } 626 The fields in ValueMac have the following meanings: 628 o macAlgorithm identifies the MAC algorithm used to generate the 629 value placed in digest. 631 o mac is the base64 encoded, as specified in Section 4 of [RFC4648], 632 mac value. 634 3.2.13. Key User Id 636 The Key User Id attribute indicates the user with whom the key is 637 associated using a distinguished name, as defined in [RFC4514]. For 638 example: UID=jsmith,DC=example,DC=net. The attribute definition is as 639 follows: 641 at-pskc-keyUserId ATTRIBUTE ::= { 642 TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId } 644 id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 } 646 As specified in [PSKC], there are no semantics associated with this 647 element, i.e., there are no checks enforcing that only a specific 648 user can use this key. As such, this element is for informational 649 purposes only. 651 3.3. Key Policy Attributes 653 Key policy attributes indicate a policy that can be attached to a 654 key. These attributes are defined in the subsections that follow. 656 3.3.1. Key Start Date 658 When included in sKeyAttrs, the Key Start Date attribute indicates 659 the start of the key's validity period. The date MUST be represented 660 in a form that matches the dateTime production in "canonical 661 representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time 662 resolution finer than milliseconds and MUST NOT generate time 663 instants that specify leap seconds. The attribute definition is as 664 follows: 666 at-pskc-keyStartDate ATTRIBUTE ::= { 668 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 670 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 672 3.3.2. Key Expiry Date 674 When included in sKeyAttrs, the Key Expiry Date attribute indicates 675 the end of the key's validity period. The date MUST be represented 676 in a form that matches the dateTime production in "canonical 677 representation" [XMLSCHEMA]. Implementations SHOULD NOT rely on time 678 resolution finer than milliseconds and MUST NOT generate time 679 instants that specify leap seconds. The attribute definition is as 680 follows: 682 at-pskc-keyExpiryDate ATTRIBUTE ::= { 683 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 685 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 687 3.3.3. Number of Transactions 689 The Number of Transactions attribute indicates the maximum number of 690 times a key carried within the package can be used. When this 691 element is omitted there is no restriction regarding the number of 692 times a key can be used. The attribute definition is as follows: 694 at-pskc-noOfTransactions ATTRIBUTE ::= { 695 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-noOfTransactions } 697 id-pskc-noOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 699 3.3.4. Key Usage 701 The Key Usage attribute constrains the intended usage of the key. 702 The recipient MUST enforce the key usage. The attribute definition 703 is as follows: 705 at-pskc-keyUsage ATTRIBUTE ::= { 706 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 708 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 710 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 712 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 713 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 714 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 716 The fields in PSKCKeyUsage have the following meanings: 718 o OTP: The key MUST only be used for OTP generation. 720 o CR: The key MUST only be used for Challenge/Response purposes. 722 o Encrypt: The key MUST only be used for data encryption purposes. 724 o Integrity: The key MUST only be used to generate a keyed message 725 digest for data integrity or authentication purposes. 727 o Verify: The key MUST only be used to verify a keyed message 728 digest for data integrity or authentication purposes (is converse 729 of Integrity). 731 o Unlock: The key MUST only be used for an inverse challenge 732 response in the case where a user has locked the device by 733 entering a wrong PIN too many times (for devices with PIN-input 734 capability). 736 o Decrypt: The key MUST only be used for data decryption purposes. 738 o KeyWrap: The key MUST only be used for key wrap purposes. 740 o Unwrap: The key MUST only be used for key unwrap purposes. 742 o Derive: The key MUST only be used with a key derivation function 743 to derive a new key (see also Section 8.2.4 of [NIST800-57]). 745 o Generate: The key MUST only be used to generate a new key based 746 on a random number and the previous value of the key (see also 747 Section 8.1.5.2.1 of [NIST800-57]). 749 3.3.5. PIN Policy 751 The PIN Policy attribute allows policy about the PIN usage to be 752 associated with the key. The attribute definition is as follows: 754 at-pskc-pinPolicy ATTRIBUTE ::= { 755 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 757 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 759 PINPolicy ::= SEQUENCE { 760 pinKeyId [0] UTF8String OPTIONAL, 761 pinUsageMode [1] PINUsageMode, 762 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 763 minLength [3] INTEGER (0..MAX) OPTIONAL, 764 maxLength [4] INTEGER (0..MAX) OPTIONAL, 765 pinEncoding [5] Encoding OPTIONAL } 767 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append" | 768 "Algorithmic") 770 The fields in PIN Policy have the following meanings: 772 o pinKeyId uniquely identifies the key held within this container 773 that contains the value of the PIN that protects the key. 775 o pinUsageMode indicates the way the PIN is used during the 776 usage of the key. The following values are defined in [PSKC]: 777 Local, Prepend, Append, Algorithmic. 779 o maxFailedAttempts indicates the maximum number of times the PIN 780 may be entered wrongly before it MUST NOT be possible to use the 781 key anymore (reasonable values are in the positive integer range 782 of at least 2 and no more than 10). 784 o minLength indicates the minimum length of a PIN that can be set to 785 protect the associated key. It MUST NOT be possible to set a PIN 786 shorter than this value. If pinEncoding is 'DECIMAL', 787 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 788 digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this 789 value indicates the number of bytes of the unencoded value. 791 o maxLength indicates the maximum length of a PIN that can be set to 792 protect this key. It MUST NOT be possible to set a PIN longer 793 than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL' or 794 'ALPHANUMERIC' this value indicates the number of 795 digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', 796 this value indicates the number of bytes of the unencoded value. 798 o pinEncoding is based on Encoding, which is defined in Section 799 3.2.6, and specifies encoding of the PIN and MUST be one of the 800 following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or 801 BINARY. 803 If pinUsageMode is set to "Local" then the device MUST enforce the 804 restriction indicated in maxFailedAttempts, minLength, maxLength and 805 pinEncoding, otherwise it MUST be enforced on the server side. 807 4. Key Encoding 809 Two parties receiving the same key as an sKey OCTET STRING must make 810 use of the key in exactly the same way in order to interoperate. To 811 ensure that, it is necessary to define a correspondence between the 812 abstract syntax of sKey and the notation in the standard algorithm 813 description that defines how the key is used. The next sections 814 establish that correspondence for the algorithms AES [FIPS197] and 815 TDEA [SP800-67]. 817 4.1. AES Key Encoding 819 [FIPS197] section 5.2, titled Key Expansion, uses the input key as an 820 array of bytes indexed starting at 0. The first octet of sKey SHALL 821 become the key byte in AES labeled index 0 in [FIPS197]; the 822 succeeding octets of sKey SHALL become key bytes in AES in increasing 823 index order. 825 Proper parsing and key load of the contents of sKey for AES SHALL be 826 determined by using the following sKey octet string to generate and 827 match the key expansion test vectors in [FIPS197] Appendix A for AES 828 Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 830 Tag Length Value 831 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 833 4.2. Triple DES Key Encoding 835 A Triple-DES key consists of three keys for the cryptographic engine 836 (Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8 837 parity bits); the three keys are also collectively referred to as a 838 key bundle [SP800-67]. A key bundle may employ either two or three 839 independent keys. When only two independent keys are employed 840 (called two-key Triple DES), then the same value is used for Key1 and 841 Key3. 843 Each key in a Triple-DES key bundle is expanded into a key schedule 844 according to a procedure defined in [SP800-67] Appendix A. That 845 procedure numbers the bits in the key from 1 to 64, with number 1 846 being the left-most, or most significant bit (MSB). The first octet 847 of sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the MSB. 848 The second octet of sKey SHALL be bits 9 through 16 of Key1, and so 849 forth, so that the trailing octet of sKEY SHALL be bits 57 through 64 850 of Key3 (or Key2 for two-key Triple DES). 852 Proper parsing and key load of the contents of sKey for Triple-DES 853 SHALL be determined by using the following sKey octet string to 854 generate and match the key expansion test vectors in [SP800-67] 855 appendix B for the key bundle: 857 Key1 = 0123456789ABCDEF 859 Key2 = 23456789ABCDEF01 861 Key3 = 456789ABCDEF0123 863 Tag Length Value 864 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123 866 5. Security Considerations 868 Implementers of this protocol are strongly encouraged to consider 869 generally accepted principles of secure key management when 870 integrating this capability within an overall security architecture. 872 The symmetric key package contents are not protected. This content 873 type can be combined with a security protocol to protect the contents 874 of the package. One possibility is to include this content type in 875 place of a PSKC package in [DSKPP] exchanges. In this case, the 876 algorithm requirements are found in those documents. Another 877 possibility is to encapsulate this content type in a CMS [RFC5652] 878 protecting content type. 880 6. IANA Considerations 882 This document makes use of object identifiers to identify a CMS 883 content type (Appendix A.1), the ASN.1 version of the PSKC attributes 884 (Appendix A.2), and the ASN.1 modules found in Appendix A.1 and A.2. 886 All OIDs are registered in an arc delegated by RSADSI to the SMIME 887 Working Group. The current contents of the arc are located here: 889 http://www.imc.org/ietf-smime/sm-oid.asn 891 They were obtained by sending a request to 892 ietf-smime-oid-reg@imc.org. When the SMIME WG closes, this arc and 893 registration procedures will be transferred to IANA. No further 894 action by IANA is necessary for this document or any anticipated 895 updates. 897 7. References 899 7.1. Normative References 901 [FIPS197] National Institute of Standards. "FIPS Pub 197: 902 Advanced Encryption Standard (AES)", 26 November 2001. 904 [IANAPENREG] IANA, "IANA Private Enterprise Number Registry", 905 . 907 [LUHN] ISO/IEC 7812-1:2006 Identification cards - 908 Identification of issuers - Part 1: Numbering system. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 914 10646", STD 63, RFC 3629, November 2003. 916 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 917 Representing Date and Time in ASN.1", RFC 4049, April 918 2005. 920 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 921 (LDAP): String Representation of Distinguished Names", 922 RFC 4514, June 2006. 924 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 925 Encodings", RFC 4648, October 2006. 927 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 928 Languages", BCP 47, RFC 5646, September 2009. 930 [RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for 931 Cryptographic Message Syntax (CMS) and S/MIME", RFC 932 5911, June 2010. 934 [RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the 935 Public Key Infrastructure Using X.509 (PKIX)", RFC 936 5912, June 2010. 938 [OATHMAN] OATH Manufacturer prefixes: 939 http://www.openauthentication.org/oath-id/prefixes/ 941 [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 942 Key Container (PSKC), draft-ietf-keyprov-pskc-07.txt, 943 work-in-progress. 945 //** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is 946 the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and 947 elsewhere in the document. **// 949 [SP800-67] National Institute of Standards and Technology, "NIST 950 Special Publication 800-67 Version 1.1: Recommendation 951 for the Triple Data Encryption Algorithm (TDEA) Block 952 Cipher", NIST Special Publication 800-67, May 2008. 954 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 955 1:2002. Information Technology - Abstract Syntax 956 Notation One. 958 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- 959 2:2002. Information Technology - Abstract Syntax 960 Notation One: Information Object Specification. 962 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 963 3:2002. Information Technology - Abstract Syntax 964 Notation One: Constraint Specification. 966 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 967 4:2002. Information Technology - Abstract Syntax 968 Notation One: Parameterization of ASN.1 Specifications. 970 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 971 1:2002. Information Technology - ASN.1 encoding rules: 972 Specification of Basic Encoding Rules (BER), Canonical 973 Encoding Rules (CER) and Distinguished Encoding Rules 974 (DER). 976 [XMLSCHEMA] Biron, P., and A. Malhotra, "XML Schema Part 2: 977 Datatypes Second Edition", 978 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, 979 2004. 981 7.2. Informative References 983 [DSKPP] Doherty, A., Pei, M., Machani, S., and M. Nystrom, 984 "Dynamic Symmetric Key Provisioning Protocol", Internet 985 Draft Informational, URL: http://www.ietf.org/internet- 986 drafts/draft-ietf-keyprov-dskpp-10.txt, work in 987 progress. 989 //** RFC EDITOR: Please replace [DSKPP] with [RFCXXXX] where XXXX is 990 the draft-ietf-keyprov-dskpp's RFC #. Make the replacements here and 991 elsewhere in the document. **// 993 [NIST800-57] National Institute of Standards and Technology, "NIST 994 Special Publication 800-57, Recommendation for Key 995 Management - Part 1: General (Revised)", NIST Special 996 Publication 800-57, March 2007. 998 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 999 5652, September 2009. 1001 APPENDIX A: ASN.1 Module 1003 This appendix provides the normative ASN.1 definitions for the 1004 structures described in this specification using ASN.1 as defined in 1005 [X.680], [X.681], [X.682], and [X.683]. 1007 A.1. Symmetric Key Package ASN.1 Module 1009 SymmetricKeyPackageModulev1 1010 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1011 smime(16) modules(0) id-mod-symmetricKeyPkgV1(33) } 1013 DEFINITIONS IMPLICIT TAGS ::= 1015 BEGIN 1017 -- EXPORTS ALL 1019 IMPORTS 1021 -- From New PKIX ASN.1 [RFC5912] 1023 ATTRIBUTE 1024 FROM PKIX-CommonTypes-2009 1025 { iso(1) identified-organization(3) dod(6) internet(1) 1026 security(5) mechanisms(5) pkix(7) id-mod(0) 1027 id-mod-pkixCommon-02(57) } 1029 -- From New SMIME ASN.1 [RFC5911] 1031 CONTENT-TYPE, Attribute{} 1032 FROM CryptographicMessageSyntax-2009 1033 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1034 smime(16) modules(0) id-mod-cms-2004-02(41) } 1036 ; 1038 ContentSet CONTENT-TYPE ::= { 1039 ct-symmetric-key-package, 1040 ... -- Expect additional content types -- 1041 } 1043 ct-symmetric-key-package CONTENT-TYPE ::= 1044 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 1046 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 1047 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1048 smime(16) ct(1) 25 } 1050 SymmetricKeyPackage ::= SEQUENCE { 1051 version KeyPkgVersion DEFAULT v1, 1052 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute 1053 {{ SKeyPkgAttributes }} OPTIONAL, 1054 sKeys SymmetricKeys, 1055 ... } 1057 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 1059 OneSymmetricKey ::= SEQUENCE { 1060 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute 1061 {{ SKeyAttributes }} OPTIONAL, 1062 sKey OCTET STRING OPTIONAL } 1063 ( WITH COMPONENTS { ..., sKeyAttrs PRESENT } | 1064 WITH COMPONENTS { ..., sKey PRESENT } ) 1066 KeyPkgVersion ::= INTEGER { v1(1) } ( v1, ... ) 1068 SKeyPkgAttributes ATTRIBUTE ::= { ... } 1070 SKeyAttributes ATTRIBUTE ::= { ... } 1072 END 1074 A.2. PSKC ASN.1 Module 1076 PSKCAttributesModule 1077 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1078 smime(16) modules(0) id-mod-pskcAttributesModule(53) } 1080 DEFINITIONS IMPLICIT TAGS ::= 1082 BEGIN 1084 -- EXPORTS ALL 1086 IMPORTS 1088 -- From New PKIX ASN.1 [RFC5912] 1090 ATTRIBUTE 1091 FROM PKIX-CommonTypes-2009 1092 { iso(1) identified-organization(3) dod(6) internet(1) 1093 security(5) mechanisms(5) pkix(7) id-mod(0) 1094 id-mod-pkixCommon-02(57) } 1096 -- From BinaryTime [RFC4049] 1098 BinaryTime 1099 FROM BinarySigningTimeModule 1100 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1101 smime(16) modules(0) id-mod-binarySigningTime(27) } 1103 -- From New SMIME ASN.1 [RFC5911] 1105 id-smime 1106 FROM SecureMimeMessageV3dot1-2009 1107 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1108 smime(16) modules(0) id-mod-msg-v3dot1-02(39) } 1110 ; 1112 -- 1113 -- PSKC Attributes OIDs are taken from the SMIME Arc. 1114 -- 1116 id-pskc OBJECT IDENTIFIER ::= { id-smime 12 } 1117 -- 1118 -- Merge SKeyPKGAttributes to the set of attributes for sKeyPkgAttrs 1119 -- 1121 SKeyPkgAttributes ATTRIBUTE ::= { 1122 at-pskc-manufacturer | at-pskc-serialNo | at-pskc-model | 1123 at-pskc-issueNo | at-pskc-deviceBinding | 1124 at-pskc-deviceStartDate | at-pskc-deviceExpiryDate | 1125 at-pskc-moduleId | at-deviceUserId, ... } 1127 -- 1128 -- Merge SKeyAttributes to the set of attributes for sKeyAttrs 1129 -- 1131 SKeyAttributes ATTRIBUTE ::= { 1132 at-pskc-keyId | at-pskc-algorithm | at-pskc-issuer | 1133 at-pskc-keyProfileId | at-pskc-keyReference | 1134 at-pskc-friendlyName | at-pskc-algorithmParameters | 1135 at-pskc-counter | at-pskc-time | at-pskc-timeInterval | 1136 at-pskc-timeDrift | at-pskc-valueMAC | at-keyUserId | 1137 at-pskc-keyStartDate | at-pskc-keyExpiryDate | 1138 at-pskc-numberOfTransactions | at-pskc-keyUsage | 1139 at-pskc-pinPolicy,... } 1141 at-pskc-manufacturer ATTRIBUTE ::= { 1142 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 1144 id-pskc-manufacturer OBJECT IDENTIFIER ::= { id-pskc 1 } 1146 at-pskc-serialNo ATTRIBUTE ::= { 1147 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 1149 id-pskc-serialNo OBJECT IDENTIFIER ::= { id-pskc 2 } 1151 at-pskc-model ATTRIBUTE ::= { 1152 TYPE UTF8String IDENTIFIED BY id-pskc-model } 1154 id-pskc-model OBJECT IDENTIFIER ::= { id-pskc 3 } 1156 at-pskc-issueNo ATTRIBUTE ::= { 1157 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 1159 id-pskc-issueNo OBJECT IDENTIFIER ::= { id-pskc 4 } 1161 at-pskc-deviceBinding ATTRIBUTE ::= { 1162 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 1164 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { id-pskc 5 } 1166 at-pskc-deviceStartDate ATTRIBUTE ::= { 1167 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceStartDate } 1169 id-pskc-deviceStartDate OBJECT IDENTIFIER ::= { id-pskc 6 } 1171 at-pskc-deviceExpiryDate ATTRIBUTE ::= { 1172 TYPE GeneralizedTime IDENTIFIED BY id-pskc-deviceExpiryDate } 1174 id-pskc-deviceExpiryDate OBJECT IDENTIFIER ::= { id-pskc 7 } 1176 at-pskc-moduleId ATTRIBUTE ::= { 1177 TYPE UTF8String IDENTIFIED BY id-pskc-moduleId } 1179 id-pskc-moduleId OBJECT IDENTIFIER ::= { id-pskc 8 } 1181 at-pskc-deviceUserId ATTRIBUTE ::= { 1182 TYPE UTF8String IDENTIFIED BY id-pskc-deviceUserId } 1184 id-pskc-deviceUserId OBJECT IDENTIFIER ::= { id-pskc 26 } 1186 at-pskc-keyId ATTRIBUTE ::= { 1187 TYPE UTF8String IDENTIFIED BY id-pskc-keyId } 1189 id-pskc-keyId OBJECT IDENTIFIER ::= { id-pskc 9 } 1191 at-pskc-algorithm ATTRIBUTE ::= { 1192 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 1194 id-pskc-algorithm OBJECT IDENTIFIER ::= { id-pskc 10 } 1196 at-pskc-issuer ATTRIBUTE ::= { 1197 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 1199 id-pskc-issuer OBJECT IDENTIFIER ::= { id-pskc 11 } 1201 at-pskc-keyProfileId ATTRIBUTE ::= { 1202 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 1204 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { id-pskc 12 } 1206 at-pskc-keyReference ATTRIBUTE ::= { 1207 TYPE UTF8String IDENTIFIED BY id-pskc-keyReference } 1209 id-pskc-keyReference OBJECT IDENTIFIER ::= { id-pskc 13 } 1210 at-pskc-friendlyName ATTRIBUTE ::= { 1211 TYPE FriendlyName IDENTIFIED BY id-pskc-friendlyName } 1213 id-pskc-friendlyName OBJECT IDENTIFIER ::= { id-pskc 14 } 1215 FriendlyName ::= SEQUENCE { 1216 friendlyName UTF8String, 1217 friendlyNameLangTag UTF8String OPTIONAL } 1219 at-pskc-algorithmParameters ATTRIBUTE ::= { 1220 TYPE PSKCAlgorithmParameters 1221 IDENTIFIED BY id-pskc-algorithmParameters } 1223 id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { id-pskc 15 } 1225 PSKCAlgorithmParameters ::= CHOICE { 1226 suite UTF8String OPTIONAL, 1227 challengeFormat [0] ChallengeFormat, 1228 responseFormat [1] ResponseFormat, 1229 ... } 1231 ChallengeFormat ::= SEQUENCE { 1232 encoding Encoding, 1233 checkDigit BOOLEAN DEFAULT FALSE, 1234 min INTEGER (0..MAX), 1235 max INTEGER (0..MAX), 1236 ... } 1238 Encoding ::= UTF8String ("DECIMAL" | "HEXADECIMAL" | 1239 "ALPHANUMERIC" | "BASE64" | "BINARY" ) 1241 ResponseFormat ::= SEQUENCE { 1242 encoding Encoding, 1243 length INTEGER (0..MAX), 1244 checkDigit BOOLEAN DEFAULT FALSE, 1245 ... } 1247 at-pskc-counter ATTRIBUTE ::= { 1248 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-counter } 1250 id-pskc-counter OBJECT IDENTIFIER ::= { id-pskc 16 } 1252 at-pskc-time ATTRIBUTE ::= { 1253 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1255 id-pskc-time OBJECT IDENTIFIER ::= { id-pskc 17 } 1256 at-pskc-timeInterval ATTRIBUTE ::= { 1257 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeInterval } 1259 id-pskc-timeInterval OBJECT IDENTIFIER ::= { id-pskc 18 } 1261 at-pskc-timeDrift ATTRIBUTE ::= { 1262 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-timeDrift } 1264 id-pskc-timeDrift OBJECT IDENTIFIER ::= { id-pskc 19 } 1266 at-pskc-valueMAC ATTRIBUTE ::= { 1267 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 1269 id-pskc-valueMAC OBJECT IDENTIFIER ::= { id-pskc 20 } 1271 ValueMac ::= SEQUENCE { 1272 macAlgorithm UTF8String, 1273 mac UTF8String } 1275 at-pskc-keyUserId ATTRIBUTE ::= { 1276 TYPE UTF8String IDENTIFIED BY id-pskc-keyUserId } 1278 id-pskc-keyUserId OBJECT IDENTIFIER ::= { id-pskc 27 } 1280 at-pskc-keyStartDate ATTRIBUTE ::= { 1281 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyStartDate } 1283 id-pskc-keyStartDate OBJECT IDENTIFIER ::= { id-pskc 21 } 1285 at-pskc-keyExpiryDate ATTRIBUTE ::= { 1286 TYPE GeneralizedTime IDENTIFIED BY id-pskc-keyExpiryDate } 1288 id-pskc-keyExpiryDate OBJECT IDENTIFIER ::= { id-pskc 22 } 1290 at-pskc-numberOfTransactions ATTRIBUTE ::= { 1291 TYPE INTEGER (0..MAX) IDENTIFIED BY id-pskc-numberOfTransactions } 1293 id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { id-pskc 23 } 1295 at-pskc-keyUsage ATTRIBUTE ::= { 1296 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 1298 id-pskc-keyUsages OBJECT IDENTIFIER ::= { id-pskc 24 } 1300 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 1301 PSKCKeyUsage ::= UTF8String ("OTP" | "CR" | "Encrypt" | 1302 "Integrity" | "Verify" | "Unlock" | "Decrypt" | 1303 "KeyWrap" | "Unwrap" | "Derive" | "Generate") 1305 at-pskc-pinPolicy ATTRIBUTE ::= { 1306 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 1308 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { id-pskc 25 } 1310 PINPolicy ::= SEQUENCE { 1311 pinKeyId [0] UTF8String OPTIONAL, 1312 pinUsageMode [1] PINUsageMode, 1313 maxFailedAttempts [2] INTEGER (0..MAX) OPTIONAL, 1314 minLength [3] INTEGER (0..MAX) OPTIONAL, 1315 maxLength [4] INTEGER (0..MAX) OPTIONAL, 1316 pinEncoding [5] Encoding OPTIONAL } 1318 PINUsageMode ::= UTF8String ("Local" | "Prepend" | "Append"| 1319 "Algorithmic") 1321 END 1323 Authors' Addresses 1325 Sean Turner 1326 IECA, Inc. 1327 3057 Nutley Street, Suite 106 1328 Fairfax, VA 22031 1329 USA 1331 EMail: turners@ieca.com 1333 Russ Housley 1334 Vigil Security, LLC 1335 918 Spring Knoll Drive 1336 Herndon, VA 20170 1337 USA 1339 EMail: housley@vigilsec.com