Yaron Sheffer writes: > No, Sec. 1.1.1 of RFC 5652 (which you are quoting) only describes > the differences between the original PKCS #7 v1.5 and RFC 2630.
I took the text from RFC2630 Abstract, didn't check the later ones in that much detail to find out the changes since sections... :) > There follow a few more sections with other bells and whistles > leading to RFC 5652. Yes, but I do not think we need any of those bells and whistles. > Besides, even if the later RFCs are (mostly) *backward compatible* > with RFC 2315, they may still be adding useful stuff. This is just > speculation on my part, not actual knowledge. The PKCS#7 has been used to just put together buch of certificates and send them to other end in format that other ends certificate library can easily parse, and then take the certificates out from the PKCS#7 container and use them to validate the certificate used in the authentication. This is how it was used in IKEv1 and this is how I expect it to be used in IKEv2. I.e. it was mostly what we now have with the certificate bundle, but that ASN.1 blob was sent inband and using different format. In our IKEv1 code we just recursively went through the PKCS#7 blob and added all certificate and CRLs we found from there to the certificate manager and then tried to find suitable valid certificate based on the ID. We never had any code to send those PKCS#7 wrapped blobs, but I do remember that for some vendors that was almost the only format they supported (for certificate chains). My old isakmp test site seemed to have 26 connections using pkcs#7 format to send certs in from 5 different hosts. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
