Keyprov PSKC spec Philip Hoyer 71-st IETF, Philadelphia

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

Status update – changes based on draft - 03 from 22/2/ 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 referenced also from DSKPP 9. Explicit section on attribute semantics that can be referenced from ASN.1 spec

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 is not an XML attribute but key related meta- data  Key Attribute model based on name-values is common practice in existing crypto APIs such as PKCS#11 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  Issue got confused between extension of XML elements and attributes and ability to carry a list of not pre-defined key metadata

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

SAML Attribute assertion schema

Current spec attribute example <Key KeyAlgorithm=" KeyId=" "> AnIssuer AprkuA== <xenc:EncryptionMethod Algorithm=" kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE= cwJI898rRpGBytTqCAsegaQqPZA= T00:00:00

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

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 Familiar to crypto programmers (pkcs#11)  Cons Not very XML  Pros More XML style Allows for better typing of plainvalues  Cons Harder to parse Schema needs extension with every new attribute type

Mailing list extension discussion  Chair Phillip Hallam-Baker with Tony Nadalin (IBM) 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.  Issue - how do we register new key metadata semantics informal RFC? New version of PSKC with specific section about semantics?

Outstanding Issues  Fix a few TODOs: Extend 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 Reference Eastlake informational RFC Specify some locally (RSA SecurID, ActivIdentity,others)?  change URI xxx/pskc#valuecompare to xxx/pskc#pin in section 6.3. #valuecompare is not 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, kw- algos not all HSMs)  Make sure all examples use ‘real key and hash values’  add support of a key template to spec (alignment w/ASN.1 spec)?