Re: [KEYPROV] New version of PSKC

The reason is that DerivedKey portion only describe how a key is derived for a desired length, not indicating how a key is used. For PBES2, the encryption scheme parameter is required. It should either go to PKCS#5 parameters, or EncryptionMethod part of the xenc:EncryptedDataType. We chose the second one. The encrytion key element contains only the key portion as we have been doing, similar to the pre-shared key case. It is consistent. The common element EncryptionKey includes the key data information, not the encryption algorithm information.

- Ming

From: Philip Hoyer [mailto:phoyer at actividentity.com]
Sent: Wednesday, September 02, 2009 5:18 AM
To: Pei, Mingliang; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Ming and all,

Please see questions and explanation of my perplexion below. Bear with me.

Which MAC key for which example?

My main concern are the PBE examples that you generated and the existing one forget for a moment the namsespace change.

Following are some differences (highlighted in bold):

SPEC ONE:

Lets start with an extract of the existing one in the spec:

    <pskc:MACMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
        <pskc:MACKey>
            <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
            <xenc:CipherData>
                <xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoNhk05y8DNyOHuSDuRZLn6DhIjoTY/dX4SkUAbQ
SWJblA7Dzi031L6FNnUrcjsGGcQ==
                </xenc:CipherValue>
            </xenc:CipherData>
        </pskc:MACKey>
    </pskc:MACMethod>

GENERATED ONE:

<pskc:MACMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">

<pskc:MACKey>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx</xenc:CipherValue>

</xenc:CipherData>

</pskc:MACKey>

</pskc:MACMethod>

Now I do not understand why we need EncryptionScheme at all. Should it not be as the one in the spec?

I have the same question about EncryptionScheme later in both examples:

SPEC ONE:

....

<pskc:Secret>

                <pskc:EncryptedValue Id="ED">
                    <xenc:EncryptionMethod
                        Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">
                        <pskc:EncryptionScheme
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        </xenc:EncryptionMethod>
                        <xenc:CipherData>
                            <xenc:CipherValue>
      oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f
                        </xenc:CipherValue>
                    </xenc:CipherData>

GENERATED ONE:

ryptedValue>

<xenc:EncryptionMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2">

<pskc:EncryptionScheme Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

</xenc:EncryptionMethod>

<xenc:CipherData>

<xenc:CipherValue>oTvo+S22nsmS2Z/RtcoF8Hfh+jzMe0RkiafpoDpnoZTjPYZu6V+A4aEn032yCr4f</xenc:CipherValue>

</xenc:CipherData>

Why do we need EncryptionScheme at all? Since we know it is a derived key in the main element?

Should these not be like the preshared key one?:

PRE-SHARED-KEY

<Secret>
                    <EncryptedValue>
                        <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>
    AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
                            </xenc:CipherValue>
                        </xenc:CipherData>
                    </EncryptedValue>
                    <ValueMAC>aSRlEG1agUo0CS2dt/OvIAqQ6Co=
                    </ValueMAC>
                </Secret>

Also should we align the examples that they use prefixed namespace for pskc. e.g. <pskc:element> I rather have default namespace of pskc so that it reads: <element>.

Additional question, should we add the xenc11 import statement to the schema?

Philip

From: Pei, Mingliang [mailto:mpei at verisign.com]
Sent: Wed 02/09/2009 7.43
To: Philip Hoyer; Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: RE: New version of PSKC

Hi Philip,

Please see the forwarded email that includes the examples from my implementation that I sent earlier. The latest draft doesn't seem to have the CipherValue for the MAC key right. Please update it to

2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx

Thanks,

- Ming

From: Philip Hoyer [mailto:phoyer at actividentity.com]
Sent: Friday, August 28, 2009 9:56 AM
To: Hannes.Tschofenig at gmx.net; Phillip Hallam-Baker; Pei, Mingliang; Salah Machani; Sean Turner
Cc: Doherty, Andrea; Magnus Nyström; KEYPROV
Subject: New version of PSKC

Ladies and Gentlemen,

Please find attached the new version of PSKC.

Changes:

incorporated all of the feedback from Andrea and Sean.
reference name change to the new DerivedKey element (moved to XMLEnc11)
Corrected AES example to include (prepend) IV inline with XMLENC spec and mentions IV handling.

I have one big problem:

The samples that Ming sent out for PBE and RSA do not match the ones in the spec.

Especially the PBE is different form the one Ming already says was corrected.

Based on the new XML Enc 1.1 spec for PBE and DerivedKeys. Are we sure we are aligned here?

This is the only thing that needs to be clarified.

Otherwise,

What do I need to do now.

Do I just submit or send to Russ and Pasi directly?

Philip

________________________________

Philip Hoyer

Senior Architect - Office of CTO

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

Telephone: +44 (0) 20 7960 0220

Fax: +44 (0) 20 7902 1985

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.