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
