Re: [Hipsec] draft-ietf-hip-cert-02-pre00

["Mattes, David" <david.mattes at boeing.com>]

Hi Samu,

As some background, I am focused on using HIP operationally and therefore have a pragmatic point of view of the specifications.  Here are some in-line opinions for your questions below.

Also, what is the purpose of requiring the HIT as part of the X.509 information?  In practice (at least until HIP is a de-facto standard ;-), I think it will be quite difficult to convince Certificate issuers to include new or different information.  I think you should remove that recommendation from the draft.

Page 1, Introduction, Last sentence: Do you mean Section 5.2 of RFC5201?

Minor nit:
Page 3, Paragraph 1, Line 2: s/X.503.v3/X.509.v3

Thank you for your work on this!

Regards,
David Mattes

> -----Original Message-----
> - Is the draft sufficient? Do we need to specify something more? Is
> something important missing?

I agree that having on-path middleboxes request remote data is problematic (also from a trust point of view!), so what about introducing a mechanism for the middleboxes or responders to request the full certificate when presented with a CERT URL?  This way, middleboxes and responders can cache certs and only request the entire certificate when necessary.  This mechanism could also allow post-mobility-event middleboxes to request endpoint certificates when they start to see a new flow.  

This mechanism is probably outside the scope of this draft, but would the requests themselves be defined here?  Another object I could envision being requested would be a CA chain for a given certificate.

> 
> - Is SPKI the right choice for the default format? X.509 is more widely
> deployed and has better support vs. SPKI is simpler but has less
> support. In the pre-version I already changed X.509s as the default,
> because the X.509s are commonly used in the wild and SPKIs are more like
> research curiosity(?).

I think that X.509 should be the default format.

> 
> - Are the hash and URL encodings needed? At least with on-path
> middleboxes they are problematic.

I think the hash and URL encodings are important and would even like to see them expanded to include http URL, Distinguished Name, and LDAP path.

> 
> - Are the examples in the appendixes sufficient?

It would be nice to see an example with sending a certificate chain.