[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] draft-ietf-hip-cert-02-pre00
Mattes, David kirjoitti:
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.
We do not want to enforce all certificates to have HITs encoded as
subjects and/or issuers. It is there if you need to encode HITs. I will
rephrase the text to clearly state this.
Page 1, Introduction, Last sentence: Do you mean Section 5.2 of RFC5201?
Looks like it, will fix it.
Minor nit:
Page 3, Paragraph 1, Line 2: s/X.503.v3/X.509.v3
Typo, will fix it.
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.
We have been discussing this and our solution for this is to use
draft-heer-hip-service-00 (see Section 4.1. Certificates)to signal the
end-host about the needed additional credentials.
- 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.
I agree.
- 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.
I'll look into this.
- Are the examples in the appendixes sufficient?
It would be nice to see an example with sending a certificate chain.
With all certificates included or just the parameter headers and
parameter payload omitted? This will take loads of space but could be
usefull.
Thanks for the comments. They were helpfull.
--
BR,
Samu
"Programmer is an organism that changes caffeine into code"