Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 16 Oct 2007 18:22:54 +0200

Attendees: 

Philip Hoyer, Ming Pei, Shuh Chang, Salah Macchani, Phillip
Hallam-Baker, Hannes Tschofenig

1)       Initially decided to tackle the issue of algorithms that are
represented as enumerations in PSKC and if we should go to a URI based
approach that allows for easier extension. There are 3 type of algorithm
definitions in PSKC

a.       EncryptionAlgorithm of the key material in the container

b.       DigestAlgorithm to create a digest of the uncencrypted keys

c.       OTP Algorithm, identifier of the algorithm that the key is
being used with

2)       Agreed to change EncryptionAlgorithm and DigestAlgorithm to
change to URI

3)       Ming Pei to change schema and add minimum list of URIs 

a.       Issue, what about PBE related algorithms, no URIs found by Ming

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the
list of algorithms for which he has not found URIs. Philip Hallam Baker
will then try to find URIs or get back to authors with way to proceed

4)       Discussion about digest of the key for RSA encrypted keys -
Ming, Shuh to check if it is a bad idea - Philip to ask to the list

a.       The problem here is that the Digest used for symmetric
algorithms is a keyed digest eg HMAC-SHA1 which is still not broken. If
for transmission of keys wrapped by a public Key of the receiving party
we use a simple digest iof the unencrypted key material, it might open
the container for brute force attacks. Since a keyvalue to hash value
mapping might be much quicker to find than brute forcing HMAC-SHA1

5)       URIs for KeyAlgorithm? 

a.       Fundamentally the people agreed that it is a better idea but
even more than encryption and digest algorithms, OTP algotihms do not
have a defined URI

b.       Ming Pei to send Phillip Hallam Baker and to mailing list the
list of algorithms for which he has not found URIs Philip Hallam Baker
will then try to find URIs or get back to authors with way to proceed

6)       Philip Hoyer proposed to introduce a keyType at container level
with attributes such as algorithm and logo and usage type that the key
can reference (this would avoid repeating all the data for similar keys
within the container) - Everyone agreed that this was a good idea but
deemed a priority 2 item

7)       Hannes to investigate what best practice is regarding URN
versioning, current proposal is to add numeric version so all
ietf:keyprov URN should add ':1'

8)       Should we reorganise PBE to support PKCS5 XML schema, currently
this was deemed to complicate the schema too much so it was deferred for
now 

9)       Discussion around attributes and elements, should the ASN.1
document contain the description of the attributes. Decision for
ASN.1document to incorporate attribute definition of PSKC spec. Hannes
to send email to the list.

10)   Discussion if we need to have a face to face meeting to align
spec. Hannes asked if a set of conference calls with a precise short
agenda. Would be good. Should we have a weekly conference call? Agreed
to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30 minutes

11)   IV should be moved back to EncryptionMethod since it is used for
symmetric algorithms and not only for PBE (Ming in his latest revision
had moved it to the PBEParams element)

12)   Discussed initial PIN transmission, Philip invited for
participants to review and agree. If no disagreements Philip Hoyer will
include in October revision of the spec

 

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

Telephone: +44 (0) 20 7744 6248

Direct: +44 (0) 20 7744 6455

Fax: +44 (0) 20 7744 6249

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended
recipient,

you must not copy, distribute, discuss or take any action in reliance on
it.

If you have received this communication in error, please notify the
sender

and delete this message immediately.

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Oct 2007 10:18:25 +0300

For the group:

I collect the phone numbers of the draft authors. I really give them a 
call from time-to-time to remind them about the work we have todo and 
also to investigate what the open issues are.

In this case I thought it might be valuable for the group to learn more 
about the topics we discussed. Hence, I asked Philip to distribute his 
notes.

Ciao
Hannes

---

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 17 Oct 2007 20:13:52 -0400

Philip,
 
Thank you for forwarding these minutes to the mailing list.
 
