Encryption Updates

Proposal Editing Information

• Who Updates: JarekKaczynski, JohnShields, StevenDovich
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus: IP

Requirement Summary

* Corrections_to_the_Encryption_Flow_description_in_IEEE_Std_1076.pdf: (Jerry Kaczynski). Based on the works of P1735 group.

• • Adopt recommendations (under development) from P1735 for Encryption -- JohnShields - 2011-06-09
    • required algorithm support for encryption and encoding
    • new pragmas for visibility and rights management
    • incorporation of use case and key management recommendations by reference

Note: Visibility and rights management issues have been moved to a separate proposal: P1735 Visibility Updates -- StevenDovich - 2014-03-20

Review

Review copy of Encryption is here Please login to get to the review page. There was a presentation(pptx) that overviewed what is in P1735 draft 3 and d3 addendum. It is attached to this page.

Review of 1076-2008 VS P1735

Review by PabloBlecua

P1735_d3_2013 Page 9 Line 52: "clarifies the rsa algorithm conventions" to IETF RFC 3447 whereas in the 1076-2008 24.1.3.2 only "rsa" is stated (IETF RFC 2417 [B21]).

P1735_d3_2013 Page 10 Line 10: key_public_key pragma in 1076-2008 is missing. See also P1735_d3_2013 6.4.2 and 6.5.2

P1735_d3_2013 Page 12 Line 50: Recommends to deprecate the "license" pragma in 1076-2008 and implement proposal from IEEE P1735 (see Clause 7 and Clause 8).

P1735_d3_2013 Page 13 5.3.4 Secure keyring: I could not find in the 1076-2008 any support for "Secure keyrings". After reading further looks like this might be out of the scope of the 1076-2008, but should be double checked.

P1735_d3_2013 Page 22 6.4.1.6 Mapping the pragma information to certificate fields: pragmas from P1735 and 1076-2008 should be harmonized:
P1735 1076-2008
keyowner key_keyowner (24.1.2.9)
keyname key_keyname (24.1.2.10)
keymethod key_method (24.1.2.11)
data_keyowner data_keyowner(24.1.2.13)
data_keyname data_keyname (24.1.2.14)
????? data_method (24.1.2.15)
This might be a comment to how P1735 is written, since they appeart to use different names for the same pragma in different sections (e.g. keyowner vs. key_keyowner).

P1735_d3_2013 Page 28 7.5 Syntax and markup:
common rights block is optional, and consists of language-specific markup and rights <- I am not sure that this exists in the 1076-2008
tool-specific rights block is mandatory, and consists of language-specific markup and rights followed by a digest <- I am not sure that this exists in the 1076-2008
Section 7.5.1 has an example of basic syntax that might need to be added to the 1076-2008

P1735_d3_2013 Page 29 7.5.2 Rights digest: Needs to be checkes if it is compatible with 1076-2008 24.1.3.3. Some pragmans probably need to be added: rights_digest, rights_digest_method
Digest algorithms in the P135 are sha1, md5 and sha256. sha256 is not listed in 1076-2008 24.1.3.3 so probably needs to be added. Some methods in the 1076-2008 are not in the P1735 (md2 and ripemd-160), so remove?

P1735_d3_2013 Page 30 7.5.3 Conditional rights: Missing in 1076-2008. Add rights_block, rights_keyowner, and rights control (e.g. 'protect control right = condition ? true-value:false-value)

P1735_d3_2013 Page 35 8.4 License specification: 1076-2008 in 24.1.2.24 uses deprecated ones see P1735_d3a_2013 (and comments below).

P1735_d3a_2013 Page 48 9.7.2 Deprecated IP protection pragma: decryp_license from 1076-2008 is deprecated (recommended to remove).

P1735_d3a_2013 Page 51 10.3.2 Viewport pragma: viewport seems to be OK for VHDL (see also P1735 9.3.4). However is recommended to apply it to the "run tool phase" (not clear if this has implications to the 1076-2008).

P1735_d3a_2013 Page 52 10.6.1 Granularity of encryption envelopes: Calls for actions about granularity of encryption in the VHDL standard.

I have read all of the above review comments and agree with them. I note that there are many new things in P1735 that do not appear in 1076-2008 and that is appropriate. They will have to be added or referenced, as appropriate. This work can be properly done after 1735 is balloted. -- JohnShields - 2013-04-12

Proposal

See attached Word file (1076-edits-for-1735.docx) for LCS changes.

Questions

General Comments

Note that significant requirements are adopted from IEEE 1735-2014 by reference. It has been the intention of DASC to consolidate much of the IP protection details into the 1735 standard and enable the specific language standards to reference that common specification where appropriate. The changes in this LCS leverage the common specifications from 1735-2014 to augment the specific details in 1076 where 1735 has not yet offered a reference specification.

Supporters

Add your signature here to indicate your support for the proposal DanielKho