IEEE P1735 Draft Development Committee Meeting of June 20, 2014

Meeting Info

Conference Information

Participants

• Attending
  • Dave Graubart, Synopsys DR (Chair)
  • Joe Daniels, P1735 Technical Editor
  • Rod Price, Synopsys DRA
  • Ray Martin, Xilinx DR
  • Satyam Jani, Aldec DR
  • Steven Dovich, P1076 liaison
  • Ruchi Tyagi, Cadence DRA
• Not Attending
  • Dave Clemans, Synopsys DRA
  • John Shields, Mentor DR
  • Adam Sherer, Cadence DR
  • Gael Paul, Accellera DR
  • Michael Smith, Synopsys DRA
  • Jeff Fox, Altera DR
  • Luis Humberto, Jasper DRA
  • Sourabh Tandon, Synopsys
  • Jonathan Goldberg, IEEE Professional Services
  • Joe Hupcey, Jasper DR
  • Sridhar Gangadharan, Atrenta DR
  • Nitin Khurana, Cadence DR
  • Krista Gluchoski, IEEE Professional Services
  • Dmitry Melnick, Aldec DRA
  • Stan Krolikoski, Cadence (DASC Chair)
  • Parminder Gill, Synopsys DRA

Agenda

1. Schedule
2. Reviewer comments
3. Other Business

Minutes

Schedule

Technical Editor comments:

Updates sent today on Clause 1 to incorporate feedback from Adam and John. Also incorporated non-controversal feedback into other clauses - not circulated yet. About a dozen comments from John and one from Ray still open.

Steve comments:

8.7 - Wrong keywords.

Steve will post comments this afternoon including above, typographical recommendations, use of V1/V2 and version1/version 2.

Mentor comments:

98 of them. All but 13 addressed by Joe, the ones marked in red (update not circulatecd yet). Highlighted by John:

1.2 – we make a statement about what this standard specifies that is false.

Ruchi/Steve,

This is the first draft with your new rewrite. It still has the basic problem I have raised in the past about self-signed certificates and validation of identity. I hope we can fix it.

Clause 6.2.4 is flawed. It suggests that self-signed certificates are valuable for trusting identity. That is false. It notes web of trust and suggest self-signed certs are used with web of trust. It fails to clarify that web of trust based on signing depends on other signatures besides the self signature. Without those other signatures, there is no trust established from the provenance of the cert. At that point, it is no different than an unsigned cert or a pragma based public key.

6.4 intro paragraph overstates things. We only require pragma exchange format for [V1] and we have added certificate exchange format for [V2].

6.4.2.3 discusses validity and overreaches, IMHO. There is discussion in Annex C on this topic.

Dave,

The tool block is defined to contain the key block in clause 7. This is version 2 only and different from V1 structure. That is fine in and of itself. I think we might need to take into account things that are triggered at the presence of the key block in V1. We recognize the digital envelope use case when a key block is detected. We clarify SV semantics of naming keys and handling pragma values based on the key block in 5.3.3. We should make sure that the tool block embedded key block has the same properties or clarify the differences. I don’t have a prescription for what to change.

In 7.4.5, I like the addition of short-circuit evaluation. I have to point out that it does not apply to the example in 7.4.6 across separate rights pragmas for the same right ; each is evaluated. This is emphasized in 7.4.7. Should we point it out? It can contribute to unintended, multiple license checkouts.

7.5 Moving rights from one IP block to another IP block

I am wondering what triggers a new session key for compliance to this anti-tamper rule? A session key could be construed to be once for each execution of an encryption tool, once for each encryption envelope, once for each set of common block and tool-specific rights blocks in the encryption input stream, etc. It was a non-issue for V1. Frankly, I am confused and would like to talk about it next meeting.

8.5.5 license public key should shares namespace with all other public keys in encryption envelope. I think we should do that by reference and I noted where this is an issue in a couple of spots.

Xilinx comments:

14 of them

Cadence comments:

From Adam: Page 6 (of the pdf) - Please add Ruchi to the Participants list

Page 17 Clause 5.4.1.1 – Will the 1735 committee manage the public keys? If we are not taking on the work, then I don’t believe we can set the requirement here so strongly. At best I would say “… Public key management strategies can be defined …”.

Page 86 Clause B.2.1 — Conformance “recommendations”. “Requirements" suggests a body that will check compliance.

More from Ruchi

Synopsys comments:

3 of them - all simple

Other Business

Next Meeting

WG meeting 6/23.

-- DaveGraubart - 2014-06-20