It is good to see progress towards use of standard XML (esp. URIs for
algorithms).  Toward this end, and also for alignment with DSKPP, a
couple of things are needed:
1. Switch to use of ordinary XMLEnc, XMLDSig
2. Switch to use PKCS #5 XML as it makes no sense to have this in DSKPP
and not in PSKC.  The schema is not complex.  What is being referred to
as "difficult" (see #8 below)?
 
Regarding use of URIs for OTP algorithms --- why is this necessary?  I
know we spoke of doing this before, but stepping back a bit, isn't it
really up to vendors to specify their own URIs?  If vendor-specific URIs
are included in the doc that should be fine since the purpose of using
URIs is to allow for extensibility.
 
Andrea

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 12:23 PM
To: [email-masked]; Hallam-Baker, Phillip; Pei, Mingliang;
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07

Attendees: 

 

 

Philip Hoyer 

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 17 Oct 2007 22:14:50 -0700

All,
 
In our effort to use URIs instead of enumerations in PSKC for
EncryptionAlgorithms, DigestAlgorithms, and KeyAlgorithms, we found that
some algorithms don't have a defined / registered URIs yet, mostly, for
the PBE methods and Key Algorithms. Attached please find current laundry
list of the algorithms for their respective URIs, and those that need
some URIs to be defined. We found most URIs defined by XML signature and
encryption specification (xmldsig, additional xmldsig URIs, and xmlenc
).
 
Please let us know if you find some places that have defined URIs for
the listed missing ones, or any suggestions where we should define the
new ones, for example, OTP algorithms by HOTP, variours vendors (VASCO,
SecurID (if need one other than current RSA URL)).
 
Please see the attached doc for questions. Here are quoted questions:

a) Where can we find URIs defined for PBE algorithms?

PBEs are defined in PKCS#5. The XML version defined the following URI.
One PBE algorithm would need two URIs to define, for example,
PBE-AES128-CBC would be identified with the following two:

http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2

http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc

and possibly a third one that identifies key derivative function.

b) Shall we define one URI for each PBE method with encryption such as
PBE-AES128-CBC?

Thank you,
 
- Ming

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Tuesday, October 16, 2007 9:23 AM
	To: [email-masked]; Hallam-Baker, Phillip; Pei,
Mingliang; [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: IETF Keyprov PSKC meeting minutes 15/10.07

	Attendees: 

	 

	1)       Initially decided to tackle the issue of algorithms
that are represented as enumerations in PSKC and if we should go to a
URI based approach that allows for easier extension. There are 3 type of
algorithm definitions in PSKC

	a.       EncryptionAlgorithm of the key material in the
container

	b.       DigestAlgorithm to create a digest of the uncencrypted
keys

	c.       OTP Algorithm, identifier of the algorithm that the key
is being used with

	2)       Agreed to change EncryptionAlgorithm and
DigestAlgorithm to change to URI

	a.       Issue, what about PBE related algorithms, no URIs found
by Ming

	b.       Ming Pei to send Phillip Hallam Baker and to mailing
list the list of algorithms for which he has not found URIs. Philip
Hallam Baker will then try to find URIs or get back to authors with way
to proceed

	4)       Discussion about digest of the key for RSA encrypted
keys - Ming, Shuh to check if it is a bad idea - Philip to ask to the
list

	a.       Fundamentally the people agreed that it is a better
idea but even more than encryption and digest algorithms, OTP algotihms
do not have a defined URI

	b.       Ming Pei to send Phillip Hallam Baker and to mailing
list the list of algorithms for which he has not found URIs Philip
Hallam Baker will then try to find URIs or get back to authors with way
to proceed

	6)       Philip Hoyer proposed to introduce a keyType at
container level with attributes such as algorithm and logo and usage
type that the key can reference (this would avoid repeating all the data
for similar keys within the container) - Everyone agreed that this was a
good idea but  deemed a priority 2 item

	7)       Hannes to investigate what best practice is regarding
URN versioning, current proposal is to add numeric version so all
ietf:keyprov URN should add ':1'

	8)       Should we reorganise PBE to support PKCS5 XML schema,
currently this was deemed to complicate the schema too much so it was
deferred for now 

	9)       Discussion around attributes and elements, should the
ASN.1 document contain the description of the attributes. Decision for
ASN.1document to incorporate attribute definition of PSKC spec. Hannes
to send email to the list.

	10)   Discussion if we need to have a face to face meeting to
