Subject: CMS Questionnaire

From: Sean Turner <[email-masked]>
Date: Mon, 26 Jan 2009 15:48:47 -0500

Russ and Tim have challenged me to try to advance CMS to Draft Standard 
using the process in BCP 97 to deal with the dependencies that have not 
yet advanced (or aren't advancing).  To that end, I've drawn up the 
following questionnaire that I'd like implementers to complete and 
return to me.  What we're shooting for is to find two implementations 
that generate messages for each feature, and two implementations that 
process each feature.  We don't think it should matter if the same two 
implementations are used in both stages.

Thanks in advance,

spt
Please list the product and version number (if applicable) covered by this questionnaire.

What evidence do you have that you can interop with other implementations?
Have you worked through the examples draft?

Which of the following content types did you implement:
- ContentInfo,
- id-data,
- id-signed-data,
- id-enveloped-data?

For those that implemented SignedData:
- which version(s): v1, v3, v4, v5?
- without Certificates & CRLs?
- with Certificates?
- with CRL?
- with embedded content?
- with detached content?
- SignerInfo without signed attributes?
- SignerInfo with signed attributes: id-messageDigest, id-contentType, id-signingTime, id-counterSignature?
- SignerInfo with unsigned attributes?
- SignerInfo with SKI, issuer/serialnumber, or both?

For those that implemented EnvelopedData:
- which version(s): v0, v2, v3, v4?
- with unprotected attributes?
- which RecipientInfo: ktri, kari, kekri, pwri, ori?
- for ktri, which identifier issuer/serial, SKI, or both?
- for kari, which identifier issuer/serial, SKI, or both?
- for kari, was ukm supported?
- for kekri, is date, other or both supported in KEKIdentifier?

For those that implemented both SignedData and EnvelopedData:
- Can you support receiving a triple wrapped message: An id-signedData encapsulated in an id-envelopedData encapsulated in id-envelopedData?

Bonus questions, which are not going to be included in the CMS interop report:
- For SignedData, do you support the multisig ID?
- For AuthenticatedData, do you support DigestedData, CompressedData, EncryptedData, and/or AuthEnvelopedData?
- For SignedData what do you do when you encounter an attribute that you don't support?

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 27 Jan 2009 16:22:10 +1300

>implementations are used in both stages.

Are you just after straight yes-or-no answers, or are you interested in 
metadata as well?  By metadata I mean things like "I probably support method 
XYZ but since I've never found anything else that does to test against I can't 
guarantee that it's correct", or "I've implemented XYZ but since no user has 
ever asked for it it's never been tested".  It may be useful to get (or at 
least I'd be very interested in seeing) data on what's actually being used in 
the real world.  Motivated by the history of RFC 4134, I'd also prefer to be 
able to qualify a claim of "I support XYZ" with further details if there's 
never been any opportunity to test whether it's actually implemented as 
required (in other words to differentiate "I'm pretty sure I support XYZ" vs. 
"I definitely support XYZ and have interoperated with others using it").

Peter.

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Jan 2009 10:21:56 -0500

> "I definitely support XYZ and have interoperated with others using it").

I'm definitely interested in metadata.

spt