Subject: CM over CMS (draft-ietf-pkix-2797-bis-04.txt)

From: Massimiliano Pala <[email-masked]>
Date: Tue, 07 Aug 2007 12:22:34 -0400

Hi all,

I have several questions about the CMM over CMS document. First of all,
the current draft published on the web pages of the WG is expired (Sep 2006),
does this mean that there is no interest in going forward with this
document ?

I do have to say I did not follow the discussions about this document, but
I hope the authors to clarify some of the rationales that were followed when
writing the doc. It seems to me that this draft is *really* complex to
implement. Many of the MUST, as I see them, should be changed to MAY. For
example section 5.2 states that servers and clients MUST implement the
Identification and IdentityProof Control Attributes based on shared secrets.
Why ?

I also noticed the extensive usage of the `ANY DEFINED BY' in the document,
which, in my experience, are not really easy to deal with when developing
applications - and this may easily lead to implementation bugs and security
holes. Was this the only viable option ?

I do really support the message wrapping, but I am not a great fan of the
BodyPartPath/BodyPartID method to identify a message part... is this really
needed ? Can the controls be referred to the whole wrapped message ? Maybe
it would be less flexible, but it would definitely be easier and less error
prone :)

Practical Question -> Do you know of any full implementation ? If so, are
them publicly available ?

Some other small questions are as follows:
* In section 3.3.3.2 why CMC compliant implementation MUST support [DH-POP]
   section 4 ?

* In section 4.5 - the three options are required to be supported. I do not
   see what great benefits are coming from Option2 over Option1, the only
   thing is that you may authenticate the data before decrypting. Is this
   really needed ? Can we simplify with a MUST support Normal and Option1 and
   MAY support Option2 ?

* Section 3.6.3 - Typo error (?) ``This control >>is<< uses the PKIData ..."

* Section 5.4 - In the Data Return Control Attribute the clients are allowed
   to send arbitrary data to the server. Am I the only one that thinks this
   could be a security threat ? Allowing for "arbitrary" input from clients
   is usually (in my experience) a very bad idea. At least some type of
   constrains should be enforced, in my opinion.

* Section 5.6 - I would strongly suggest to extend the use of NONCES by
   changing the MAY to SHOULD. For example "Replay protection can be supported..."
   should be changed in "Replay protection should be supported by .. ", and
   "Clients MAY include ... " in "Clients SHOULD include ...". Any specific
   reason for this to be optional and not strongly encouraged ?

* Section 5.5.1 / 5.5.2 - Why the Add Extension Control has not been eliminated ?
   Besides, where can I find the CertTemplate definition ?

* Section 5.11 - Maybe I am missing something here, but how does the EE get the
   shared secret needed to revoke the certificate ? Could this be included in the
   full response (encrypted with the key from each certificate issued ?). As well,
   to protect the real value of the revocation-enabling value, should this be
   encrypted ? It should be a one-time usage.. but what if the rev request is
   rejected ? Does that value still holds ? As it has been exposed, should the
   CA/LRA send another one ?

I guess this is enough... I would really like to have a more simple approach
to CMM over CMS, any will to work to simplify it ?

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------