align spec. Hannes asked if a set of conference calls with a precise
short agenda. Would be good. Should we have a weekly conference call?
Agreed to have a weekly call on Monday 3pm Central 4pm EDT 9 pm for 30
minutes

	11)   IV should be moved back to EncryptionMethod since it is
used for symmetric algorithms and not only for PBE (Ming in his latest
revision had moved it to the PBEParams element)

	 

	Philip Hoyer 

	ActivIdentity (UK)

	109 Borough High Street

	London SE1 1NL

	Private and confidential: This message and any attachments may
contain

	privileged / confidential information. If you are not an
intended recipient,

	you must not copy, distribute, discuss or take any action in
reliance on it.

	If you have received this communication in error, please notify
the sender

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 18 Oct 2007 11:59:39 +0200

Ming,

The MKEYLABEL is not really an algorithm but a way to denote a unique
label of a pre shared master key. 

Maybe we can do this by defining the masterkey-label in the credentialed
and creating URIs for the masterkey derivation algorithms.

This is the case for example for EMV cards where in PSKC you would only
transmit the data necessary for key derivation and refer to a master key
label and a derivation algorithm.

It might be the case that we should make this more explicit (eg a choice
between algorithm and derivation algorithm). I personally believe this
is overkill.

I suggest we remove MKEYLABEL and add a description in the spec saying
that for keys derived from masterkeys the credentialed contains the
masterkey label and the algorithm is the derivation algorithm.

Obviously this means that we need to create some URIs for key-derivation
algorithms we want to support.

Philip

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 6:15 AM
To: Philip Hoyer; [email-masked]; Hallam-Baker, Phillip;
[email-masked]; [email-masked]; Doherty, Andrea;
[email-masked]
Subject: Where and how to define the undefined URIs for the algorithmes
listed in the current PSKC?

All,

  

Thank you,

- Ming

	Attendees: 

	 

	 

	Philip Hoyer 

	ActivIdentity (UK)

	109 Borough High Street

	London SE1 1NL

---

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 19 Oct 2007 13:38:54 -0700

I like to add another issue to track and resolve.
 
13) Consistent attribute name convention: upper case vs. lower case.
 
DSKPP uses upper case for all element names and attribute names. PSKC
used lower case in majority attribute names, and some in upper cases.
For example:
 
UsageType:
 
    <attribute name="otp" type="boolean"
               default="false"/>
    <attribute name="cr" type="boolean"
               default="false"/>
    <attribute name="sign" type="boolean"
               default="false"/>
    <attribute name="encrypt" type="boolean"
               default="false"/>
    <attribute name="unlock" type="boolean"
               default="false"/>

KeyType:
 
<attribute name="KeyId" type="string" use="required"/>
 
DataType:
 
    <attribute name="Name" type="string"
               use="required"/>
 
For consistency, I suggest that we change them all to upper case.
Comments?
 
- Ming

From: Doherty, Andrea [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 5:14 PM
To: Philip Hoyer; [email-masked]; Hallam-Baker, Phillip; Pei,
Mingliang; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07

Philip,

 
 
Andrea

Attendees: 

 

 

Philip Hoyer 

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 22 Oct 2007 10:56:18 +0200

Ming,

When you say upper case I assume you mean the first letter upper case
and not all capitalized,

I have no objections to make this consistent between the two specs hence
make them all upper case.

Philip

From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Friday, October 19, 2007 9:39 PM
To: Doherty, Andrea; Philip Hoyer; [email-masked];
Hallam-Baker, Phillip; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07

UsageType:

KeyType:

DataType:

- Ming

Philip,

Andrea

Attendees: 

 

 

Philip Hoyer 

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 22 Oct 2007 10:57:09 -0700

Philip,
 
Right, we want to capitalize the first letter: version -> Version etc..
Some attribute word is better to be entirely changed upper case though,
e.g., cr to CR instead of Cr and otp to OTP instead of Otp.
 
I will make changes in schema file, and send out for review.
 
- Ming

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 1:56 AM
To: Pei, Mingliang; Doherty, Andrea; [email-masked];
Hallam-Baker, Phillip; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [KEYPROV] IETF Keyprov PSKC meeting minutes 15/10.07

Ming,

Philip

 

UsageType:

KeyType:

DataType:

- Ming

Philip,

Andrea

Attendees: 

 

 

Philip Hoyer 

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL