Re: [IPsec] Issue #107
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPsec] Issue #107
At 12:19 AM +0300 5/12/09, Yaron Sheffer wrote:
>In two words, why not? What is the exact new requirement you are referring
>to?
"multiple CERT payloads of type 4 MUST be used". That is a new requirement.
>More generally, this is not some obscure part of the RFC that we're
>discussing. This is possibly the most mainstream usage scenario.
I suspect not. From what I have heard from VPNC members over the years:
preshared secrets >>
certs issued directly from a trust anchor >
certs in a hierarchy
(Where EAP fits in this list varies wildly between vendors)
>And we need
>to make every effort possible in order to ensure interoperability.
Fully agree. That's why I think it is important to not create new MUSTs for this, but to expect implementers to be able to handle validation chains in a variety of sensible fashions.
--Paul Hoffman, Director
--VPN Consortium
- References:
- [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- From: Matthew Cini Sarreo
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- From: Matthew Cini Sarreo
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
- [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
- Re: [IPsec] Issue #107
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.