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.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Yoav Nir
> Sent: Monday, May 11, 2009 12:23
> To: pasi.ero...@nokia.com; paul.hoff...@vpnc.org; ipsec@ietf.org
> Subject: Re: [IPsec] Issue #107
>
> Pasi.Eronen wrote:
> >
> > Yoav Nir wrote:
> > > > You can:
> > > >
> > > > a) start using hash-and-url
> > > >
> > > > b) hope your peer has the sub-CA
> > > >
> > > > c) write an extension to 4306 that allows bundles in CERT
> > > >
> > > > Doing (a) is the most interoperable, but you're probably
> > save with
> > > > (b) in a typical closed network.
> > >
> > > Or I can go with option (d) and send multiple CERT
> > payloads, as Pasi
> > > suggested here:
> > http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html
> > >
> > > (thanks, Yaron)
> > >
> > > Either way, we should have it clear what is and is not allowed in
> > > section 3.6.
> >
> > I thought this was already clear in RFC 4306, but apparently
> > it's not as clear as it should be. Section 1.2 says "...might
> > also send its
> > certificate(s) in CERT payload(s)..." -- so multiple CERT
> > payloads are allowed -- but Section 3.6 is indeed a bit
> > silent about this.
> >
> > Best regards,
> > Pasi
>
> So how about replacing this:
>
> o 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:
>
> o X.509 Certificate - Signature (4) contains a DER encoded X.509
> certificate whose public key is used to validate the sender's AUTH
> payload. Note that with this encoding if a chain of certificates
> needs to be sent, multiple CERT payloads MUST be used, only the
> first of which holds the public key used to validate the sender's
> AUTH payload.
>
>
> Email secured by Check Point
> _______________________________________________
> 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
