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

["Henderson, Thomas R" <thomas.r.henderson at boeing.com>]

> -----Original Message-----
> From: hipsec-bounces at ietf.org
> [mailto:hipsec-bounces at ietf.org] On Behalf Of Mattes, David
> Sent: Wednesday, October 21, 2009 11:44 AM
> To: 'Varjonen Samu'; HIP
> Subject: Re: [Hipsec] draft-ietf-hip-cert-02-pre00
>
> 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.

I am guessing that the HIT is mandated because the draft focuses on self-signed certificates.  However, I don't really understand such a use case (self-signed certificate).  Isn't all of the information in the example certificate already provided as part of RFC 5201 HIP messaging?

I had thought that the HIP CERT draft could specify the following:
1) using the HIP HI (public key) as a subject public key, bind a subject Alternative Name (such as email address or other value) to that key, based on the CA signature.
2)  elements of procedure for exchanging CERTs, or requesting that the peer provide a CERT.

So, I'm guessing that David has the first use case in mind, that the CA need not even be HIP aware but is just asked to sign the binding between key and name, and then the host can use the subject key as a host identity.

Regarding elements of procedure, it seemed to me that it would be in scope to specify how to ask the end host to provide a CERT, plus how to handle failure cases (e.g. "I don't recognize the CA", "Bad certificate signature", etc.).  In addition, I agree with David's comment that a HIP-aware middlebox ought to be able to challenge a host to provide a CERT.  I don't know whether just a generic challenge would be needed, or whether the middlebox would be able to identify the CAs that it recognizes in the challenge.

> >
> > - Is SPKI the right choice for the default format?

Do we need a default for this?  What does it mean that "All implementations MUST support the X.509v3 format."  This is an optional, non-critical parameter.

It seems to me that implementations ought to be RECOMMENDED to support one or both formats, and we specify what happens when one side of the exchange does not understand CERT at all, or when it understands CERT but does not support the Type number.

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

Agree.

>
> >
> > - Are the examples in the appendixes sufficient?
>
> It would be nice to see an example with sending a certificate chain.

Agree (a non-self-signed example).

A few small editorial comments are that in section 2, the capitalization is not consistent in paragraph 3, and it seems like the last sentence before the figure should be the lead sentence of paragraph three, so the reader doesn't infer from the existing paragraph three lead sentence that any HIP packet (e.g. I1) carries CERT.

Regards,
Tom