Subject: Re: [IPsec] #118: Reference for PKCS #7

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Nov 2009 19:09:24 +0200

Russ later pointed out that there are multiple RFCs defining PKCS #7. Inputs on current implementations are welcome.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 2009 1:18
To: IPsecme WG
Subject: [IPsec] #118: Reference for PKCS #7

PKCS#7  should reference RFC 2315<http://tools.ietf.org/html/rfc2315>.

Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Nov 2009 10:29:05 -0800

At 7:09 PM +0200 11/24/09, Yaron Sheffer wrote:
>PKCS#7  should reference <http://tools.ietf.org/html/rfc2315>RFC 2315.

I think we should leave this as UNSPECIFIED. There are many ways to wrap an X.509 certificate in a CMS message, and we don't know what any vendor has done.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 14:01:24 +0200

Yaron Sheffer writes:
> Russ later pointed out that there are multiple RFCs defining PKCS
> #7. Inputs on current implementations are welcome. 
> 

I think the two options is either RFC5652 (latest CMS) or RFC2315
(original PKCS#7). All other of the rfcs have been obsoleted by the
RFC5652.

I do not know enough of the later CMS versions, but RFC2630 says that
it should be backward compatible with RFC2315 expect where it was
changed to "accommodate attribute certificate transfer and key
agreement techniques for key management".

As I do not think we need any of those in IKEv2, I think it is enough
to refer to the RFC2315. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Nov 2009 15:01:05 +0200

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. There follow a few more sections with other bells and whistles leading to RFC 5652.

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.

Thanks,
	Yaron

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 14:01
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: Re: [IPsec] #118: Reference for PKCS #7
> 
> Yaron Sheffer writes:

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Nov 2009 17:14:05 +0200

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.
-- 
[email-masked]