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

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

    [ http://tools.oasis-open.org/issues/browse/CAMP-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36033#action_36033 ] 

Gilbert Pilz commented on CAMP-102:
-----------------------------------

With respect to the comment on "weaker hash algorithm for transport and than for digests" comment: There is no particular reason that the hash algorithms for the transport and the manifests should agree with one another; the context in which they are used is different. The hash algorithm in TLS is used primarily to guarantee the integrity of the *messages* exchanged between CAMP clients and servers. The hash algorithm used to generate the digests of the files in the PDP is used to guarantee the integrity of the *files* in the PDP. The effective strength of the integrity guarantee is the *greater* of that used during transport and that in the camp.mf file.

For example, if the Provider allowed it (through an extension), a client could upload a PDP in the clear, with no integrity protection whatsoever. A man in the middle could completely alter the contents of the files in the PDP but none of the files so altered will have a digest value that matches the value in the camp.mf file (which is signed with the secret key corresponding to the public key in the camp.cert file).

With respect to the use of SHA-3: there isn't any compelling reason to specify the use of this hashing standard either as a requirement (e.g. "SHALL"), or an option (e.g. "SHOULD" or "MAY"). No significant attack on the SHA-2 family has been demonstrated. Meanwhile requiring CAMP implementations to use a relatively new hashing function may hurt adoption as the required libraries for the Providers language of choice may not exist yet.

> 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