Subject: Re: [KEYPROV] Additional notes about PSKC

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 17 Sep 2008 14:29:01 +0200

Thanks Pasi for your comments I will review and comment when back from holiday (end of September)

Philip

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Wed Sep 17 11:48:42 2008
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.

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

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