idnits 2.17.1 draft-ietf-keyprov-symmetrickeyformat-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 20, 2009) is 5301 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 1114 -- Looks like a reference, but probably isn't: '1' on line 1115 -- Looks like a reference, but probably isn't: '2' on line 1116 -- Looks like a reference, but probably isn't: '3' on line 1117 -- Looks like a reference, but probably isn't: '4' on line 1111 -- Looks like a reference, but probably isn't: '5' on line 1093 -- Looks like a reference, but probably isn't: '6' on line 1094 -- Looks like a reference, but probably isn't: '7' on line 1095 -- Looks like a reference, but probably isn't: '8' on line 1096 -- Looks like a reference, but probably isn't: '9' on line 1097 -- Looks like a reference, but probably isn't: '10' on line 1098 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' ** Obsolete normative reference: RFC 4049 (Obsoleted by RFC 6019) -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-67' == Outdated reference: A later version (-09) exists of draft-ietf-keyprov-pskc-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 KEYPROV Working Group Sean Turner, IECA 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standard Track October 20, 2009 4 Expires: April 20, 2010 6 Symmetric Key Package Content Type 7 draft-ietf-keyprov-symmetrickeyformat-06.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 20, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This document defines the symmetric key format content type. It is 46 transport independent. The Cryptographic Message Syntax can be used 47 to digitally sign, digest, authenticate, or encrypt this content 48 type. 50 Table of Contents 52 1. Introduction...................................................3 53 1.1. Requirements Terminology..................................3 54 1.2. ASN.1 Syntax Notation.....................................3 55 2. Symmetric Key Package Content Type.............................3 56 3. PSKC Attributes................................................4 57 3.1. PSKC Key Package Attributes...............................5 58 3.1.1. Device Information Attributes........................5 59 3.1.2. Cryptographic Module Information Attributes..........7 60 3.2. PSKC Key Attributes.......................................7 61 3.2.1. Key Identifier.......................................7 62 3.2.2. Algorithm............................................8 63 3.2.3. Issuer...............................................8 64 3.2.4. Key Profile Identifier...............................8 65 3.2.5. Friendly Name........................................8 66 3.2.6. Algorithm Parameters.................................9 67 3.2.7. Counter.............................................11 68 3.2.8. Time................................................11 69 3.2.9. Time Interval.......................................11 70 3.2.10. Time Drift.........................................11 71 3.2.11. Value MAC..........................................12 72 3.3. Key Policy Attributes....................................12 73 3.3.1. Start Date..........................................12 74 3.3.2. Expiry Date.........................................12 75 3.3.3. Number of Transactions..............................13 76 3.3.4. Key Usage...........................................13 77 3.3.5. PIN Policy..........................................14 78 4. Key Encoding..................................................15 79 4.1. AES Key Encoding.........................................16 80 4.2. Triple DES Key Encoding..................................16 81 5. Security Considerations.......................................17 82 6. IANA Considerations...........................................17 83 7. References....................................................17 84 7.1. Normative References.....................................17 85 7.2. Non-Normative References.................................18 87 APPENDIX A: ASN.1 Modules........................................18 89 1. Introduction 91 This document defines the symmetric key format content type. It is 92 transport independent. The Cryptographic Message Syntax (CMS) 93 [RFC5652] can be used to digitally sign, digest, authenticate, or 94 encrypt this content type. 96 The uses cases that motivated this work are elaborated in [PSKC]. 97 They are omitted to avoid duplication. 99 This document also includes Abstract Syntax Notation One (ASN.1) 100 definitions of the Extensile Markup Language (XML) element and 101 attributes defined in [PSKC]. 103 1.1. Requirements Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1.2. ASN.1 Syntax Notation 111 The key package is defined using the ASN.1 [X.680, X.681, X.682, and 112 X.683]. 114 2. Symmetric Key Package Content Type 116 The symmetric key package content type is used to transfer one or 117 more plaintext symmetric keys from one party to another. A symmetric 118 key package MAY be encapsulated in one or more CMS protecting content 119 types. This content type must be Distinguished Encoding Rules (DER) 120 encoded [X.690]. 122 The symmetric key package content type has the following syntax: 124 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 126 symmetric-key-package PKCS7-CONTENT-TYPE ::= 127 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 129 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 130 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 131 smime(16) ct(1) 25 } 133 SymmetricKeyPackage ::= SEQUENCE { 134 version KeyPkgVersion DEFAULT v1, 135 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 136 sKeys SymmetricKeys } 138 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 140 OneSymmetricKey ::= SEQUENCE { 141 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 142 sKey OCTET STRING OPTIONAL } 143 -- At least sKeyAttrs or sKey MUST be present. 145 KeyPkgVersion ::= INTEGER { v1(1), ... } 147 The SymmetricKeyPackage fields are used as follows: 149 - version identifies version of the symmetric key package content 150 structure. For this version of the specification, the default 151 value, v1, MUST be used. 153 - sKeyPkgAttrs optionally provides attributes that apply to all of 154 the symmetric keys in the package. If an attribute appears here it 155 MUST NOT also be included in sKeyAttrs. 157 - sKeys contains a sequence of OneSymmetricKey values. This 158 structure is discussed below. 160 The OneSymmetricKey fields are used as follows: 162 - sKeyAttrs optionally provides attributes that apply to one 163 symmetric key. If an attribute appears here it MUST NOT also be 164 included in sKeyPkgAttrs. 166 - sKey optionally contains the key value encoded as an OCTET STRING. 168 The OneSymmetricKey field MUST include either sKeyAttrs, or sKey, or 169 sKeyAttrs and sKey. 171 3. PSKC Attributes 173 The following attributes are defined to assist those using the 174 symmetric key package defined in this document as part of a Portable 175 Symmetric Key Container protocol [PSKC]. [PSKC] should be consulted 176 for the definitive attribute descriptions. The attributes fall in to 177 three categories. The first category includes attributes that apply 178 to a key package, and these attributes will generally appear in 179 sKeyPkgAttrs. The second category includes attributes that apply to 180 a particular key, and these attributes will generally appear in 181 sKeyAttrs. The third category includes attributes that apply to a key 182 policy. Of the attributes defined next, only the Key Identifier 183 (Section 3.2.1) and Algorithm (Section 3.2.2) key attributes MUST be 184 included. All other attributes are OPTIONAL. 186 Like PSKC, the Symmetric Key Content Type supports extensibility. 187 Primarily this is accomplished through the definition and inclusion 188 of new attributes, but in some instances where the attribute contains 189 more than one type the ASN.1 "..." extensibility mechanism is 190 employed. 192 A straightforward approach to conversion from XML types to ASN.1 is 193 employed. The type converts to UTF8String; the XML 194 type converts to GeneralizedTime; and the XML integer 195 types convert to INTEGER or BinaryTime [RFC4049]. 197 3.1. PSKC Key Package Attributes 199 PSKC key package attributes apply to an entire key package. These 200 attributes can be categorized by two different attribute collections: 201 device information and cryptographic module attributes. All of these 202 key package attributes are OPTIONAL. 204 3.1.1. Device Information Attributes 206 Device Information attributes when taken together uniquely identify a 207 device to which the Symmetric Key Package is provisioned. 209 3.1.1.1. Manufacturer 211 The Manufacturer attribute indicates the manufacturer of the device. 212 The attribute definition is as follows: 214 at-pskc-manufacturer ATTRIBUTE ::= { 215 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 217 id-pskc-manufacturer OBJECT IDENTIFIER ::= { TBD } 219 3.1.1.2. Serial Number 221 The Serial Number attribute indicates the serial number of the 222 device. The attribute definition is as follows: 224 at-pskc-serialNo ATTRIBUTE ::= { 225 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 227 id-pskc-serialNo OBJECT IDENTIFIER ::= { TBD } 229 3.1.1.3. Model 231 The Model attribute indicates the model of the device. The attribute 232 definition is as follows: 234 at-pskc-model ATTRIBUTE ::= { 235 TYPE UTF8String IDENTIFIED BY id-pskc-model } 237 id-pskc-model OBJECT IDENTIFIER ::= { TBD } 239 3.1.1.4. Issue Number 241 The Issue Number attribute contains an issue number to distinguish 242 between two devices with the same serial number. The attribute 243 definition is as follows: 245 at-pskc-issueNo ATTRIBUTE ::= { 246 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 248 id-pskc-issueNo OBJECT IDENTIFIER ::= { TBD } 250 3.1.1.5. Device Binding 252 The Device Binding attribute provides an opaque identifier that 253 allows keys to be bound to the device or to a class of devices. 254 When loading keys into a device, the attribute's value MUST be 255 checked against information provided to the user via out-of-band 256 mechanisms. The implementation then ensures that the correct device 257 or class of device is being used with respect to the provisioned key. 259 at-pskc-deviceBinding ATTRIBUTE ::= { 260 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 262 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { TBD } 264 3.1.1.6. Start Date 266 When included in sKeyPkgAttrs, the Start Date attribute indicates the 267 start date for a device. The date MUST be expressed in UTC form with 268 no time zone component. Implementations SHOULD NOT rely on time 269 resolution finer than milliseconds and MUST NOT generate time 270 instants that specify leap seconds. The attribute definition is as 271 follows: 273 at-pskc-startDate ATTRIBUTE ::= { 274 TYPE GeneralizedTime IDENTIFIED BY id-pskc-startDate } 276 id-pskc-startDate OBJECT IDENTIFIER ::= { TBD } 278 3.1.1.7. Expiry Date 280 When included in sKeyPkgAttrs, the Expiry Date attribute indicates 281 the expiry date for a device. The date MUST be expressed in UTC form 282 with no time zone component. Implementations SHOULD NOT rely on time 283 resolution finer than milliseconds and MUST NOT generate time 284 instants that specify leap seconds. The attribute definition is as 285 follows: 287 at-pskc-expiryDate ATTRIBUTE ::= { 288 TYPE GeneralizedTime IDENTIFIED BY id-pskc-expiryDate } 290 id-pskc-expiryDate OBJECT IDENTIFIER ::= { TBD } 292 3.1.2. Cryptographic Module Information Attributes 294 Cryptographic Module attributes uniquely identify a cryptographic 295 module. This is useful when the device contains more than one 296 cryptographic module. At this time only one attribute is defined. 298 3.1.2.1. Cryptographic Module Identifier 300 When included in sKeyPkgAttrs, the Identifier attribute uniquely 301 identifies the cryptographic module to which the key is being or was 302 provisioned. The attribute definition is as follows: 304 at-pskc-id ATTRIBUTE ::= { 305 TYPE UTF8String IDENTIFIED BY id-pskc-id } 307 id-pskc-id OBJECT IDENTIFIER ::= { TBD } 309 3.2. PSKC Key Attributes 311 PSKC key attributes apply to a specific key. As noted earlier, the 312 Key Identifier (Sec 3.2.1) and Algorithm (Sec 3.2.2) key attributes 313 are REQUIRED. All other attributes are OPTIONAL. 315 3.2.1. Key Identifier 317 When included in sKeyAttrs, the Identifier attribute uniquely 318 identifies the key. The syntax is found in Section 3.1.2.1. 320 3.2.2. Algorithm 322 The Algorithm attribute uniquely identifies the PSKC algorithm 323 profile. Values may be taken from [PSKC-ALGORITHM-PROFILES]. The 324 attribute definition is as follows: 326 at-pskc-algorithm ATTRIBUTE ::= { 327 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 329 id-pskc-algorithm OBJECT IDENTIFIER ::= { TBD } 331 3.2.3. Issuer 333 The Issuer attribute names the entity that issued the key. The 334 attribute definition is as follows: 336 at-pskc-issuer ATTRIBUTE ::= { 337 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 339 id-pskc-issuer OBJECT IDENTIFIER ::= { TBD } 341 3.2.4. Key Profile Identifier 343 The Key Profile Identifier attribute carries a unique identifier used 344 between the sending and receiving parties to establish a set of key 345 attribute values that are not transmitted within the container but 346 agreed between the two parties out of band. This attribute will then 347 represent the unique reference to a set of key attribute values. 349 at-pskc-keyProfileId ATTRIBUTE ::= { 350 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 352 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { TBD } 354 3.2.5. Friendly Name 356 The Friendly Name attribute contains a human readable name for the 357 secret key. The attribute definition is as follows: 359 at-pskc-friendlyName ATTRIBUTE ::= { 360 TYPE UTF8String IDENTIFIED BY id-pskc-friendlyName } 362 id-pskc-friendlyName OBJECT IDENTIFIER ::= { TBD } 364 3.2.6. Algorithm Parameters 366 The Algorithm Parameters attribute contains parameters that influence 367 the result of the algorithmic computation, for example response 368 truncation and format in One-Time Password (OTP) and Challenge- 369 Response (CR) algorithms. 371 at-pskc-algorithmParameters ATTRIBUTE ::= { 372 TYPE PSKCAlgorithmParameters 373 IDENTIFIED BY id-pskc-algorithmParameters } 375 id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { TBD } 377 The Algorithm Parameters attribute has the following syntax: 379 PSKCAlgorithmParameters ::= CHOICE { 380 challengeFormat [0] ChallengeFormat, 381 responseFormat [1] ResponseFormat, 382 ... } 384 ChallengeFormat ::= SEQUENCE { 385 encoding Encoding, 386 checkDigit BOOLEAN OPTIONAL, 387 min INTEGER, 388 max INTEGER, 389 ... } 391 Encoding ::= CHOICE { 392 decimal [0] UTF8String ("DECIMAL"), 393 hexidecimal [1] UTF8String ("HEXIDECIMAL"), 394 alphanumeric [2] UTF8String ("ALPHANUMERIC"), 395 base64 [3] UTF8String ("BASE64"), 396 binary [4] UTF8String ("BINARY") } 398 ResponseFormat ::= SEQUENCE { 399 encoding Encoding, 400 length INTEGER, 401 checkDigit BOOLEAN OPTIONAL, 402 ... } 404 The fields in PSKCAlgorithmParameters have the following meanings: 406 o ChallengeFormat defines the characteristics of the challenge in a 407 CR usage scenario whereby the following fields are defined: 409 o encoding specifies the encoding of the challenge accepted by 410 the device and MUST be one of the following values: DECIMAL, 411 HEXIDECIMAL, ALPHANUMERIC, BASE64, or BINARY. 413 o checkDigit indicates whether a device needs to check the 414 appended Luhn check digit, as defined in [LUHN], contained in a 415 challenge. The checkDigit MUST NOT be present if the encoding 416 value is anything other than 'DECIMAL'. A value of TRUE 417 indicates that the device will check the appended Luhn check 418 digit in a provided challenge. A value of FALSE indicates that 419 the device will not check the appended Luhn check digit in the 420 challenge. 422 o min defines the minimum size of the challenge accepted by the 423 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 424 'ALPHANUMERIC' this value indicates the minimum number of 425 digits/characters. If encoding is 'BASE64' or 'BINARY', this 426 value indicates the minimum number of bytes of the unencoded 427 value. 429 o max defines the maximum size of the challenge accepted by the 430 device for CR mode. If encoding is 'DECIMAL', 'HEXADECIMAL' or 431 'ALPHANUMERIC' this value indicates the maximum number of 432 digits/characters. If the encoding is 'BASE64' or 'BINARY', 433 this value indicates the maximum number of bytes of the 434 unencoded value. 436 o ResponseFormat defines the characteristics of the result of a 437 computation and defines the format of the OTP or the response to 438 a challenge. For cases where the key is a personal 439 identification number (PIN) value, this element contains the 440 format of the PIN itself (e.g., DECIMAL, length 4 for a 4 digit 441 PIN). The following fields are defined: 443 o encoding specifies the encoding of the response generated by 444 the device and MUST be one of the following values: DECIMAL, 445 HEXADECIMAL, ALPHANUMERIC, BASE64, or BINARY. 447 o length defines the length of the response generated by the 448 device. If encoding is 'DECIMAL', 'HEXADECIMAL' or 449 'ALPHANUMERIC' this value indicates the number of 450 digits/characters. If encoding is 'BASE64' or 'BINARY', this 451 value indicates the number of bytes of the unencoded value. 453 o checkDigit indicates whether the device needs to append a Luhn 454 check digit, as defined in [LUHN], to the response. This is 455 only valid if encoding attribute is 'DECIMAL'. If the value is 456 TRUE then the device will append a Luhn check digit to the 457 response. If the value is FALSE, then the device will not 458 append a Luhn check digit to the response. 460 3.2.7. Counter 462 The Counter attribute contains the event counter for event-based OTP 463 algorithms. The attribute definition is as follows: 465 at-pskc-counter ATTRIBUTE ::= { 466 TYPE INTEGER IDENTIFIED BY id-pskc-counter } 468 id-pskc-counter OBJECT IDENTIFIER ::= { TBD } 470 3.2.8. Time 472 The Time attribute conveys the time for time-based OTP algorithms. 473 If the Time Interval attribute is included, then this element carries 474 the number of time intervals passed for a specific start point. It 475 uses the BinaryTime syntax from [RFC4049]. The attribute definition 476 is as follows: 478 at-pskc-time ATTRIBUTE ::= { 479 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 481 id-pskc-time OBJECT IDENTIFIER ::= { TBD } 483 3.2.9. Time Interval 485 The Time Interval attribute conveys the time interval value for time- 486 based OTP algorithms. It uses the BinaryTime syntax from [RFC4049]. 487 The attribute definition is as follows: 489 at-pskc-timeInterval ATTRIBUTE ::= { 490 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 492 id-pskc-timeInterval OBJECT IDENTIFIER ::= { TBD } 494 3.2.10. Time Drift 496 The Time Drift attribute contains the device clock drift value, the 497 number of seconds per day the device clocks drifts, for time-based 498 OTP algorithms. It uses the BinaryTime syntax from [RFC4049]. The 499 attribute definition is as follows: 501 at-pskc-timeDrift ATTRIBUTE ::= { 502 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 504 id-pskc-timeDrift OBJECT IDENTIFIER ::= { TBD } 506 3.2.11. Value MAC 508 The Value MAC attribute is a Message Authentication Code (MAC) 509 generated from the encrypted value in case the encryption algorithm 510 does not support integrity checks (e.g., AES-CBC does not provide 511 integrity while AES Key Wrap with MLI does). The attribute definition 512 is as follows: 514 at-pskc-valueMAC ATTRIBUTE ::= { 515 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 517 id-pskc-valueMAC OBJECT IDENTIFIER ::= { TBD } 519 ValueMac ::= SEQUENCE { 520 macAlgorithm UTF8String, 521 mac UTF8String } 523 The fields in ValueMac have the following meanings: 525 o macAlgorithm identifies the MAC algorithm used to generate the 526 value placed in digest. Values may be taken from [PSKC-ALGORITHM- 527 PROFILES]. 529 o mac is the mac value. 531 3.3. Key Policy Attributes 533 Key policy attributes indicate a policy that can be attached to a 534 key. These attributes are defined in the subsections that follow. 536 3.3.1. Start Date 538 When included in sKeyPkgAttrs, the Start Date attribute indicates the 539 start of the keys validity. The date MUST be expressed in UTC form 540 with no time zone component. Implementations SHOULD NOT rely on time 541 resolution finer than milliseconds and MUST NOT generate time 542 instants that specify leap seconds. The attribute definition is as 543 in Section 3.1.1.6. 545 3.3.2. Expiry Date 547 When included in sKeyAttrs, the Expiry Date attribute indicates the 548 end of the key's validity period. The date MUST be expressed in UTC 549 form with no time zone component. Implementations SHOULD NOT rely on 550 time resolution finer than milliseconds and MUST NOT generate time 551 instants that specify leap seconds. The attribute definition is as in 552 Section 3.1.1.7. 554 3.3.3. Number of Transactions 556 The Number of Transactions attribute indicates the maximum number of 557 times a key carried within the package can be used. When this 558 element is omitted there is no restriction regarding the number of 559 times a key can be used. The attribute definition is as follows: 561 at-pskc-numberOfTransactions ATTRIBUTE ::= { 562 TYPE INTEGER IDENTIFIED BY id-pskc-numberOfTransactions } 564 id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { TBD } 566 3.3.4. Key Usage 568 The Key Usage attribute constrains the intended usage of the key. 569 The recipient MUST enforce the key usage. The attribute definition 570 is as follows: 572 at-pskc-keyUsage ATTRIBUTE ::= { 573 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 575 id-pskc-keyUsages OBJECT IDENTIFIER ::= { TBD } 577 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 579 PSKCKeyUsage ::= CHOICE { 580 otp [0] UTF8String ("OTP"), 581 cr [1] UTF8String ("CR"), 582 encrypt [2] UTF8String ("Encrypt"), 583 integrity [3] UTF8String ("Integrity"), 584 verify [4] UTF8String ("Verify"), 585 unlock [5] UTF8String ("Unlock"), 586 decrypt [6] UTF8String ("Decrypt"), 587 keyWrap [7] UTF8String ("KeyWrap"), 588 unwrap [8] UTF8String ("Unwrap"), 589 derive [9] UTF8String ("Derive"), 590 generate [10] UTF8String ("Generate") } 592 The fields in PSKCKeyUsage have the following meanings: 594 o OTP: The key MUST only be used for OTP generation. 596 o CR: The key MUST only be used for Challenge/Response purposes. 598 o Encrypt: The key MUST only be used for data encryption purposes. 600 o Integrity: The key MUST only be used to generate a keyed message 601 digest for data integrity or authentication purposes. 603 o Verify: The key MUST only be used to verify a keyed message 604 digest for data integrity or authentication purposes. (is converse 605 of Integrity) 607 o Unlock: The key MUST only be used for an inverse challenge 608 response in the case where a user has locked the device by 609 entering a wrong PIN too many times (for devices with PIN-input 610 capability). 612 o Decrypt: The key MUST only be used for data decryption purposes. 614 o KeyWrap: The key MUST only be used for key wrap purposes. 616 o Unwrap: The key MUST only be used for key unwrap purposes. 618 o Derive: The key MUST only be used with a key derivation function 619 to derive a new key (see also Section 8.2.4 of [NIST800-57]). 621 o Generate: The key MUST only be used to generate a new key based 622 on a random number and the previous value of the key (see also 623 Section 8.1.5.2.1 of [NIST800-57]). 625 3.3.5. PIN Policy 627 The PIN Policy attribute allows policy about the PIN usage to be 628 associated with the key. The attribute definition is as follows: 630 at-pskc-pinPolicy ATTRIBUTE ::= { 631 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 633 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { TBD } 635 PINPolicy ::= SEQUENCE { 636 pinKeyId [0] UTF8String OPTIONAL, 637 pinUsageMode [1] PINUsageMode, 638 maxFailedAttempts [2] INTEGER OPTIONAL, 639 minLength [3] INTEGER OPTIONAL, 640 maxLength [4] INTEGER OPTIONAL, 641 pinEncoding [4] Encoding OPTIONAL } 643 PINUsageMode ::= CHOICE { 644 local [0] UTF8String ("Local"), 645 prepend [1] UTF8String ("Prepend"), 646 append [2] UTF8String ("Append"), 647 algorithmic [3] UTF8String ("Algorithmic") } 649 The fields in PIN Policy have the following meanings: 651 o pinKeyId uniquely identifies the key held within this container 652 that contains the value of the PIN that protects the key. 654 o pinUsageMode indicates the way the PIN is used during the usage of 655 the key. The following values are defined: Local, Prepend, 656 Append, Algorithmic. 658 o maxFailedAttempts indicates the maximum number of times the PIN 659 may be entered wrongly before it MUST NOT be possible to use the 660 key anymore. 662 o minLength indicates the minimum length of a PIN that can be set to 663 protect the associated key. It MUST NOT be possible to set a PIN 664 shorter than this value. If pinEncoding is 'DECIMAL', 665 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of 666 digits/ characters. If pinEncoding is 'BASE64' or 'BINARY', this 667 value indicates the number of bytes of the unencoded value. 669 o maxLength indicates the maximum length of a PIN that can be set to 670 protect this key. It MUST NOT be possible to set a PIN longer 671 than this value. If pinEncoding is 'DECIMAL', 'HEXADECIMAL' or 672 'ALPHANUMERIC' this value indicates the number of 673 digits/characters. If the pinEncoding is 'BASE64' or 'BINARY', 674 this value indicates the number of bytes of the unencoded value. 676 o pinEncoding is based on Encoding, which is defined in Section 677 3.2.6, and specifies encoding of the PIN and MUST be one of the 678 following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC, BASE64, or 679 BINARY. 681 If pinUsageMode is set to "Local" then the device MUST enforce the 682 restriction indicated in maxFailedAttempts, minLength, maxLength and 683 pinEncoding, otherwise it MUST be enforced on the server side. 685 4. Key Encoding 687 Two parties receiving the same key as an sKey OCTET STRING must make 688 use of the key in exactly the same way in order to interoperate. To 689 ensure that, it is necessary to define a correspondence between the 690 abstract syntax of sKey and the notation in the standard algorithm 691 description that defines how the key is used. The next sections 692 establish that correspondence for the algorithms AES [FIPS197] and 693 TDEA [SP800-67]. 695 4.1. AES Key Encoding 697 [FIPS197] section 5.2, titled Key Expansion, uses the input key as an 698 array of bytes indexed starting at 0. The first octet of sKey SHALL 699 become the key byte in AES labeled index 0 in [FIPS197] SHALL be the 700 first octet of sKey, and the other key bytes SHALL follow in index 701 order. 703 Proper parsing and key load of the contents of sKey for AES SHALL be 704 determined by using the following sKey octet string to generate and 705 match the key expansion test vectors in [FIPS197] Appendix A for AES 706 Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 708 Tag Length Value 709 04 16 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c 711 4.2. Triple DES Key Encoding 713 A Triple-DES key consists of three keys for the cryptographic engine 714 (Key1, Key2, and Key3) that are each 64 bits (even though only 56 are 715 used); the three keys are also referred to as a key bundle (KEY) 716 [SP800-67]. A key bundle may employ either two or three mutually 717 independent keys. When only two are employed (called two-key Triple 718 DES), then Key1 = Key3. 720 Each key in a Triple-DES key bundle is expanded into a key schedule 721 according to a procedure defined in [SP800-67] Appendix A. That 722 procedure numbers the bits in the key from 1 to 64, with number 1 723 being the left-most, or most significant bit. The first octet of 724 sKey SHALL be bits 1 through 8 of Key1 with bit 1 being the msb. The 725 second octet of sKey SHALL be bits 9 through 16 of Key1, and so 726 forth, so that the trailing octet of sKEY SHALL be bits 57 through 64 727 of Key3 (or Key2 for two-key Triple DES). 729 Proper parsing and key load of the contents of sKey for Triple-DES 730 SHALL be determined by using the following sKey octet string to 731 generate and match the key expansion test vectors in [SP800-67] 732 appendix B for the key bundle: 734 Key1 = 0123456789ABCDEF 736 Key2 = 23456789ABCDEF01 738 Key3 = 456789ABCDEF0123 739 Tag Length Value 740 04 24 0123456789ABCDEF 23456789ABCDEF01 456789ABCDEF0123 742 5. Security Considerations 744 The symmetric key package contents are not protected. This content 745 type can be combined with a security protocol to protect the contents 746 of the package. 748 6. IANA Considerations 750 None: All identifiers are already registered. Please remove this 751 section prior to publication as an RFC. 753 7. References 755 7.1. Normative References 757 [FIPS197] National Institute of Standards. "FIPS Pub 197: Advanced 758 Encryption Standard (AES)", 26 November 2001. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC4049] Housley, R., "BinaryTime: An Alternate Format for 764 Representing Date and Time in ASN.1", RFC 4049, April 2005. 766 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 767 Information Technology - Abstract Syntax Notation One. 769 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 770 Information Technology - Abstract Syntax Notation One: Information 771 Object Specification. 773 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 774 Information Technology - Abstract Syntax Notation One: Constraint 775 Specification. 777 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 778 Information Technology - Abstract Syntax Notation One: 779 Parameterization of ASN.1 Specifications. 781 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 782 Information Technology - ASN.1 encoding rules: Specification of Basic 783 Encoding Rules (BER), Canonical Encoding Rules (CER) and 784 Distinguished Encoding Rules (DER). 786 [SP800-67] National Institute of Standards and Technology, "NIST 787 Special Publication 800-67 Version 1.1: Recommendation for the Triple 788 Data Encryption Algorithm (TDEA) Block Cipher", NIST Special 789 Publication 800-67, May 2008. 791 7.2. Non-Normative References 793 [LUHN] Luhn, H., "Luhn algorithm", US Patent 2950048, August 1960, 794 http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=2950048. 796 [PSKC] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key 797 Container (PSKC), draft-ietf-keyprov-pskc-03.txt, work-in-progress. 799 //** RFC EDITOR: Please replace [PSKC] with [RFCXXXX] where XXXX is 800 the draft-ietf-keyprov-pskc's RFC #. Make the replacements here and 801 elsewhere in the document. **// 803 [PSKC-ALGORITHM-PROFILES] Hoyer, P., Pei, M., Machani, S., and A. 804 Doherty, "Additional Portable Symmetric Key Container (PSKC) 805 Algorithm Profiles", Internet Draft Informational, URL: 806 http://tools.ietf.org/html/draft-hoyer-keyprov-pskc-algorithm- 807 profiles-00, December 2008. 809 //** RFC EDITOR: Please replace [PSKC-ALGORITHM-PROFILES] with 810 [RFCXXXX] where XXXX is this ID's RFC #. Make the replacements here 811 and elsewhere in the document. **// 813 [NIST800-57] National Institute of Standards and Technology, "NIST 814 Special Publication 800-57, Recommendation for Key Management - Part 815 1: General (Revised)", NIST Special Publication 800-57, March 2007. 817 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 818 5652, September 2009. 820 APPENDIX A: ASN.1 Module 822 This appendix provides the normative ASN.1 definitions for the 823 structures described in this specification using ASN.1 as defined in 824 [X.680] through [X.683]. 826 SymmetricKeyPackageModulev1 827 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 828 smime(16) modules(0) 33 } 830 DEFINITIONS IMPLICIT TAGS ::= 832 BEGIN 833 -- EXPORTS ALL 835 -- IMPORTS NOTHING 837 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 839 KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= { 840 symmetric-key-package | 841 ... -- Expect additional content types -- 842 } 844 symmetric-key-package PKCS7-CONTENT-TYPE ::= 845 { SymmetricKeyPackage IDENTIFIED BY id-ct-KP-sKeyPackage } 847 id-ct-KP-sKeyPackage OBJECT IDENTIFIER ::= 848 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 849 smime(16) ct(1) 25 } 851 SymmetricKeyPackage ::= SEQUENCE { 852 version KeyPkgVersion DEFAULT v1, 853 sKeyPkgAttrs [0] SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 854 sKeys SymmetricKeys } 856 SymmetricKeys ::= SEQUENCE SIZE (1..MAX) OF OneSymmetricKey 858 OneSymmetricKey ::= SEQUENCE { 859 sKeyAttrs SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL, 860 sKey OCTET STRING OPTIONAL 861 -- At least sKeyAttrs or sKey MUST be present. 862 } 864 KeyPkgVersion ::= INTEGER { v1(1), ... } 866 Attribute ::= SEQUENCE { 867 type ATTRIBUTE.&id ({SupportedAttributes}), 868 values SET SIZE (1..MAX) OF ATTRIBUTE.&Type 869 ({SupportedAttributes}{@type}) } 871 SupportedAttributes ATTRIBUTE ::= { ... } 873 ATTRIBUTE ::= CLASS { 874 &derivation ATTRIBUTE OPTIONAL, 875 &Type OPTIONAL, 876 -- either &Type or &derivation required 877 &equality-match MATCHING-RULE OPTIONAL, 878 &ordering-match MATCHING-RULE OPTIONAL, 879 &substrings-match MATCHING-RULE OPTIONAL, 880 &single-valued BOOLEAN DEFAULT FALSE, 881 &collective BOOLEAN DEFAULT FALSE, 882 -- operational extensions 883 &no-user-modification BOOLEAN DEFAULT FALSE, 884 &usage AttributeUsage DEFAULT userApplications, 885 &id OBJECT IDENTIFIER UNIQUE } 886 WITH SYNTAX { 887 [ SUBTYPE OF &derivation ] 888 [ WITH SYNTAX &Type ] 889 [ EQUALITY MATCHING RULE &equality-match ] 890 [ ORDERING MATCHING RULE &ordering-match ] 891 [ SUBSTRINGS MATCHING RULE &substrings-match ] 892 [ SINGLE VALUE &single-valued ] 893 [ COLLECTIVE &collective ] 894 [ NO USER MODIFICATION &no-user-modification ] 895 [ USAGE &usage ] 896 ID &id } 898 MATCHING-RULE ::= CLASS { 899 &AssertionType OPTIONAL, 900 &id OBJECT IDENTIFIER UNIQUE } 901 WITH SYNTAX { 902 [ SYNTAX &AssertionType ] 903 ID &id } 905 AttributeType ::= ATTRIBUTE.&id 907 AttributeValue ::= ATTRIBUTE.&Type 909 AttributeUsage ::= ENUMERATED { 910 userApplications (0), 911 directoryOperation (1), 912 distributedOperation (2), 913 dSAOperation (3) } 915 SupportAttributes ATTRIBUTE ::= { ... } 917 END 919 PSKCAttributesModule 920 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 921 smime(16) modules(0) TBD } 923 DEFINITIONS IMPLICIT TAGS ::= 925 BEGIN 926 -- EXPORTS ALL 928 IMPORTS 930 -- From SymmetricKeyModulev1 932 ATTRIBUTE 933 FROM SymmetricKeyPackageModulev1 934 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 935 smime(16) modules(0) 33 } 937 -- From BinaryTime [RFC4049] 939 BinaryTime 940 FROM BinarySigningTimeModule 941 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 942 smime(16) modules(0) 27 } 944 ; 946 SupportedAttributes ATTRIBUTE ::= { 947 at-pskc-manufacturer | at-pskc-serialNo | at-pskc-issueNo | 948 at-pskc-deviceBinding | at-pskc-startDate | at-pskc-expiryDate | 949 at-pskc-id | at-pskc-algorithm | at-pskc-issuer | 950 at-pskc-keyProfileId | at-pskc-friendlyName | 951 at-pskc-algorithmParameters | at-pskc-counter | at-pskc-time | 952 at-pskc-timeInterval | at-pskc-timeDrift | at-pskc-valueMAC | 953 at-pskc-numberOfTransactions | at-pskc-keyUsage | 954 at-pskc-pinPolicy, ... } 956 at-pskc-manufacturer ATTRIBUTE ::= { 957 TYPE UTF8String IDENTIFIED BY id-pskc-manufacturer } 959 id-pskc-manufacturer OBJECT IDENTIFIER ::= { TBD } 961 at-pskc-serialNo ATTRIBUTE ::= { 962 TYPE UTF8String IDENTIFIED BY id-pskc-serialNo } 964 id-pskc-serialNo OBJECT IDENTIFIER ::= { TBD } 966 at-pskc-model ATTRIBUTE ::= { 967 TYPE UTF8String IDENTIFIED BY id-pskc-model } 969 id-pskc-model OBJECT IDENTIFIER ::= { TBD } 971 at-pskc-issueNo ATTRIBUTE ::= { 972 TYPE UTF8String IDENTIFIED BY id-pskc-issueNo } 974 id-pskc-issueNo OBJECT IDENTIFIER ::= { TBD } 976 at-pskc-deviceBinding ATTRIBUTE ::= { 977 TYPE UTF8String IDENTIFIED BY id-pskc-deviceBinding } 979 id-pskc-deviceBinding OBJECT IDENTIFIER ::= { TBD } 981 at-pskc-startDate ATTRIBUTE ::= { 982 TYPE GeneralizedTime IDENTIFIED BY id-pskc-startDate } 984 id-pskc-startDate OBJECT IDENTIFIER ::= { TBD } 986 at-pskc-expiryDate ATTRIBUTE ::= { 987 TYPE GeneralizedTime IDENTIFIED BY id-pskc-expiryDate } 989 id-pskc-expiryDate OBJECT IDENTIFIER ::= { TBD } 991 at-pskc-id ATTRIBUTE ::= { 992 TYPE UTF8String IDENTIFIED BY id-pskc-id } 994 id-pskc-id OBJECT IDENTIFIER ::= { TBD } 996 at-pskc-algorithm ATTRIBUTE ::= { 997 TYPE UTF8String IDENTIFIED BY id-pskc-algorithm } 999 id-pskc-algorithm OBJECT IDENTIFIER ::= { TBD } 1001 at-pskc-issuer ATTRIBUTE ::= { 1002 TYPE UTF8String IDENTIFIED BY id-pskc-issuer } 1004 id-pskc-issuer OBJECT IDENTIFIER ::= { TBD } 1006 at-pskc-keyProfileId ATTRIBUTE ::= { 1007 TYPE UTF8String IDENTIFIED BY id-pskc-keyProfileId } 1009 id-pskc-keyProfileId OBJECT IDENTIFIER ::= { TBD } 1011 at-pskc-friendlyName ATTRIBUTE ::= { 1012 TYPE UTF8String IDENTIFIED BY id-pskc-friendlyName } 1014 id-pskc-friendlyName OBJECT IDENTIFIER ::= { TBD } 1016 at-pskc-algorithmParameters ATTRIBUTE ::= { 1017 TYPE PSKCAlgorithmParameters 1018 IDENTIFIED BY id-pskc-algorithmParameters } 1020 id-pskc-algorithmParameters OBJECT IDENTIFIER ::= { TBD } 1021 PSKCAlgorithmParameters ::= CHOICE { 1022 challengeFormat [0] ChallengeFormat, 1023 responseFormat [1] ResponseFormat, 1024 ... } 1026 ChallengeFormat ::= SEQUENCE { 1027 encoding Encoding, 1028 checkDigit BOOLEAN OPTIONAL, 1029 min INTEGER, 1030 max INTEGER, 1031 ... } 1033 Encoding ::= CHOICE { 1034 decimal [0] UTF8String ("DECIMAL"), 1035 hexidecimal [1] UTF8String ("HEXIDECIMAL"), 1036 alphanumeric [2] UTF8String ("ALPHANUMERIC"), 1037 base64 [3] UTF8String ("BASE64"), 1038 binary [4] UTF8String ("BINARY") } 1040 ResponseFormat ::= SEQUENCE { 1041 encoding Encoding, 1042 length INTEGER, 1043 checkDigit BOOLEAN OPTIONAL, 1044 ... } 1046 at-pskc-counter ATTRIBUTE ::= { 1047 TYPE INTEGER IDENTIFIED BY id-pskc-counter } 1049 id-pskc-counter OBJECT IDENTIFIER ::= { TBD } 1051 at-pskc-time ATTRIBUTE ::= { 1052 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1054 id-pskc-time OBJECT IDENTIFIER ::= { TBD } 1056 at-pskc-timeInterval ATTRIBUTE ::= { 1057 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1059 id-pskc-timeInterval OBJECT IDENTIFIER ::= { TBD } 1061 at-pskc-timeDrift ATTRIBUTE ::= { 1062 TYPE BinaryTime IDENTIFIED BY id-pskc-time } 1064 id-pskc-timeDrift OBJECT IDENTIFIER ::= { TBD } 1066 at-pskc-valueMAC ATTRIBUTE ::= { 1067 TYPE ValueMac IDENTIFIED BY id-pskc-valueMAC } 1069 id-pskc-valueMAC OBJECT IDENTIFIER ::= { TBD } 1071 ValueMac ::= SEQUENCE { 1072 macAlgorithm UTF8String, 1073 mac UTF8String } 1075 at-pskc-numberOfTransactions ATTRIBUTE ::= { 1076 TYPE INTEGER IDENTIFIED BY id-pskc-numberOfTransactions } 1078 id-pskc-numberOfTransactions OBJECT IDENTIFIER ::= { TBD } 1080 at-pskc-keyUsage ATTRIBUTE ::= { 1081 TYPE PSKCKeyUsages IDENTIFIED BY id-pskc-keyUsages } 1083 id-pskc-keyUsages OBJECT IDENTIFIER ::= { TBD } 1085 PSKCKeyUsages ::= SEQUENCE OF PSKCKeyUsage 1087 PSKCKeyUsage ::= CHOICE { 1088 otp [0] UTF8String ("OTP"), 1089 cr [1] UTF8String ("CR"), 1090 encrypt [2] UTF8String ("Encrypt"), 1091 integrity [3] UTF8String ("Integrity"), 1092 verify [4] UTF8String ("Verify"), 1093 unlock [5] UTF8String ("Unlock"), 1094 decrypt [6] UTF8String ("Decrypt"), 1095 keyWrap [7] UTF8String ("KeyWrap"), 1096 unwrap [8] UTF8String ("Unwrap"), 1097 derive [9] UTF8String ("Derive"), 1098 generate [10] UTF8String ("Generate") } 1100 at-pskc-pinPolicy ATTRIBUTE ::= { 1101 TYPE PINPolicy IDENTIFIED BY id-pskc-pinPolicy } 1103 id-pskc-pinPolicy OBJECT IDENTIFIER ::= { TBD } 1105 PINPolicy ::= SEQUENCE { 1106 pinKeyId [0] UTF8String OPTIONAL, 1107 pinUsageMode [1] PINUsageMode, 1108 maxFailedAttempts [2] INTEGER OPTIONAL, 1109 minLength [3] INTEGER OPTIONAL, 1110 maxLength [4] INTEGER OPTIONAL, 1111 pinEncoding [4] Encoding OPTIONAL } 1113 PINUsageMode ::= CHOICE { 1114 local [0] UTF8String ("Local"), 1115 prepend [1] UTF8String ("Prepend"), 1116 append [2] UTF8String ("Append"), 1117 algorithmic [3] UTF8String ("Algorithmic") } 1119 END 1121 Authors' Address 1123 Sean Turner 1124 IECA, Inc. 1125 3057 Nutley Street, Suite 106 1126 Fairfax, VA 22031 1127 USA 1129 Email: turners@ieca.com 1131 Russ Housley 1132 Vigil Security, LLC 1133 918 Spring Knoll Drive 1134 Herndon, VA 20170 1135 USA 1137 EMail: housley@vigilsec.com