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

Simon Josefsson <simon@josefsson.org> Mon, 09 December 2013 13:47 UTC

Return-Path: <simon@josefsson.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 2CDA31ADF84 for <keyprov@ietfa.amsl.com>; Mon, 9 Dec 2013 05:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level:
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_27=0.6, 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 LVtOkP-YFTXh for <keyprov@ietfa.amsl.com>; Mon, 9 Dec 2013 05:47:04 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 15C521ADF79 for <keyprov@ietf.org>; Mon, 9 Dec 2013 05:47:03 -0800 (PST)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id rB9Djulx027067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 14:45:59 +0100
From: Simon Josefsson <simon@josefsson.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20131125104504.CA60575E015@rfc-editor.org>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:131209:ivan.micanovic@verisec.com::k/PQjpfR+80uLvyj:i4/
X-Hashcash: 1:22:131209:smachani@diversinet.com::gnRn2/vrpBGdeeRW:61cn
X-Hashcash: 1:22:131209:rfc-editor@rfc-editor.org::Yx4VTERRJYk0MO+o:4Bna
X-Hashcash: 1:22:131209:turners@ieca.com::RKZjl6uFht1rc5hw:BLRI
X-Hashcash: 1:22:131209:mpei@verisign.com::nnd+9V2IXxLAABOe:GssN
X-Hashcash: 1:22:131209:phill@hallambaker.com::9Ox+3/+i5AundNN5:9KJN
X-Hashcash: 1:22:131209:keyprov@ietf.org::tq2+rEZJVnWuYIau:M87a
X-Hashcash: 1:22:131209:stephen.farrell@cs.tcd.ie::8e2WWGZz4vBkmxRI:8sBV
X-Hashcash: 1:22:131209:phoyer@actividentity.com::6eD1H8Gy4QUeUNl1:DlUN
X-Hashcash: 1:22:131209:hannes.tschofenig@gmx.net::uXrQ3/SJBx/vsXHP:Dhp/
Date: Mon, 09 Dec 2013 14:45:56 +0100
In-Reply-To: <20131125104504.CA60575E015@rfc-editor.org> (RFC Errata System's message of "Mon, 25 Nov 2013 02:45:04 -0800 (PST)")
Message-ID: <87siu2rvcb.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: phill@hallambaker.com, ivan.micanovic@verisec.com, mpei@verisign.com, keyprov@ietf.org, turners@ieca.com
Subject: Re: [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, 09 Dec 2013 13:47:06 -0000

Wouldn't it be more generic to require that the EncryptedValue content
holds the same data type that the PlainValue content would have
otherwise done, if encryption was not used?  Not all data types are
necessarily integers.  I would fine it confusing that we have to parse
binary data when everything else is XML.

The RFC contains examples of encrypted data, so it is possible to check
how that looks (if the encryptionkey is mentioned in the document).

/Simon

RFC Errata System <rfc-editor@rfc-editor.org>; writes:

> 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
> _______________________________________________
> KEYPROV mailing list
> KEYPROV@ietf.org
> https://www.ietf.org/mailman/listinfo/keyprov