Paul Hoffman writes: > 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.
Yes, it might be better to say at the beginning of the section 3.6 that multiple CERT payloads is allowed, and if CERT encoding is such that it can only encode one certificate then multiple CERT payloads is the way to send the chains. If encoding can handle multiple certificates (Hash and URL of X.509 bundle), then the whole certificate chain (and associated CRLs if needed) can be sent as one CERT payload (or split to multiple pieces if needed). There can also be multiple CERT payloads with different encodings. Sending multiple CERT payloads is not only restricted to X.509 Certificate - Signature (4) format, and because of this the text should be at the beginning of 3.6 section. Note, that 3.6 explicitly says that except the first certificate, all other certificates can be in any order. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
