Re: [Hipsec] draft-ietf-hip-cert-04-pre01

Samu Varjonen <samu.varjonen@hiit.fi> Wed, 30 June 2010 11:21 UTC

Return-Path: <samu.varjonen@hiit.fi>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD943A695A for <hipsec@core3.amsl.com>; Wed, 30 Jun 2010 04:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Level:
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=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 W9UwY6f0Q6LW for <hipsec@core3.amsl.com>; Wed, 30 Jun 2010 04:21:01 -0700 (PDT)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 3EDDF3A67D0 for <hipsec@ietf.org>; Wed, 30 Jun 2010 04:21:01 -0700 (PDT)
Received: from [128.214.113.196] (sutherland.hiit.fi [128.214.113.196]) by argo.otaverkko.fi (Postfix) with ESMTP id 4464225ED10; Wed, 30 Jun 2010 14:21:11 +0300 (EEST)
Message-ID: <4C2B288E.3000703@hiit.fi>
Date: Wed, 30 Jun 2010 14:20:46 +0300
From: Samu Varjonen <samu.varjonen@hiit.fi>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Ari Keranen <ari.keranen@nomadiclab.com>
References: <4C18A462.40206@hiit.fi> <4C231744.3010204@nomadiclab.com>
In-Reply-To: <4C231744.3010204@nomadiclab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] draft-ietf-hip-cert-04-pre01
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2010 11:21:03 -0000

Hi,

Here is the new preversion of the hip-cert with some editorial changes, 
clean-up, new certificate examples, and so on...

http://www.cs.helsinki.fi/u/sklvarjo/draft-ietf-hip-cert-04-pre02.txt

Comments inline...

Ari Keranen wrote:
> Hi Samu,
> 
> On 06/16/2010 01:16 PM, Samu Varjonen wrote:
>> Here is the preversion of the draft-ietf-hip-cert-04
>> http://www.cs.helsinki.fi/u/sklvarjo/draft-ietf-hip-cert-04-pre02.txt
> 
> Great! Looking forward seeing this work finalized.
> 
> [...]
>> Comments are appreciated...
> 
> Some comments:
> 
> The document would benefit from using more normative language, i.e., 
> capitalizing the relevant shoulds/musts/mays and thinking once more 
> through which form is appropriate.
> 
> 
> 2.  CERT Parameter
> 
>    The CERT parameter is covered by the HIP SIGNATURE field and is a
>    non-critical parameter.
> 
> This is better than the previous version, but I'd suggest adding "(where 
> present)" after "is covered" to point out that in I1 it would not be 
> covered by a signature.
> 

OK, changed

>    Cert groups may only span multiple
>    packets if the Cert group does not fit the packet.
> 
> What packet size limit should one use for determining this? Next hop 
> MTU, PMTUD, or something?

Have to think a bit more on this.

> 
>              |         URL of X.509.v3        |      3      |
>              |           URL of SPKI          |      4      |
>              |        Hash of X.509.v3        |      5      |
>              |          Hash of SPKI          |      6      |
> [...]
>    Hash and URL encodings (3 to 6) are used as defined in [RFC4306].
> 
> I'd recommend adding the corresponding section number(s) to the 
> reference since the IKEv2 spec is quite a long one. And if I understand 
> RFC4306 correctly, you should not have separate "Hash" and "URL" 
> encodings, but just "Hash and URL" that contains concatenation of the 
> hash and URL.
> 

Good catch, it was correct in some earlier versions and in some point in editing 
it has been changed. Reverting it to "Hash and URL" like it is described in RFC 
4306 section 3.6

> 
> 7.  IANA Considerations
> 
> Should the certificate types have their own registry?
> 

I would say yes, any other opinions.

> 
> 
> Cheers,
> Ari