[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] draft-ietf-hip-cert-02-pre00
Henderson, Thomas R kirjoitti:
-----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?
There is an answer in the earlier mail for this. Rephrasing the text.
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.
That can be done after I rephrase the mandated HIT text.
2) elements of procedure for exchanging CERTs, or requesting that the peer provide a CERT.
This has been discussed but for some reason we put it into
hip-service-00. Do you think hip-cert should have its own way of asking
the certificates or could it use hip-service-00? The functionality would
overlap with the hip-service-00.
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.
Sounds like hip-service-00 :)
- 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.
It was supposed to be like: If you implement this non-critical parameter
you should at-least implement support for this certificate. But I can
see your point and I am leaning towards it and here I should refer to
the hip-service-00 again.
- 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.
Looking into this and agreeing.
- 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).
OK. can be done.
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.
OK, will fix this.
Regards,
Tom
Thanks for the helpful comments.
--
BR,
Samu
"Programmer is an organism that changes caffeine into code"