Subject: [KEYPROV] Additional notes about PSKC

From: <[email-masked]>
Date: Wed, 17 Sep 2008 12:48:42 +0300

Hi,

I finally found time to transcribe the random notes on my printed
copy of PSKC -05 draft (sorted by section, not importance):

Abstract: " This work is a joint effort by the members of OATH
(Initiative for Open AuTHentication)..." It's now effort of the
KEYPROV WG, based on earlier work in OATH.

Section 1, "This Internet draft describes" -> "This document describes",
"This draft also specifies" -> "This document also specifies"

Section 1, "a format with small (size in bytes) [...] is desirable,
avoiding complexity of PKCS#12": I'd suggest rephrasing this -- since
PSKC uses XML, it's larger (in bytes) and more complex than PKCS#12.

Section 2.2/overall terminology: I'd suggest changing "Encryption Key"
to "Key Encryption Key", since in some cases, the "inner key" could
also be used with an encryption algorithm.

Section 2.2/overall terminology: "Key Issuer: An organization that
issues symmetric keys to end-users" I guess "...that issues
authentication tokens..." would be more accurate?

Section 3.1/3.2: term "cryptomodule" is not used anywhere else
in the document.

Section 3.1.3/3.1.4, expand acronyms "SD" and "OTA"

Sections 3 and 4: these sections should be more explicit whether
the mapping between authentication tokens/keys and users is
considered part of the key information or not. Some of the
text suggests it is, others (e.g. R2 in Section 4) isn't so clear.q

Section 4, one important requirement (which probably should come
just after R2) is to allow distributing only the attributes associated
with the key without the key itsel; this obviously would be used
in e.g. DSKPP

Section 5, "contains the following main entities": Should probably say
how many there are: e.g. "One KeyContainer entity", "Zero or more
KeyProperties entities", "One or more Device entities", and "Each
Device entity contains one or more Key entities" (or something along
those lines)

Section 5.1/elsewhere: the version field is redundant, since future
versions will use anyway different element names (e.g. in 1.0, the
main element is {urn:ietf:params:xml:ns:keyprov:pskc:1.0}KeyContainer,
in 1.1 it's probably {...:1.1}KeyContainer).

Section 5.1 and 5.2: would it be simpler to use the "xml:id" attribute
instead of defining a new "pskc:ID" attribute?

Section 5.1: "keyed digest" -> "Message Authentication Code (MAC)"

Section 5.1: "signature" -> "signature or Message Authentication Code"
(MAC)", and terminology in rest of the bullet point (in XMLDSIG,
signature algorithm is always public-key).

Section 5.1 "using a symmetric key based signature with the same key
used in the encryption of the secret key data": using the same key
with multiple algorithms is very bad cryptographic practice (e.g.  if
both the encryption and MAC use AES as the primitive, they might
interact badly).

Section 5.1, typo "defintion" 

Section 5.1, the example about "Extensions" isn't valid because
the "MyExtension1" element isn't in other namespace. This also
applies to Section 5.3, 5.3.1, 5.4, 5.4.2, and 5.4.4.

Section 5.3.1, "Manufacturer" -- for e.g. physical smart card (perhaps
EMV), would this be the *manufacturer* or *card issuer*?  (probably
the latter, as you usually don't even know who manufactured your EMV
credit card).

Section 5.3.1: Using the PAN (essentially credit card number) as the
device identifier here seems slightly risky (since it can be used for
malicious purposes, not just identifying the device). Don't the cards
have something like Card Serial Number (CSN), too?

Section 5.3.1: semantics of DeviceBinding seem vary vague (and unlikely
to lead to any kind of interoperability).

Section 5.3.1: the semantics of StartDate and ExpiryDate need
description: what should the device, or back-end server, do with
these?

Section 5.4: KeyAlgorithm probably needs to be mandatory.

Section 5.4, semantics of KeyProfileId seem extremely vague (and 
unlikely to lead any kind of interoperability).

Section 5.4, the semantics of StartDate and EndDate need better
description, both for the token and the back-end server.

Section 5.4, "the value MAY be a string representation of a
Distinguished Name", here "MAY" means it can be anything else, 
too -- is a MUST intended here?

Section 5.4.1: It sounds like you *are* actually using XML encryption,
but not to encrypt XML elements (XML encryption can encrypt things
that are not XML, and obviously those don't need XML canonicalization).
Needs rephrasing.

Section 5.4.1: doesn't say what data the MAC covers exactly.

Section 5.4.1: having an integer type (where the encrypted plaintext
is in ASCII format) would sound simpler than separate types for 32 bit
and 64 bit integer (and this would be more in line with XML anyway).

Section 5.4.2: "Usage" element probably needs significant rewrite
(once you have text describing the various algorithm definitions,
some parts of this can probably go away anyway; e.g. the OTP/CR/
Integrity/Encrypt/Unlock attributes), and needs to describe 
the semantics much better.

Section 5.4.2.1.1/5.4.2.1.2: Luhn check digit needs a reference.

Section 5.4.4: needs to describe expected behavior for both client
and server.

Section 6.1.1: usually IETF specs have a single mandatory-to-implement
algorithm; here most of the algorithms are mandatory, which seems
unnecessary.

Section 6.1.1: XMLEnc doesn't have algorithm called kw-aes512?

Section 6.1.2: example has many of the elements in wrong namespaces.

Section 6.1.2: doesn't say anything how to turn the passphrase (a
character string) to the octet string 'P' that PBKDF2 expects as input.

Section 6.1.1: the text isn't clear whether password-based encryption
would use just PBKDF2 to derive a key for e.g. xmlenc#aes128-cbc
encryption algorithm URI, or whether it would use pkcs-5#pbes2 as
the encryption algorithm URI.

Overall: Please change all HTTP URIs pointing to www.ietf.org to
IANA-assigned URNs (the HTTP URIs will anyway resolve to "404 Not
Found", so using them is unnecessary).

Section 8.1, "charset" description should probably say "the charset
parameter of application/xml as specified in [RFC3023]

Section 8.2/8.3: registers the same URN for two different purposes.

Section 8.4: this section probably should talk only about the URIs
used for KeyAlgorithm element; if there's need to talk about
other URIs (MAC algorithms,digest algorithms, etc) at all, those
should be in separate place.

Section 8.4: RFC 2434 has been obsoleted by 5226.

Overall: there document doesn't really say anything about certificates
(except that Section 6.2 implies that they'd usually contain RSA
keys). It probably needs to.

Best regards,
Pasi
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 23 Sep 2008 10:43:12 -0700

Hi Pasi,

Thank you very much for the detailed comments. Please see my comments
inline. We am going to incorporate your comments into the next revision.
I will pick up the obvious ones this week in the draft, and some others
for team discussion next week.

Here are a few issues that we will follow up more later.

1. Versioning. Should "Version" attribute from elements be removed from
XML element definition?
2. Section 5.3.1. Manufacturer vs "card issuer" for EMV card
3. Device ID using PAN
4. UserId MUST use DN representation
5. Usage element definition

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, September 17, 2008 2:49 AM
To: [email-masked]
Subject: [KEYPROV] Additional notes about PSKC

Hi,

I finally found time to transcribe the random notes on my printed copy
of PSKC -05 draft (sorted by section, not importance):

Abstract: " This work is a joint effort by the members of OATH
(Initiative for Open AuTHentication)..." It's now effort of the KEYPROV
WG, based on earlier work in OATH.

MP: Agreed. 

MP: It seems that we have different views on which one is more complex.
At the time, we considered that PSKC#12 is more PKI oriented, it is more
complex to describe a symmetric key with it. Shall we just remove this
line? The other reason to use XML instead of PKCS#12 is to specify more
explicit attributes of Key.

Section 2.2/overall terminology: I'd suggest changing "Encryption Key"
to "Key Encryption Key", since in some cases, the "inner key" could also
be used with an encryption algorithm.

MP: Agreed.

MP: This goes back to overall scope of the document: token or general
key. We tried to allow general key while providing more coverage on
token. If the key is a 3DES key for disk encryption, "issues auth
tokens" doesn't apply. I prefer to leave it as is. Or change to "issues
symmetric keys [in authentication tokens or other containers]" ...

Section 3.1/3.2: term "cryptomodule" is not used anywhere else in the
document.

MP: Good catch. Will remove. We tried to align the terminology between
PSKC and DSKPP. CryptoModule was intended to replace a client. PSKC
doesn't involve much of client as a content format.

MP: Agreed.

Sections 3 and 4: these sections should be more explicit whether the
mapping between authentication tokens/keys and users is considered part
of the key information or not. Some of the text suggests it is, others
(e.g. R2 in Section 4) isn't so clear.q

MP: Will rephrase. Yes, it is intended to carry the user that is
associated with a key

Section 4, one important requirement (which probably should come just
after R2) is to allow distributing only the attributes associated with
the key without the key itsel; this obviously would be used in e.g.
DSKPP

MP: Agreed. Will add it. This also affects the algorithm definition in
the IANA section. "Secret" will be optional.

Section 5, "contains the following main entities": Should probably say
how many there are: e.g. "One KeyContainer entity", "Zero or more
KeyProperties entities", "One or more Device entities", and "Each Device
entity contains one or more Key entities" (or something along those
lines)

MP: The sentence intends to express the main XML element definitions in
the document rather than number of elements within a given Key Container
object instance. My reading of "Zero or more KeyProperties entities"
seems to indicate the later, right?

Section 5.1/elsewhere: the version field is redundant, since future
versions will use anyway different element names (e.g. in 1.0, the main
element is {urn:ietf:params:xml:ns:keyprov:pskc:1.0}KeyContainer,
in 1.1 it's probably {...:1.1}KeyContainer).

MP: True that multiple versioning mechanisms are used. We considered to
use Version changes for minor changes one some particular element
without changing the schema URI. The same logic is used in DSKPP as
well. This seemed to be a common practice. SAML schema also uses both
element version and schema version. In implementation, we often found
easier to handle element version for multiple version support in server
side. I agree that schema URI versioning alone could handle the case but
I also like the value of element versioning.

We will follow up more on this.

MP: I cannot find "pskc:ID". Do you mean "KeyID"? We used standard
"xs:ID" to indicate ID attributes that will be referred by other XML
objects in the document. KeyID is special one that doesn't fit the
category.

MP: Agreed.

MP: Agreed.

Section 5.1 "using a symmetric key based signature with the same key
used in the encryption of the secret key data": using the same key with
multiple algorithms is very bad cryptographic practice (e.g.  if both
the encryption and MAC use AES as the primitive, they might interact
badly).

MP: This will go to Security Consideration. We recommend using a
different key for MAC in general. If the same key is used, then security
risk exists.

MP: Will change.

Section 5.1, the example about "Extensions" isn't valid because the
"MyExtension1" element isn't in other namespace. This also applies to
Section 5.3, 5.3.1, 5.4, 5.4.2, and 5.4.4.

MP: Will correct.

Section 5.3.1, "Manufacturer" -- for e.g. physical smart card (perhaps
EMV), would this be the *manufacturer* or *card issuer*?  (probably the
latter, as you usually don't even know who manufactured your EMV credit
card).

MP: The initial seed provisioning process at the card issuer would know
who the manufacturer is. Agree that an end-user most probably won't
know. If a user bought such a card and then dynamically request a key to
load into the card, the user won't know the information. However, the
provisioning client embedded on the card usually may know. The issue may
be whether we should carry "card issuer" information here as an
additional attribute. We will review this further.

MP: Will check this further.

MP: We touched this point in the last IETF call and a follow-up call.
Let us know if this is still an issue. 

Section 5.3.1: the semantics of StartDate and ExpiryDate need
description: what should the device, or back-end server, do with these?

MP: We consider that validation service and key management may utilize
these information. If a key expires, the validation service may reject
the validation request. For other keys, it may trigger renewal. Will add
description.

MP: Agreed.

MP: Agree your assessment. Philip might have more information here.

MP: Will add. See above for device.

Section 5.4, "the value MAY be a string representation of a
Distinguished Name", here "MAY" means it can be anything else, too -- is
a MUST intended here?

MP: UserId is one of the difficult ones to define. We were weighting
whether we should allow some flexibility for a key issuer for the field
for other form, e.g., just simply the email address or even some URL (in
form of OpenID) of the user. Requiring DN format will also work with
better interoperability but rigid, I think. With DN, we will have the
following examples.

UID=[email-masked]
UID=http://mpei.myopenid.com
CN=Mingliang Pei, O=VeriSign [, C=US]

It looks fine. We will review this for a consesus.

Section 5.4.1: It sounds like you *are* actually using XML encryption,
but not to encrypt XML elements (XML encryption can encrypt things that
are not XML, and obviously those don't need XML canonicalization).
Needs rephrasing.

MP: Correct. Will rephrase.

MP: You are right. Will add.

Section 5.4.1: having an integer type (where the encrypted plaintext is
in ASCII format) would sound simpler than separate types for 32 bit and
64 bit integer (and this would be more in line with XML anyway).

MP: Sounds good for change. Will follow up.

Section 5.4.2: "Usage" element probably needs significant rewrite (once
you have text describing the various algorithm definitions, some parts
of this can probably go away anyway; e.g. the OTP/CR/
Integrity/Encrypt/Unlock attributes), and needs to describe the
semantics much better.

MP: Will follow up on this next.

MP: Will add.

Section 5.4.4: needs to describe expected behavior for both client and
server.

MP: Agreed. Will add.

MP: Agreed. aes128-cbc was discussed as the mandatory one for
encryption. 

MP: Good catch. Not sure how it was accidently copied there. Will remove
it.

MP: Will double check. Examples in the Appendix passed schema
validation. Some example section may be not correctly copied here.

MP: Will add description.

Section 6.1.1: the text isn't clear whether password-based encryption
would use just PBKDF2 to derive a key for e.g. xmlenc#aes128-cbc
encryption algorithm URI, or whether it would use pkcs-5#pbes2 as the
encryption algorithm URI.

MP: Will add more description and check. It tries to specify both key
derivation and encryption scheme. pkcs-5#pbes2 is assumed whenever a
password is used. The following original example in PKCS#5 XML is
considered a sample for PSKC. PSKC example may need to change
EncryptionMethod to be PBES2 instead of kw-aes for clarity.

<xenc:EncryptionMethod
Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2"
<pkcs-5:PBES2-params>
<KeyDerivationFunc
Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2
">
<Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</Parameters>
</KeyDerivationFunc>
<EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc">
</EncryptionScheme>
</pkcs-5:PBES2-params>
</xenc:EncryptionMethod>

MP: Can you provide an example for this comment?
http://www.ietf.org/keyprov/pskc#hotp points to www.ietf.org. It is one
of the URIs that we request for IANA registration in this document.

MP: Agreed.

MP: You are right. Will fix. I believe it intends respectively for
"urn:ietf:params:xml:schema:keyprov:..." and
"urn:ietf:params:xml:ns:keyprov..."

Section 8.4: this section probably should talk only about the URIs used
for KeyAlgorithm element; if there's need to talk about other URIs (MAC
algorithms,digest algorithms, etc) at all, those should be in separate
place.

MP: It requests to register several key algorithm URIs. The digest was
mentioned in the section 8.4.2.2 but no new ones are registered. We will
review it for cleaness.

MP: Thanks for the information. Will update.

Overall: there document doesn't really say anything about certificates
(except that Section 6.2 implies that they'd usually contain RSA keys).
It probably needs to.

MP: Certificates will be involved only in signature purpose. We would
like to follow up for more of your thoughts on this.

Overall, thank you very much for the complete section by section review,
and the great suggestions and sharp obsevations of some issues.

---------

Best regards,
Pasi