Subject: Re: [KEYPROV] Additional notes about PSKC

From: <[email-masked]>
Date: Mon, 13 Oct 2008 10:32:00 +0300

Hi Ming,

I haven't yet checked the updated draft you posted last Wednesday,
but here are quick replies about some issues:

> > Section 5.1 and 5.2: would it be simpler to use the "xml:id"
> > attribute instead of defining a new "pskc:ID" attribute?
> 
> 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.

pskc:ID attribute is present in e.g. KeyContainerType and
KeyPropertiesType.

<snip>
> > 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.

To make this actually work, I think you should specify how a single
key string (entered by the admin) gets used (e.g. derive two keys with
a PRF, or just split the string if it's of correct length).

<snip>

> > Section 5.3.1: semantics of DeviceBinding seem vary vague (and
> > unlikely to lead to any kind of interoperability).
> 
> MP: We touched this point in the last IETF call and a follow-up call.
> Let us know if this is still an issue. 

I haven't participated in these conference calls, but I'm looking
forward to seeing the updated text.

<snip>
> 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).
> 
> 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.

You can't register www.ietf.org URIs with IANA, only URNs.

<snip>
> > 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.

Typically other IETF documents have said e.g. how the certificate is
validated (often using pre-configured trust anchors and RFC 5280 path
validation -- but e.g. draft-ietf-syslog-transport-tls used fingerprints
since assuming PKI is deployed everywhere wasn't a realistic assumption),
and how the information in the certificate (subject/subjectAltName, EKU, 
etc.) is used by the party verifying the signature.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 13 Oct 2008 11:21:22 +0200

>a PRF, or just split the string if it's of correct length).

This is indeed extremely important.  Personally (as a non-cryptographer),
I'm skeptical about applying rules like section 5.1 to a (one-time) key
import operation, and would go to any length avoiding multiple keys
(passwords).  I would also take a peek in other schemes like PKCS 12
and JKS and see how they address this problem.   Key derivation seems
like a very good "workaround".

Anders

---

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 16 Oct 2008 18:19:20 -0700

Hi Pasi,

Thank you for the clarifications. Please see inline.

- Ming 

---------

> pskc:ID attribute is present in e.g. KeyContainerType and 

Right. Agreed, and I have made change by now.

> > > 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).
> > 
> To make this actually work, I think you should specify how a 
> single key string (entered by the admin) gets used (e.g. 
> derive two keys with a PRF, or just split the string if it's 
> of correct length).
> 

Good point. DSKPP uses this approach. We will consider adding some
specification along this line.

> I haven't participated in these conference calls, but I'm 
> looking forward to seeing the updated text.
> 

Will update text for further clarification and ask your review.

> > It is one of the URIs that we request for IANA registration in this 
> > document.
> 

I will look into this further. For a quick reference, do you mean that
only those with www.ietf.org cannot or actually any URIs with IANA? Many
existing algorithms are cited as URIs rather than URNs, e.g. those in
XMLDSIG and XMLENC such as

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

> Typically other IETF documents have said e.g. how the 
> certificate is validated (often using pre-configured trust 
> anchors and RFC 5280 path validation -- but e.g. 
> draft-ietf-syslog-transport-tls used fingerprints since 
> assuming PKI is deployed everywhere wasn't a realistic 
> assumption), and how the information in the certificate 
> (subject/subjectAltName, EKU,

If I understand correctly, you mean that the document should discuss how
the certificate will be utilized and verified. PSKC uses certificate for
key transport purpose only. The key transport with a certificate and
decryption with its private seem to be well known. But it will be more
precise and clearer as a specification with more information on the
requirement of certificate. For example, the key pair should be strong
for the protection purpose and so on. Do you think that some addition
along this line be sufficient?