[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:-ipsec-pki-req-03 - EKU's
At 12:24 PM 10/27/99 +0200, Rodney Thayer wrote:
>Regarding the EKU discussion...
>
>I originally put in two kinds of EKU's -- one for end systems and
>one for intermediate systems. It is my opinion that you want to be
>able to label a certificate with this information:
>
> -- it's for IPsec
> -- it's for an end system (only this machine)
> -- it's for a gateway ("intermediate") system (it can do IPsec
> for packets it forwards
Question to the group: is there a value for both the second and third
requirements? I have heard arguments both ways.
>I do not know of anyone REQUIRING EKU. I do know of multiple
>implementations of it today.
I think we need to require it in the profile so that there is a definitive
way for an IKE system to say "this cert can be used for IKE". Without such
a requirement, the IKE system has to make too many guesses that can lead to
lack of interoperability.
>If there's a PKIX lawyer in the room, and they have some
>mechanism other than EKU that is more culturally compatible
>with PKIX, we should discuss that. As I understand it, EKU
>is a "PKIX-style" feature, though, so we're ok on that point.
I will play PKIX lawyer for a moment (even though I hear guffaws from the
peanut gallery). We can put this either in EKU or policy. There are many
folks in the PKIX WG who have argued (I think persuasively) that key usage
is a type of policy. Having said that, there is no advantage of one over
the other, so I think that we should leave whatever we do in EKU.
>On the subject of "how many EKU's can you have", I don't think
>we should prohibit others, however I vaguely recall this was some
>sort of PKIX requirement. I myself have seen people wanting "swiss
>army certificates" which enable SSL, SMIME, IPsec, right turn on
>red without stopping, and all sorts of other features. I happen
>to think that's unsafe, but it does seem to be a requirement. I
>would like to allow multiple EKU's.
I agree.
--Paul Hoffman, Director
--VPN Consortium
References: