1. KeyProv PSKC Specification Mingliang Pei Authors: P. Hoyer, M. Pei and S. Machani 73 nd IETF meeting, Minneapolis, Nov. 2008

2. Agenda  Status update  Outstanding issues  Next steps

3. Status Update: Revisions since v5  Reviewed by Pasi and others with extensive comments  Major enhancements 1. IANA section is largely refined to include “ entity profile” for each registered algorithm. This increases clarity on interoperability 2. Passphrase based encryption support clarification 3. Various other cleanups  Spelling  Descriptions  Single mandatory algorithm  Some schema changes for clarity

4. Revision 1: Key Entity XML Profile  Problem Interoperability  Many elements and attributes are optional in order to support broad types of keys  How can a Provider know what elements and attributes are required and how they should be set for a particular key algorithm?  Solution Explicitly specify the information for each registered OTP algorithms in IANA section  Specify required elements and attributes  Specify supported value ranges  Provide an example

5. Revision 1: Key Entity XML Profile Sample 8.4.4.1. HOTP Common Name: HOTP Class: OTP URI: http://www.ietf.org/keyprov/pskc#hotp Algorithm Definition: http://www.ietf.org/rfc/rfc4226.txt … Profile of XML attributes and subelements of the entity: For a of this algorithm, the subelements MUST be present. The "OTP" attribute of the MUST be set "true“ and it MUST be the only attribute set. The element of the MUST be used to indicate the OTP length and the value format. For the elements of a of this algorithm, the following subelements MUST be present in either the element itself or an commonly shared element. * Counter The following additional constraints apply: - The value of the element MUST contain key material with a lengthy of at least 16 octets (128 bits) if it is present. - The element MUST have the 'Format' attribute set to "DECIMAL", and the 'Length' attribute MUST be between 6 and 9. - The element MAY be present but the child element of the element cannot be set to "Algorithmic". An example of a of this algorithm is as follows.

6. Revision 1: Key Entity Example (HOTP) <KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> TokenVendorAcme 987654321 <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="987654321"> Issuer MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= 0

7. Revision 2: PBE Support Clarification  Revised description (section 6.1.2) to add information how PKCS#5 key derivation and encryption scheme should be specified  Updated schema pskc:KeyDerivationMethod uses PKCS#5 XML element definition for better schema check  instead of the equivalent  Define to better specify PBES2 <xenc:EncryptionMethod Algorithm= "http://www.rsasecurity.com/rsalabs/pkcs/schemas/ pkcs-5#pbes2"> <pskc:EncryptionScheme Algorithm= "http://www.w3.org/2001/04/xmlenc#aes128-cbc">

8. Revision 3: Various Cleanups  Only one mandatory encryption and hash algorithm to support Mandatory encryption algorithm  http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc Mandatory hash algorithm  http://www.w3.org/2000/09/xmldsig#hmac-sha1 Optional camellia key encryption algorithms are included  XML encryption clarification XML schema is used for raw key material encryption, not XML document encryption  Some schema changes for better consistency and standards

9. Revision 3: Other Schema Changes  of a MUST be DN  Standard XML attribute is used In the last revision, the XML ID attribute is changed to use the standard XML type type. In this revision, we eliminate names at all by referring to  to  Affected PSKC types  DerivedKeyType  KeyContainerType  KeyPropertiesType

10. Outstanding Issues  Security concerns over DeviceId using PAN (Primary Account Number) PAN is the credit card number. Passing the information in a KeyContainer requires participating entities to handle the data properly such as in compliance of PCI.  Clarify how a different MAC from encryption key can be specified Current schema doesn’t define a type to carry MAC key A separate MAC key could be same as the KEK, pre-loaded, derived, and created (similar to DSKPP MAC key generation)  Register HOTP algorithms as URN without using http://www.ietf.org/xxx URI We preferred to register algorithms as URI for consistency  http://www.ietf.org/keyprov/pskc#hotp  http://www.w3.org/2001/04/xmldsig-more#rsa-sha256  http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/otps- wst#SecurID-AES Using www.ietf.org URI isn’t permitted. URN should be usedwww.ietf.org Shall we register HTOP as URN or find other URI prefix?  urn:ietf:params:xml:ns:keyprov:pskc#hotp

11. Outstanding Issues  Register additional OTP algorithms VASCO OTP algorithm, others (?) Random generating OTP algorithm (e.g. SMS OTP use)  KeyContainer XML schema version as an attribute or as part of the namespace urn Version in root element considered best practice for minor changes (e.g. new attribute addition) instead of bumping up namespace urn version. Namespace version is changed when old schema won’t validate in the new schema  http://www.xfront.com/Versioning.pdf http://www.xfront.com/Versioning.pdf  Having an integer type instead of two 32-bit and 64-bit types (intDataType and longDataType)  Revise for default value support When XML schema uses default values, signature may break Add a paragraph to indicate that the "signer" always fills in the right data, or make the attribute required  Make examples in the Appendix as test vectors (Work in progress)

12. Next Steps  Review feedbacks and address the issues into the next revision  Target last call after the next revision