[OASIS Issue Tracker] Created: (CAMP-102) 4.1.2 Validating Integrity

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

4.1.2 Validating Integrity
--------------------------

                 Key: CAMP-102
                 URL: http://tools.oasis-open.org/issues/browse/CAMP-102
             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
          Issue Type: Bug
          Components: Public Review
            Reporter: Gilbert Pilz


Patrick Durusau submitted the following PR comment (https://lists.oasis-open.org/archives/camp-comment/201309/msg00046.html):

The first paragraph of 4.1.2 Validating Integrity reads:

*****
A PDP MAY contain a manifest file, named camp.mf, at the root of the
archive. [PDP-06] This file contains SHA256 [SHA256] digests of some
or all files in the package. A Provider SHOULD reject a PDP if any
digest listed in the manifest does not match the computed digest for
that file in the package. [PDP-07]
*****

I take the implication of:

"This file contains SHA256 [SHA256] digests of some or all files in
the package."

to be that a manifest file contains only SHA256 digests.

And any PDF with a listed digest that does not match a computed SHA256
digest for a file in the package should be rejected.

Yes?

The reason I ask is that 6.1 Transfer Protocol:

*****
TLS 1.1 [RFC4346] SHALL be implemented by the Provider. [PR-41] TLS
1.2 [RFC5246] is RECOMMENDED.[PR-42] When TLS is implemented, the
following cipher suites are RECOMMENDED to ensure a minimum level of
security and interoperability between implementations:

 TLS_RSA_WITH_AES_128_CBC_SHA (mandatory for TLS 1.1/1.2) [PR-43]

 TLS_RSA_WITH_AES_256_CBC_SHA256 (addresses 112-bit security strength
requirements)
   [PR-44]
*****

may cause some confusion.

True, one requirement is for transport and the other for digests but
why permit a weaker transport protocol than is used for digests?

Second, my bad on my RFC 4346 comment yesterday in not noticing it has
been obsoleted by RFC5246. Obsolete RFCs should not be used as
normative references. I will supplement that comment.

BTW, SHA-3 is in the process of being published, as your encryption
specialists already know: http://www.nist.gov/itl/csd/sha-100212.cfm


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira