1. Keyprov PSKC spec Philip Hoyer 71-st IETF, Philadelphia

2. Agenda  Status update  Discussion points Key Attribute – transmission and extension Current approach SAML attribute assertion schema Current spec example Comparison between current and new proposal Mailing list extension discussion  List of outstanding issues

3. Status update – changes based on draft - 03 from 22/2/2008 1. Completely reworked spec based on an entity description top-down approach 1. Aligned terminology (credential->key) 2. Removed LogoType 3. Adopted xml encryption types within schema 4. Added PINPolicy to allow transmission of PINs 5. Added start and expiry date to device and key entity 6. Removed UserEntity 1. Device -> user binding is via a UserId attribute in device 7. Added examples for PIN transmission and asymmetric wrapping 8. More detailed section on protection methods of payload 1. Added profile of symmetric, password based, key wrapping and asymmetric algorithms 9. Explicit section on attribute semantics that can be referenced from ASN.1 spec

4. Discussion: how to transmit key attribute values  Lots of traffic on mailing list  Main points: Need a way to carry attributes related to a key An attribute can be encrypted or plaintext Spec needs to be able to cater for a list of attributes Not all attributes are semantically defined Need to be able to cater for future attributes

5. Current approach to transmit key attributes  Attributes are a list of name value pairs:  Spec defines semantics for reserved attributes eg: COUNTER: the event counter for event based OTP algorithms. 8 bytes unsigned integer in big endian (i.e. network byte order) form base64 encoded

6. SAML Attribute assertion schema

7. Current spec attribute example <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" KeyId="0755225266"> AnIssuer AprkuA== <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE= cwJI898rRpGBytTqCAsegaQqPZA= 2012-12-31T00:00:00

8. Comparison between current spec Hannes proposal on mailing list <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/ 04/xmlenc#aes256-cbc"/> kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAP vKzHHQ8SdxyE= cwJI898rRpGBytTqCAseg aQqPZA= 1234 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001 /04/xmlenc#kw-aes128"/> rf4dx3r vEPO0vKtKL14NbeVu8nk= 1234

9. pros and cons CurrentHannes  Pros Schema is always valid does not need to change for new attributes Way to transmit attributes in line with ASN.1 spec  Cons Not very XML  Pros More XML style Allows for better typing of plainvalues  Cons Harder to parse Schema needs extension with every new attibute

10. Mailing list extension discussion  Chair Phillip Hallam-Baker with Tony Nadalin (IBM) Using HTTP identifiers in protocols is a problem, people attempt to resolve them when they should not and do not resolve them when you want them to. On structured data, distinguish between extending the protocol schema and incorporating lists of tag value pairs:  Using to extend the protocol is bad, you lose the ability to perform schema validation on the protocol elements.  Using for structured tag-value pairs is acceptable and is the prefered method if you have a tag-value pair that you may need to instantiate into multiple schemas. So for example, if X.509 was an XML data format:  Changes to the X.509v3 cert format should use inheritance/subclassing so that the cert can be schema validated.  should be used at the point where X.509v3 requires an OID- Structure pair defining a certificate extension. This allows an extension to be incorporated in Certificates, CRLs, OCSP, etc.  Comment from Anders Rundgren (RSA) A remaining issue is that there is no way figuring out which extensions are understood and supported except by requesting vendor support. X.509 world has a concept known as "non-critical" extensions. On the surface this looks like a great idea (just skip things you don't understand), but the reality is that if you don't support a bunch of these you cannot for example know if a certificate is revoked or not.

11. Outstanding Issues  Fix a few TODOs: Agree on definition of userId for user device binding, current proposal is DN style (OU=Engineering, CN=James…) Add definition of type in DerivedKey Add example of asymmetric key protection in section 6.2  Should plaintext be string instead of base64  Clean up references to OTP algorithm URI in Section 6.3.1.2 Reference Eastlake informational RFC Specify some locally (RSA SecurID, ActivIdentity,others)  change URI xxx/pskc#valuecompare to xxx/pskc#pin in section 6.3. not sure that #valuecompare is a good name for type of credential (PIN).  Clean up reference section (some reference may not be "Normative" such as OATHRefArch )  More clarification of ValueMac for specific transport security options (eg asymmetric)  Make sure all examples use ‘real key and hash values’