[KEYPROV] [Technical Errata Reported] RFC6030 (3811)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 25 November 2013 10:45 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: keyprov@ietfa.amsl.com
Delivered-To: keyprov@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36541AD73F for <keyprov@ietfa.amsl.com>; Mon, 25 Nov 2013 02:45:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.303
X-Spam-Level:
X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_27=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCfkPHGg_Jq1 for <keyprov@ietfa.amsl.com>; Mon, 25 Nov 2013 02:45:05 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9353A1ACC7D for <keyprov@ietf.org>; Mon, 25 Nov 2013 02:45:05 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id CA60575E015; Mon, 25 Nov 2013 02:45:04 -0800 (PST)
To: phoyer@actividentity.com, mpei@verisign.com, smachani@diversinet.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, phill@hallambaker.com, Hannes.Tschofenig@gmx.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20131125104504.CA60575E015@rfc-editor.org>
Date: Mon, 25 Nov 2013 02:45:04 -0800 (PST)
Cc: keyprov@ietf.org, ivan.micanovic@verisec.com, rfc-editor@rfc-editor.org
Subject: [KEYPROV] [Technical Errata Reported] RFC6030 (3811)
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyprov/>
List-Post: <mailto:keyprov@ietf.org>
List-Help: <mailto:keyprov-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 10:45:07 -0000

The following errata report has been submitted for RFC6030,
"Portable Symmetric Key Container (PSKC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6030&eid=3811

--------------------------------------
Type: Technical
Reported by: Ivan Micanovic <ivan.micanovic@verisec.com>;

Section: 4.1.

Original Text
-------------
All the elements listed above (and those defined in the future)
      obey a simple structure in that they MUST support child elements
      to convey the data value in either plaintext or encrypted format:

      Plaintext:  The <PlainValue> element carries a plaintext value
         that is typed, for example, to xs:integer.

      Encrypted:  The <EncryptedValue> element carries an encrypted
         value.

Corrected Text
--------------


Notes
-----
In case that <Counter>, <Time>, <TimeInterval> or <TimeDrift> are encrypted in the PSKC file, the standard doesn't say anything about how to interpret this encrypted data.
After decrypting those values we have byte array. 

Example: 
   Counter plain text value: 10000 decimal

   In the case that this value is encrypted and later decrypted what should we expect?
   Byte content 0x27 0x10 or 0x01 0x00 0x00 or something else?

   1. Byte content 0x27 0x10 is interpreted as 10000 decimal if this bytes are interpreted as binary data (Big endian). 
   2. Byte content 0x01 0x00 0x00 is interpreted as 10000 decimal if this bytes are interpreted as hex data (Big endian).
      Each hex digit will be mapped to a resulting decimal digit. From my point of view this way is a bit confusing.
       
My proposal to solve this issue is described in 1.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6030 (draft-ietf-keyprov-pskc-09)
--------------------------------------
Title               : Portable Symmetric Key Container (PSKC)
Publication Date    : October 2010
Author(s)           : P. Hoyer, M. Pei, S. Machani
Category            : PROPOSED STANDARD
Source              : Provisioning of Symmetric Keys
Area                : Security
Stream              : IETF
Verifying Party     : IESG