Re: [secdir] review of draft-ietf-keyprov-symmetrickeyformat-07

Sean Turner <> Sun, 25 April 2010 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D407A3A69D4 for <>; Sun, 25 Apr 2010 15:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.863
X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pXytN0jIUO9d for <>; Sun, 25 Apr 2010 15:55:43 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 606713A689B for <>; Sun, 25 Apr 2010 15:55:42 -0700 (PDT)
Received: (qmail 89144 invoked from network); 25 Apr 2010 22:55:28 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 25 Apr 2010 15:55:27 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: Bd3T1h0VM1lsCI2F_ulu2niZsnR8aT6HMvean8fUb3DOiYDowYoik7yIAmxtzlfuygENeOsckD7L097iIAzxfcbr3kTYkNCf9tg_JuIJwTBXege3Px.7y8RD1c4umv4QytinxMn1ZpGIwheuWtBTR.UJgJSuw7K1RHHDZowXVcegxP7SY_fVL2oSxzPM4q2Rlalr2uXsOXK7GpVxS5h7J.fivgPupzULmaEx6Ky0UmlBlsABPpgZ2Zp1S_y_nRecW8vg.JS3UM5nXn6uIEycS.1PIk9hOGaDXsZG5ULH7c5sbh5NP6kgZSPxF1kt9OWxW2CD0OehFsBuOICS_cRJaodQaHsjAOZUETP2zxF67UjN.ghXvWzNT8nQM.LJKN07dtd7Y7P_ddh2RxUF6Ku5Z_7VFgQG9P4Z5Ja4v8sOEAJn3uOzMQeHgYxBiv7M6S9GCzK9Mleo4HTSX1oHuHo-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Sun, 25 Apr 2010 18:55:22 -0400
From: Sean Turner <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] review of draft-ietf-keyprov-symmetrickeyformat-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Apr 2010 22:55:43 -0000

Joseph Salowey (jsalowey) wrote:
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> The document defines an ASN.1 container for symmetric keys.  This seems
> useful.  For the most part the document is clear.  I have the following
> comments (I also copied the authors of draft-ietf-keyprov-pskc-05 since
> some of the comments may more pertain to that document). 
> 1. Is the sKey value encrypted or clear text?  

It can be either.  If it's in the cleartext then an encapsulation 
mechanism is needed to provide confidentiality (DSKPP provides one and 
CMS is another).  But, you could also encrypt just the key and add an 
attribute that gives you the information needed to decrypt it.

> 2. Section 3.2.12 Value MAC
> I was not clear to me how this MAC was calculated.  What exactly does it
> cover?  I assume it is the octet string in the sKey field in the
> OneSymmetricKey sequence.  Does it include the ASN.1 encoding or not.  

This attribute is necessary because PSKC supports encryption of just the 
key but the required key encryption algorithms does not provide an 
integrity check (i.e., they're requiring AES-128-CBC and not AES Key 
Wrap or AES Key Wrap with Padding).  If the key is encrypted with an 
algorithm that doesn't support an integrity check, then you do a MAC 
over the encrypted key (the text uses "encrypted value") and this 
attribute identifies the MAC algorithm and includes the MAC value.  Does 
the following make more sense:


The Value MAC attribute is a Message Authentication Code (MAC) generated 
from the encrypted value in case the encryption algorithm does not 
support integrity checks (e.g., AES-CBC does not provide integrity while 
AES Key Wrap with MLI does).


The Value MAC attribute is a Message Authentication Code (MAC) generated 
over the encrypted key in case the key encryption algorithm does not 
support integrity checks (e.g., AES-CBC does not provide integrity while 
AES Key Wrap with MLI does).  The MAC is over the value portion of the 
sKey field.

> 3. Why is section 4 necessary in
> draft-ietf-keyprov-symmetrickeyformat-07 and not in

I don't see why it couldn't go in PSKC.  I think I just forgot to 
suggest that they include it.

> Thanks,
> Joe