In two words, why not? What is the exact new requirement you are referring to?
More generally, this is not some obscure part of the RFC that we're
discussing. This is possibly the most mainstream usage scenario. And we need
to make every effort possible in order to ensure interoperability.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Paul Hoffman
> Sent: Monday, May 11, 2009 18:58
> To: ipsec@ietf.org
> Subject: Re: [IPsec] Issue #107
>
> At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote:
> >Or possibly:
> >
> >X.509 Certificate - Signature (4) contains a DER encoded X.509
> certificate
> >whose public key is used to validate the sender's AUTH payload. With this
> >encoding, if a chain of certificates needs to be sent, multiple CERT
> >payloads of type 4 MUST be used, the first of which holds the public key
> >used to directly validate the sender's AUTH payload. The other CERT
> payloads
> >contain the other components of the chain in natural order, i.e. each
> >certificate signing the preceding one.
>
> In a word: no. This is a new requirement on a topic that was vague before.
>
> It should be sufficient for us to say something in 3.6 about multiple CERT
> payloads being acceptable, and probably (but not necessarily) the correct
> way to send a PKIX chain if the party believes that it is needed.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
