Portable Symmetric Key Container (PSKC) Mingliang Pei Philip Hoyer Dec. 3, th IETF, Vancouver

Agenda  Status update  Main Discussion Topics Use of XMLEnc / XMLDsig PIN policy Profile of supported algorithms Logo Type  List of Other Open Issues  Next step

Status update - changes  11/5/2007 Version Changed algorithm enumerations to URIs 2. Changed all attribute name initial from lower case to upper case 3. Changed VersionType to use 2 major digits and 3 minor digits.  11/18/2007 Version Changed PSKC schema file to not use default namespace 2. Fixed examples and verified them against schema 3. Added name TIME_DRIFT for HOTP time based algorithm 4. Changed HOTP key algorithm URI from URN style to URL. This causes some inconsistency with DSKPP v1.1 and we will align both specifications in the next revision. 5. Added description about Logo in the common attribute section. 6. Added logo schema content in the schema section. 7. Fixed a few typos. 8. Updated acknowledgement section.

Topic 1: Use of xmlenc / xmldsig  Main issue: shall we leverage more XMLEnc for encryption key entry and encrypted value definition? Received various comments from Magnus and Andrea from RSA to increase use of xmlenc and xmldsig in PSKC spec  Use ds:KeyInfo as the type to define the wrapping key  Use pkcs-5 xml schema for PBE parameters  Use xenc:EncryptedDataType as the carrier of the wrapped keys  No need for digest if key wrapping algorithms are used that preserve integrity The original design goal of PSKC is to keep it simple and small size without relying on extensive XMLEnc and XMLDsig schema

Comparison: Encryption Key by Current Spec vs. Magnus’s Proposal <pskc:EncryptionMethod Algorithm= " /schemas/pkcs-5#pbes2"> <PBEEncryptionParam EncryptionAlgorithm= " aes128-cbc"> y6TzckeLRQw= 1024 c2FtcGxlaXY= y6TzckeLRQw=

Comparison: Wrapped Key by Current Spec vs. Magnus’s Proposal <Key KeyAlgorithm=" rg/keyprov/pskc#hotp" KeyId=" "> … JSPUyp3azOkqJENSsh6b2hdX z1WBYypzJxEr+ikQAa22M6V/ BgZhRg== i8j+kpbfKQsSlwmJYS99lQ== <Key KeyAlgorithm=" rg/keyprov/pskc#hotp" KeyId=" "> … JSPUyp3azOkqJENSsh6b2hdXz1 WBYypzJxEr+ikQAa22M6V/Bg ZhRg==

Pros and Cons  Pros More standard Can ride on extension to xmlenc and xmldsig spec Possible advantage of using existing tools  Cons More complex for bulk (need to create xmlenc refs) Increased scope for interoperability with XMLENC spec More schemas to import Larger payload size Major re-work late in spec lifecycle

Topic 2: PIN policy  Issue: how to transmit initial PIN value for devices using PSKC Current spec only specifies whether a PIN is used Lack of specification how PIN is transferred and its usage  Use Case Considerations Allow possibly multiple PINs and which keys are protected by the PIN. A PIN can be used in multiple ways  Locally authenticated in a client  Part of data sent to server for validation along with that from a target key  Embedded in device

Proposal: PIN policy  Introduce an element called PINPolicy  Each key optionally has a PIN policy  A PIN policy may contain a PINUsage Pseudo sample: … LOCAL …

Proposal: PIN transmit  Leverage “Key” element to carry PIN value by treating PIN as one kind of credential Can re-use all wrapping and usage parts for PIN value definition  Use a reference ID attribute to associate a Key and a PIN that protects it PINPolicy of a key has an attribute referring to PIN entry PIN entry has an attribute referring to key ID that it protects  Questions Do we need to allow a device level PIN policy? Any other use cases with regard to PIN usage?

