Key Management Interoperability Protocol

1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
Key Management Interoperability Protocol Usage Guide Version 1.1

Committee Note 01 27 July 2012
Specification URIs
This version: http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.doc !uthoritative" http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.html http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.pd# Previous version: http://$$$.oasis-open.org/committees/do$nload.php/%%&&'/kmip-ugv1.1-cnprd01.(ip Latest version: http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1.doc !uthoritative" http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1.html http://docs.oasis-open.org/kmip/ug/v1.1/kmip-ug-v1.1.pd# Technical Committee: )!*+* ,ey -anagement +nteropera.ility /rotocol ,-+/" 0C Chairs: 1o.ert 2ri##in ro.ert.gri##in3rsa.com"4 5-C Corporation *u.hash *ankuratripati *u.hash.*ankuratripati3netapp.com"4 Net!pp Editors: +ndra 6it(gerald indra.#it(gerald3hp.com"4 7/ 1o.ert 2ri##in ro.ert.gri##in3rsa.com"4 5-C Corporation Related work: 0his document replaces or supersedes: Key Management Interoperability Protocol Usage Guide Version 1.0. )!*+* Committee *peci#ication 01. 18 June 2010. http://docs.oasis-open.org/kmip/ug/v1.0/cs01/kmip-ug-1.0-cs01.html.
4 35 36 37 38 39 40 41
0his is a Non-*tandards 0rack ;ork /roduct. 0he patent provisions o# the )!*+* +/1 /olicy do not apply.
0his document is related to: Key Management Interoperability Protocol Specification Version 1.1 . <atest version. http://docs.oasis-open.org/kmip/spec/v1.1/kmip-spec-v1.1.html Key Management Interoperability Protocol Profiles Version 1.1 . <atest version. http://docs.oasis-open.org/kmip/pro#iles/v1.1/kmip-pro#iles-v1.1.html
42 Key Management Interoperability Protocol Test ases Version 1.1 . <atest 43 version. 44 http://docs.oasis-open.org/kmip/testcases/v1.1/kmip-testcases-v1.1.html 45A stract: 460his document is intended to complement the ,ey -anagement +nteropera.ility 47/rotocol *peci#ication .y providing guidance on ho$ to implement the ,ey 48-anagement +nteropera.ility /rotocol ,-+/" most e##ectively to ensure 49interopera.ility. 50,-+/ =1.1 enhances the ,-+/ =1.0 standard esta.lished in )cto.er 2010" .y 51 1" de#ining ne$ #unctionality in the protocol to improve interopera.ility4 such 52 as a >iscover =ersions operation and a 2roup o.?ect@ 53 2" de#ining additional 0est Cases #or veri#ying and validating the ne$ 54 #unctionality@ 55 '" providing additional in#ormation in the ,-+/ Asage 2uide to assist in 56 e##ective implementation o# ,-+/ in key management clients and servers@ 57 and 58 %" de#ining ne$ pro#iles #or esta.lishing ,-+/-compliant implementations. 590he ,ey -anagement +nteropera.ility /rotocol ,-+/" is a single4 60comprehensive protocol #or communication .et$een clients that reBuest any o# a 61$ide range o# encryption keys and servers that store and manage those keys. Cy 62replacing redundant4 incompati.le key management protocols4 ,-+/ provides 63.etter data security $hile at the same time reducing eDpenditures on multiple 64products. 65Status: 660his document $as last revised or approved .y the )!*+* ,ey -anagement 67+nteropera.ility /rotocol ,-+/" 0C on the a.ove date. 0he level o# approval is also 68listed a.ove. Check the E<atest versionF location noted a.ove #or possi.le later revisions 69o# this document. 70 0echnical Committee mem.ers should send comments on this document to 71 the 0echnical CommitteeGs email list. )thers should send comments to the 72 0echnical Committee .y using the E*end ! CommentF .utton on the 73 0echnical CommitteeGs $e. page at http://$$$.oasis74 open.org/committees/kmip/. 75Citation format: 76;hen re#erencing this document the #ollo$ing citation #ormat should .e used:
5kmip-ug-v1.1-cn01 6Non-*tandards 0rack 7
27 July 2012 Copyright H )!*+* )pen 2012. !ll 1ights 1eserved. /age 2 o# I%
90ype the document title:
77!"#IP$U%& 78Key Management Interoperability Protocol Usage Guide Version 1.1. 27 July 792012. )!*+* Committee Note 01. 80http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.html . 81
27 July 2012 Copyright H )!*+* )pen 2012. !ll 1ights 1eserved. /age ' o# I%
14
13
82Copyright H )!*+* )pen 2012. !ll 1ights 1eserved. 83!ll capitali(ed terms in the #ollo$ing teDt have the meanings assigned to them in 84the )!*+* +ntellectual /roperty 1ights /olicy the J)!*+* +/1 /olicyJ". 0he #ull 85/olicy may .e #ound at the )!*+* $e.site. 860his document and translations o# it may .e copied and #urnished to others4 and 87derivative $orks that comment on or other$ise eDplain it or assist in its 88implementation may .e prepared4 copied4 pu.lished4 and distri.uted4 in $hole or 89in part4 $ithout restriction o# any kind4 provided that the a.ove copyright notice 90and this section are included on all such copies and derivative $orks. 7o$ever4 91this document itsel# may not .e modi#ied in any $ay4 including .y removing the 92copyright notice or re#erences to )!*+*4 eDcept as needed #or the purpose o# 93developing any document or delivera.le produced .y an )!*+* 0echnical 94Committee in $hich case the rules applica.le to copyrights4 as set #orth in the 95)!*+* +/1 /olicy4 must .e #ollo$ed" or as reBuired to translate it into languages 96other than 5nglish.
970he limited permissions granted a.ove are perpetual and $ill not .e revoked .y 98)!*+* or its successors or assigns. 990his document and the in#ormation contained herein is provided on an J!* +*J 100.asis and )!*+* >+*C<!+-* !<< ;!11!N0+5*4 5K/15** )1 +-/<+5>4 101+NC<A>+N2 CA0 N)0 <+-+05> 0) !NL ;!11!N0L 07!0 075 A*5 )6 075 102+N6)1-!0+)N 7515+N ;+<< N)0 +N61+N25 !NL );N51*7+/ 1+270* )1 103!NL +-/<+5> ;!11!N0+5* )6 -51C7!N0!C+<+0L )1 6+0N5** 6)1 ! 104/!10+CA<!1 /A1/)*5.
27 July 2012 Copyright H )!*+* )pen 2012. !ll 1ights 1eserved. /age % o# I%
19
18
105Table
of Contents
1061 +ntroduction................................................................................................................. & 107 1.1 0erminology...........................................................................................................& 108 1.2 6or a list o# terminologies re#er to 9,-+/-*pec:. Normative 1e#erences.................& 109 1.' Non-normative 1e#erences..................................................................................1% 1102 !ssumptions ............................................................................................................. 18 111 2.1 +sland o# 0rust......................................................................................................18 112 2.2 -essage *ecurity................................................................................................18 113 2.' *tate-less *erver.................................................................................................18 114 2.% 5Dtensi.le /rotocol..............................................................................................18
115 2.8 *erver /olicy........................................................................................................18 116 2.I *upport #or Cryptographic ).?ects.......................................................................18 117 2.7 Client-*erver -essage-.ased -odel...................................................................1I 118 2.& *ynchronous and !synchronous -essages........................................................1I 119 2.M *upport #or E+ntelligent ClientsF and E,ey Asing >evicesE.....................................1I 120 2.10 Catched 1eBuests and 1esponses....................................................................1I 121 2.11 1elia.le -essage >elivery.................................................................................17 122 2.12 <arge 1esponses...............................................................................................17 123 2.1' ,ey <i#e-cycle and ,ey *tate.............................................................................17 124' Asage 2uidelines......................................................................................................1& 125 '.1 !uthentication......................................................................................................1& 126
'.1.1 Credential.....................................................................................................1&
127 '.2 !uthori(ation #or 1evoke4 1ecover4 >estroy and !rchive )perations..................21 128 '.' Asing Noti#y and /ut )perations..........................................................................21 129 '.% Asage !llocation..................................................................................................22 130 '.8 ,ey *tate and 0imes............................................................................................22 131 '.I 0emplate.............................................................................................................. 2% 132
'.I.1 0emplate Asage 5Damples...........................................................................28
24
23
133 '.7 !rchive )perations..............................................................................................2I 134 '.& -essage 5Dtensions............................................................................................2I 135 '.M AniBue +denti#iers.................................................................................................2I 136 '.10 1esult -essage 0eDt.........................................................................................2I 137 '.11 Nuery................................................................................................................. 2I 138 '.12 Canceling !synchronous )perations.................................................................2I 139 '.1' -ulti-instance 7ash...........................................................................................27 140 '.1% 1eturning 1elated ).?ects.................................................................................27 141 '.18 1educing -ultiple 1eBuests through the Ase o# Catch......................................27 142 '.1I -aDimum -essage *i(e....................................................................................27 143 '.17 Asing )##set in 1e-key and 1e-certi#y )perations..............................................2& 144 '.1& <ocate Nueries...................................................................................................2&
145 '.1M +> /laceholder...................................................................................................'0 146 '.20 ,ey Clock........................................................................................................... '1 147 '.21 Asing ;rapped ,eys $ith ,-+/........................................................................'2 148 149 150 151 152 153 154 155 156 157
'.21.1 5ncrypt-only 5Dample $ith a *ymmetric ,ey as an 5ncryption ,ey #or a 2et 1eBuest and 1esponse...........................................................................................'2 '.21.2 5ncrypt-only 5Dample $ith a *ymmetric ,ey as an 5ncryption ,ey #or a 1egister 1eBuest and 1esponse.............................................................................'' '.21.' 5ncrypt-only 5Dample $ith an !symmetric ,ey as an 5ncryption ,ey #or a 2et 1eBuest and 1esponse....................................................................................'% '.21.% -!C-only 5Dample $ith an 7-!C ,ey as an !uthentication ,ey #or a 2et 1eBuest and 1esponse...........................................................................................'8 '.21.8 1egistering a ;rapped ,ey as an )paBue Cryptographic ).?ect..............'8 '.21.I 5ncoding )ption #or ;rapped ,eys............................................................'I
158 '.22 ).?ect 2roup......................................................................................................'7 159 '.2' Certi#y and 1e-certi#y.........................................................................................'& 160 '.2% *peci#ying !ttri.utes during a Create ,ey /air or 1e-key ,ey /air )peration...'M 161
'.2%.1 5Dample o# *peci#ying !ttri.utes during the Create ,ey /air )peration.....'M
162 '.28 1egistering a ,ey /air.......................................................................................%0 163 '.2I Non-Cryptographic ).?ects................................................................................%1

27 July 2012 Copyright H )!*+* )pen 2012. !ll 1ights 1eserved. /age I o# I%
29
28
164 '.27 !symmetric Concepts $ith *ymmetric ,eys......................................................%2 165 '.2& !pplication *peci#ic +n#ormation.........................................................................%' 166 '.2M -utating !ttri.utes.............................................................................................%% 167 '.'0 +nteropera.le ,ey Naming #or 0ape...................................................................%8 168
'.'0.1 Native 0ape 5ncryption .y a ,-+/ Client...................................................%8
169 '.'1 1evocation 1eason Codes................................................................................%M 170 '.'2 Certi#icate 1ene$al4 Apdate4 and 1e-key..........................................................80 171 '.'' ,ey 5ncoding.....................................................................................................80 172 173
'.''.1 !5* ,ey 5ncoding.....................................................................................80 '.''.2 0riple->5* ,ey 5ncoding...........................................................................80
174 '.'% Asing the *ame !symmetric ,ey /air in -ultiple !lgorithms.............................81 175 '.'8 Cryptographic <ength o# !symmetric ,eys........................................................81
176 '.'I >iscover =ersions..............................................................................................82 177 '.'7 =endor 5Dtensions.............................................................................................82 178 179
'.'7.1 Nuery 5Dtension +n#ormation......................................................................8' '.'7.2 1egistering 5Dtension +n#ormation..............................................................8'
180 '.'& Certi#icate !ttri.ute 1elated 6ields.....................................................................8% 181 '.'M Certi#icate 1evocation <ists................................................................................88 182 '.%0 Asing the E1a$F ,ey 6ormat 0ype.....................................................................88 183 '.%1 >eprecated 6unctionality...................................................................................88 184% >e#erred ,-+/ 6unctionality......................................................................................8I 1858 +mplementation Con#ormance...................................................................................8& 186!ppendiD !. !ckno$ledgements..................................................................................8M 187!ppendiD C. !cronyms ................................................................................................I2 188!ppendiD C. 1evision 7istory.......................................................................................I% 189
33
1901
Introduction
1910his ,ey -anagement +nteropera.ility /rotocol Asage 2uide =ersion 1.1 is intended to 192complement the ,ey -anagement +nteropera.ility /rotocol *peci#ication !"#IP$Spec& 193.y providing guidance on ho$ to implement the ,ey -anagement +nteropera.ility 194/rotocol ,-+/" most e##ectively to ensure interopera.ility. +n particular4 it includes the 195#ollo$ing guidance: 196
197
Clarification of assumptions and requirements that drive or influence the design of KMIP and the implementation of KMIP-compliant key management. Specific recommendations for implementation of particular KMIP functionality. Clarification of mandatory and optional capabilities for conformant implementations. unctionality considered for inclusion in KMIP !"."# but deferred to subsequent versions of the standard.
198 199 200

