[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] draft-ietf-hip-cert-02-pre00
Hi.
Comments inline.
Am 22.10.2009 um 08:16 schrieb Samu Varjonen:
Henderson, Thomas R kirjoitti:
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.
The HIP hip-service-00 draft presents a general way of notifying end-
hosts about requirements and properties of a service and allows some
simple negotiations. Requesting certain certificates was one of the
main reasons for writing the draft. However, we felt that more general
negotiations would be out of scope for the hip-crt draft. The draft
has not been advanced because we got very little comments on which
services people would/could use. If needed we can narrow down the
types of services that can be negotiated and focus on the signaling of
the certificate first but I wouldn't really want to abandon a more
general use of the HIP service parameter.
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.
If needed we can flesh out the certificate handling in the hip-service
draft to support the hip-cert draft. So far, the hip-service-00 draft
was discussed in the RG. Should we expand this to the WG and process
hip-cert and hip-service as a bundle?
BR,
Tobias
- 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"
_______________________________________________
Hipsec mailing list
Hipsec at ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
--
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer