Here are the messages recieved as input for the Encryption Review.
Please read them through carefully to determine what changes if any
are being requested. In the Wednesday meeting we will review these
comments and determine the appropriate disposition for each requested
change.
For those who have indicated that they are unable to attend, please
forward comments and recommendations for dispositioning to the
btf-ip@boyd.com reflector.
/sjd
attached mail follows:
Hi, Steven.
I have not looked seriously at the encryption proposal in the past.
Only over the last day or two did I look at it more carefully, though
still only rather quickly, and I have a number of concerns.
First, the proposal to add a `pragma compiler directive to section 19 has
to be able to stand on its own, without any connection to encryption.
Strictly speaking, this is more properly in the scope of the regular BTF,
rather than the BTF-IP.
This concerns me, because although your minutes say that it was shown to
the BTF, there is no record of any serious detailed discussion in the
BTF minutes. Did the BTF get a detailed proposal and discuss it?
I fear this part did not get a thorough review for consistency with
other parts of the Verilog LRM.
Some of my specific concerns:
I refer to the document filed in the SV DB as 314. It is labelled
CDN P1364e/D2.
First, there is no description of the motivation or justification of
`pragma or the envisioned typical use models. That is, if I just read
this, I don't understand why you need `pragma.
Example: You want 'protect'? So define `protect and `endprotect. Why
'`pragma protect'?
Jay Lawrence originally proposed `pragma in BTF 430. I speculate that
it was the source of this part of the proposal. But Jay's discussion
included a description of the need for and use of `pragma which is
missing here but needed. Ditto for why non-recognized pragmas should
be ignored instead of creating warnings or errors.
(It's still not clear to me why 'protect' should be a pragma instead of
a regular compiler directive, though...)
(Also, it is still not clear that unrecognized directives should not
generate at least a warning, which could help spotting mis-spelled
directives.)
The first sentence describes `pragma as 'a structured specification'.
Excuse me, but that is a meaningless buzz-phrase, at least without
a further explanation or at least an example. What makes it different
from other directives?
Speaking of examples, this section definitely needs an example, preferably
more than one.
Regarding the syntax, it is not clear whether or where white space may
or may not appear in the form 'keyword=value' or within constant_expression.
And it is not clear what operands and operators may appear in
constant_expression in this context. I had wanted to propose extensions
to the preprocessing capabilities of Verilog by adding some CPP and Verilog
pre-processor directives like '`if <expression>' and `for, but I got stuck
on this very point, and I saw it was not possible to get to a solid formal
specification within the deadline.
19.10.1 should be titled something like 'reset, resetall' instead of
'Standard Pragmas'. (Aren't you proposing that 'protect' be a standard
pragma as well?)
Examples are badly needed.
The first sentence in 19.10.1 is very confusing, because you have not yet
said that the 'affected pragmas' appear as keywords of the reset pragma.
Moving on to Section 28, the question about where white space may and may
not appear is common to many of the items in this section.
The syntaxes should appear as, instead of 'begin', as '`pragma protect begin'.
28.3.2 Description should be 28.3.2.2.
28.3.9.2 references other standards. They must be properly referenced,
probably in Annex H.
28.3.11.2 and 28.3.21.2 reference a bunch of Encryption and Digest algorithms.
All need to be properly referenced.
By the way, is support of encryption to be mandatory for compliance to
1364-2005? I'm not sure how much support there will be for that among the
balloters.
Annex I mentions Verilog-XL. I'm not sure you can do that, even if the Annex
is only normative.
Annex I refers to 'the following pragmas', whereas in 28, they are called
'pragma_keywords'. The distinction between pragma, pragma name, and pragma
keyword is important.
As you can see, I think this still needs work.
I think there are still too many open issues.
Sorry if I sounded a bit harsh.
Thanks and regards,
Shalom
-- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
attached mail follows:
Hi, Steve.
On Thu, 9 Dec 2004, Steven J. Dovich wrote:
> Shalom,
>
> Thanks for your feedback. It would have been useful to have it
> earlier in the process.
Unfortunately, my time has been too limited to be involved in everything.
And my expertise (and interest, frankly) in encryption is also limited.
Nor have I been able to participate much in the BTF meetings due to the
late hour in my time zone.
> > I have not looked seriously at the encryption proposal in the past.
> > Only over the last day or two did I look at it more carefully, though
> > still only rather quickly, and I have a number of concerns.
> >
> > First, the proposal to add a `pragma compiler directive to section 19 has
> > to be able to stand on its own, without any connection to encryption.
> > Strictly speaking, this is more properly in the scope of the regular BTF,
> > rather than the BTF-IP.
> >
> > This concerns me, because although your minutes say that it was shown to
> > the BTF, there is no record of any serious detailed discussion in the
> > BTF minutes. Did the BTF get a detailed proposal and discuss it?
> > I fear this part did not get a thorough review for consistency with
> > other parts of the Verilog LRM.
>
> While the Encryption committee was a subcommittee of the BTF, I
> attended those meetings to report and request guidance. I specifically
> requested that the BTF handle the pragma definition since that was
> more properly within their domain of expertise. I was given guidance
> and directed to handle the language issues in the Encryption committee.
Still, it is unfortunate that it was ont reviewed by the BTF.
> The resulting proposal for the `pragma directive is responsive to
> the specific comments I recieved in the BTF meeting. It is also
> the result of choices made by the Encryption committee with respect
> to dealing with existing non-standard directives.
>
>
> > Some of my specific concerns:
> >
> > I refer to the document filed in the SV DB as 314. It is labelled
> > CDN P1364e/D2.
> >
> > First, there is no description of the motivation or justification of
> > `pragma or the envisioned typical use models. That is, if I just read
> > this, I don't understand why you need `pragma.
> >
> > Example: You want 'protect'? So define `protect and `endprotect. Why
> > '`pragma protect'?
>
> Because `protect and `endprotect are existing non-standard directives
> that are reasonably widely deployed with differing semantics and
> interpretation. The committee felt it invited less confusion to
> use different directives for this new standard encryption scheme.
>
> Other directive names were discussed, and there was a conscious
> choice to specify a general extension mechanism that would solve
> the problem at hand, and also be useful for future extension by
> implementors and standards committees.
`protect is just an example.
`pragma is a general mechanism. It needs to be justified and the use model
described. Many tools defined their own directives. For example, Verilog-XL
defined `accelerate. You should show why this method of extending
directives is not adequate.
You should also show how the `pragma mechanism could help avoid conflicts
between private extensions. For example, if two different tools will define
"`pragma accelerate", then I still have a problem.
> > Jay Lawrence originally proposed `pragma in BTF 430. I speculate that
> > it was the source of this part of the proposal. But Jay's discussion
> > included a description of the need for and use of `pragma which is
> > missing here but needed. Ditto for why non-recognized pragmas should
> > be ignored instead of creating warnings or errors.
> >
> > (It's still not clear to me why 'protect' should be a pragma instead of
> > a regular compiler directive, though...)
> >
> > (Also, it is still not clear that unrecognized directives should not
> > generate at least a warning, which could help spotting mis-spelled
> > directives.)
This issue still requires a discussion.
> BTF 430 was not the seed, though this idea has been floating around
> in conversations for a while. In comparison with BTF 430, the grammar
> for the directive has been extended to better support the specification of
> pragma names like 'protect'.
>
> > The first sentence describes `pragma as 'a structured specification'.
> > Excuse me, but that is a meaningless buzz-phrase, at least without
> > a further explanation or at least an example. What makes it different
> > from other directives?
> >
> > Speaking of examples, this section definitely needs an example, preferably
> > more than one.
>
> Examples would certainly be in character for this standard. But I
> think that they can't be allowed to imply specification that is not
> actually there in the normative text. If the text is incomplete
> we need to address that. If it is complete but obtuse, then that
> is a different problem that we can word-smith around.
The minute that the actual pragma is not defined by the LRM,
there is no problem in giving an abstract example, even with meaningless
names. It certainly does not imply that the example is normative.
It is like the example of user-defined functions in 10.3.5.
Without an example, it is not clear how to use `pragma.
You could even use 'protect' as an example.
> > Regarding the syntax, it is not clear whether or where white space may
> > or may not appear in the form 'keyword=value' or within constant_expression.
>
> I would agree that this aspect requires some degree of interpretation.
For example, if the argument list is "1 -2", is that one constant_expression
("1-2") or two (1 and -2)?
> > And it is not clear what operands and operators may appear in
> > constant_expression in this context. I had wanted to propose extensions
> > to the preprocessing capabilities of Verilog by adding some CPP and Verilog
> > pre-processor directives like '`if <expression>' and `for, but I got stuck
> > on this very point, and I saw it was not possible to get to a solid formal
> > specification within the deadline.
>
> The choice of constant_expression was intended to be a connection to
> the BNF in Annex A. If there is some subtle reason why that would be
> inappropriate in the directive context, then this issue should be
> revisited.
Are all types of constants allowed? based, sized, etc?
What are the sizing and signing rules?
Are they the same as in Verilog text?
Parameters are presumably not allowed.
What about "constant system functions" (see enhancements BTF-387 and 390)?
> > 19.10.1 should be titled something like 'reset, resetall' instead of
> > 'Standard Pragmas'. (Aren't you proposing that 'protect' be a standard
> > pragma as well?)
>
> No objection. I consider this an editorial perogative, though the
> Working Group seems to want purview over these issues.
>
> > Examples are badly needed.
>
> See answer above.
It took me several reading to understand the intended syntax.
An example is essential.
> > The first sentence in 19.10.1 is very confusing, because you have not yet
> > said that the 'affected pragmas' appear as keywords of the reset pragma.
>
> Is this fixable by re-ordering the sentences in the paragraph or
> is the problem deeper than that?
Probably re-ordering and minor rewording is enough.
> > Moving on to Section 28, the question about where white space may and may
> > not appear is common to many of the items in this section.
>
> See answer above.
>
> > The syntaxes should appear as, instead of 'begin', as '`pragma protect begin'.
>
> They appear in isolation because they describe the requirements on
> the specific pragma keyword that is associated with the 'protect'
> pragma name. With a complete directive, that is by nature an example,
> as the intent is to permit compositing of adjacent protect pragma
> directives. For example:
>
> `pragma protect begin
> `pragma protect author="IEEE"
> `pragma protect data_method=rsa
>
> can be also represented as:
>
> `pragma protect begin author="IEEE" data_method=rsa
>
> Both forms have identical interpretation (clause 28 para 2).
> Since 28.3 describes the pragma keywords for 'protect' it only
> gives the syntax for the pragma keyword being described.
Good point. Such an example would be very helpful.
Note that the paragraph before 28.1 says that expressions preceding
begin 'are designated as envelope keywords', whereas expressions following
begin are 'content keywords'. But then 28.2 is titled 'Envelope directives',
which implies that they have to precede 'begin'.
> > 28.3.2 Description should be 28.3.2.2.
>
> Uncaught typo, thanks for spotting it.
>
> > 28.3.9.2 references other standards. They must be properly referenced,
> > probably in Annex H.
>
> No objection. The normative references are provided.
The IETF references need to be done in the proper format, with the required
information. It should not be the editor's job to obtain this information.
> > 28.3.11.2 and 28.3.21.2 reference a bunch of Encryption and Digest algorithms.
> > All need to be properly referenced.
>
> We spent considerable time trying to find a normative reference
> for the entire list. The fallback of local specification needs
> appropriate normative references to these algorithms.
I don't understand what you mean by this.
Some of these names I know, many I don't (Blowfish and Serpent, for example).
You have to supply references for them.
> > By the way, is support of encryption to be mandatory for compliance to
> > 1364-2005? I'm not sure how much support there will be for that among the
> > balloters.
>
> I think the text implies it is mandatory. I don't think this is a
> show-stopper though. The Encryption committee is not the right
> forum for that decision. That is a policy decision that is ultimately
> in the hands of the ballot group. We took one reasonable approach
> and are prepared to alter the policy if so requested by the Working
> Group or the Ballot Group.
I think it kills the last chance of anyone doing a 'hobbyist' implementation
of the language.
> > Annex I mentions Verilog-XL. I'm not sure you can do that, even if the Annex
> > is only normative.
> >
> > Annex I refers to 'the following pragmas', whereas in 28, they are called
> > 'pragma_keywords'. The distinction between pragma, pragma name, and pragma
> > keyword is important.
>
> Annex I is not at the quality level that I am comfortable with.
> I raised the option of omitting it from the approved proposal. The
> Encryption committee felt that there was critical informative
> content regarding use models that would otherwise be missing and
> voted to include it.
My issues remain.
> > As you can see, I think this still needs work.
> > I think there are still too many open issues.
>
> The degree of open issues and questions is a matter for the Working
> group to establish consensus on. We could continue to polish, but
> this was an item of substantial interest to the Working Group, which
> the Encryption committee has done their best to deliver in the
> time frame requested.
>
> The proposal is substantially improved over the donation. I fully
> expect to deal with additional changes in ballot, because there is
> a related effort in the VHDL committee that we need to coordinate
> with. They started from an equivalent donation and are discussing
> changes. I have provided them with this proposal and requested
> their current document in return. It would not be useful to industry
> if incompatible schemes are standardized.
>
> The Mantis "Encryption" category is where I expect to accumulate and
> address remaining issues and errata. The Encryption committee will
> be working through those issues as they are posted in an effort to
> accumulate corrections and clarifications for the next opportunity
> to amend the draft.
The question is whether to send to ballot something which we know needs
more work.
Thanks,
Shalom
>
> > Sorry if I sounded a bit harsh.
>
> You will have to try a lot harder. I still have a standing death
> threat over a compromise I successfully brokered between three
> working groups in IEEE POSIX effort.
>
>
> I hope my response is helpful in working through the proposal.
>
> /sjd
>
-- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
attached mail follows:
I plan to attend.
Since things are going back to committee, can you recall why the runtime license reverted to just returning an integer?
A corollary question I have is why the success is a 0 and the failure is non-zero.
I remember having discussions about making the licensing more complex, etc., and I'm thinking the conclusion was that if
we wanted something more complex we should just implement it on our own -- i.e., in our own library call, etc., hidden
inside the encrypted code. Is this the underlying assumption here, that nothing prevents us from encrypting our own call
that has more complex return values, etc.?
If this is correct, then I'd propose we get rid of the runtime_license pragma and replace it with an indication about
"user responsibility for runtime licensing". The current proposal isn't really going to be safe. We shouldn't even be
recommending it.
If this is incorrect, then we need to rethink the return parameter, etc., for this pragma. It just doesn't provide
enough safety.
-----Original Message-----
From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On Behalf Of Steven J. Dovich
Sent: Wednesday, December 15, 2004 2:39 PM
To: btf-ip@boyd.com; btf@boyd.com; etf@boyd.com; sv-cc@eda.org; sv-bc@eda.org; sv-ec@eda.org; sv-ac@eda.org;
ieee1800@eda.org
Subject: Review of Encryption proposal scheduled for Wed 12/22 at 1500 UTC
The P1800 Working group has referred the Encryption proposal back to the Committee to review the concerns of various
parties who are now looking at the proposal for the first time.
The Encryption committee will meet to review and address those concerns at our December 22 meeting. The agenda and call
information is attached. Please notify me if you will be attending so that I can make provision for additional call-in
ports if needed.
The proposal under consideration can be found in Mantis item 314 in PDF format. Those with concerns should send them to
me (you may also cc the <btf-ip@boyd.com> reflector) by Monday 12/20 for consideration at the meeting. I will aggregate
all the issues and forward them to all submitters and to the btf-ip reflector.
Reviewers, please be as concrete as possible in describing the nature of the issues you are noting. Use section and
paragraph numbers to pinpoint the areas you are commenting on. That will permit us to sort comments and issues for
effective review in the meeting. Please include some indication of the sort of resolution that will satisfy your
concerns.
/sjd
Agenda for Encryption group meeting - 22-Dec-2004 at 1100 US/Eastern
When: Wednesday, Dec 22, 2004
11:00 am - 12:00 pm US-Eastern (1500 UTC)
Phone Conf: 866-700-8779
210-839-5678 for international access
Passcode: 879814
Leader: Steven J. Dovich <dovich@cadence.com>
1) Approve the agenda
2) Review of patent policy
http://standards.ieee.org/board/pat/pat-slideset.ppt
3) Review of minutes
4) Discussion of reviewer concerns and issues
5) Other business
6) Action Item assignments
7) Adjourn
attached mail follows:
<div class="moz-text-flowed" style="font-family: -moz-fixed">Hi Steven,
Please note the feedback after reviewing the encryption proposal:
1) The proposal is very complex for what it is supposed to define
2) Absence of examples
3) The proposal is weak primarily in the following areas :
-- It leaves the burden of implementing a number of encryption
algorithms to the EDA tool vendor.
-- List of algorithms in Page-16
-- There is a concern that software containing certain encryption
algorithms cannot be shipped to certain nations
-- The licensing mechanism is extremely weak
-- The IP-provider's shared object needs to be loaded for license
check only. This is extremely easy to work-around
-- It does not define how to encrypt/license 'derivative' code, for
example RTL code generated by an assertion-RTL translator
4) The generality and the role of pragma construct in future "compile
directive" type of functionality.
Surrendra
At 05:39 PM 12/15/2004 -0500, you wrote:
>The P1800 Working group has referred the Encryption proposal back to
>the Committee to review the concerns of various parties who are now
>looking at the proposal for the first time.
>
>The Encryption committee will meet to review and address those
>concerns at our December 22 meeting. The agenda and call information
>is attached. Please notify me if you will be attending so that I
>can make provision for additional call-in ports if needed.
>
>The proposal under consideration can be found in Mantis item 314
>in PDF format. Those with concerns should send them to me (you
>may also cc the <btf-ip@boyd.com> reflector) by Monday 12/20
>for consideration at the meeting. I will aggregate all the issues
>and forward them to all submitters and to the btf-ip reflector.
>
>Reviewers, please be as concrete as possible in describing the
>nature of the issues you are noting. Use section and paragraph
>numbers to pinpoint the areas you are commenting on. That will
>permit us to sort comments and issues for effective review in the
>meeting. Please include some indication of the sort of resolution
>that will satisfy your concerns.
>
>
>/sjd
>
>
>
>Agenda for Encryption group meeting - 22-Dec-2004 at 1100 US/Eastern
>
>
>
>When: Wednesday, Dec 22, 2004
> 11:00 am - 12:00 pm US-Eastern (1500 UTC)
>
>Phone Conf: 866-700-8779
> 210-839-5678 for international access
>Passcode: 879814
>Leader: Steven J. Dovich <dovich@cadence.com>
>
>
>1) Approve the agenda
>
>2) Review of patent policy
>
> http://standards.ieee.org/board/pat/pat-slideset.ppt
>
>3) Review of minutes
>
>4) Discussion of reviewer concerns and issues
>
>5) Other business
>
>6) Action Item assignments
>
>7) Adjourn
**********************************************
Surrendra A. Dudani
Synopsys, Inc.
377 Simarano Drive, Suite 300
Marlboro, MA 01752
Tel: 508-263-8072
Fax: 508-263-8123
email: Surrendra.Dudani@synopsys.com
**********************************************
</div>
attached mail follows:
I have not had much time, but I looked at a little more of this and found a
few more unclear points.
The introduction to 28 says that an encryption envelope begins with a
'begin' pragma expression. 28.1 says that encryption transforms encryption
envelopes. So does 28.1.1. But 28.1.1 also says that encryption transforms
encryption envelope pragma expressions. Yet the introduction to 28 calls
pragma expressions which precede 'begin' as 'envelope' keywords, whereas
pragma expressions which follow 'begin' are called 'content' keywords.
There seems to be an inconsistent use of 'envelope' as an adjective.
(In the 3rd paragraph of 28, line 4, "occurs a the point" should be
"occurs at the point".)
28.1.1 refers to a 'session' key. What is a session?
28.1.1 and 28.1.2 refer to 'tools that provide encryption services' and
'tools that support decrypting compilation'. This sounds like such
support is optional, not required. Is that the intent?
The table in 28.2 lists 'data_decrypt_key' as 'specifies the session key
for data encryption'. That formulation is very confusing, using both terms,
decrypion and encryption. Same for digest_decrypt_key. 28.3.14.2 describes
it as the 'encoded value of the key that will decrypt the data_block.'
This describes it as a decryption key, not an encryption key.
Finally, as I stated previously, I think it is not good that an entire
18-page section does nothave a single example in it.
Regards,
Shalom
-- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential ProprietaryReceived on Mon Dec 20 20:52:19 2004
This archive was generated by hypermail 2.1.8 : Mon Dec 20 2004 - 20:52:23 PST