Re: [KEYPROV] DISCUSS and COMMENT: draft-ietf-keyprov-symmetrickeyformat

Sean Turner <turners@ieca.com> Mon, 26 April 2010 00:52 UTC

Return-Path: <turners@ieca.com>
X-Original-To: keyprov@core3.amsl.com
Delivered-To: keyprov@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CD23A682F for <keyprov@core3.amsl.com>; Sun, 25 Apr 2010 17:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.849
X-Spam-Level:
X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRx7zacqCKUX for <keyprov@core3.amsl.com>; Sun, 25 Apr 2010 17:52:58 -0700 (PDT)
Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 5E0C53A6782 for <keyprov@ietf.org>; Sun, 25 Apr 2010 17:52:58 -0700 (PDT)
Received: (qmail 86182 invoked from network); 26 Apr 2010 00:52:44 -0000
Received: from thunderfish.local (turners@96.231.128.135 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 25 Apr 2010 17:52:44 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 2hRm3e8VM1kh1Nh9AzRQ_rK8NsJGWQvzJdI5lc_MHVRn.vokwCGlJEGIg2MIVe48NRFkcTJUjYGS_N2yhId1uby3AZjp6hzZzj3GUrASqNepTBI_aS_WvTeTpsRYbL7IbKqpD74MjG7phAEvF6bW9lRVgu6yTPtaxz3uKQwX9Sqzw3c7Y4c4FPaInV0cMuS_IlhIR8XPtYUU1eLIU2J2lpry8Rd2PvvKJ6P59Rv498wJAEnLKLBHQMXqFuv2Zt8FWUN9CTE8MGAyRjTw7Ff1Q50GQ.rqdtzLZzPLzIAQLwJO15pcVidpgci4hcAgL4yyrkDF3XusQSgRjarOip_qbivLcDA_Oe9WZnYJK_zYyOXUpCzx9fcJdHFbDYw2PAP6LWHLSN7HTWm39IskpgMe1sRFJ6Ep0.a8w9mHsC800.V9hgnImP3c
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4BD4E3DB.5050105@ieca.com>
Date: Sun, 25 Apr 2010 20:52:43 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: KEYPROV <keyprov@ietf.org>
References: <20100424115650.25C2A28C106@core3.amsl.com> <4BD31272.5040401@ieca.com> <4BD31E78.5020600@ieca.com>
In-Reply-To: <4BD31E78.5020600@ieca.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [KEYPROV] DISCUSS and COMMENT: draft-ietf-keyprov-symmetrickeyformat
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 26 Apr 2010 00:52:59 -0000

Sean Turner wrote:
> I got two comments that I was hoping the PSKC authors could help me with 
> because they will probably get the exact same DISCUSS and COMMENT from 
> Alexey:
> 
> 
>> Alexey Melnikov wrote:
>> DISCUSS
>>> 3.3.5:
>>>
>>> o pinUsageMode indicates the way the PIN is used during the usage of 
>>>      the key.  The following values are defined: Local, Prepend,      
>>> Append, Algorithmic.
>>>
>>> The meaning of the choices is not clear to me. So I don't think
>>> they can be used in an interoperable fashion.
> 
> Is there some text lounging around that I can use or do we have to come 
> up with our own?

I found the text in PSKC.

>  >COMMENT
>>> 3.2.7. Algorithm Parameters
>>>
>>>   o min defines the minimum size of the challenge accepted by the 
>>>         device for CR mode.  If encoding is 'DECIMAL', 'HEXADECIMAL' 
>>> or         'ALPHANUMERIC' this value indicates the minimum number of 
>>>         digits/characters.
>>>
>>> So just to double check: for a HEXADECIMAL value "ABCD", min is 4, 
>>> not 2?
>>> (The same question about "max", ResponseFormat/"length", 
>>> PINPolicy/"minLength" & "maxLength")
>>>
>>>         If encoding is 'BASE64' or 'BINARY', this         value 
>>> indicates the minimum number of bytes of the unencoded         value.
> 
> Is he correct or is there some other interpretation?

Still curious about this one.