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

[Massimiliano Pala <pala@xxxxxxxxxxxxxxxx>]

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]            pala@xxxxxxxxxxxxxxxx
                                                 project.manager@xxxxxxxxxx

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