201
202! selected set o# con#ormance pro#iles and authentication suites are de#ined in the ,-+/ 203/ro#iles speci#ication !"#IP$Prof&'6urther assistance #or implementing ,-+/ is provided 204.y the ,-+/ 0est Cases #or /roo# o# Concept 0esting document 9,-+/-0C: that 205descri.es a set o# recommended test cases and provides the 00<= 206 0ag/0ype/<ength/=alue" #ormat #or the message eDchanges de#ined .y those test 207cases. 2081.1 Terminology 2091.2 or a list of terminologies refer to [KMIP-Spec]. !ormati"e #eferences
210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229
[FIPS186-3] Digital Signature Standard (DSS), FIPS PUB 186-3, June 2009, http$%%csrc.nist.gov%publications%fips%fips"&'-(%fips)"&'-(.pdf [FIPS197] Advanced Encryption Standard (AES), FIPS PUB 197, November 26, 2001, http$%%csrc.nist.gov%publications%fips%fips"*+%fips-"*+.pdf [FIPS198-1] The Keyed-Hash Message Authentication Code (HMAC) , FIPS PUB 198-1, July 2008, http$%%csrc.nist.gov%publications%fips%fips"*&-"% IPS-"*&-")final.pdf [I 1003-1]
I,,, Std "--(."# Standard for information technology - portable operating system interface (POSIX). Shell and utilities, 200!"
34
35
230 231 232 233 234 235 236 237 238 239 240
[IS#16609] IS.# Banking -- e!uirements for message authentication using symmetric techni!ues, IS# 16609, 1991" [IS#9797-1] IS.%I,C# Information technology -- Security techni!ues -- "essage #uthentication $odes ("#$s) -- Part %& "echanisms using a block cipher, IS#$I % 9797-1, 1999"
241 242 243 244 245

246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277
!"#IP$Spec& Key Management Interoperability Protocol Specification Version 1.1.;orking >ra#t 07. 27 !pril 2012. http://$$$.oasisopen.org/apps/org/$orkgroup/kmip/do$nload.php/%87'1/kmipspec-v1.1-$d0I.doc
[&'IP-Pro(] Key Management nteropera!ility "rotocol "ro#iles $ersion %&%. /orking 0raft "". 1' 2pril 1-"1. http$%%333.oasisopen.org%apps%org%3orkgroup%kmip%do3nload.php%45&54%kmip-profilesv"."-3d"".doc6 [P&%S)1] 7S2 8aboratories# "KCS '% v(&%) *SA Cryptography Standard# 9une "4# 1--1# http$%%333.rsa.com%rsalabs%node.asp:id;1"15 [P&%S)*] 7S2 8aboratories# "KCS '+ v(&%) "ass,ord--ased Cryptography Standard # .ctober 5# 1--'# http$%%333.rsa.com%rsalabs%node.asp:id;1"1+ [P&%S)7] 7S2 8aboratories# "KCS'. v%&+) Cryptographic Message Synta/ Standard& 0ovem!er %1 %2231 http$%%333.rsa.com%rsalabs%node.asp:id;1"1* [P&%S)8] 7S2 8aboratories# PKCS<& v".1$ Private-Key Information Synta6 Standard# =ovember "# "**(# http$%%333.rsa.com%rsalabs%node.asp:id;1"([P&%S)10] 7S2 8aboratories# "KCS '%4 v%&.) Certi#ication *e5uest Synta/ Standard # May 1'# 1---# http$%%333.rsa.com%rsalabs%node.asp:id;1"(1
36
37
278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326
[+F%1319] >. Kaliski# 'he "() "essage-(igest #lgorithm, I ,F +F% 1319, -.r 1992, http$%%333.ietf.org%rfc%rfc"("*.t6t [+F%1320] 7. 7ivest# 'he "(* "essage-(igest #lgorithm, I ,F +F% 1320, -.r 1992, http$%%333.ietf.org%rfc%rfc"(1-.t6t [+F%1321] 7. 7ivest# 'he "(+ "essage-(igest #lgorithm, I ,F +F% 1321, -.r 1992, http$%%333.ietf.org%rfc%rfc"(1".t6t [+F%1!21] 9. 8inn# Pri,acy -nhancement for Internet -lectronic "ail& "art ) Message Encryption and Authentication "rocedures. I ,F +F% 1!21, Feb 1993, http$%%333.ietf.org%rfc%rfc"41".t6t [+F%1!2!] >. Kaliski# "rivacy Enhancement #or nternet Electronic Mail) "art $) Key Certi#ication and *elated Services# I,? 7 C "414# ebruary "**(# http$%%333.ietf.org%rfc%rfc"414.t6t [+F%210!] @. Kra3cAyk# M. >ellare# 7. Canetti# /"#$& 0eyed-/ashing for "essage #uthentication, I ,F +F% 210!, Feb 1997, http$%%333.ietf.org%rfc%rfc1"-4.t6t [+F%2119] S. >radner# Key ,ords #or use in *6Cs to ndicate *e5uirement 7evels # http$%%333.ietf.org%rfc%rfc1""*.t6t# I,? 7 C 1""*# March "**+. B7 C115(C M. /ahl# S. Kille# ?. @o3es# 8ight3eight 0irectory 2ccess Protocol Dv(E$ F? -& String 7epresentation of 0istinguished =ames# I,? 7 C 115(# 0ec "**+# http$%%333.ietf.org%rfc%rfc115(.t6t [+F%2898] >. Kaliski# P0$S 1+& Pass2ord-Based $ryptography Specification 3ersion ).4 , I ,F +F% 2898, Se. 2000, http$%%333.ietf.org%rfc%rfc1&*&.t6t
38
39
327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375
[+F%339!] 9. Schaad# 7. @ousley# #d,anced -ncryption Standard (#-S) 0ey 5rap #lgorithm , I ,F +F% 339!, Se. 2002, http$%%333.ietf.org%rfc%rfc((*4.t6t [+F%3!!7] 9. 9onsson# >. Kaliski# Public-0ey $ryptography Standards (P0$S) 1%& S# $ryptography Specifications 3ersion ).%, I ,F +F% 3!!7 Feb 2003, http$%%333.ietf.org%rfc%rfc(44+.t6t [+F%3629] . Gergeau# 6'7-8. a transformation format of ISO %49*9, I ,F +F% 3629, Nov 2003, http$%%333.ietf.org%rfc%rfc('1*.t6t [+F%36!7] S. Chokhani# /. ord# 7. Sabett# C. Merrill# and S. /u# *6C389.) nternet :&+42 "u!lic Key n#rastructure Certi#icate "olicy and Certi#ication "ractices 6rame,or; # =ovember 1--(# http$%%333.ietf.org%rfc%rfc('4+.t6t [+F%!210] C. 2dams# S. arrell# ?. Kause and ?. Mononen# *6C(+%4) nternet :&+42 "u!lic Key n#rastructure Certi#icate Management "rotocol (CM") # September 1--5# http$%%333.ietf.org%rfc%rfc41"-.t6t [+F%!211] 9. Schaad# *6C 9(%%) nternet :&+42 "u!lic Key n#rastructure Certi#icate *e5uest Message 6ormat (C*M6)# September 1--5# http$%%333.ietf.org%rfc%rfc41"".t6t [+F%!868] S. Kelly# S. rankel# 6sing /"#$-S/#-)+9. /"#$-S/#-:8*. and /"#$-S/#-+%) 2ith IPsec, I ,F +F% !868, '/y 2007, http$%%333.ietf.org%rfc%rfc4&'&.t6t [+F%!880] 9. Callas# 8. 0onnerhacke# @. inney# 0. Sha3# and 7. ?hayer# OpenP;P "essage 7ormat, I ,F +F% !880, Nov 2007, http$%%333.ietf.org%rfc%rfc4&&-.t6t [+F%!9!9] 7. Shirey# *6C9292) nternet Security <lossary1 $ersion (# 2ugust 1--+# http$%%333.ietf.org%rfc%rfc4*4*.t6t [+F%*272]
40
41
376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425
9. Schaad and M. Meyers# *6C+(.() Certi#icate Management over CMS (CMC) # 9une 1--&# http$%%333.ietf.org%rfc%rfc51+1.t6t [+F%*280] 0. Cooper# S. Santesson# S. arrell# S. >oeyen# 7. @ousley and /. Polk# *6C +(=4) nternet :&+42 "u!lic Key n#rastructure Certi#icate and Certi#icate *evocation 7ist (C*7) "ro#ile# May 1--&# http$%%333.ietf.org%rfc%rfc51&-.t6t [+F%*6!9] 7. @ousley# #d,anced -ncryption Standard (#-S) 0ey 5rap 2ith Padding #lgorithm , I ,F +F% *6!9, -u0 2009, http$%%333.ietf.org%rfc%rfc5'4*.t6t [SP800-38-] M. 03orkin# ecommendation for Block $ipher "odes of Operation < "ethods and 'echni!ues, NIS, S.e12/l Publ21/32on 800-38-, 4e1 2001, http$%%csrc.nist.gov%publications%nistpubs%&---(&a%sp&---(&a.pdf
[SP800-38B] M. 03orkin# ecommendation for Block $ipher "odes of Operation& 'he $"#$ "ode for #uthentication, NIS, S.e12/l Publ21/32on 800-38B, '/y 200*, http$%%csrc.nist.gov%publications%nistpubs%&---(&>%SP)&---(&>.pdf
[SP800-38%] M. 03orkin# ecommendation for Block $ipher "odes of Operation& the $$" "ode for #uthentication and $onfidentiality, NIS, S.e12/l Publ21/32on 80038%, '/y 200!, http$%%csrc.nist.gov%publications%nistpubs%&--(&C%SP&---(&C)updated-9uly1-)1--+.pdf
[SP800-384] M. 03orkin# ecommendation for Block $ipher "odes of Operation& ;alois=$ounter "ode (;$") and ;"#$, NIS, S.e12/l Publ21/32on 800-384, Nov 2007, http$%%csrc.nist.gov%publications%nistpubs%&---(&0%SP-&---(&0.pdf
[SP800-38 ] M. 03orkin# ecommendation for Block $ipher "odes of Operation& 'he X'S-#-S "ode for $onfidentiality on Block-Oriented Storage (e,ices , NIS, S.e12/l Publ21/32on 800-38 , J/n 2010, http$%%csrc.nist.gov%publications%nistpubs%&---(&,%nist-sp-&---(&,.pdf
[SP800-*6-] ,. >arker# 0. 9ohnson# and M. Smid, ecommendation for Pair-5ise 0ey -stablishment Schemes 6sing (iscrete >ogarithm $ryptography ( e,ised) , NIS,
42
43
426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475
S.e12/l Publ21/32on 800-*6-, '/r15 2007, http$%%csrc.nist.gov%publications%nistpubs%&---5'2%SP&--5'2)7evision")Mar-&-1--+.pdf [SP800-*6B] ,. >arker# 8. Chen# 2. 7egenscheid# M. Smid# ecommendation for Pair-5ise 0ey -stablishment Schemes 6sing Integer 7actori?ation $ryptography , NIS, S.e12/l Publ21/32on 800-*6B, -u0u63 2009, http$%%csrc.nist.gov%publications%nistpubs%&---5'>%sp&---5'>.pdf [SP800-*7-1] ,. >arker# /. >arker# /. Burr, 7" Pol8, /n9 '" Sm29, ecommendations for 0ey "anagement - Part %& ;eneral ( e,ised). NIS, S.e12/l Publ21/32on 800-*7 ./r3 1, '/r15 2007, http$%%csrc.nist.gov%publications%nistpubs%&---5+%sp&---5+-Part"revised1)Mar-&-1--+.pdf [SP800-'+C /. >arker# ecommendation for the 'riple (ata -ncryption #lgorithm ('(-#) Block $ipher, NIS, S.e12/l Publ21/32on 800-67, :er62on 1"1, +ev26e9 19 '/y 2008, http$%%csrc.nist.gov%publications%nistpubs%&---'+%SP&---'+.pdf
[SP800-108] 8. Chen# ecommendation for 0ey (eri,ation 6sing Pseudorandom 7unctions ( e,ised), NIS, S.e12/l Publ21/32on 800-108, #13ober 2009, http$%%csrc.nist.gov%publications%nistpubs%&---"-&%sp&---"-&.pdf
[;"*09] International ?elecommunication Fnion DI?FEH?# I.5-*$ Information technology H .pen systems interconnection H ?he 0irectory$ Public-key and attribute certificate frame3orks# 2ugust 1--5# http$%%333.itu.int%rec%?-7,C-I.5-*1--5-&-I%en [;9"2!-1] 2=SI# X@.)*& etail 7inancial Ser,ices Symmetric 0ey "anagement - Part %& 6sing Symmetric 'echni!ues, 200!" [;9"31] 2=SI# X@.:%& (igital Signatures 6sing e,ersible Public 0ey $ryptography for the 7inancial Ser,ices Industry (r(S#), Se.3ember 1998" [;9"!2]
44
45
476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503
2=SI# X@-*)& Public 0ey $ryptography for the 7inancial Ser,ices Industry& #greement of Symmetric 0eys 6sing (iscrete >ogarithm $ryptography , 2003" [;9-*7] 2=SI# X@-+A& Public 0ey $ryptography for the 7inancial Ser,ices Industry& $ertificate "anagement, 1997" [;9"62] 2=SI# X@-9)& Public 0ey $ryptography for the 7inancial Ser,ices Industry. 'he -lliptic $ur,e (igital Signature #lgorithm (-$(S#), 200*" [;9-63] 2=SI# X@-9:& Public 0ey $ryptography for the 7inancial Ser,ices Industry. 0ey #greement and 0ey 'ransport 6sing -lliptic $ur,e $ryptography , 2001" [;9-102] 2=SI# X@-%4)& Symmetric 0ey $ryptography for the 7inancial Ser,ices Industry 5rapping of 0eys and #ssociated (ata, 2008" [;9 ,+-31] 2=SI# X@ ' -:%& Interoperable Secure 0ey -Bchange 0ey Block Specification for Symmetric #lgorithms, 200*"
5041.$ !on%normati"e #eferences

505 506 507 508 509
[&'IP-,%] Key Management nteropera!ility "rotocol Test Cases $ersion %&%& Committee =ote 0raft." 0ecember 1-"". http$%%docs.oasis-open.org%kmip%usecases%v"."%kmipusecases-v"."-cnd-".doc
510 511 512
46
47
5132
&ssumptions
5140he section descri.es assumptions that underlie the ,-+/ protocol and the 515implementation o# clients and servers that utili(e the protocol. 5162.1 Island of Trust 517Clients may .e provided key material .y the server4 .ut they only use that keying 518material #or the purposes eDplicitly listed in the delivery payload. Clients that ignore 519these instructions and use the keys in $ays not eDplicitly allo$ed .y the server are non520compliant. 0here is no reBuirement #or the key management system4 ho$ever4 to 521en#orce this .ehavior. 5222.2 Message 'ecurity 523,-+/ relies on the chosen authentication suite as speci#ied in !"#IP$Prof& to 524authenticate the client and on the underlying transport protocol to provide con#identiality4 525integrity4 message authentication and protection against replay attack. ,-+/ o##ers a 526$rapping mechanism #or the ,ey =alue that does not rely on the transport mechanism 527used #or the messages@ the $rapping mechanism is intended #or importing or eDporting 528managed cryptographic o.?ects. 5292.$ 'tate%less 'er"er 5300he protocol operates on the assumption that the server is state-less4 $hich means that 531there is no concept o# EsessionsF inherent in the protocol. 0his does not mean that the 532server itsel# maintains no state4 only that the protocol does not reBuire this. 5332.( )*tensible Protocol 5340he protocol provides #or EprivateF or vendor-speci#ic eDtensions4 $hich allo$ #or 535di##erentiation among vendor implementations. 7o$ever4 any o.?ects4 attri.utes and 536operations included in an implementation are al$ays implemented as speci#ied in 537!"#IP$Spec&( regardless o# $hether they are optional or mandatory. 5382.+ 'er"er Policy 539! server is eDpected to .e con#ormant to ,-+/ and supports the con#ormance clauses 540as speci#ied in . 7o$ever4 a server may re#use a server-supported operation or client541setta.le attri.ute i# disallo$ed .y the server policy. 5422., 'upport for Cryptograp-ic .b/ects 5430he protocol supports key management system-related cryptographic o.?ects. 0his list 544currently includes: 545 546 48

Symmetric Keys Split Dmulti-partE Keys
49 547 548 549 550 551

2symmetric Key Pairs and their components 0igital Certificates 0erived Keys Secret 0ata .paque Dnon-interpretableE cryptographic obJects
5522.0 Client%'er"er Message%based Model 5530he protocol operates primarily in a client-server4 message-.ased model. 0his means 554that most protocol eDchanges are initiated .y a client sending a reBuest message to a 555server4 $hich then sends a response to the client. 0he protocol also provides optional 556mechanisms to allo$ #or unsolicited noti#ication o# events to clients using the Noti#y 557operation4 and unsolicited delivery o# cryptographic o.?ects to clients using the /ut 558operation@ that is4 the protocol allo$s a EpushF model4 $here.y the server initiates the 559protocol eDchange $ith either a Noti#y or /ut operation. 0hese Noti#y or /ut #eatures are 560optionally supported .y servers and clients. Clients may register in order to receive such 561events/noti#ications. 1egistration is implementation-speci#ic and not descri.ed in the 562speci#ication. 5632.1 'ync-ronous and &sync-ronous Messages 5640he protocol allo$s t$o modes o# operation. *ynchronous mandatory" operations are 565those in $hich a client sends a reBuest and $aits #or a response #rom the server. /olled 566!synchronous operations optional" are those in $hich the client sends a reBuest4 the 567server responds $ith a EpendingF status4 and the client polls the server #or the completed 568response and completion status. *erver implementations may choose not to support the 569/olled !synchronous #eature o# the protocol. 5702.2 'upport for 3Intelligent Clients4 and 3Key Using 5e"ices3 5710he protocol supports intelligent clients4 such as end-user $orkstations4 $hich are 572capa.le o# reBuesting all o# the #unctions o# ,-+/. +t also allo$s su.sets o# the protocol 573and possi.le alternate message representations in order to support less-capa.le 574devices4 $hich only need a su.set o# the #eatures o# ,-+/. 5752.16 7atc-ed #e8uests and #esponses 5760he protocol contains a mechanism #or sending .atched reBuests and receiving the 577corresponding .atched responses4 to allo$ #or higher throughput on operations that deal 578$ith a large num.er o# entities4 e. g.4 reBuesting do(ens or hundreds o# keys #rom a 579server at one time4 and per#orming operations in a group. !n option is provided to 580indicate $hether to continue processing reBuests a#ter an earlier reBuest in the .atch 581#ails or to stop processing the remaining reBuests in the .atch. Note that there is no 582option to treat an entire .atch as atomic4 that is4 i# a reBuest in the .atch #ails4 then 583preceding reBuests in the .atch are not undone or rolled .ack see *ection '.18". ! 584special +> /laceholder see *ection '.1M" is provided in ,-+/ to allo$ related reBuests 585in a .atch to .e pipelined.
50
51 5862.11 #eliable Message 5eli"ery 5870he relia.le message delivery #unction is relegated to the transport protocol4 and is not 588part o# the key management protocol itsel#. 5892.12 9arge #esponses 5906or reBuests that could result in large responses4 a mechanism in the protocol allo$s a 591client to speci#y in a reBuest the maDimum allo$ed si(e o# a response or in the case o# 592the <ocate operation the maDimum num.er o# items $hich should .e returned. 0he 593server indicates in a response to such a reBuest that the response $ould have .een too 594large and4 there#ore4 is not returned. 5952.1$ Key 9ife%cycle and Key 'tate 596 descri.es the key li#e-cycle model4 .ased on the N+*0 */ &00-87 key state de#initions 597!SP)**$+,$-&4 supported .y the ,-+/ protocol. /articular implications o# the key li#e598cycle model in terms o# de#ining time-related attri.utes o# o.?ects are discussed in 599*ection '.8 .elo$.
600
52
53
601$
Usage Guidelines
6020his section provides guidance on using the #unctionality descri.ed in the ,ey 603-anagement +nteropera.ility /rotocol *peci#ication. 604$.1 &ut-entication 605!s discussed in !"#IP$Spec&4 a con#orming ,-+/ implementation esta.lishes and 606maintains channel con#identiality and integrity4 and provides assurance o# server 607authenticity #or ,-+/ messaging. Client authentication is per#ormed according to the 608chosen ,-+/ authentication suite as speci#ied in !"#IP$Prof&. )ther mechanisms #or 609client and server authentication are possi.le and optional #or ,-+/ implementations. 610,-+/ implementations that support the ,-+/-de#ined Credential 0ypes or use other 611vendor-speci#ic mechanisms #or authentication may use the optional !uthentication 612structure speci#ied inside the 1eBuest 7eader to include additional identi#ication 613in#ormation. >epending on the serverGs con#iguration4 the server may interpret the 614identity o# the reBuestor #rom the Credential structure4 contained in the !uthentication 615structure i# it is not provided during the channel-level authentication. 6or eDample4 in 616addition to per#orming mutual authentication during a 0<* handshake4 the client passes 617the Credential structure e.g.4 a username and pass$ord" in the reBuest. +# the 618reBuestorGs username is not speci#ied inside the client certi#icate and is instead speci#ied 619in the Credential structure4 the server interprets the identity o# the reBuestor #rom the 620Credential structure. 0his supports use cases $here channel-level authentication 621authenticates a machine or service that is used .y multiple users o# the ,-+/ server. +# 622the client provides the username o# the reBuestor in .oth the client certi#icate and the 623Credential structure4 the server veri#ies that the usernames are the same. +# they di##er4 624the authentication #ails and the server returns an error. +# no Credential structure is 625included in the reBuest4 the username o# the reBuestor is eDpected to .e provided inside 626the certi#icate. +# no username is provided in the client certi#icate and no Credential 627structure is included in the reBuest message4 the server is eDpected to re#use 628authentication and return an error. 629+# authentication is unsuccess#ul4 and it is possi.le to return an Eauthentication not 630success#ulF error4 this error should .e returned in pre#erence to any other result status. 6310his prevents status code pro.ing .y a client that is not a.le to authenticate. 632*erver decisions regarding $hich operations to re?ect i# there is insu##iciently strong 633authentication o# the client are not speci#ied in the protocol. 7o$ever4 see *ection '.2 #or 634operations #or $hich authentication and authori(ation are particularly important. 635$.1.1 Credential 636 de#ines the Asername and /ass$ord structure #or the Credential 0ype Asername and 637/ass$ord. 0he structure consists o# t$o #ields: Asername and /ass$ord. /ass$ord is a 638recommended4 .ut optional4 #ield4 $hich may .e eDcluded only i# the client is 639authenticated using one o# the authentication suites de#ined in !"#IP$Prof&' 6or 54
55 640eDample4 i# the client per#orms client certi#icate authentication during the 0<* 641handshake4 and the !uthentication structure is provided in the -essage 1eBuest4 the 642/ass$ord #ield is an optional #ield in the Asername and /ass$ord structure o# the 643Credential structure. 6440he Credential structure is used to provide additional identi#ication in#ormation. !s 645descri.ed a.ove4 #or certain use cases4 channel-level authentication may only 646authenticate a machine or service that is used .y multiple clients o# the ,-+/ server. 6470he Credential structure may .e used in this scenario to identi#y individual clients .y 648speci#ying the username in the Asername and /ass$ord structure. !lternatively4 the 649>evice Credential may .e used to uniBuely identi#y .ack-end devices .y speci#ying 650>evice as the Credential 0ype in the Credential structure. 6510he >evice Credential may .e used in a proDy environment $here the proDy 652authenticates $ith the client certi#icate and supports ,-+/ $hile the .ack-end devices 653may not support ,-+/ or 0<*. !n eDample is illustrated .elo$: 654
655
656. I%URE -: A %%RE%AT/R CLIE0T E 1A#PLE
6570he end device identi#ies itsel# $ith a device uniBue set o# identi#ier values that include 658the device hard$are serial num.er4 the net$ork identi#ier4 the machine identi#ier4 or the 659media identi#ier. 6or many o# the sel#-encrypting devices there is a uniBue serial num.er 660assigned to the device during manu#acturing. 0he a.ility to use net$ork4 machine4 or 661media identi#ier eDplicitly should map to di##erent device types and achieve .etter 662interopera.ility since di##erent types o# identi#ier values are eDplicitly enumerated. 0he 663device identi#ier is included #or more generic usage. !n optional pass$ord or shared 664secret may .e used to #urther authenticate the device.
56
57 665 666*erver implementations may choose to en#orce rules #or uniBueness #or di##erent types 667o# identi#ier values4 com.inations o# 0<* certi#icate used in com.ination $ith the >evice 668Credential4 and optionally en#orce the use o# a >evice Credential pass$ord. 6696our identi#iers are optionally provided .ut are uniBue in aggregate: 670 671 672 673 674 675
1. *erial Num.er4 #or eDample the hard$are serial num.er o# the device 2. Net$ork +denti#ier4 #or eDample the -!C address #or 5thernet connected devices '. -achine +denti#ier4 #or eDample the client aggregator identi#ier4 such as a tape li.rary aggregating tape drives %. -edia +denti#ier4 #or eDample the volume identi#ier used #or a tape cartridge
6760he device identi#ier .y choice o# server policy may or may not .e used in con?unction 677$ith the a.ove identi#iers to insure uniBueness. 6780hese additional identi#iers are generally use#ul #or auditing and monitoring encryption 679and could according to server policy .e logged or used in server implementation speci#ic 680validation. 681! speci#ic eDample #or sel#-encrypting tape drive and tape li.rary $ould .e: 682 683 684 685 686 687 688 689 690 691 692 694 695 696 697 698 699 700 701 702 703
1. the tape drive has a serial num.er that is uniBue #or that manu#acturer and the vendor has procedures #or maintaining and tracking serial num.er usage 2. a pass$ord optionally is created and stored either on the drive or the li.rary to help authenticate the drive '. the tape drives may .e connected via #i.re channel to the li.rary and there#ore have a ;orld ;ide Name assigned %. a machine identi#ier can .e used to identi#y the tape li.rary that is aggregating the device in Buestion 8. the media identi#ier helps identi#y the individual media such as a tape cartridge #or proo# o# encryption reporting
693!nother eDample using sel#-encrypting disk drives inside o# a server $ould .e:
1. the disk drive has a uniBue serial num.er 2. a pass$ord may .e supplied .y con#iguration o# the drive or the server $here the drive is located '. the net$ork identi#ier may come #rom the internal attachment identi#ier #or the disk drive in the server %. the machine identi#ier may come #rom a serverGs mother.oard or service processor identi#ier4 8. and the media identi#ier comes #rom the volume name used .y the serverGs operating system to identi#y the volume on the disk drive
704*erver implementations could control $hat devices may read and $rite keys and use the 705device credential #ields to in#luence access control en#orcement. 706
58
59 707!nother eDample applied to server virtuali(ation and encryption .uilt into virtuali(ation 708$ould .e: 709 710 711 712 713 714 715 716 717 718
1. the virtual machine instance has a uniBue identi#ier that is used #or the serial num.er 2. the hypervisor supplies a shared secret that is used as the pass$ord to authenticate the virtual machine '. the net$ork identi#ier could .e used to identi#y the -!C address o# the physical server $here the virtual machine is running %. the machine identi#ier could .e used to identi#y the hypervisor 8. the media identi#ier could .e used to identi#y the storage volume used .y the virtual machine
7190hese are eDamples o# usage and are not meant to de#ine all device credential usage 720patterns nor restrict server speci#ic implementations. 7210he device credentials may .e eDplicitly added .y the administrator or may .e captured 722in line $ith the reBuest and implicitly registered depending upon server policy. 723;hen a server is not a.le to resolve the identi#ier values in the device credential to a 724uniBue client identi#ication4 it may choose to re?ect the reBuest $ith an error code o# 725operation #ailed and reason code o# item not #ound. 726$.2 &ut-ori:ation for #e"o;e< #eco"er< 5estroy and &rc-i"e .perations 7270he authentication suite4 as speci#ied in 4 descri.es ho$ the client identity is esta.lished 728#or ,-+/-compliant implementations. 0his authentication is per#ormed #or all ,-+/ 729operations. 730Certain operations that may .e reBuested .y a client via ,-+/4 particularly 1evoke4 7311ecover4 >estroy and !rchive4 may have a signi#icant impact on the availa.ility o# a key4 732on server per#ormance and/or on key security. ;hen a server receives a reBuest #or one 733o# these operations4 it should ensure that the client has authenticated its identity see the 734!uthentication *uites section in !"#IP$Prof&". 0he server should also ensure that the 735client reBuesting the operation is an o.?ect o$ner4 security o##icer or other identity 736authori(ed to issue the reBuest. +t may also reBuire additional authentication to ensure 737that the o.?ect o$ner or a security o##icer has issued that reBuest. 5ven $ith such 738authentication and authori(ation4 reBuests #or these operations should .e considered 739only a EhintF to the key management system4 $hich may or may not choose to act upon 740this reBuest depending on server policy. 741$.$ Using !otify and Put .perations 7420he Noti#y and /ut operations are the only operations in the ,-+/ protocol that are 743initiated .y the server4 rather than the client. !s client-initiated reBuests are a.le to 744per#orm these #unctions e.g.4 .y polling to reBuest noti#ication"4 these operations are 745optional #or con#orming ,-+/ implementations. 7o$ever4 they provide a mechanism #or 746optimi(ed communication .et$een ,-+/ servers and clients. 747+n using Noti#y and /ut4 the #ollo$ing constraints and guidelines should .e o.served: 60
61 748
749 750 751 752
?he client enrolls 3ith the server# so that the server kno3s ho3 to locate the client to 3hich a =otify or Put is being sent and 3hich events for the =otify are supported. @o3ever# such registration is outside the scope of the KMIP protocol. 7egistration also includes a specification of 3hether a given client supports Put and =otify# and 3hat attributes may be included in a Put for a particular client. Communication bet3een the client and the server is authenticated. 2uthentication for a particular client%server implementation is at a minimum accomplished using one of the mandatory authentication mechanisms Dsee [&'IP-Pro(]E. urther strengthening of the client%server communications integrity by means of signed message content and%or 3rapped keys is recommended. 2ttribute values other than K8ast Change 0ateL should not be included in a =otify to minimiAe risk of e6posure of attribute information. In order to minimiAe possible divergence of key or state information bet3een client and server as a result of server-initiated communication# any client receiving =otify or Put messages returns ackno3ledgements of these messages to the server. ?his ackno3ledgement may be at communication layers belo3 the KMIP layer# such as by using transport-level ackno3ledgement provided in ?CP%IP. or client devices that are incapable of responding to messages from the server# communication 3ith the server happens via a pro6y entity that communicates 3ith the server# using KMIP# on behalf of the client. It is possible to secure communication bet3een a pro6y entity and the client using other# potentially proprietary mechanisms.
753
754 755 756 757 758
759
760 761 762 763
764
765 766 767
768$.( Usage &llocation 769Asage should .e allocated and handled care#ully at the client4 since po$er outages or 770other types o# client #ailures crashes" may render allocated usage lost. 6or eDample4 in 771the case o# a key .eing used #or the encryption o# tapes4 such a loss o# the usage 772allocation in#ormation #ollo$ing a client #ailure during encryption may result in the 773necessity #or the entire tape .ackup session to .e re-encrypted using a di##erent key4 i# 774the server is not a.le to allocate more usage. +t is possi.le to address this through such 775approaches as caching usage allocation in#ormation on sta.le storage at the client4 776and/or having conservative allocation policies at the server e.g.4 .y keeping the 777maDimum possi.le usage allocation per client reBuest moderate". +n general4 usage 778allocations should .e as small as possi.le@ it is pre#era.le to use multiple smaller 779allocation reBuests rather than a single larger reBuest to minimi(e the likelihood o# 780unused allocation. 781$.+ Key 'tate and Times 782 provides a num.er o# time-related attri.utes4 including the #ollo$ing: 783
784

Initial 0ate$ ?he date and time 3hen the managed cryptographic obJect 3as first created by or registered at the server 2ctivation 0ate$ ?he date and time 3hen the managed cryptographic obJect may begin to be used for applying cryptographic protection to data Process Start 0ate$ ?he date and time 3hen a managed symmetric key obJect may begin to be used for processing cryptographically protected data Protect Stop 0ate$ ?he date and time 3hen a managed symmetric key obJect may no longer be used for applying cryptographic protection to data 0eactivation 0ate$ ?he date and time 3hen the managed cryptographic obJect may no longer be used for any purpose# e6cept for decryption# signature verification# or
785
786
787
788
789
790
791
792
62
63
793 794
un3rapping# but only under e6traordinary circumstances and 3hen special permission is granted

795 796
797
0estroy 0ate$ ?he date and time 3hen the managed cryptographic obJect 3as destroyed Compromise .ccurrence 0ate$ ?he date and time 3hen the managed cryptographic obJect 3as first believed to be compromised Compromise 0ate$ ?he date and time 3hen the managed cryptographic obJect is entered into the compromised state 2rchive 0ate$ ?he date and time 3hen the managed obJect 3as placed in .ff-8ine storage
798
799
800
801
8020hese attri.utes apply to all cryptographic o.?ects symmetric keys4 asymmetric keys4 803etc" $ith eDceptions as noted in !"#IP$Spec&. 7o$ever4 certain o# these attri.utes such 804as the +nitial >ate" are not speci#ied .y the client and are implicitly set .y the server. 805+n using these attri.utes4 the #ollo$ing guidelines should .e o.served: 806
807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823
2s discussed for each of these attributes in [&'IP-S.e1], a number of these times are set once and it is not possible for the client or server to modify them. @o3ever# several of the time attributes Dparticularly the 2ctivation 0ate# Protect Start 0ate# Process Stop 0ate and 0eactivation 0ateE may be set by the server and%or requested by the client. Coordination of time-related attributes bet3een client and server# therefore# is primarily the responsibility of the server# as it manages the cryptographic obJect and its state. @o3ever# special conditions related to time-related attributes# governing 3hen the server accepts client modifications to time-related attributes# may be communicated out-of-band bet3een the client and server outside the scope of KMIP. In general# state transitions occur as a result of operational requests# such as Create# Create Key Pair# 7egister# 2ctivate# 7evoke# and 0estroy. @o3ever# clients may need to specify times in the future for such things as 2ctivation 0ate# 0eactivation 0ate# Process Start 0ate# and Protect Stop 0ate. KMIP allo3s clients to specify times in the past for such attributes as 2ctivation 0ate and 0eactivation 0ate. ?his is intended primarily for clients that 3ere disconnected from the server at the time that the client performed that operation on a given key.
824
825 826 827
It is valid to have a proJected 0eactivation 0ate 3hen there is no 2ctivation 0ate. ?his means# ho3ever# that the key is not yet active# even though its proJected 0eactivation 0ate has been specified. 2 valid 0eactivation 0ate is greater than or equal to the 2ctivation 0ate Dif the 2ctivation 0ate has been setE. ?he Protect Stop 0ate may be equal to# but may not be later than the 0eactivation 0ate. Similarly# the Process Start 0ate may be equal to# but may not precede# the 2ctivation 0ate. KMIP implementations should consider specifying both these attributes# particularly for symmetric keys# as a key may be needed for processing protected data De.g.# decryptionE long after it is no longer appropriate to use it for applying cryptographic protection to data De.g.# encryptionE. KMIP does not allo3 an 2ctive obJect to be destroyed 3ith the 0estroy operation. ?he server returns an error# if the client invokes the 0estroy operation on an 2ctive obJect. ?o destroy an 2ctive obJect# clients first call the 7evoke operation or e6plicitly set the 0eactivation 0ate of the obJect. .nce the obJect is in 0eactivated state# clients may destroy the obJect by calling the 0estroy operation. ?hese operations may be performed in a batch. If other time-related attributes De.g.# Protect Stop 0ateE are set to a future date# the server should set these to the 0eactivation 0ate. 2fter a cryptographic obJect is destroyed# a key management server may retain certain information about the obJect# such as the Fnique Identifier.
828
829 830 831 832 833
834
835 836 837 838 839 840
841
842
64
65 843,-+/ allo$s the speci#ication o# attri.utes on a per-client .asis4 such that a server could 844maintain or present di##erent sets o# attri.utes #or di##erent clients. 0his #leDi.ility may .e 845necessary in some cases4 such as $hen a server maintains the availa.ility o# a given 846key #or some clients4 even a#ter that same key is moved to an inactive state e.g.4 847>eactivated state" #or other clients. 7o$ever4 such an approach might result in 848signi#icant inconsistencies regarding the o.?ect state #rom the point o# vie$ o# all 849participating clients and should4 there#ore4 .e avoided. ! server should maintain a 850consistent state #or each o.?ect4 across all clients that have or are a.le to reBuest that 851o.?ect. 852$., Template 8530he usage o# templates is an alternative approach #or setting attri.utes in an operation 854reBuest. +nstead o# individually speci#ying each attri.ute4 a template may .e used to set 855any o# the #ollo$ing attri.utes #or a managed o.?ect: 856 Cryptographic 2lgorithm 857 Cryptographic 8ength 858 Cryptographic 0omain Parameters 859 Cryptographic Parameters 860 .peration Policy =ame 861 Cryptographic Fsage Mask 862 Certificate 8ength 863 0igital Signature 2lgorithm 864 Fsage 8imits 865 2ctivation 0ate 866 Process Start 0ate 867 Protect Stop 0ate 868 0eactivation 0ate 869 .bJect Mroup 870 2pplication Specific Information 871 Contact Information 872 Custom 2ttribute 873+n addition to these attri.utes4 the template has attri.utes that are applica.le to the 874template itsel#. 0hese include the attri.utes AniBue +denti#ier4 +nitial >ate4 <ast Change 875>ate4 and !rchive >ate" set implicitly a#ter success#ully completing a certain operation 876and attri.utes set .y the client ).?ect 0ype and Name" in the 1egister reBuest. ;hen 877registering a template4 the Name attri.ute #or the template should .e set. +t is used to 878speci#y and identi#y the template in the 0emplate-!ttri.ute structure $hen attri.utes #or a 879managed o.?ect are set. 8800he 0emplate-!ttri.ute structure allo$s #or multiple template names and individual 881attri.utes to .e speci#ied in an operation reBuest. 0he structure is used in the Create4 882Create ,ey /air4 1egister4 1e-key4 1e-key ,ey /air4 >erive ,ey4 Certi#y4 and 1e-certi#y 883operations. !ll o# these operations $ith the eDception o# the Create ,ey /air and the 1e-
66
67 884key ,ey /air operations use the 0emplate-!ttri.ute tag. 0he Create ,ey /air and the 8851e-key ,ey /air operations use the Common 0emplate-!ttri.ute4 /rivate ,ey 0emplate 886!ttri.ute4 and /u.lic ,ey 0emplate-!ttri.ute tags. 8870emplates may .e the su.?ect o# the 1egister4 <ocate4 2et4 2et !ttri.utes4 2et !ttri.ute 888<ist4 !dd !ttri.ute4 -odi#y !ttri.ute4 >elete !ttri.ute4 >elete !ttri.ute4 and >estroy 889operations. Clients are not a.le to create a template $ith the Create operation@ instead 890templates are created using the 1egister operation. ;hen the template is the su.?ect o# 891the operation4 the AniBue +> is used to identi#y the template. 0he template name is only 892used to identi#y the template inside a 0emplate-!ttri.ute structure. 893$.,.1 Template Usage )*amples 8940he purpose o# these eDamples is to illustrate ho$ templates are used. 0he #irst eDample 895sho$s ho$ a template is registered. 0he second eDample sho$s ho$ the ne$ly 896registered template is used to create a symmetric key. 897$.,.1.1 )*ample of #egistering a Template 898+n this eDample4 a client registers a template .y encapsulating attri.utes #or creating a 89928I-.it !5* key $ith the Cryptographic Asage -ask set to 5ncrypt and >ecrypt. 9000he #ollo$ing is speci#ied inside the 1egister 1eBuest /ayload: 901 902 903 904 905 906

.bJect ?ype$ ?emplate ?emplate-2ttribute$
Name: 0emplate1 Cryptographic !lgorithm: !5* Cryptographic <ength: 28I Cryptographic Asage -ask: 5ncrypt and >ecrypt
907 )peration /olicy Name: )peration/olicy1 9080he )peration /olicy )peration/olicy1 applies to the !5* key .eing created using the 909template. +t is not used to control operations on the template itsel#. ,-+/ does not allo$ 910operation policies to .e speci#ied #or controlling operations on the template itsel#. 0he 911de#ault policy #or template o.?ects is used #or this purpose and is speci#ied in the ,-+/ 912*peci#ication. 913$.,.1.2 )*ample of Creating a 'ymmetric Key using a Template 914+n this eDample4 the client uses the template created in eDample '.I.1 to create a 28I-.it 915!5* key. 9160he #ollo$ing is speci#ied in the Create 1eBuest /ayload: 917 918 919 920 68

.bJect ?ype$ Symmetric Key ?emplate-2ttribute$
Name: 0emplate1 !ttri.ute:
69 921 =ame$ 2,Skey 922 Custom 2ttribute$ 6-I0+45*1 9230he 0emplate-!ttri.ute structure speci#ies .oth a template name and additional 924attri.utes. 0he Name attri.ute is not an attri.ute that may .e set .y a template. 0he 925Name attri.ute set #or the template applies to the template itsel# e.g.4 0emplate1 is the 926Name attri.ute o# the 0emplate o.?ect". 0he Name attri.ute #or the symmetric key is 927there#ore speci#ied separately under !ttri.ute. +t is possi.le to speci#y the Custom 928!ttri.ute inside the template $hen the template is registered@ ho$ever4 this particular 929eDample sets this attri.ute separately. 930$.0 &rc-i"e .perations 931;hen the !rchive operation is per#ormed4 it is recommended that a uniBue identi#ier and 932a minimal set o# attri.utes .e retained $ithin the server #or operational e##iciency. +n such 933a case4 the retained attri.utes may include AniBue +denti#ier and *tate. 934$.1 Message )*tensions 935!ny num.er o# vendor-speci#ic eDtensions may .e included in the -essage 5Dtension 936optional structure. 0his allo$s ,-+/ implementations to create multiple eDtensions to the 937protocol. 938$.2 Uni8ue Identifiers 9396or clients that reBuire uniBue identi#iers in a special #orm4 out-o#-.and 940registration/con#iguration may .e used to communicate this reBuirement to the server. 941$.16 #esult Message Te*t 942,-+/ speci#ies the 1esult *tatus4 the 1esult 1eason and the 1esult -essage as 943normative message contents. 6or the 1esult *tatus and 1esult 1eason4 the 944enumerations provided in !"#IP$Spec& are the normative values. 0he values #or the 9451esult -essage teDt are implementation-speci#ic. +n consideration o# internationali(ation4 946it is recommended that any vendor implementation o# ,-+/ provide appropriate 947language support #or the 1eturn -essage. 7o$ a client speci#ies the language #or 1esult 948-essages is outside the scope o# the ,-+/. 949$.11 =uery 950Nuery does not eDplicitly support client reBuests to determine $hat operations reBuire 951authentication. 0o determine $hether an operation reBuires authentication4 a client 952should reBuest that operation. 953$.12 Canceling &sync-ronous .perations 954+# an asynchronous operation is cancelled .y the client4 no in#ormation is returned .y the 955server in the result code regarding any operations that may have .een partially 956completed. +denti#ication and remediation o# partially completed operations is the 957responsi.ility o# the server.
70
71 958+t is the responsi.ility o# the server to determine $hen to discard the status o# 959asynchronous operations. 0he determination o# ho$ long a server should retain the 960status o# an asynchronous operation is implementation-dependent and not de#ined .y 961,-+/. 962)nce a client has received the status on an asynchronous operation other than 963EpendingF4 any su.seBuent reBuest #or status o# that operation may return either the 964same status as in a previous polling reBuest or an Eunavaila.leF response. 965$.1$ Multi%instance >as9660he >igest attri.ute contains the output o# hashing a managed o.?ect4 such as a key or a 967certi#icate. 0he server al$ays generates the *7!-28I hash value $hen the o.?ect is 968created or generated. ,-+/ allo$s multiple instances o# the digest attri.ute to .e 969associated $ith the same managed o.?ect. 6or eDample4 it is common practice #or 970pu.licly trusted C!s to pu.lish t$o digests o#ten re#erred to as the #ingerprint or the 971thum.print" o# their certi#icate: one calculated using the *7!-1 algorithm and another 972using the ->8 algorithm. +n this case4 each digest $ould .e calculated .y the server 973using a di##erent hash algorithm. 974$.1( #eturning #elated .b/ects 9750he key .lock returns a single o.?ect4 $ith associated attri.utes and other data. 6or 976those cases in $hich multiple related o.?ects are needed .y a client4 such as the private 977key and the related certi#icate4 the client should issue multiple 2et reBuests to o.tain 978these related o.?ects. 979$.1+ #educing Multiple #e8uests t-roug- t-e Use of 7atc980,-+/ supports .atch operations in order to reduce the num.er o# calls .et$een the 981client and server. 6or eDample4 <ocate and 2et are likely to .e commonly accomplished 982$ithin a single .atch reBuest. 983,-+/ does not ensure that .atch operations are atomic on the server side. +# servers 984implement such atomicity4 the client is a.le to use the optional EundoF mode to reBuest 985roll-.ack #or .atch operations implemented as atomic transactions. 7o$ever4 support #or 986EundoF mode is optional in the protocol4 and there is no guarantee that a server that 987supports EundoF mode has e##ectively implemented atomic .atches. 0he use o# EundoF4 988there#ore4 should .e restricted to those cases in $hich it is possi.le to assure the client4 989through mechanisms outside o# ,-+/4 o# the server e##ectively supporting atomicity #or 990.atch operations. 991$.1, Ma*imum Message 'i:e 992;hen a server is processing reBuests in a .atch4 it should compare the cumulative 993response si(e o# the message to .e returned a#ter each reBuest $ith the speci#ied 994-aDimum 1esponse *i(e. +# the message is too large4 it should prepare a maDimum 995message si(e error response message at that point4 rather than continuing $ith
72
73 996operations in the .atch. 0his increases the clientGs a.ility to understand $hat operations 997have and have not .een completed. 998;hen processing individual reBuests $ithin the .atch4 the server that has encountered a 999-aDimum 1esponse *i(e error should not return attri.ute values or other in#ormation as 1000part o# the error response. 10010he <ocate operation also supports the concept o# a maDimum item count to include in 1002the returned list o# uniBue identi#iers. 1003$.10 Using .ffset in #e%;ey and #e%certify .perations 10040he 1e-key4 1e-key ,ey /air4 and 1e-certi#y operations allo$ the speci#ication o# an 1005o##set interval. 10060he 1e-key and the 1e-key ,ey /air operations allo$ the client to speci#y an o##set 1007interval #or activation o# the key. 0his o##set speci#ies the duration o# time .et$een the 1008time the reBuest is made and the time $hen the activation o# the key occurs. +# an o##set 1009is speci#ied4 all other times #or the ne$ key are determined #rom the ne$ !ctivation >ate4 1010.ased on the intervals used .y the previous key4 i.e.4 #rom the !ctivation >ate to the 1011/rocess *tart >ate4 /rotect *top >ate4 etc. 10120he 1e-certi#y operation allo$s the client to speci#y an o##set interval that indicates the 1013di##erence .et$een the +nitial >ate o# the ne$ certi#icate and the !ctivation >ate o# the 1014ne$ certi#icate. !s $ith the 1e-key operation4 all other times #or the certi#icate are 1015determined using the intervals used #or the previous certi#icate. 1016Note that in re-key operations i# activation date4 process start date4 protect stop date and 1017deactivation date are o.tained #rom the eDisting key4 and the initial date is o.tained #rom 1018the current time4 then the deactivation/activation date/process start date/protect stop 1019date is smaller or less than initial date. ,-+/ allo$s .ack-dating o# these values to 1020prevent this contradiction see ,-+/-*pec '.22 and ,-+/-A2 '.8 and '.2M". 1021 1022$.11 9ocate =ueries 1023+t is possi.le to #ormulate <ocate Bueries to address any o# the #ollo$ing conditions: 1024
1025

,6act match of a transition to a given state. 8ocate the keyDsE 3ith a transition to a certain state at a specified time DtE. 7ange match of a transition to a given state. 8ocate the keyDsE 3ith a transition to a certain state at any time at or bet3een t3o specified times Dt and tNE. ,6act match of a state at a specified time. 8ocate the keyDsE that are in a certain state at a specified time DtE. Match of a state during an entire time range. 8ocate the keyDsE that are in a certain state during an entire time specified 3ith times Dt and tNE. =ote that the 2ctivation 0ate could occur at or before t and that the 0eactivation 0ate could occur at or after tNO". Match of a state at some point during a time range. 8ocate the keyDsE that are in a certain state at some time at or bet3een t3o specified times Dt and tNE. In this case# the transition to that state could be before the start of the specified time range.
1026
1027
1028
1029
1030
1031 1032
1033
1034 1035
74
75 10360his is accomplished .y allo$ing any date/time attri.ute to .e present either once #or an 1037eDact match" or at most t$ice #or a range match". 10386or instance4 i# the state $e are interested in is !ctive4 the <ocate Bueries $ould .e the 1039#ollo$ing corresponding to the .ulleted list a.ove": 1040
1041

,6act match of a transition to a given state$ 8ocate D2ctivation0ateDtEE. 8ocate keys 3ith an 2ctivation 0ate of t. 7ange match of a transition to a given state$ 8ocate D2ctivation0ateDtE# 2ctivation0ateDtPEE. 8ocate keys 3ith an 2ctivation 0ate at or bet3een t and tN. ,6act match of a state at a specified time$ 8ocate D2ctivation0ateD-E# 2ctivation0ateDtE# 0eactivation0ateDtO"E# 0eactivation0ateDM2I)I=?E# Compromise0ateDtO"E# Compromise0ateDM2I)I=?E E. 8ocate keys in the 2ctive state at time t# by looking for keys 3ith a transition to 2ctive before or until t# and a transition to 0eactivated or Compromised after t Dbecause 3e donPt 3ant the keys that have a transition to 0eactivated or Compromised before tE. ?he server assumes that keys 3ithout a 0eactivation0ate or Compromise0ate is equivalent to M2I)I=? Di.e.# infiniteE. Match of a state during an entire time range$ 8ocate D2ctivation0ateD-E# 2ctivation0ateDtE# 0eactivation0ateDtPO"E# 0eactivation0ateDM2I)I=?E# Compromise0ateDtPO"E# Compromise0ateDM2I)I=?E E. 8ocate keys in the 2ctive state during the entire time from t to tN. Match of a state at some point during a time range$ 8ocate D2ctivation0ateD-E# 2ctivation0ateDtP-"E# 0eactivation0ateDtO"E# 0eactivation0ateDM2I)I=?E# Compromise0ateDtO"E# Compromise0ateDM2I)I=?EE. 8ocate keys in the 2ctive state at some time from t to tN# by looking for keys 3ith a transition to 2ctive bet3een - and tN-" and e6it out of 2ctive on or after tO".
1042
1043
1044
1045 1046 1047 1048 1049 1050
1051
1052 1053 1054
1055
1056 1057 1058 1059
10600he Bueries $ould .e similar #or +nitial >ate4 >eactivation >ate4 Compromise >ate and 1061>estroy >ate. 1062+n the case o# the >estroyed-Compromise state4 there are t$o dates recorded: the 1063>estroy >ate and the Compromise >ate. 6or this state4 the <ocate operation $ould .e 1064eDpressed as #ollo$s: 1065
1066 1067 1068 1069 1070
,6act match of a transition to a given state$ 8ocate DCompromise0ateDtE# StateD0estroyed-CompromisedEE and 8ocate D0estroy0ateDtE# StateD0estroyedCompromisedEE. KMIP does not support the .7 in the 8ocate request# so t3o requests should be issued. 8ocate keys that 3ere 0estroyed and transitioned to the 0estroyedCompromised state at time t# and locate keys that 3ere Compromised and transitioned to the 0estroyed-Compromised state at time t. 7ange match of a transition to a given state$ 8ocate DCompromise0ateDtE# Compromise0ateDtPE# StateD0estroyed-CompromisedEE and 8ocate D0estroy0ateDtE# 0estroy0ateDtPE# StateD0estroyed-CompromisedEE. 8ocate keys that are 0estroyedCompromised and 3ere Compromised or 0estroyed at or bet3een t and tN. ,6act match of a state at a specified time$ 8ocate DCompromise0ateD-E# Compromise0ateDtE# 0estroy0ateD-E# 0estroy0ateDtEEQ nothing else is needed# since there is no e6it transition. 8ocate keys 3ith a Compromise 0ate at or before t# and 3ith a 0estroy 0ate at or before t. ?hese keys are# therefore# in the 0estroyed-Compromised state at time t. Match of a state during an entire time range$ 8ocate DCompromise0ateD-E# Compromise0ateDtE# 0estroy0ateD-E# 0estroy0ateDtEE. Same as above. 2s there is no e6it transition from the 0estroyed-Compromised state# the end of the range DtNE is irrelevant.
1071
1072 1073 1074
1075
1076 1077 1078 1079
1080
1081 1082
76
77 1083
1084 1085 1086 1087
Match of a state at some point during a time range$ 8ocate DCompromise0ateD-E# Compromise0ateDtP-"E# 0estroy0ateD-E# 0estroy0ateDtP-"EE. 8ocate keys 3ith a Compromise 0ate at or before tN-"# and 3ith a 0estroy 0ate at or before tN-". 2s there is no e6it transition from the 0estroyed-Compromised state# the start of the range DtE is irrelevant.
1088$.12 I5 Place-older 1089! num.er o# operations are a##ected .y a mechanism re#erred to as the +> /laceholder. 10900his is a temporary varia.le consisting o# a single AniBue +denti#ier that is stored inside 1091the server #or the duration o# eDecuting a .atch o# operations. 0he +> /laceholder is 1092o.tained #rom the AniBue +denti#ier returned .y certain operations@ the applica.le 1093operations are identi#ied in 0a.le 14 along $ith a list o# operations that accept the +> 1094/laceholder as input.
/peration I2 Placeholder I2 Placeholder upon completion of the at the e3innin3 operation 4in case of operation failure( a of the operation atch usin3 the I2 Placeholder stops5 +> o# ne$ ).?ect +> o# ne$ /rivate ,ey +> o# ne$ /u.lic ,ey may .e o.tained via a <ocate" +> o# ne$ly registered ).?ect
Create Create ,ey /air 1egister >erive ,ey
- multiple +> o# ne$ *ymmetric ,ey AniBue +denti#iers may .e speci#ied in the reBuest" +> o# ).?ect +> o# located ).?ect no change no change
<ocate 2et =alidate
2et !ttri.utes +> o# ).?ect <ist/-odi#y/!dd/>elet e !ctivate 1evoke >estroy !rchive/1ecover Certi#y 1e-certi#y 1e-key +> o# ).?ect +> o# ).?ect +> o# ).?ect +> o# ).?ect
no change no change no change no change
+> o# /u.lic ,ey +> o# ne$ Certi#icate +> o# Certi#icate +> o# ne$ Certi#icate +> o# *ymmetric +> o# ne$ *ymmetric ,ey ,ey to .e
78
79
rekeyed 1e-key ,ey /air ).tain <ease +> o# /rivate ,ey +> o# ne$ /rivate ,ey +> o# ne$ /u.lic ,ey to .e rekeyed may .e o.tained via a <ocate" +> o# ).?ect no change no change no change
RESULTI0%
.R/# A
2et Asage !llocation +> o# ,ey Check

1095
+> o# ).?ect
T/ A02
T A6LE -: I2 P LACE7/L2ER P RI/R
"#IP / PERATI/0
1096$.26 Key 7loc; 10970he protocol uses the ,ey Clock structure to transport a key to the client or server. 0his 1098,ey Clock consists o# the ,ey =alue 0ype4 the ,ey =alue4 and the ,ey ;rapping >ata. 10990he ,ey =alue 0ype identi#ies the #ormat o# the ,ey -aterial4 e.g.4 1a$ #ormat or 11000ransparent ,ey structure. 0he ,ey =alue consists o# the ,ey -aterial and optional 1101attri.utes. 0he ,ey ;rapping >ata provides in#ormation a.out the $rapping key and the 1102$rapping mechanism4 and is returned only i# the client reBuests the ,ey =alue to .e 1103$rapped .y speci#ying the ,ey ;rapping *peci#ication inside the 2et 1eBuest /ayload. 11040he ,ey ;rapping >ata may also .e included inside the ,ey Clock i# the client registers 1105a $rapped key. 11060he protocol allo$s any attri.ute to .e included inside the ,ey =alue and allo$s these 1107attri.utes to .e cryptographically .ound to the ,ey -aterial i.e.4 .y signing4 -!Cing4 1108encrypting4 or .oth encrypting and signing/-!Cing the ,ey =alue". *ome o# the 1109attri.utes that may .e included include the #ollo$ing: 1110 1111
1112

Fnique Identifier H uniquely identifies the key Cryptographic 2lgorithm De.g.# 2,S# (0,S# 7S2E H this attribute is either specified inside the Key >lock structure or the Key !alue structure Cryptographic 8ength De.g.# "1&# 15'# 1-4&E H this attribute is either specified inside the Key >lock structure or the Key !alue structure Cryptographic Fsage MaskH identifies the cryptographic usage of the key De.g.# ,ncrypt# /rap Key# ,6portE Cryptographic Parameters H provides additional parameters for determining ho3 the key may be used
1113
1114
1115
1116
1117
1118
1119 1120 1121 1122 1123 1124 1125 1126 1127 1128
Clock Cipher -ode e.g.4 CCC4 N+*0,ey;rap4 2C-" O this parameter identi#ies the mode o# operation4 including .lock cipher-.ased -!Cs or $rapping mechanisms /adding -ethod e.g.4 )!5/4 KM.'14 /**" O identi#ies the padding method and i# applica.le the signature or encryption scheme 7ashing !lgorithm e.g.4 *7!-28I" O identi#ies the hash algorithm to .e used $ith the signature/encryption mechanism or -ask 2eneration 6unction@ note that the di##erent 7-!Cs are de#ined individually as algorithms and do not reBuire the 7ashing !lgorithm parameter to .e set ,ey 1ole 0ype O +denti#ies the #inancial key role e.g.4 >5,4 ,5,"
80
81 1129 1130 1131

1132

State De.g.# 2ctiveE 0ates De.g.# 2ctivation 0ate# Process Start 0ate# Protect Stop 0ateE Custom 2ttribute H allo3s vendors and clients to define vendor-specific attributesQ may also be used to prevent replay attacks by setting a nonce
1133$.21 Using ?rapped Keys @it- KMIP 1134,-+/ provides the option to register and get keys in $rapped #ormat. Clients reBuest the 1135server to return a $rapped key .y including the ,ey ;rapping *peci#ication in the 2et 11361eBuest /ayload. *imilarly4 clients register a $rapped key .y including the ,ey 1137;rapping >ata in the 1egister 1eBuest /ayload. 0he ;rapping -ethod identi#ies the 1138type o# mechanism used to $rap the key4 .ut does not identi#y the algorithm or .lock 1139cipher mode. +t is possi.le to determine these #rom the attri.utes set #or the speci#ied 11405ncryption ,ey or -!C/*igning ,ey. +# a key has multiple Cryptographic /arameters set4 1141clients may include the applica.le parameters in ,ey ;rapping *peci#ication. +# omitted4 1142the server chooses the Cryptographic /arameter attri.ute $ith the lo$est indeD. 11430he ,ey =alue includes .oth the ,ey -aterial and4 optionally4 attri.utes o# the key@ these 1144may .e provided .y the client in the 1egister 1eBuest /ayload@ the server only includes 1145attri.utes $hen reBuested in the ,ey ;rapping *peci#ication o# the 2et 1eBuest 1146/ayload. 0he ,ey =alue may .e encrypted4 signed/-!Ced4 or .oth encrypted and 1147signed/-!Ced and vice versa". +n addition4 clients have the option to reBuest or import 1148a $rapped ,ey Clock according to standards4 such as !N*+ 01-'14 or vendor-speci#ic 1149key $rapping methods. 1150+t is important to note that i# the ,ey ;rapping *peci#ication is included in the 2et 11511eBuest /ayload4 the ,ey =alue may not necessarily .e encrypted. +# the ;rapping 1152-ethod is -!C/sign4 the returned ,ey =alue is in plainteDt4 and the ,ey ;rapping >ata 1153includes the -!C or *ignature o# the ,ey =alue. 1154/rior to $rapping or un$rapping a key4 the server should veri#y that the $rapping key is 1155allo$ed to .e used #or the speci#ied purpose. 6or eDample4 i# the AniBue +> o# a 1156symmetric key is speci#ied in the ,ey ;rapping *peci#ication inside the 2et reBuest4 the 1157symmetric key should have the E;rap ,eyF .it set in its Cryptographic Asage -ask. 1158*imilarly4 i# the client registers a signed key4 the server should veri#y that the *ignature 1159,ey4 as speci#ied .y the client inside the ,ey ;rapping >ata4 has the E=eri#yF .it set in 1160the Cryptographic Asage -ask. +# the $rapping key is not permitted to .e used #or the 1161reBuested purpose e.g.4 $hen the Cryptographic Asage -ask is not set"4 the server 1162should return the )peration 6ailed result status. 1163$.21.1 )ncrypt%only )*ample @it- a 'ymmetric Key as an )ncryption Key for a 1164 Get #e8uest and #esponse 11650he client sends a 2et reBuest to o.tain a key that is stored on the server. ;hen the 1166client sends a 2et reBuest to the server4 a ,ey ;rapping *peci#ication may .e included. 1167+# a ,ey ;rapping *peci#ication is included in the 2et reBuest4 and a client $ants the 1168reBuested key and its Cryptographic Asage -ask attri.ute to .e $rapped $ith !5* key 1169$rap4 the client includes the #ollo$ing in#ormation in the ,ey ;rapping *peci#ication:
82
83 1170 1171 1172

/rapping Method$ ,ncrypt ,ncryption Key Information
AniBue ,ey +>: ,ey +> o# the !5* $rapping key
1173 Cryptographic /arameters: 0he Clock Cipher -ode is N+*0,ey;rap not 1174 necessary i# de#ault .lock cipher mode #or $rapping key is N+*0,ey;rap" 1175 2ttribute =ame$ Cryptographic Fsage Mask 11760he server uses the AniBue ,ey +> speci#ied .y the client to determine the attri.utes set 1177#or the proposed $rapping key. 6or eDample4 the algorithm o# the $rapping key is not 1178eDplicitly speci#ied inside the ,ey ;rapping *peci#ication. 0he server determines the 1179algorithm to .e used #or $rapping the key .y identi#ying the !lgorithm attri.ute set #or the 1180speci#ied 5ncryption ,ey. 11810he Cryptographic /arameters attri.ute should .e speci#ied .y the client i# multiple 1182instances o# the Cryptographic /arameters eDist4 and the lo$est indeD does not 1183correspond to the N+*0 key $rap mode o# operation. 0he server should veri#y that the 1184!5* $rapping key has N+*0,ey;rap set as an allo$a.le Clock Cipher -ode4 and that 1185the E;rap ,eyF .it is set in the Cryptographic Asage -ask. 1186+# the correct data $as provided to the server4 and no con#licts eDist4 the server !5* key 1187$raps the ,ey =alue .oth the ,ey -aterial and the Cryptographic Asage -ask 1188attri.ute" #or the reBuested key $ith the $rapping key speci#ied in the 5ncryption ,ey 1189+n#ormation. 0he $rapped key .yte string" is returned in the serverGs response inside the 1190,ey =alue o# the ,ey Clock. 11910he ,ey ;rapping >ata o# the ,ey Clock in the 2et 1esponse /ayload includes the 1192same data as speci#ied in the ,ey ;rapping *peci#ication o# the 2et 1eBuest /ayload 1193eDcept #or the !ttri.ute Name. 1194$.21.2 )ncrypt%only )*ample @it- a 'ymmetric Key as an )ncryption Key for a 1195 #egister #e8uest and #esponse 11960he client sends a 1egister reBuest to the server and includes the $rapped key and the 1197AniBue +> o# the $rapping key inside the 1eBuest /ayload. 0he $rapped key is provided 1198to the server inside the ,ey Clock. 0he ,ey Clock includes the ,ey =alue 0ype4 the ,ey 1199=alue4 and the ,ey ;rapping >ata. 0he ,ey =alue 0ype identi#ies the #ormat o# the ,ey 1200-aterial4 the ,ey =alue consists o# the ,ey -aterial and optional attri.utes that may .e 1201included to cryptographically .ind the attri.utes to the ,ey -aterial4 and the ,ey 1202;rapping >ata identi#ies the $rapping mechanism and the encryption key used to $rap 1203the o.?ect and the $rapping mechanism. 1204*imilar to the eDample in '.21.1 the key is $rapped using the !5* key $rap. 0he ,ey 1205=alue includes #our attri.utes: Cryptographic !lgorithm4 Cryptographic <ength4 1206Cryptographic /arameters4 and Cryptographic Asage -ask. 12070he ,ey ;rapping >ata includes the #ollo$ing in#ormation: 1208 1209

84
85 1210
AniBue ,ey +>: ,ey +> o# the !5* $rapping key
1211 Cryptographic /arameters: 0he Clock Cipher -ode is N+*0,ey;rap not 1212 necessary i# de#ault .lock cipher mode #or $rapping key is N+*0,ey;rap" 1213!ttri.utes do not need to .e speci#ied in the ,ey ;rapping >ata. ;hen registering a 1214$rapped ,ey =alue $ith attri.utes4 clients may include these attri.utes inside the ,ey 1215=alue $ithout speci#ying them inside the 0emplate-!ttri.ute. 1216/rior to un$rapping the key4 the server determines the $rapping algorithm #rom the 1217!lgorithm attri.ute set #or the speci#ied AniBue +> in the 5ncryption ,ey +n#ormation. 0he 1218server veri#ies that the $rapping key may .e used #or the speci#ied purpose. +n 1219particular4 i# the client includes the Cryptographic /arameters in the 5ncryption ,ey 1220+n#ormation4 the server veri#ies that the speci#ied Clock Cipher -ode is set #or the 1221$rapping key. 0he server also veri#ies that the $rapping key has the EAn$rap ,eyF .it 1222set in the Cryptographic Asage -ask. 12230he 1egister 1esponse /ayload includes the AniBue +> o# the ne$ly registered key and 1224an optional list o# attri.utes that $ere implicitly set .y the server. 1225$.21.$ )ncrypt%only )*ample @it- an &symmetric Key as an )ncryption Key for a 1226 Get #e8uest and #esponse 12270he client sends a 2et reBuest to o.tain a key either symmetric or asymmetric" that is 1228stored on the server. ;hen the client sends a 2et reBuest to the server4 a ,ey ;rapping 1229*peci#ication may .e included. +# a ,ey ;rapping *peci#ication is included4 and the key 1230is to .e $rapped $ith an 1*! pu.lic key using the )!5/ encryption scheme4 the client 1231includes the #ollo$ing in#ormation in the ,ey ;rapping *peci#ication. Note that #or this 1232eDample4 attri.utes #or the reBuested key are not reBuested. 1233 1234 1235 1236 1237 1238

AniBue ,ey +>: ,ey +> o# the 1*! pu.lic key Cryptographic /arameters: /adding -ethod: )!5/ 7ashing !lgorithm: *7!-28I
12390he Cryptographic /arameters attri.ute is speci#ied .y the client i# multiple instances o# 1240Cryptographic /arameters eDist #or the $rapping key4 and the lo$est indeD does not 1241correspond to the associated padding method. 0he server should veri#y that the 1242speci#ied Cryptographic /arameters in the ,ey ;rapping *peci#ication and the E;rap 1243,eyF .it in the Cryptographic Asage -ask are set #or the corresponding $rapping key. 12440he ,ey ;rapping >ata returned .y the server in the ,ey Clock o# the 2et 1esponse 1245/ayload includes the same data as speci#ied in the ,ey ;rapping *peci#ication o# the 12462et 1eBuest /ayload. 12476or .oth )!5/ and /**4 ,-+/ assumes that the 7ashing !lgorithm speci#ied in the 1248Cryptographic /arameters o# the 2et reBuest is used #or .oth the -ask 2eneration
86
87 12496unction -26" and hashing data. 0he eDample a.ove reBuires the server to use *7!125028I #or .oth purposes. 1251$.21.( M&C%only )*ample @it- an >M&C Key as an &ut-entication Key for a 1252 Get #e8uest and #esponse 12530he client sends a 2et reBuest to o.tain a key that is stored on the server. ;hen the 1254client sends a 2et reBuest to the server4 a ,ey ;rapping *peci#ication may .e included. 1255+# a key and Custom !ttri.ute i.e.4 D-Nonce" is to .e -!Ced $ith 7-!C *7!-28I4 the 1256#ollo$ing ,ey ;rapping *peci#ication is speci#ied: 1257 /rapping Method$ M2C%sign 1258 M2C%Signature Key Information 1259 AniBue ,ey +>: ,ey +> o# the -!Cing key note that the algorithm associated 1260 $ith this key $ould .e 7-!C-*7!28I" 1261 2ttribute =ame$ 6-=once 12626or 7-!C4 no Cryptographic /arameters need to .e speci#ied4 since the algorithm4 1263including the hash #unction4 may .e determined #rom the !lgorithm attri.ute set #or the 1264speci#ied -!C ,ey. 0he server should veri#y that the 7-!C key has the E-!C 12652enerateF .it set in the Cryptographic Asage -ask. Note that an 7-!C key does not 1266reBuire the E;rap ,eyF .it to .e set in the Cryptographic Asage -ask. 12670he server creates an 7-!C value over the ,ey =alue i# the speci#ied -!Cing key may 1268.e used #or the speci#ied purpose and no con#licts eDist. 0he ,ey =alue is returned in 1269plainteDt4 and the ,ey Clock includes the #ollo$ing ,ey ;rapping >ata: 1270 /rapping Method$ M2C%sign 1271 M2C%Signature Key Information 1272 Fnique Key I0$ Key I0 of the M2Cing key 1273 M2C%Signature$ @M2C result of the Key !alue 1274+n the eDample4 the custom attri.ute D-Nonce $as included to help clients4 $ho are 1275relying on the proDy model4 to detect replay attacks. 5nd-clients4 $ho communicate $ith 1276the key management server4 may not support 0<* and may not .e a.le to rely on the 1277message protection mechanisms provided .y a security protocol. !n alternative 1278approach #or these clients $ould .e to use the custom attri.ute to hold a random 1279num.er4 counter4 nonce4 date4 or time. 0he custom attri.ute needs to .e created .e#ore 1280reBuesting the server to return a $rapped key and is recommended to .e set i# clients 1281#reBuently $rap/sign the same key $ith the same $rapping/signing key. 1282$.21.+ #egistering a ?rapped Key as an .pa8ue Cryptograp-ic .b/ect 1283Clients may $ant to register and store a $rapped key on the server $ithout the server 1284.eing a.le to un$rap the key i.e.4 the $rapping key is not kno$n to the server". +nstead 1285o# storing the $rapped key as an opaBue o.?ect4 clients have the option to store the 1286$rapped key inside the ,ey Clock as an opaBue cryptographic o.?ect4 i.e.4 the $rapped 1287key is registered as a managed cryptographic o.?ect4 .ut the encoding o# the key is 1288unkno$n to the server. 1egistering an opaBue cryptographic o.?ect allo$s clients to set
88
89 1289all the applica.le attri.utes that apply to cryptographic o.?ects e.g.4 Cryptographic 1290!lgorithm and Cryptographic <ength"4 1291)paBue cryptographic o.?ects are set .y speci#ying the #ollo$ing inside the ,ey Clock 1292structure: 1293 1294
Key ormat ?ype$ .paque Key Material$ /rapped key as a >yte String
1295?he Key /rapping 0ata does not need to be specified.
1296$.21., )ncoding .ption for ?rapped Keys 1297,-+/ provides the option to speci#y the 5ncoding )ption inside the ,ey ;rapping 1298*peci#ication and ,ey ;rapping >ata. 0his option allo$s users to 2et or 1egister the 1299,ey =alue in a non-00<= encoded #ormat. 0his may .e desira.le in a proDy 1300environment4 $here the end-client is not ,-+/-a$are. 1301 13020he 5ncoding )ption is only availa.le i# no attri.utes are speci#ied inside the ,ey =alue. 13030he server returns the 5ncoding )ption 5rror i# .oth the 5ncoding )ption and !ttri.ute 1304Names are speci#ied inside the ,ey ;rapping *peci#ication. *imilarly4 the server is 1305eDpected to return the 5ncoding )ption 5rror $hen registering a $rapped o.?ect $ith 1306attri.utes inside the ,ey =alue and the 5ncoding )ption is set in the ,ey ;rapping 1307>ata. +# no 5ncoding )ption is speci#ied4 ,-+/ assumes that the ,ey =alue is 00<=1308encoded. 0hus4 .y de#ault4 the complete 00<=-encoded ,ey =alue content4 as sho$n in 1309the eDample .elo$4 is $rapped: 1310Key Material 1311Value
|| Byte String || Length || Key Material
1312420043 || 08 || 00000010 || 13130123456789ABC !"0123456789ABC !" 1314*ome end-clients may not understand or have the space #or anything more than the 1315actual key material i.e.4 012'%8I7&M!CC>56012'%8I7&M!CC>56 in the a.ove 1316eDample". 0o $rap only the ,ey -aterial value during a 2et operation4 the 5ncoding 1317)ption 00001 #or no encoding" should .e speci#ied inside the ,ey ;rapping 1318*peci#ication. 0he same 5ncoding )ption should .e speci#ied in the ,ey ;rapping >ata 1319$hen returning the non-00<= encoded $rapped o.?ect inside the 2et 1esponse 1320/ayload or $hen registering a $rapped o.?ect in non-00<= encoded #ormat. 1321+t is important to .e a$are o# the risks involved $hen eDcluding the attri.utes #rom the 1322,ey =alue. Cinding the attri.utes to the key material in certain environments is essential 1323to the security o# the end-client. !n untrusted proDy could change the attri.utes 1324 provided separately via the 2et !ttri.utes operation" that determine ho$ the key is 1325.eing used e.g.4 Cryptographic Asage". +ncluding the attri.utes inside the ,ey =alue 1326and cryptographically .inding it to the ,ey -aterial could prevent potential misuse o# the 1327cryptographic o.?ect and may prevent a replay attack i#4 #or eDample4 a nonce is included
90
91 1328as a custom attri.ute. 0he eDclusion o# attri.utes and there#ore the usage o# the 13295ncoding )ption are only recommended in at least one o# the #ollo$ing scenarios: 1330 1. 5nd-clients are registered $ith the ,-+/ server and are communicating $ith the 1331 server directly i.e.4 the 0<* connection is .et$een the server and client". 1332 2. 0he environment is controlled and non-,-+/-a$are end-clients are a$are ho$ 1333 $rapped cryptographic o.?ects possi.ly 1a$ keys" #rom the ,-+/ server should .e 1334 used $ithout having to rely on the attri.utes provided .y the 2et !ttri.utes operation. 1335 '. 0he $rapped cryptographic o.?ect consists o# attri.utes inside the ,ey -aterial 1336 value. 0hese attri.utes are not interpreted .y the ,-+/ server4 .ut are understood .y 1337 the end-client. 0his may .e the case i# the ,ey 6ormat 0ype is opaBue or vendor1338 speci#ic. 1339 %. 0he proDy communicating $ith the ,-+/ server on .ehal# o# the end-client is 1340 considered to .e trusted and is operating in a secure environment. 13411egistering a $rapped o.?ect $ithout attri.utes is not recommended in a proDy 1342environment4 unless scenario % is met. 1343$.22 .b/ect Group 13440he key management system may speci#y rules #or valid group names $hich may .e 1345created .y the client. Clients are in#ormed o# such rules .y a mechanism that is not 1346speci#ied .y !"#IP$Spec&. +n the protocol4 the group names themselves are teDt strings 1347o# no speci#ied #ormat. *peci#ic key management system implementations may choose 1348to support hierarchical naming schemes or other syntaD restrictions on the names. 13492roups may .e used to associate o.?ects #or a variety o# purposes. ! set o# keys used 1350#or a common purpose4 .ut #or di##erent time intervals4 may .e linked .y a common 1351).?ect 2roup. *ervers may create prede#ined groups and add o.?ects to them 1352independently o# client reBuests. 1353,-+/ allo$s clients to speci#y $hether it $ants a E#reshF or Ede#aultF o.?ect #rom a 1354common ).?ect 2roup. 6resh is an indication o# $hether a mem.er o# a group has .een 1355retrieved .y a client $ith the 2et operation. 0he value o# #resh may .e set as an attri.ute 1356$hen creating or registering an o.?ect. *u.seBuently4 the 6resh attri.ute is modi#ia.le 1357only .y the server. 6or eDample4 a set o# symmetric keys .elong to the ).?ect 2roup 1358E*ymmetric,ey2roup1F and the 6resh attri.ute is set to true #or mem.ers o# the group at 1359the time o# creating or registering the mem.er. 0o add a ne$ symmetric key to the 1360group4 the ).?ect 2roup attri.ute is set to E*ymmetric,ey2roup1F and the 6resh 1361attri.ute is set to true $hen creating or registering the symmetric key o.?ect. 13620he de#inition o# a Ede#aultF o.?ect in a group is .ased on server policy. )ne eDample o# 1363server policy is to use round ro.in selection to serve a key #rom a group. +n this case 1364$hen a client reBuests the de#ault key #rom a group4 the server uses round ro.in 1365selection to serve the key. 1366!n o.?ect may .e removed #rom a group .y deleting the ).?ect 2roup attri.ute4 as long 1367as server policy permits it. ! client $ould need to delete each individual mem.er o# a 1368group to remove all mem.ers o# a group.
92
93 13690he ).?ect 2roup -em.er #lag is speci#ied in the <ocate reBuest to indicate the type o# 1370group mem.er to return. ).?ect 2roup -em.er is an enumeration that can take the 1371value 2roup -em.er 6resh or 2roup -em.er >e#ault. 6ollo$ing are eDamples o# ho$ 1372the ).?ect 2roup -em.er #lag is used: 1373;hen a <ocate reBuest is made .y speci#ying the ).?ect 2roup attri.ute e.g.4 1374Jsymmetric,ey2roup1" and setting the ).?ect 2roup -em.er #lag to J2roup -em.er 13756reshJ4 matching o.?ects #rom the speci#ied group e.g.4 Jsymmetric,ey2roup1J" have 1376the 6resh attri.ute set to true. +# there are no #resh o.?ects remaining in the group4 the 1377server may generate a ne$ o.?ect on the #ly .ased on server policy. 1378;hen a <ocate reBuest is made .y speci#ying the ).?ect 2roup attri.ute e.g.4 1379Jsymmetric,ey2roup2" and setting the ).?ect 2roup -em.er #lag to J2roup -em.er 1380>e#aultJ4 a de#ault o.?ect is returned #rom the group. +n this eDample4 the server policy 1381de#ines de#ault to .e the neDt key in the group Jsymmetric,ey2roup2F@ the group has 1382three group mem.ers $hose AniBue +denti#iers are uuid14 uuid24 uuid'. +# the client 1383per#orms #our consecutive .atched <ocate and 2et operations $ith ).?ect 2roup set to 1384Jsymmetric,ey2roup2J and ).?ect 2roup -em.er set to E2roup -em.er >e#aultF in the 1385<ocate reBuest4 the server returns uuid14 uuid24 uuid'4 and uuid1 restarting #rom the 1386.eginning $ith uuid1 #or the #ourth reBuest" in the #our 2et responses. 1387$.2$ Certify and #e%certify 13880he key management system may contain multiple em.edded C!s or may have access 1389to multiple eDternal C!s. 7o$ the server routes a certi#icate reBuest to a C! is vendor1390speci#ic and outside the scope o# ,-+/. +# the server reBuires and supports the capa.ility 1391#or clients to speci#y the C! to .e used #or signing a Certi#icate 1eBuest4 then this 1392in#ormation may .e provided .y including the Certi#icate +ssuer attri.ute in the Certi#y or 13931e-certi#y reBuest. 1394!"#IP$Spec& supports multiple options #or su.mitting a certi#icate reBuest to the key 1395management server $ithin a Certi#y or 1e-Certi#y operation. +t is a vendor decision as to 1396$hether the key management server o##ers certi#ication authority C!" #unctionality or 1397proDies the certi#icate reBuest onto a separate C! #or processing. 0he type o# certi#icate 1398reBuest #ormats supported is also a vendor decision4 and this may4 in part4 .e .ased 1399upon the reBuest #ormats supported .y any C! to $hich the server proDies the certi#icate 1400reBuests. 1401!ll certi#icate reBuest #ormats #or reBuesting K.80M certi#icates speci#ied in !"#IP$Spec& 1402 i.e.4 /,C*P104 /5- and C1-6" provide a means #or allo$ing the C! to veri#y that the 1403client that created the certi#icate reBuest possesses the private key corresponding to the 1404pu.lic key in the certi#icate reBuest. 0his is re#erred to as /roo#-o#-/ossession /)/". 14057o$ever4 it should .e noted that in the case o# the C1-6 #ormat4 some C!s may not 1406support the C1-6 /)/ option4 .ut instead rely upon the underlying certi#icate 1407management protocols i.e.4 C-/ and C-C" to provide /)/. +n the case $here the C! 1408does not support /)/ via the C1-6 #ormat including C! #unctionality $ithin the key 1409management server"4 an alternative certi#icate reBuest #ormat i.e.4 /,C*P104 /5-" 1410$ould need to .e used i# /)/ needs to .e veri#ied.
94
95 1411$.2( 'pecifying &ttributes during a Create Key Pair or #e%;ey Key Pair 1412 .peration 14130he Create ,ey /air and the 1e-key ,ey /air operations allo$ clients to speci#y 1414attri.utes using the Common 0emplate-!ttri.ute4 /rivate ,ey 0emplate-!ttri.ute4 and 1415/u.lic ,ey 0emplate-!ttri.ute. 0he Common 0emplate-!ttri.ute o.?ect includes a list o# 1416attri.utes that apply to .oth the pu.lic and private key. !ttri.utes that are not common to 1417.oth keys may .e speci#ied using the /rivate ,ey 0emplate-!ttri.ute or /u.lic ,ey 14180emplate-!ttri.ute. +# a single-instance attri.ute is speci#ied in multiple 0emplate1419!ttri.ute o.?ects4 the server o.eys the #ollo$ing order o# precedence: 1420 1421 1422 1423 1424 1425
". 2ttributes specified e6plicitly in the Private and Public Key ?emplate2ttribute# then 1. 2ttributes specified via templates in the Private and Public Key ?emplate-2ttribute# then (. 2ttributes specified e6plicitly in the Common ?emplate-2ttribute# then 4. 2ttributes specified via templates in the Common ?emplate-2ttribute
1426$.2(.1 )*ample of 'pecifying &ttributes during t-e Create Key Pair .peration 1427! client speci#ies several attri.utes in the Create ,ey /air 1eBuest /ayload. 0he 1428Common 0emplate-!ttri.ute includes the template name 1*!Com and other eDplicitly 1429speci#ied common attri.utes: 1430Common 0emplate-!ttri.ute 1431 1432 1433 1434 1435 1436 1437 1438 1439

7S2Com ?emplate
Cryptographic !lgorithm: 1*! Cryptographic <ength: 20%& Cryptographic /arameters: /adding -ethod )!5/ Custom !ttri.ute: D-*erial 12'% ).?ect 2roup: ,ey encryption group 1 Cryptographic <ength: %0MI Cryptographic /arameters: /adding -ethod /,C*1 v1.8
2ttribute
1440 Custom !ttri.ute: D-+> 8I7&M 14410he /rivate ,ey 0emplate-!ttri.ute includes the template name 1*!/riv and other 1442eDplicitly-speci#ied private key attri.utes: 1443/rivate ,ey 0emplate-!ttri.ute 1444 1445 1446 1447
7S2Priv ?emplate
).?ect 2roup: ,ey encryption group 2 Cryptographic Asage -ask: An$rap ,ey
2ttribute
96
97 1448 Name: /rivate,ey1 14490he /u.lic ,ey 0emplate !ttri.ute includes eDplicitly-speci#ied pu.lic key attri.utes: 1450/u.lic ,ey 0emplate-!ttri.ute 1451 1452
2ttribute
Cryptographic Asage -ask: ;rap ,ey
1453 Name: /u.lic,ey1 1454 14556ollo$ing the attri.ute precedence rule4 the server creates a %0MI-.it 1*! key. 0he 1456#ollo$ing client-speci#ied attri.utes are set: 1457/rivate ,ey 1458 Cryptographic 2lgorithm$ 7S2 1459 Cryptographic 8ength$ 4-*' 1460 Cryptographic Parameters$ .2,P 1461 Cryptographic Parameters$ PKCS" v".5 1462 Cryptographic Fsage Mask$ Fn3rap Key 1463 Custom 2ttribute$ 6-Serial "1(4 1464 Custom 2ttribute$ 6-I0 5'+&* 1465 .bJect Mroup$ Key encryption group " 1466 .bJect Mroup$ Key encryption group 1 1467 =ame$ PrivateKey" 1468/u.lic ,ey 1469 1470 1471 1472 1473 1474 1475 1476 1477