PIN Policy example … Credential Issuer MyFirstToken zOkqJENSsh6b2hdXz1WBK/oprbY= AAAAAAAAAAA= 10/30/2012 PREPEND <Key KeyAlgorithm=" KeyId=" "> Credential Issuer RandomInitialTokenPIN zOkqJENSsh6b2hdXz1WBK/oprbY=

Questions  Do we need to allow a device level PIN policy for bulk case? For local device PIN, PIN policy applies to the key device and one shared PIN policy should be sufficient  Any other use cases with regard to PIN usage?

Topic 3: Profiling of PSKC  With the move to URIs as algorithm identifiers from an enumerated list we need to define: A list of algorithms that an implementation MUST support:  PBE  PKCS5  Symmetric     Asymmetric   A list of algorithms it SHOULD support  ?  Do we need more than one profile?  Do we need to have a symmetric and asymmetric profile?  Where do we define additional URIs not defined yet?

Where do we find URIs for algorithms?  Xmldsig-core  E.g.,  RFC More xmldsig URIs  E.g.,  XMLEnc spec  E.g.,  New RFC draft for additional algorithms identifiers-00.txt identifiers-00.txt How shall we register new key algorithm URIs?  OTP algorithms  Algorithms used in PKCS#5 PBE  In this draft? In KEYPROV drafts? Other? Should it list all algorithms or only new algorithm URIs?

Topic 4: Logo Type  Currently, each key (by pskc:KeyType) can have a Logo element of LogoType  LogoType Schema Defined along with v1.0 of PSKC Separate schema file from PSKC Own namespace urn:ietf:params:xml:ns:keyprov:logo:1.0 Defined as a XML version of the ASN.1 version for a Certificate [RFC3709]  A key can have an issuer’s logo, multiple community logo, and others. <element name="CommunityLogos" type="logo:LogoInfoType" minOccurs="0" maxO ccurs="unbounded"/> <element name="OtherLogos" type="logo:LogoInfoType" minOccurs="0" maxOccur s="unbounded"/>

Logo Type Issues  Where do we document LogoType if not in PSKC spec? Intended to be a common type similar to algorithm URIs such that LogoType can be used by other specifications Options  Propose a new RFC draft about Logo for keys  RFC Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates  Make it common schema as it is today and explain LogoType and schema information in PSKC spec  Is it sufficient to define logo type to include only image data and MIME type?  Currently additional logo image parameters such as size and resolution are allowed, as defined from the original certificate logo type definition

Open Issues  OTP algorithm URI definition location Proposed in v1.2  HOTP URI specified in PSKC  Vendor patented / specific algorithm is up to the owner to provide URI, e.g. SecurID, VASCO time based, ActivIdentity time / event based etc.  ValueDigest with Keyed digest (HMAC) vs. unkeyed (SHA1) Concerns  Keyed digest needs verification of digest key itself  What digest key to use when a certificate is used for encryption? Public key is used in this case. Is regular digest over raw secret safe? Keyed digest is used for better security.  URI for PSKC KeyContainer Needed by DSKPP to indicate preference of requested key container format Propose to define it in DSKPP, not in PSKC

Alignment between DSKPP and PSKC  Majority of them have been resolved  KeyType / KeyAlgorithmType PSKC: KeyType is a type used to define what a key is. One of its attribute ‘KeyAlgorithmType’ indicates the type of the key. Usage: DSKPP: KeyType is an element used to mean what kind of key to request. It plays the equivalent role of KeyAlgorithmType in PSKC. Usage: Algorithm URIs AlgorithmURI

Resolution Options  Change DSKPP KeyType to KeyAlgorithmType Algorithm URIs AlgorithmURI Matches the value used: KeyAlgorithmType Algorithm URI Concern: KeyAlgorithmType isn’t as popular as KeyType by Google search to mean type of key to use.  Change PSKC KeyType to something like KeyDataType Concern: not as clean as KeyType for the object model – Container, Device and Key

Next Steps  Resolve outstanding issues using the mailing list and conf calls  Revise and resubmit draft for review