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

From: Samu Varjonen <[email-masked]>
Date: Wed, 16 Jun 2010 13:16:02 +0300

Hi,

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

Changes from the previous version:

- Addition of the non-HIP aware use case
- changed wording in the introduction
- changed the LDAP URL to DN as it should be in the end of section 2
- changed "may be covered by HIP signature" to "is covered" as RFC 5201
   says "Parameters numbered between 0-1023 are used in HIP
   handshake and update procedures and are covered by signatures"

Comments are appreciated...

BR,
Samu Varjonen

---

From: "Mattes, David" <[email-masked]>
Date: Thu, 17 Jun 2010 09:39:39 -0700

Hi Samu,

Thank you for updating the draft.  Here are a few nits:

Section 2, last paragraph, 2nd sentence: s/Using LDAP DN encoding/Using DN encoding/
Section 5: missing period after 1st sentence: s/[RFC2693]  Revocation/[RFC2693].  Revocation/
Section 9, last sentence, repeated word: s/Section Section 3/Section 3/

Regards,
David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Samu Varjonen
> Sent: Wednesday, June 16, 2010 3:16 AM
> To: HIP
> Subject: [Hipsec] draft-ietf-hip-cert-04-pre01
> 
> Hi,
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Ari Keranen <[email-masked]>
Date: Thu, 24 Jun 2010 11:28:52 +0300

Hi Samu,

> 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.

    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?

              |         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.

7.  IANA Considerations

Should the certificate types have their own registry?

Cheers,
Ari

---

From: Samu Varjonen <[email-masked]>
Date: Wed, 30 Jun 2010 14:20:46 +0300

Hi,

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

Comments inline...

> present)" after "is covered" to point out that in I1 it would not be 

OK, changed

> MTU, PMTUD, or something?

Have to think a bit more on this.

> encodings, but just "Hash and URL" that contains concatenation of the 

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

> Should the certificate types have their own registry?

I would say yes, any other opinions.

---

From: Ari Keranen <[email-masked]>
Date: Wed, 30 Jun 2010 16:14:25 +0300

Hi,

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

Thanks, looks better now. More comments in line.

>> through which form is appropriate.

I still found only one capitalized MUST in the whole document (and no 
MAYs or SHOULDs). Maybe it's just me, but I find a non-informational 
document lacking RFC 2119 keywords a bit disturbing: it looks like it is 
all purely informational.

Then I realized that the document's current status is indeed 
Informational. Shouldn't it be experimental?

>> 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

This is a true nit, but I would have put the "where present" in 
parenthesis or surrounded it with commas.

> I would say yes, any other opinions.

Yes.

Cheers,
Ari