Cryptographic 2lgorithm$ 7S2 Cryptographic 8ength$ 4-*' Cryptographic Parameters$ .2,P Cryptographic Parameters$ PKCS" v".5 Cryptographic Fsage Mask$ /rap Key Custom 2ttribute$ 6-Serial "1(4 Custom 2ttribute$ 6-I0 5'+&* .bJect Mroup$ Key encryption group " =ame$ PublicKey"
1478$.2+ #egistering a Key Pair 1479>uring a Create ,ey /air or 1e-key ,ey /air operation4 a <ink !ttri.ute is automatically 1480created .y the server #or each o.?ect i.e.4 a link is created #rom the private key to the 1481pu.lic key and vice versa". Certain attri.utes are the same #or .oth o.?ects and are set 1482.y the server $hile creating the key pair. 0he ,-+/ protocol does not support an 1483eBuivalent operation #or registering a key pair. Clients are a.le to register the o.?ects 1484independently and manually set the <ink attri.utes to make the server a$are that these 1485keys are associated $ith each other. ;hen the <ink attri.ute is set #or .oth o.?ects4 the
98
99 1486server should veri#y that the registered o.?ects indeed correspond to each other and 1487apply similar restrictions as i# the key pair $as created on the server. 1488Clients should per#orm the #ollo$ing steps $hen registering a key pair: 1489 5. 7egister the public key and set all associated attributes$ 1490 a. Cryptographic 2lgorithm 1491 b. Cryptographic 8ength 1492 c. Cryptographic Fsage Mask 1493 '. 7egister the private key and set all associated attributes 1494 a. Cryptographic 2lgorithm is the same for both public and private key 1495 b. Cryptographic 8ength is the same for both public and private key 1496 c. Cryptographic Parameters may be setQ if set# the value is the same for both the public 1497 and private key 1498 d. Cryptographic Fsage Mask is set# but does not contain the same value for both the 1499 public and private key 1500 e. 8ink is set for the Private Key 3ith 8ink ?ype "u!lic Key 7in; and the 8inked .bJect 1501 Identifier of the corresponding Public Key 1502 f. 8ink is set for the Public Key 3ith 8ink ?ype "rivate Key 7in; and the 8inked .bJect 1503 Identifier of the corresponding Private Key 1504$.2, !on%Cryptograp-ic .b/ects 15050he ,-+/ protocol allo$s clients to register *ecret >ata o.?ects. *ecret >ata o.?ects 1506may include pass$ords or data that are used to derive keys. 1507,-+/ de#ines *ecret >ata as cryptographic o.?ects. 5ven i# the o.?ect is not used #or 1508cryptographic purposes4 clients may still set certain attri.utes4 such as the Cryptographic 1509Asage -ask4 #or this o.?ect unless other$ise stated. *imilarly4 servers set certain 1510attri.utes #or this o.?ect4 including the >igest4 *tate4 and certain >ate attri.utes4 even i# 1511the attri.utes may seem relevant only #or other types o# cryptographic o.?ects. 1512;hen registering a *ecret >ata o.?ect4 the #ollo$ing attri.utes are set .y the server: 1513 Fnique Identifier 1514 .bJect ?ype 1515 0igest 1516 State 1517 Initial 0ate 1518 8ast Change 0ate 1519;hen registering a *ecret >ata o.?ect #or non-cryptographic purposes4 the #ollo$ing 1520attri.utes are set .y either the client or the server: 1521
Cryptographic Fsage Mask
100
101 1522$.20 &symmetric Concepts @it- 'ymmetric Keys 15230he Cryptographic Asage -ask attri.ute is intended to support asymmetric concepts 1524using symmetric keys. 0his is common practice in esta.lished crypto systems: the -!C 1525is an eDample o# an operation $here a single symmetric key is used at .oth ends4 .ut 1526policy dictates that one end may only generate cryptographic tokens using this key the 1527-!C" and the other end may only veri#y tokens. 0he security o# the system #ails i# the 1528veri#ying end is a.le to use the key to per#orm generate operations. 1529+n these cases it is not su##icient to descri.e the usage policy on the keys in terms o# 1530cryptographic primitives like EencryptF vs. EdecryptF or EsignF vs. Everi#yF. 0here are t$o 1531reasons $hy this is the case. 1532
1533 1534 1535 1536 1537
In some of these operations# such as M2C generate and verify# the same cryptographic primitive is used in both of the complementary operations. M2C generation involves computing and returning the M2C# 3hile M2C verification involves computing that same M2C and comparing it to a supplied value to determine if they are the same. ?hus# both generation and verification use the KencryptL operation# and the t3o usages are not able to be distinguished by considering only KencryptL vs. KdecryptL. Some operations 3hich require separate key types use the same fundamental cryptographic primitives. or e6ample# encryption of data# encryption of a key# and computation of a M2C all use the fundamental operation KencryptL# but in many applications# securely differentiated keys are used for these three operations. Simply looking for an attribute that permits KencryptL is not sufficient.
1538
1539 1540 1541 1542
1543!llo$ing the use o# these keys outside o# their speciali(ed purposes may compromise 1544security. +nstead4 speciali(ed application-level permissions are necessary to control the 1545use o# these keys. ,-+/ provides several pairs o# such permissions in the Cryptographic 1546Asage -ask '.1%"4 such as:
-!C 25N51!05 -!C =51+6L 6or cryptographic -!C operations. !lthough it is possi.le to compose certain -!Cs using a series o# encrypt calls4 the security o# the -!C relies on the operation .eing atomic and speci#ic. 6or composite cryptogram operations such as #inancial C=C or !1NC. 0o speci#y eDactly $hich cryptogram the key is used #or it is also necessary to speci#y a role #or the key see *ection '.I ECryptographic /arametersF in ". 0o accommodate secure routing o# tra##ic and data. +n many areas that rely on symmetric techniBues nota.ly4 .ut not eDclusively #inancial net$orks"4 in#ormation is sent #rom place to place encrypted using shared symmetric keys. ;hen encryption keys are changed4 it is desira.le #or the change to .e an atomic operation4 other$ise distinct un$rap-$rap or decrypt-encrypt steps risk
25N51!05 C1L/0)21!=!<+>!05 C1L/0)21!-
01!N*<!05 5NC1L/0 01!N*<!05 >5C1L/0 01!N*<!05 ;1!/ 01!N*<!05 AN;1!/
102
103
leaking the plainteDt data during the translation process. T!"#S$"T% %# !&PT'(% !&PT is used #or data encipherment. T!"#S$"T% )!"P'U#)!"P is used #or key $rapping.
1547
T A6LE 8: C R9PT/%RAP7IC USA%E #AS"S PAIRS
1548+n order to support asymmetric concepts using symmetric keys in a ,-+/ system4 the 1549server implementation needs to .e a.le to di##erentiate .et$een clients #or generate 1550operations and clients #or veri#y operations. !s indicated .y *ection ' E!ttri.utesF" o# 1551there is a single key o.?ect in the system to $hich all relevant clients re#er4 .ut $hen a 1552client reBuests that key4 the server is a.le to choose $hich attri.utes permissions" to 1553send $ith it4 .ased on the identity and con#igured access rights o# that speci#ic client. 15540here is4 thus4 no need to maintain and synchroni(e distinct copies o# the symmetric key 1555O ?ust a need to de#ine access policy #or each client or group o# clients. 15560he internal implementation o# this #eature at the server end is a matter o# choice #or the 1557vendor: storing multiple key .locks $ith all necessary com.inations o# attri.utes or 1558generating key .locks dynamically are .oth accepta.le approaches. 1559$.21 &pplication 'pecific Information 15600he !pplication *peci#ic +n#ormation attri.ute is used to store data $hich is speci#ic to 1561the application s" using the o.?ect. *ome eDamples o# !pplication Namespace and 1562!pplication >ata pairs are given .elo$. 1563 SMIM,# PsomeuserRcompany.comP 1564 ?8S# Psome.domain.nameP 1565 !olume Identification# P"1((4(4(4P 1566 ile =ame# Psecret.docP 1567 Client Menerated Key I0# S45-**4--(P 15680he #ollo$ing !pplication Namespaces are recommended: 1569 SMIM, 1570 ?8S 1571 IPS,C 1572 @??PS 1573 PMP 1574 !olume Identification 1575 ile =ame 1576 8?.4 and 8?.5 1577 8I>727G-8?.4 and 8I>727G-8?.5 1578,-+/ provides optional support #or server-generated !pplication >ata. Clients may 1579reBuest the server to generate the !pplication >ata #or the client .y omitting !pplication 104
105 1580>ata $hile setting or modi#ying the !pplication *peci#ic +n#ormation attri.ute. ! server 1581only generates the !pplication >ata i# the !pplication >ata is completely omitted #rom 1582the reBuest4 and the client-speci#ied !pplication Namespace is recogni(ed and 1583supported .y the server. !n eDample #or reBuesting the server to generate the 1584!pplication >ata is sho$n .elo$: 1585
!dd!ttri.ute AniBue +>4 !pp*pec+n#oQ!ppName*paceRG<+C1!1L-<0)%GS"@
1586+# the server does not recogni(e the namespace4 the E!pplication Namespace Not 1587*upportedF error is returned to the client. 1588+# the !pplication >ata is set to null4 as sho$n in the eDample .elo$4 and the !pplication 1589Namespace is recogni(ed .y the server4 the server does not generate the !pplication 1590>ata #or the client. 0he server stores the !pplication *peci#ic +n#ormation attri.ute $ith 1591the !pplication >ata value set to null. 1592 !dd!ttri.ute AniBue +>4 !pp*pec+n#oQ!ppName*paceRG<+C1!1L-<0)%G4 1593!pp>ataRnullS"@ 1594$.22 Mutating &ttributes 1595,-+/ does not support server mutation o# client-supplied attri.utes. +# a server does not 1596accept an attri.ute value that is .eing speci#ied inside the reBuest .y the client4 the 1597server returns an error and speci#ies E+nvalid 6ieldF as 1esult 1eason. 1598!ttri.utes that are not set .y the client4 .ut are implicitly set .y the server as a result o# 1599the operation4 may optionally .e returned .y the server in the operation response inside 1600the 0emplateO!ttri.ute. 1601+# a client sets a time-related attri.ute to the current date and time as perceived .y the 1602client"4 .ut as a result o# a clock ske$4 the speci#ied date o# the attri.ute is earlier than 1603the time perceived .y the server4 the serverGs policy is used to determine $hether to 1604accept the E.ackdated attri.uteF. ,-+/ does not reBuire the server to #ail a reBuest i# a 1605.ackdated attri.ute is set .y the client. 1606+# a server does not support .ackdated attri.utes4 and cryptographic o.?ects are 1607eDpected to change state at the speci#ied current date and time as perceived .y the 1608client"4 clients are recommended to issue the operation that $ould implicitly set the date 1609#or the client. 6or eDample4 instead o# eDplicitly setting the !ctivation >ate4 clients could 1610issue the !ctivate operation. 0his $ould reBuire the server to set the !ctivation >ate to 1611the current date and time as perceived .y the server. 1612+# it is not possi.le to set a date attri.ute via an operation4 and the server does not 1613support .ackdated attri.utes4 clients need to take into account that potential clock ske$ 1614issues may cause the server to return an error even i# a date attri.ute is set to the 1615clientGs current date and time. 16166or additional in#ormation4 re#er to the sections descri.ing the *tate attri.ute and the 16170ime *tamp #ield in !"#IP$Spec&' 1618.
106
107 1619$.$6 Interoperable Key !aming for Tape 16200his section descri.es methods #or creating and storing key identi#iers that are 1621interopera.le across multi-vendor ,-+/ clients. 1622$.$6.1 !ati"e Tape )ncryption by a KMIP Client 16230his method is primarily intended to promote interopera.le key naming .et$een tape 1624li.rary products $hich already support non-,-+/ key managers4 $here ,-+/ support is 1625.eing added. 1626;hen those eDisting li.rary products .ecome ,-+/ clients4 a common method #or 1627naming and storing keys may .e used to support moving tape cartridges .et$een the 1628li.raries4 and success#ully retrieving keys4 assuming that the clients have appropriate 1629access privileges. 0he li.rary clients may .e #rom multiple vendors4 and may .e served 1630.y a ,-+/ key manager #rom a di##erent vendor. 1631$.$6.1.1 Met-od ."er"ie@ 1632 ?he method uses the KMIP 2pplication Specific Information D2SIE attributeNs 2pplication
1633 1634
0ata field to store the key name. ?he 2SI 2pplication =amespace is used to identify the namespace Dsuch as 8I>727G-8?.4 or 8I>727G-8?.5E.
1635
1636 1637 1638
?he method also uses the tape formatPs Key 2ssociated 0ata DK20E fields to store the key name. ?ape formats may provide both authenticated and unauthenticated storage for the K20 data. ?his method ensures optimum utiliAation of the authenticated K20 data 3hen the tape format supports authentication. ?he method supports both client-generated and server-generated key names. ?he method# in many cases# is back3ard-compatible if tapes are returned to a non-KMIP key manager environment. Key names stored in the KMIP serverPs 2SI attribute are al3ays 2SCIIformat. Key names stored on the KMIP clientPs K20 fields are al3ays numeric format# due to space limitations of the tape format. ?he method basically consists of implementing a specific algorithm for converting bet3een te6t and numeric formats. ?he algorithm used by this conversion is reversible.
1639 1640
1641
1642
1643 1644 1645
1646
1647$.$6.1.2 5efinitions 1648 Key 2ssociated 0ata DK20E. Part of the tape format. May be segmented into
1649 1650
authenticated and unauthenticated fields. K20 usage is detailed in the SCSI SSC-( standard from the ?"- organiAation.

1651 1652
1653 1654 1655 1656 1657 1658
2pplication Specific Information D2SIE. 2 KMIP attribute. @e6adecimal numeric characters. Case-sensitive# printable# single byte 2SCII characters representing the numbers - through * and uppercase alpha 2 through . DFS-2SCII characters (-h-(*h and 4"h-4'hE. @e6adecimal numeric characters are al3ays paired# each pair representing a single &-bit numeric value. 2 leading Aero character is provided# if necessary# so that every byte in the tapeNs K20 is represented by e6actly 1 he6adecimal numeric characters.
1659
1660
=DkE. ?he number of bytes in the tape formatPs combined K20 fields Dboth authenticated and unauthenticatedE.
108
109 1661
1662
=DaE# =DuE. ?he number of bytes in the tape formatPs authenticated# and unauthenticated K20 fields# respectively.
1663$.$6.1.$ &lgorit-m 1. !umeric to te*t direction Atape formatBs K&5 to KMIP &'IC 1664>escription: !ll in#ormation contained in the tape #ormatGs ,!> #ields is converted to a 1665null-terminated !*C++ string consisting o# heDadecimal numeric character pairs. 6irst4 the 1666unauthenticated ,!> data is converted to teDt. 0hen4 the authenticated ,!> data is 1667converted and appended to the end o# the string. 0he string is then null-terminated. 1668+mplementation 5Dample: 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687
". 0efine an input buffer siAed for =DkE. or 8?.4# =DkE is 44 bytes D"1 bytes authenticated# (1 unauthenticatedE. or 8?.5# =DkE is *1 bytes D'bytes authenticated# (1 bytes unauthenticatedE. 1. 0efine an output buffer sufficient to contain a null-terminated string 3ith a ma6imum length of 1T=DkEO" bytes. (. 0efine the standard P.SII Dalso kno3n as CE locale. ,ach character in the string is a single-byte FS-2SCII character. 4. Copy the tape formatNs K20 data# from the unauthenticated K20 field first# to the input buffer. ,ffectively# the first byte Dbyte -E of the input buffer is the first byte of unauthenticated K20. >ytes from the authenticated K20 are concatenated# after the unauthenticated bytes. 5. or each byte in the input buffer# convert to FS-2SCII as follo3s$ a. Convert the bytePs value to e6actly 1 he6adecimal numeric characters# including a leading - 3here necessary. 2ppend these 1 numeric characters to the output buffer# 3ith the high-nibble represented by the left-most he6adecimal numeric character. b. 2fter all byte values have been converted# null terminate the output buffer. '. /hen storing the string to the KMIP server# use the obJectNs 2SI attributeNs 2pplication 0ata field. Store the namespace Dsuch as 8I>727G8?.4E in the 2SI attributeNs 2pplication =amespace field.
1688$.$6.1.( &lgorit-m 2. Te*t to numeric direction AKMIP &'I to tape formatBs K&5C 1689>escription: 7eDadecimal numeric character pairs in the null-terminated !*C++ string are 1690converted to single .yte numeric values4 and stored in the tape #ormatGs ,!> #ields. 0he 1691authenticated ,!> #ield is populated #irst4 #rom a su.-string consisting o# the last 2TN a" 1692characters in the #ull string. !ny remaining characters in the string are converted and 1693stored to the unauthenticated ,!> #ield. 0he null termination .yte is not converted. 1695+mplementation 5Dample: 1696 1697 1698 1699 1700 1701
". .btain the keyNs name from the KMIP serverNs 2SI attribute for that obJect. Copy the null terminated string to an input buffer of siAe 1T=DkE O " bytes. or 8?.4# an &* character string# including null termination# is sufficient to represent any key name stored directly in the K20 fields. or 8?.5# a "*5 character string# including null termination# is sufficient to represent any key name stored directly in the K20 fields..
110
111 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714
1. 0efine output buffers for unauthenticated K20# and authenticated K20# of siAe =DuE and =DaE respectively. or 8?.4# this 3ould be (1 bytes of unauthenticated data# and "1 bytes of authenticated data. or 8?.5# this 3ould be (1 bytes of unauthenticated data and '- bytes of authenticated data. (. 0efine the standard P.SII Dalso kno3n as CE locale. ,ach character in the string is a single-byte FS-2SCII character. 4. irst# populate the authenticated K20 buffer# converting a sub-string consisting of the last 1T=DaE characters of the full string# not including the null termination byte. 5. /hen the authenticated K20 is filled# ne6t populate the unauthenticated K20 buffer# by converting the remaining he6adecimal character pairs in the string.
1715$.$6.1.+ )*ample .utput 17160he #ollo$ing are eDamples illustrating some results o# this method. +n the #ollo$ing 1717eDamples4 the si(es o# the ,!> #or <0)% are used. >i##erent tape #ormats may utili(e 1718di##erent ,!> si(es. 17195Dample 1. 6ull com.ined ,!> #or <0)% 17200his <0)% tapeGs com.ined ,!> contains the #ollo$ing data represented in 1721heDadecimal". 6or <0)%4 the unauthenticated ,!> contains '2 .ytes4 and the 1722authenticated ,!> contains 12 .ytes. 1723 1724 1725 1726 1727
5Dample 1a. 7eDadecimal numeric data #rom a tapeGs ,!>. *haded data is authenticated .y the tape drive. 02 0% 17 11 'M %' %2 'I '0 %1 '' '% 'M '1 %% '' %1 %1 %' 'I '2 %2 07 6I 8% 8% '2 'I '0 '& %C '% '0 '0 '0 'M '0 '8 '2 '& '0 '% '1 '2
17280he algorithm converts the numeric ,!> data to the #ollo$ing &M character null1729terminated string #or storage in the !pplication >ata #ield o# a ,-+/ o.?ectUs !pplication 1730*peci#ic +n#ormation attri.ute. 0he !*+ !pplication Namespace contains E<+C1!1L1731<0)%F. 1732 1733 1734 1735 1736 1737 1738 1739
5Dample 1.. 0eDt string #rom ,-+/ !*+ !pplication >ata. *haded characters are derived #rom authenticated data. 0he null character is represented as VnullW 020%1711'M%'%2'I'0%1'''%'M'1%%''%1%1%''I'2%2076I8%8%'2'I'0'&%C'% '0'0'0'M'0'8'2'&'0'%'1'2VnullW 5Dample 1c. 0he heDadecimal values o# the &M A*-!*C++ characters in string 1.4 #rom the ,-+/ !*+ !pplication >ata. Note: these values are al$ays in the range '0h-'Mh4 or in the range %1h-%Ih4 or the 0h null.
112
113 1740 1741 1742 1743

'0 '2 '0 '% '1 '7 '1 '1 '' 'M '% '' '% '2 '' 'I '' '0 '% '1 '' '' '' '% '' 'M '' '1 '% '% '' '' '% '1 '% '1 '% '' '' 'I '' '2 '% '2 '0 '7 %I 'I '8 '% '8 '% '' '2 '' 'I '' '0 '' '& '% %' '' '% '' '0 '' '0 '' '0 '' 'M '' '0 '' '8 '' '2 '' '& '' '0 '' '% '' '1 '' '2 00
17446or the reverse trans#ormation4 a client $ould retrieve the string in 1. #rom the server4 1745derive the numeric values sho$n in 1a4 and store them to the tape #ormatUs ,!> data. 17466irst4 the su.-string containing the right-most 2% characters o# the #ull 1. string are used 1747to derive the 12-.yte authenticated ,!>. 0he remaining characters are used to derive 1748the '2-.yte unauthenticated ,!>. 17495Dample 2. !uthenticated ,!> only4 #or <0)% 17500his <0)% tapeGs ,!> contains the #ollo$ing data represented in heDadecimal"4 all 12 1751.ytes o.tained #rom the authenticated ,!> #ield. 0here is no unauthenticated ,!> data. 1752 1753 1755
5Dample 2a. 7eDadecimal numeric data #rom a tapeUs ,!>. *haded data is authenticated. 17 %& '' CI 20 %2 10 !7 5& 08 6& C7
17560he algorithm converts the numeric ,!> data to the #ollo$ing 2% character null1757terminated string4 #or storage in the !pplication >ata #ield o# a ,-+/ o.?ectUs !pplication 1758*peci#ic +n#ormation attri.ute. 1759 1760 1761 1762
5Dample 2.. 0eDt string #rom ,-+/ !*+ !pplication >ata. *haded characters are derived #rom authenticated data. 0he null character is represented as VnullW 17%&''CI20%210!75&086&C7VnullW
17636or the reverse trans#ormation4 a client $ould derive the numeric values in 2a4 and store 1764them to the tape #ormatUs ,!> data. 0he right-most 2% characters o# the string in 2. are 1765used to derive the 12 .yte authenticated ,!>. +n this eDample4 there is no 1766unauthenticated ,!> data. 17675Dample '. /artially #illed authenticated ,!> originating #rom a non-,-+/ method4 #or 1768<0)% 17690his <0)% tapeGs ,!> contains the #ollo$ing data represented in heDadecimal". 0he 1770unauthenticated ,!> contains 10 .ytes4 and the authenticated ,!> contains & .ytes. 1771*ince the authenticated ,!> $as not #illed4 .ut the unauthenticated data $as populated4 1772the method creating this key name is potentially not .ack$ard-compati.le $ith the ,-+/ 1773key naming method. *ee .ack$ard-compati.ility assessment4 .elo$. 1774 1775
5Dample 'a. 7eDadecimal numeric data #rom a non-,-+/ tapeUs ,!>. *haded data is authenticated.
114
115 1776 1777 1778 17790he algorithm converts the numeric ,!> data to the #ollo$ing 'I character null1780terminated string4 #or storage in the !pplication >ata #ield o# a ,-+/ o.?ectUs !pplication 1781*peci#ic +n#ormation attri.ute. 1782 1783 1784 1785
5Dample '.. 0eDt string #rom ,-+/ !*+ !pplication >ata. *haded characters are derived #rom authenticated data. 0he null character is represented as VnullW 020%1711'M%'%2'I'0%1'0'0'0'M'0'8'2'&VnullW 02 0% 17 11 'M %' %2 'I '0 %1 '0 '0 '0 'M '0 '8 '2 '&
17866or the reverse trans#ormation4 a client $ould derive the same numeric values sho$n in 1787'a4 and store them to the tapeUs ,!>. Cut their storage locations $ithin the ,!> no$ 1788di##ers see 'c". 0he right-most 2% characters #rom the teDt string in '. are used to derive 1789the 12-.yte authenticated ,!>. 0he remaining characters are used to #ill the '2-.yte 1790unauthenticated ,!>. 1791 1792 1793 1794
5Dample 'c. 7eDadecimal numeric data #rom a tapeUs ,!>. *haded data is authenticated. 02 0% 17 11 'M %' %2 'I '0 %1 '0 '0 '0 'M '0 '8 '2 '&
1795$.$6.1., 7ac;@ard%compatibility assessment 1796;here all the #ollo$ing conditions eDist4 a non-,-+/ solution may encounter 1797compati.ility issues during the 1ead and !ppended ;rite use cases. 1798 1799 1800 1801 1802 1803
". ?he tape format supports authenticated K20# but the non-KMIP solution does not use# or only partially uses# the authenticated K20 field. 1. ?he non-KMIP solution is sensitive to data position 3ithin the combined K20. (. ?he media 3as 3ritten in a KMIP environment# using this method# then moved to the non-KMIP environment.
1804$.$1 #e"ocation #eason Codes 18050he enumerations #or the 1evocation 1eason attri.ute speci#ied in ,-+/ see ta.le 1806M.1.'.2.1M in " are aligned $ith the 1eason Code speci#ied in K.80M and re#erenced in 180716C 82&0 $ith the #ollo$ing eDceptions. 0he certificate*old and remo+e,rom !$ 1808reason codes have .een eDcluded #rom 4 since this version o# ,-+/ does not support 1809certi#icate suspension putting a certi#icate hold" or unsuspension removing a certi#icate 1810#rom hold". 0he aa ompromise reason code has .een eDcluded #rom since it only 1811applies to attri.ute certi#icates4 $hich are out-o#-scope #or . 0he pri+iledge)it-dra.n 1812reason code is included in since it may .e used #or either attri.ute or pu.lic key 116
117 1813certi#icates. +n the conteDt o# its use $ithin ,-+/ it is assumed to only apply to pu.lic key 1814certi#icates. 1815$.$2 Certificate #ene@al< Update< and #e%;ey
1816 1817 1818 1819 1820 1821
?he process of generating a ne3 certificate to replace an e6isting certificate may be referred to by multiple terms# based upon 3hat data 3ithin the certificate is changed 3hen the ne3 certificate is created. In all situations# the ne3 certificate includes a ne3 serial number and ne3 validity dates. uses the follo3ing terminology 3hich is aligned 3ith the definitions found in I,? 7 Cs [+F%36!7] and B7 C4*4*C$
1822
1823 1824
Certi#icate *ene,al$ ?he issuance of a ne3 certificate to the subJect 3ithout changing the subJect public key or other information De6cept the serial number and certificate validity datesE in the certificate. Certi#icate >pdate) ?he issuance of a ne3 certificate# due to changes in the information in the certificate other than the subJect public key. Certi#icate *e;ey$ ?he generation of a ne3 key pair for the subJect and the issuance of a ne3 certificate that certifies the ne3 public key.
1825
1826
1827
1828
18290he ,-+/ *peci#ication supports certi#icate rene$als using the 1e-Certi#y operation and 1830certi#icate updates using the Certi#y operation. Certi#icate rekey is supported through the 1831su.mission o# a 1e-key ,ey /air operation4 $hich generates a replacement ne$" key 1832pair4 #ollo$ed .y a Certi#y operation4 $hich issues a ne$ certi#icate containing the 1833replacement ne$" pu.lic key. 1834$.$$ Key )ncoding
1835 1836 1837 1838 1839 1840
?3o parties receiving the same key as a Key !alue >yte String make use of the key in e6actly the same 3ay in order to interoperate. ?o ensure that# it is necessary to define a correspondence bet3een the abstract synta6 of Key and the notation in the standard algorithm description that defines ho3 the key is used. ?he ne6t sections establish that correspondence for the algorithms 2,S and ?riple-0,S .
1841$.$$.1 &)' Key )ncoding 1842 section 8.24 titled ,ey 5Dpansion4 uses the input key as an array o# .ytes indeDed 1843starting at 0. 0he #irst .yte o# the ,ey .ecomes the key .yte in !5* that is la.eled indeD 18440 in and the other key .ytes #ollo$ in indeD order. 1845/roper parsing and key load o# the contents o# the ,ey #or !5* is determined .y using 1846the #ollo$ing ,ey .yte string to generate and match the key eDpansion test vectors in 1847!ppendiD ! #or the 12&-.it 1I .yte" !5* Cipher ,ey: 2C 75 18 1I 2& !5 >2 !I !C 67 184818 && 0M C6 %6 'C. 1849$.$$.2 Triple%5)' Key )ncoding 1850! 0riple->5* key consists o# three keys #or the cryptographic engine ,ey14 ,ey24 and 1851,ey'" that are each I% .its even though only 8I are used"@ the three keys are also 1852re#erred to as a key .undle ,5L" . ! key .undle may employ either t$o or three 1853mutually independent keys. ;hen only t$o are employed called t$o-key 0riple->5*"4 1854then ,ey1 R ,ey'.
118
119 18555ach key in a 0riple->5* key .undle is eDpanded into a key schedule according to a 1856procedure de#ined in !ppendiD !. 0hat procedure num.ers the .its in the key #rom 1 to 1857I%4 $ith num.er 1 .eing the le#t-most4 or most signi#icant .it. 0he #irst .yte o# the ,ey is 1858.its 1 through & o# ,ey14 $ith .it 1 .eing the most signi#icant .it. 0he second .yte o# the 1859,ey is .its M through 1I o# ,ey14 and so #orth4 so that the last .yte o# the ,5L is .its 87 1860through I% o# ,ey' or ,ey2 #or t$o-key 0riple->5*". 1861/roper parsing and key load o# the contents o# ,ey #or 0riple->5* is determined .y 1862using the #ollo$ing ,ey .yte string to generate and match the key eDpansion test vectors 1863in !ppendiD C #or the key .undle: 1864,ey1 R 012'%8I7&M!CC>56 1865,ey2 R 2'%8I7&M!CC>5601 1866,ey' R %8I7&M!CC>56012' 1867$.$( Using t-e 'ame &symmetric Key Pair in Multiple &lgorit-ms 18680here are mathematical relationships .et$een certain asymmetric cryptographic 1869algorithms such as the >igital *ignature !lgorithm >*!" and >i##ie-7ellman >7" and 1870their elliptic curve eBuivalents 5C>*! and 5C>7 that allo$ the same asymmetric key 1871pair to .e used in .oth algorithms. +n addition4 there are overlaps in the key #ormat used 1872to represent the asymmetric key pair #or each algorithm type.
1873 1874 1875 1876 1877 1878 1879
,ven though a single key pair may be used in multiple algorithms# the KMIP Specification has chosen to specify separate key formats for representing the asymmetric key pair for use in each algorithm. ?his approach keeps KMIP in line 3ith the reference standards De.g.# =IS? IPS "&'-( B IPS"&'-(C# 2=SI I*.41 # etcE from 3hich the key formats are obtained and the best practice documents De.g.# =IS? SP&---5+ part " # =IS? SP&---5'2 # etcE 3hich recommend that a key pair only be used for one purpose.
1880$.$+ Cryptograp-ic 9engt- of &symmetric Keys 18810he value e.g.4 20%& .its" re#erred to in the ,-+/ ryptograp-ic $engt- attri.ute #or an 1882asymmetric pu.lic or private" key may .e misleading4 since this length only re#ers to 1883certain portions o# the mathematical values that comprise the key. 0he actual length o# 1884all the mathematical values comprising the pu.lic or the private key is longer than the 1885re#erenced value. 0his point may .e illustrated .y looking at the components o# a 1*! 1886pu.lic and private key. 18870he 1*! pu.lic key is comprised o# a modulus n" and an pu.lic" eDponent e". ;hen 1888one indicates that the 1*! pu.lic key is 20%& .its in length that is a re#erence to the .it 1889length o# the modulus n" only. *o the #ull length o# the 1*! pu.lic key is actually longer 1890than 20%& .its4 since it also includes the length o# the eDponent e" and the overhead o# 1891the encoding e.g.4 !*N.1" o# the key material. 18920he 1*! private key is comprised o# a modulus n"4 the pu.lic eDponent e"4 the private 1893eDponent d"4 prime 1 p"4 prime 2 B"4 eDponent 1 d mod p-1""4 eDponent 2 d mod p18941""4 and coe##icient inverse o# B" mod p". )nce again the 20%& .it key length is
120
121 1895re#erring only to the length o# the modulus n"4 so the overall length o# the private key 1896$ould .e longer given the num.er o# additional components $hich comprise the key and 1897the overhead o# encoding e.g.4 !*N.1" o# the key material. 1898,-+/ implementations need to ensure they do not make assumptions a.out the actual 1899length o# asymmetric pu.lic and private" key material .ased on the value speci#ied in 1900the ryptograp-ic $engt- attri.ute. 1901$.$, 5isco"er Versions 19020he >iscover =ersions operation allo$s clients and servers to identi#y a ,-+/ protocol 1903version that .oth client and server understand. 0he operation $as added to ,-+/ 1.1. 1904,-+/ 1.0 clients and servers may there#ore not support this operation. +# the >iscover 1905=ersions reBuest is sent to a ,-+/ 1.0 server and the server does not support the 1906operation4 the server returns the E)peration Not *upportedF error. 1907 0he operation addresses .oth the Edum.F and EsmartF client scenarios. >um. clients 1908may simply pick the #irst protocol version that is returned .y the server4 assuming that 1909the client provides the server $ith a list o# supported protocol version. *mart clients may 1910reBuest the server to return a complete list o# supported protocol versions .y sending an 1911empty reBuest payload and picking a protocol version that is supported .y .oth client 1912and server. 1913Clients speci#y the protocol version in the reBuest header and optionally provide a list o# 1914protocol versions in the reBuest payload. +# the protocol version in the reBuest header is 1915not speci#ied in the reBuest payload and the server does not support any protocol 1916version speci#ied in the reBuest payload4 the server returns an empty list in the response 1917payload. +n this scenario4 clients are a$are that the reBuest did not result in an error and 1918could communicate $ith the server using the protocol version speci#ied in the reBuest 1919header. 1920$.$0 Vendor )*tensions 1921,-+/ allo$s #or vendor eDtensions in a num.er o# areas: 1922 1. 5numerations have speci#ic ranges $hich are noted as eDtensions 1923 2. +tem 0ag values o# the #orm 0D8%DDDD are reserved #or vendor eDtensions 1924 '. !ttri.utes may .e de#ined .y the client $ith a ED-E pre#iD or .y the server $ith a Ey-E 1925 pre#iD 19260his section covers only item 2. 19275Dtensions may .e used .y vendors to communicate in#ormation .et$een a ,-+/ client 1928and a ,-+/ server that is not currently de#ined $ithin the ,-+/ speci#ication. 1929! common use o# eDtensions is to allo$ #or the structured de#inition o# attri.utes using 1930,-+/ 00<= encoding rather than encoding vendor speci#ic in#ormation in opaBue .yte 1931strings.
122
123 1932$.$0.1 =uery )*tension Information 19330he 5Dtension +n#ormation structure added to ,-+/ 1.1 and the Nuery 5Dtension <ist 1934and Nuery 5Dtension -ap #unctions o# the Nuery )peration provide a mechanism #or a 1935,-+/ client to .e a.le to determine $hich eDtensions a ,-+/ server supports. 1936! client may reBuest the list o# 5Dtensions supported .y a ,-+/ 1.1 server .y speci#ying 1937the Nuery 5Dtension <ist value in the Nuery 6unction #ield. 0his provides the names o# 1938the supported eDtensions. 19395Dample output: 1940 1941 1942 1943
5Dtension +n#ormation 5Dtension Name: !C-5 <)C!0+)N 5Dtension +n#ormation 5Dtension Name: !C-5 X+/ C)>5
1945! client may reBuest the details o# 5Dtensions supported .y a ,-+/ 1.1 server .y 1946speci#ying the Nuery 5Dtension -ap value in the Nuery 6unction #ield. 0his provides the 1947names o# the supported eDtensions. 19485Dample output: 1949 1950 1951 1952 1953 1954 1955 1956
5Dtension +n#ormation 5Dtension Name: !C-5 <)C!0+)N 5Dtension 0ag: 0D8%!!01 5Dtension 0ype: 0eDt *tring 5Dtension +n#ormation 5Dtension Name: !C-5 X+/ C)>5 5Dtension 0ag: 0D8%!!02 5Dtension 0ype: +nteger
1957$.$0.2 #egistering )*tension Information 1958!s tag values and their interpretation #or the most part should .e kno$n #or a client and 1959server to meaning#ully use an eDtension4 the #ollo$ing registration procedure should .e 1960used. 1961 1. >ocument the 5Dtensions including: 1962 a. 5Dtension 0ag4 5Dtension Name4 5Dtension 0ype values to .e reserved 1963 .. ! .rie# description o# the purpose o# the 5Dtension 1964 c. 5Dample use case messages reBuests and responses" 1965 d. 5Dample 2uidance 1966 2. *end the >ocument to the ,-+/ 0C reBuesting revie$ 124
125 1967 '. 1eBuest a ,-+/ 0C .allot on accepting the reservation o# the 5Dtension 1968+t is anticipated that a template document may .e produced #or this registration process. 1969$.$1 Certificate &ttribute #elated ields 19700he ,-+/ v1.0 ertificate Identifier/ ertificate Sub0ect and ertificate Issuer attri.utes 1971are populated #rom values #ound $ithin K.80M pu.lic key or /2/ certi#icates. +n ,-+/ 1972v1.0 these #ields are encoded as Te1t String4 .ut the values o# these #ields are o.tained 1973#rom certi#icates $hich are "S#.1 23.4056 or octet 2PGP6 encoded. +n ,-+/ v1.14 the 1974data type associated $ith these #ields is .eing changed #rom Te1t String to 7yte String 1975so that the values o# these #ields parsed #rom the certi#icates can .e preserved and no 1976conversion #rom the encoded values into a teDt string is necessary. 1977*ince these certi#icate-related attri.utes and associated #ields $ere included as part o# 1978the v1.0 ,-+/ speci#ication and that there may .e implementations supporting these 1979attri.utes using the 0eDt *tring encoding4 a decision $as made to deprecate these 1980attri.utes in ,-+/ v1.1 and replace them $ith ne$ly named attri.utes and #ields. !s part 1981o# this change4 separate certi#icate-related attri.utes #or K.80M certi#icates are .eing 1982introduced. Certi#icate attri.utes #or /2/ certi#icates may .e introduced in a su.seBuent 1983 post v1.1" release o# ,-+/. 19840a.le ' provides a list o# the deprecated certi#icate-related attri.utes and #ields $ith their 1985corresponding tag value. 1986
4e.re1/3e9 -33r2bu3e$F2el9 Certificate Identifier Certificate Issuer Certificate Issuer 2lternative =ame 4e.re1/3e9 ,/0 :/lue 41--"4 41--"5 41--"'
Certificate Issuer 0istinguished 41--"+ =ame Certificate SubJect Certificate SubJect 2lternative =ame Certificate SubJect 0istinguished =ame Issuer Serial =umber
1987 1988T A6LE :: 2 EPRECATE2 CERTI.ICATE RELATE2 ATTRI6UTES A02 . IEL2S
41--"2 41--"> 41--"C 41--(> 41--&+
1989 1990 19910a.le % provides a mapping o# v1.0 to v1.1 certi#icate attri.utes and #ields. 126
127 1992
4e.re1/3e9 :1"0 -33r2bu3e Certificate Identifier 4e.re1/3e9 :1"0 F2el9 Issuer Serial =umber Certificate Issuer Certificate Issuer I.5-* Certificate 0istinguished =ame Issuer Certificate Issuer 2lternative =ame Certificate SubJect Certificate SubJect I.5-* Certificate 0istinguished =ame SubJect Certificate SubJect 2lternative =ame
1993 1994T A6LE ;: # APPI0% /. < -'* T/ < -'- C ERTI.ICATE RELATE2 ATTRI6UTES A02 . IEL2S
Ne< :1"1 -33r2bu3e I.5-* Certificate Identifier
Ne< :1"1 F2el9 Issuer 0istinguished =ame Certificate Serial =umber Issuer 0istinguished =ame Issuer 2lternative =ame SubJect 0istinguished =ame SubJect 2lternative =ame
1995$.$2 Certificate #e"ocation 9ists 1996!ny Certi#icate 1evocation <ist C1<" checking $hich may .e reBuired #or certi#icate1997related operations such as register and re-key should .e per#ormed .y the client prior to 1998reBuesting the operation #rom a server. 1999 2000$.(6 Using t-e 3#a@4 Key ormat Type 2001!s de#ined in *ection 2.1.' o# the ,-+/ *peci#ication =1.14 the Era$F key #ormat is 2002intended to .e used #or Ea key that contains only cryptographic key material4 encoded as 2003a string o# .ytes.F !s discussed in *ection '.21.I o# the Asage 2uide4 the Era$F key 2004#ormat supports situations such as Enon-,-+/-a$are end-clients are a$are ho$ 2005$rapped cryptographic o.?ects possi.ly 1a$ keys" #rom the ,-+/ server should .e 2006used $ithout having to rely on the attri.utes provided .y the 2et !ttri.utes operationF 2007and in that regard is similar to the )paBue key #ormat type. E1a$F key #ormat is 2008intended to .e applied to symmetric keys and not asymmetric keys@ there#ore, this #ormat 2009is not speci#ied in the asymmetric key pro#iles included in ,-+/ =1.1. 2010 2011$.(1 5eprecated unctionality 2012Ase o# deprecated #unctionality4 as descri.ed in *ection '.'M4 is discouraged since such 2013#unctionality may .e dropped in a #uture release o# the ,-+/ standard. 2014
128
129
2015(
5eferred KMIP unctionality
20160he ,-+/ *peci#ication is currently missing items that have .een ?udged candidates #or 2017#uture inclusion in the speci#ication. 0hese items currently include: 2018
2019

7egistration of Clients. ?his 3ould allo3 in-band registration and management of clients# 3hich currently may only be registered and%or managed using off-line mechanisms. Client-requested specification of additional clients that are allo3ed to use a key. ?his requires coordinated identities bet3een the client and server# and as such# is deferred until registration of clients is addressed. 7egistration of =otifications. ?his 3ould allo3 clients to specify# using an in-band mechanism# information and events that they 3ish to be notified of# and 3hat mechanisms should be used for such notifications# possibly including the configuration of pushed cryptographic material. ?his functionality 3ould assume the 7egistration of Clients as a prerequisite. Key Migration. ?his 3ould standardiAe the migration of keys from one @SM to another# using mechanisms already in the protocol or ones added for this purpose. Server to Server key management. ?his 3ould e6tend the protocol to support communication bet3een key management servers in different key management domains# for purposes of e6porting and importing cryptographic material and potentially policy information. Multiple derived keys. ?his 3ould allo3 the creation of multiple derived keys from one or more input keys. =ote# ho3ever# that the current version of KMIP provides the capability to derive multiple keys and initialiAation vectors by creating a Secret 0ata obJect and specifying a cryptographic length equal to the total length of the derived obJects. IM8 encoding. ,6pression of KMIP in IM8 rather than in tag%type%length%value may be considered for the future. Specification of Mask Meneration unction. KMIP does not currently allo3 clients to specify the Mask Meneration unction and assumes that encryption or signature schemes# such as .2,P or PSS# use MM " 3ith the hash function as specified in the Cryptographic Parameters attribute. Client specification of MM s may be considered for the future. Server monitoring of client status. ?his 3ould enable the transfer of information about the client and its cryptographic module to the server. ?his information 3ould enable the server to generate alarms and%or disallo3 requests from a client running component versions 3ith kno3n vulnerabilities. Symmetric key pairs. .nly a subset of the cryptographic usage bits of the Cryptographic Fsage Mask attribute may be permitted for keys distributed to a particular client. KMIP does not currently address ho3 to securely assign and determine the applicable cryptographic usage for a client. @ard3are-protected attribute. ?his attribute 3ould allo3 clients and servers to determine if a key may only be processed inside a secure cryptographic device# such as an @SM. If this attribute is set# the key may only e6ist in clearte6t 3ithin a secure hard3are device# and all security-relevant attributes are bound to it in such a 3ay that they may not be modified outside of such a secure device. 2lternative profiles for key establishment. 8ess capable end-clients may not be able to support ?8S and should use a pro6y to communicate 3ith the key management system. ?he KMIP protocol does not currently define alternative profiles# nor does it allo3 endclients relying on the pro6y model to securely establish a key 3ith the server.
2020
2021 2022
2023
2024 2025 2026 2027
2028
2029
2030
2031 2032 2033
2034
2035 2036 2037
2038
2039
2040
2041 2042 2043 2044
2045
2046 2047 2048
2049
2050 2051 2052
2053
2054 2055 2056 2057
2058
2059 2060 2061
130
131 2062
2063 2064
2ttribute mutation. ?he possibility for the server to use attribute values different than requested by the client if these values are not suitable for the server# and return these values in the response# instead of failing the request. Cryptographic 0omain Parameters. KMIP allo3s a limited number of parameters to be specified during a Create Key Pair operation. 2dditional parameters may be considered for the future. Certificate Suspension%Fnsuspension. KMIP does not currently support certificate suspension Dputting a certificate on holdE or unsuspension Dremoving a certificate from holdE. 2dding support for certificate suspension%unsuspension into KMIP may be considered for the future. =amespace registration. ,stablishing a registry for namespaces may be considered for the future. 7egistering e6tensions to KMIP enumerations. ,stablishing a registry for e6tensions to defined KMIP enumerations# such as in support of profiles specific to I,,, P"'"*.( or other organiAations# may be considered for the future.
2065
2066 2067
2068
2069 2070 2071
2072
2073
2074
2075 2076
2077+n addition to the #unctionality listed a.ove4 the ,-+/ 0C is interested in esta.lishing a 2078CY! certi#ication and accreditation" process #or independent validation o# claims o# 2079,-+/ con#ormance. >e#ining and esta.lishing this process is a candidate #or $ork .y the 2080,-+/ 0C a#ter =1.1.
132
133
2081+
Implementation Conformance
20820his document is intended to .e in#ormational only and as such has no con#ormance 2083clauses. 0he con#ormance reBuirements #or the ,-+/ *peci#ication can .e #ound in the 2084J,-+/ *peci#icationJ document itsel#4 at the A1< noted in the ENormative 1e#erencesF 2085section o# this document.
134
135
2086
&ppendi* &. &c;no@ledgements
2087?he follo3ing individuals have participated in the creation of this specification and are gratefully 2088ackno3ledged$
2089/ri3inal Authors of the initial contri ution:

2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136
0avid >abcock# @P Steven >ade# I>M Paolo >eAoari# =et2pp Mathias >JUrkqvist# I>M >ruce >rinson# ,MC Christian Cachin# I>M ?ony Crossman# ?hales%nCipher Stan eather# @P Indra itAgerald# @P 9udy urlong# ,MC 9on Meater# ?hales%nCipher >ob Mriffin# ,MC 7obert @aas# I>M ?imothy @ahn# I>M 9ack @ar3ood# ,MC /alt @ubis# 8SI Mlen 9aquette# I>M 9eff KravitA# I>M Michael McIntosh# I>M >rian MetAger# @P 2nthony =adalin# I>M ,laine Palmer# I>M 9oe Pato# @P 7enV Pa3litAek# I>M Subhash Sankuratripati# =et2pp Mark Schiller# @P Martin Skagen# >rocade Marcus Streets# ?hales%nCipher 9ohn ?attan# ,MC Karla ?homas# >rocade Marko !ukoliW # I>M Steve /ierenga# @P @al 2ldridge# Sypris ,lectronics Mike 2llen# Symantec Mordon 2rnold# I>M ?odd 2rnold# I>M Matthe3 >all# .racle Corporation ,laine >arker# =IS? Peter >artok# !enafi# Inc. Mathias >JUrkqvist# I>M Kelley >urgin# =ational Security 2gency 9ohn Clark# @e3lett-Packard ?om Clifford# Symantec Corp. Mraydon 0odson# 8e6mark International Inc. Chris 0unn# Safe=et# Inc. Michael 0uren# Sypris ,lectronics
2122Participants in "#IP Usa3e %uide <-'-
136
137
2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192
Paul ,arsy# Safe=et# Inc. Stan eather# @e3lett-Packard Indra itAgerald# @e3lett-Packard 2lan rindell# Safe=et# Inc. 9udith urlong# ,MC Corporation 9onathan Meater# ?hales e-Security Susan Mleeson# .racle 7obert Mriffin# ,MC Corporation Paul MroJean# Individual 7obert @aas# I>M ?homas @ardJono# M.I.?. Steve @e# !ormetric Inc. Kurt @eberlein# @e3lett-Packard 9oel @ockey# Cryptsoft Pty 8td. 8arry @ofer# ,mule6 Corporation >randon @off# ,mule6 Corporation /alt @ubis# =et2pp ?im @udson# Cryptsoft Pty 8td. 9ay 9acobs# ?arget Corporation Mlen 9aquette# I>M Scott Kipp# >rocade Communications Systems# Inc. Kathy Kriese# Symantec Corporation 0avid 8a3son# ,mule6 Corporation 9ohn 8eiseboer# Xuintenssence 8abs @al 8ockhart# .racle Corporation 7obert 8ockhart# ?hales e-Security 2nne 8uk# Cryptsoft Pty 8td. Shyam Mankala# ,MC Corporation Fpendra Mardikar# PayPal Inc. 8uther Martin# !oltage Security @yrum Mills# Mitre Corporation >ob =i6on# ,mule6 Corporation 7enV Pa3litAek# I>M 9ohn Peck# I>M 7ob Philpott# ,MC Corporation 0enis Pochuev# Safe=et# Inc. 2Jai Puri# Safe=et Inc. Peter 7eed# Safe=et Inc. >ruce 7ich# I>M /arren 7obbins# Credant Systems Saikat Saha# Safe=et# Inc. Subhash Sankuratripati# =et2pp Mark Schiller# @e3lett-Packard >rian Spector# Certivo6 ?erence Spies# !oltage Security Marcus Streets# ?hales e-Security Kiran ?hota# !M3are Sean ?urner# I,C2# Inc. Paul ?urner# !enafi# Inc. Marko !ukoliW# ,F7,C.M 7od /ideman# Xuantum Corporation Steven /ierenga# @e3lett-Packard Peter Gee# ,MC Corporation Krishna Gellepeddy# I>M Michael Goder# !ormetric. Inc. Peter Yelechoski# ,lection Systems Z Soft3are
138
139
2193
Magda Ydunkie3icA# Cryptsoft
140
141
2194
&ppendi* 7. &cronyms
- ?riple 0ata ,ncryption Standard specified in 2=SI I*.51 - 2dvanced ,ncryption Standard specified in IPS "*+ - 2merican =ational Standards Institute - 2uthoriAation 7equest Cryptogram - 2merican Standard Code for Information Interchange - Certification 2uthority - Cipher >lock Chaining specified in =IS? SP &---(&2 - Certificate Management Messages over CMS specified in 7 C 51+5 - Certificate Management Protocol specified in 7 C 41"- Certificate 7evocation 8ist specified in 7 C 51&- Certificate 7equest Message ormat specified in 7 C 41"" - Card !erification Code - 0ata ,ncryption Standard specified in IPS 4'-( - 0ata ,ncryption Key - 0iffie-@ellman specified in 2=SI I*.41 - ederal Information Processing Standard - Malois%Counter Mode specified in =IS? SP &---(&0 - Keyed-@ash Message 2uthentication Code specified in IPS "*&-" - @ard3are Security Module - @yper ?e6t ?ransfer Protocol - Identification - Internet Protocol - Internet Protocol Security - Key ,ncryption Key - Key Management Interoperability Protocol - 8inear ?ape-.pen# Meneration 4 - 8inear ?ape-.pen# Meneration 5 - Message 2uthentication Code - Message 0igest 5 2lgorithm specified in 7 C "(1" - Mask Meneration unction - =ational Institute of Standards and ?echnology - .ptimal 2symmetric ,ncryption Padding specified in PKCS<"
2195?he follo3ing abbreviations and acronyms are used in this document$ 2196(0,S 21972,S 21982=SI 219927XC 22002SCII 2201C2 2202C>C 2203CMC 2204CMP 2205C78 2206C7M 2207C!C 22080,S 22090,K 22100@ 2211 IPS 2212MCM 2213@M2C 2214@SM 2215@??P 2217I0 2218IP 2219IPSec 2220K,K 2221KMIP 22228?.4 22238?.5 2224M2C 2225M05 2226MM 2227=IS? 2228.2,P
2216@??PDSE - @yper ?e6t ?ransfer Protocol DSecure socketE
142
143
2229P,M 2230PMP 2231PKCS 2232P.P 2233P.SII 2234PSS 22357S2 2236S@2 2237SP 2239?CP 2240?8S 2241??8! 2242F7I 2243F? -& 2244I.5-* 2245IM8
- Privacy ,nhanced Mail specified in 7 C "41" - .penPMP specified in 7 C 4&&- Public-Key Cryptography Standards - Proof of Possession - Portable .perating System Interface - Probabilistic Signature Scheme specified in PKCS<" - 7ivest# Shamir# 2delman Dan algorithmE - Secure @ash 2lgorithm specified in IPS "&--1 - Special Publication - ?ransport Control Protocol - ?ransport 8ayer Security - ?ag# ?ype# 8ength# !alue - Fniform 7esource Identifier - Fniversal ?ransformation ormat &-bit specified in 7 C ('1* - Public Key Certificate specified in 7 C 51&- ,6tensible Markup 8anguage
2238S%MIM, - Secure%Multipurpose Internet Mail ,6tensions
144
145
2246
&ppendi* C. #e"ision >istory

Revisio n 2ate 2011-072I Editor +ndra 6it(gerald Chan3es #ade +ncorporated the #ollo$ing proposals: *upporting 1ekey o# !symmetric ,ey /airs $ithin ,-+/4 5ncoding )ptions #or ,ey ;rap4 >iscover =ersions4 =endor 5Dtensions4 Cryptographic <ength o# !symmetric ,eys4 and 0eDt *tring 1epresentation o# >istinguished Names. 5Dtended the multi-vendor interopera.ility method to include <0)8. +ncorporated Asage 2uide comments. +ncorporated the >evice Credential and 2roup proposal. 1emoved the 0eDt *tring 1epresentation o# >istinguished Names section. /er#ormed minor editorial changes. !dded ne$ participant list and other minor editorial changes. Converted to ne$ )!*+* template #or non-standardtrack document. +ncorporates ne$ teDt #rom Ev',-+/1.1Cert!ttri.uteApdate/roposal.docDF 5ditorial corrections to re#erences and #ormatting. Committee Note >ra#t #or /u.lic 1evie$ +ncorporate comments #rom pu.lic revie$ +ncorporate comments #rom ,-+/ 0C 1emoved attri.ute indeD teDt4 as voted .y ,-+/ 0C and updated contri.utorsG list
$d-01
$d-02
2011-0&10 2011-0&17 2011-10-7 2011-101M 2011-12-1 2011-1220 2012-1-% 2012-%-% 2012-%-1I 2012-%-2I
+ndra 6it(gerald
$d-0' $d-0% $d-08 $d-0I $d-07 cnd-01 $d-0& $d-0M $d-10
+ndra 6it(gerald 1o.ert 2ri##in 1o.ert 2ri##in 1o.ert 2ri##in 1o.ert 2ri##in )!*+* admin 1o.ert 2ri##in 1o.ert 2ri##in 1o.ert 2ri##in
2247
146

Key Management Interoperability Protocol

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Key Management Interoperability Protocol

Caricato da

Copyright:

Formati disponibili

1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Key Management Interoperability Protocol Usage Guide Version 1.1

90ype the document title:

10kmip-ug-v1.1-cn01 11Non-*tandards 0rack 12

90ype the document title:

15kmip-ug-v1.1-cn01 16Non-*tandards 0rack 17

20kmip-ug-v1.1-cn01 21Non-*tandards 0rack 22

162 '.28 1egistering a ,ey /air.......................................................................................%0 163 '.2I Non-Cryptographic ).?ects................................................................................%1

30kmip-ug-v1.1-cn01 31Non-*tandards 0rack 32

198 199 200

241 242 243 244 245

5041.$ !on%normati"e #eferences

510 511 512

Symmetric Keys Split Dmulti-partE Keys

49 547 548 549 550 551

.bJect ?ype$ ?emplate ?emplate-2ttribute$

.bJect ?ype$ Symmetric Key ?emplate-2ttribute$

Name: 0emplate1 !ttri.ute:

Create Create ,ey /air 1egister >erive ,ey

<ocate 2et =alidate

no change no change no change no change

2et Asage !llocation +> o# ,ey Check

T A6LE -: I2 P LACE7/L2ER P RI/R

81 1129 1130 1131

83 1170 1171 1172

/rapping Method$ ,ncrypt ,ncryption Key Information

AniBue ,ey +>: ,ey +> o# the !5* $rapping key

/rapping Method$ ,ncrypt ,ncryption Key Information

/rapping Method$ ,ncrypt ,ncryption Key Information

1295?he Key /rapping 0ata does not need to be specified.

Cryptographic Asage -ask: ;rap ,ey

Cryptographic Fsage Mask

25N51!05 C1L/0)21!=!<+>!05 C1L/0)21!-

01!N*<!05 5NC1L/0 01!N*<!05 >5C1L/0 01!N*<!05 ;1!/ 01!N*<!05 AN;1!/

T A6LE 8: C R9PT/%RAP7IC USA%E #AS"S PAIRS

113 1740 1741 1742 1743

41--"2 41--"> 41--"C 41--(> 41--&+

Ne< :1"1 -33r2bu3e I.5-* Certificate Identifier

5eferred KMIP unctionality

&ppendi* &. &c;no@ledgements

2089/ri3inal Authors of the initial contri ution:

2122Participants in "#IP Usa3e %uide <-'-

Magda Ydunkie3icA# Cryptsoft

2216@??PDSE - @yper ?e6t ?ransfer Protocol DSecure socketE

2238S%MIM, - Secure%Multipurpose Internet Mail ,6tensions

&ppendi* C. #e"ision >istory

$d-0' $d-0% $d-08 $d-0I $d-07 cnd-01 $d-0& $d-0M $d-10

Potrebbero piacerti anche

01!N<!05 5NC1L/0 01!N<!05 >5C1L/0 01!N<!05 ;1!/ 01!N<!05 AN;1!/