Hi,
I can't make the SV-Champions or P1800 meetings today.
In fact, in a short time, I'll be offline until Saturday night.
But it's important to give you my feedback today:
On Thu, 3 Feb 2005, Neil Korpusik wrote:
> Hi Steve,
>
> Thank you for the update.
>
> Either I or Tom should be able to create Mantis entries for these
> 18 issues.
>
> When is your next scheduled meeting? If I understand your
> naming convention you met yesterday and will therefore meet
> again on the 16th of February.
>
> From the attached text file I see the following:
>
> 7 open
> 6 closed
> 3 action
> 1 future
> 1 duplicate
> --------------
> 18 Total
>
> It looks like you are collectively referring to the closed, action,
> future and duplicate as "resolved".
>
> I think it would be good if you were able to attend the meeting tomorrow
> to give status on the encryption clause. I can attempt to do that for you
> if you are unable to attend. It does appear that most of the items are
> minor. I plan to attend (at least most of the meeting).
>
> Erratum 314 (the encryption proposal) was discussed in the 05 Jan, 2005
> P1800 meeting. I have notes from the discussion from that meeting and I
> also see the writeup from the approved minutes. It is my recollection
> that by approving 314 at that time we felt that the proposal was in
> good enough shape to let it go out in the ballot draft and then work
> on any feedback from the ballot draft and the working groups in time
> for the re-circulation draft. My understanding appears to be consistent
> with what you mentioned in your email. Thank you for jogging my
> memory on this.
Any changes that are to go into the ballot version must be approved and
reach me by mid-next-week at the latest.
In general, any changes which are not purely editorial can be made in
recirculation only as a result of ballot comments. Even purely editorial
changes beyond spelling and typos can be a problem.
It's not a good practice to plan in advance to make changes in the recirc
ballot.
>
> I suggest that an updated copy of the whole clause be sent out to
> at least the champions when you get all of the issues closed. That
> way they can have time to review it in detail.
>
> Neil
>
>
>
> Steven J. Dovich wrote:
> > The encryption committee meets on a bi-weekly basis to address
> > issues raised in editing and review. Of the 18 items we have
> > gleaned from the series of e-mails from Shalom we have resolved
> > 11 of these. Shalom is waiting for final text to address 2 of
> > these resolutions, and has sent another issue back for further
> > consideration. There are tentative resolutions for 2 more items
> > which have not yet been approved, and I expect the remaining
> > items to reach resolution at the next meeting.
> >
> > I will note that none of these issues have been filed through
> > Mantis. Rather than continuing the informal tally, I have
> > produced a standing document for Interpretation requests on the
> > Encryption clause. I have attached the initial version for your
> > reference. The status summary is:
> >
> > Interpretation requests for Encryption clause of 1364-200x
> >
> > I001 Closed [was: agenda-20050119 4.a]
> > I002 Closed [was: agenda-20050119 4.b]
> > I003 Closed [was: agenda-20050119 4.c]
> > I004 Action(dovich) [was: agenda-20050119 4.d]
> > I005 Closed [was: agenda-20050119 4.e]
> > I006 Action(mcmaster) [was: agenda-20050119 4.f]
> > I007 Closed [was: agenda-20050119 4.g]
> > I008 Future [was: agenda-20050119 4.h]
> > I009 Action(dovich) [was: agenda-20050119 4.i]
> > I010 Closed [was: agenda-20050119 4.j]
> > I011 Dup(I004) [was: agenda-20050202 4.1]
> > I012 Open [was: agenda-20050202 4.2]
> > I013 Open [was: agenda-20050202 4.3]
> > I014 Open [was: agenda-20050202 4.4]
> > I015 Open [was: agenda-20050202 4.5]
> > I016 Open [was: agenda-20050202 4.6]
> > I017 Open [was: agenda-20050202 4.7]
> > I018 Open
> >
> > I would prefer to move any of these items that Shalom or the
> > Champions find necessary to be ratified into Mantis so that
> > the defined processes can be followed.
> >
> > My perspective on the issues that have been raised is that none
> > of these issues touch the fundamental technical proposal. Most
> > deal with consistency of definition and terminology, or with minor
> > editing errors in the initial committee draft. There are at
> > most a couple of issues where portions of the text could be
> > construed to reach beyond the central intent of the proposal,
> > and we are looking to prune that over-reach in the interest of
> > stabilizing the text for ballot approval.
While these issues may not 'touch the fundamental technical proposal',
any change which affects behavior, no matter how little, is nonetheless
a technical change.
> >
> > While there is the potential for not clearing every issue before
> > the ballot draft deadline, I expect to reach consensus with
> > all comments, pre-ballot and ballot, in time to recirculate. This
> > expectation was clearly stated in the WG meeting where this
> > proposal was approved for inclusion in the draft. And there is
> > nothing in the comments recieved that leads me to believe that
> > we cannot meet that expectation.
> >
> > /sjd
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Interpretation requests for Encryption clause of 1364-200x
> >
> > The request status is one of the following:
> >
> > Open Request recieved, no resolution
> > Action(xxx) Pending action by "xxx" to resolve
> > Dup(Innn) Duplicate of request Innn
> > Resolved Resolved in committee
> > Closed Reflected in draft/WG minutes/etc.
> > Mantis(nnn) Moved to Mantis item nnn
> > Future Deferred until future revision
> >
> >
> > I001 Closed [was: agenda-20050119 4.a]
> >
> > PROBLEM:
> >
> > Reference to trademark "Verilog-XL".
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Replace "existing Verilog-XL" with "historical".
OK, done.
> >
> > I002 Closed [was: agenda-20050119 4.b]
> >
> > PROBLEM:
> >
> > Should identifiers include escaped identifiers.
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Stay with simple identifiers for now. We will defer extension
> > to escaped names for a future standard.
OK, done.
> >
> > I003 Closed [was: agenda-20050119 4.c]
> >
> > PROBLEM:
> >
> > Confusing reference to viewport in Annex example.
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Remove the viewport reference from the example, it is not
> > substantive to to point of the flow example.
OK, done.
> >
> > I004 Action(dovich) [was: agenda-20050119 4.d]
> >
> > PROBLEM:
> >
> > Conflicting statements about application of encryption
> > transformations outside of the encryption envelope (begin/end
> > region).
> >
> > RESOLUTION:
> >
> > Provide an updated example to remove confict with text.
> > Committee to further review pragma expressions text for
> > possible additional cases.
An example is informative, not normative. The normative text was explicitly
state the required behavior. An example is only to clarify.
This is an example of an issue which is technical, because the required
behavior is not specified currently, certainly not clearly and unambiguously.
> >
> > I005 Closed [was: agenda-20050119 4.e]
> >
> > PROBLEM:
> >
> > Conflicting text where 'end' pragma expression is associated
> > with the most recent unclosed 'begin' pragma expression, but
> > 28.3.1.2 says that nesting is illegal.
> >
> > RESOLUTION:
> >
> > Remove "that has not already been closed" from para 3 of 28.0.
OK, done.
> >
> > I006 Action(mcmaster) [was: agenda-20050119 4.f]
> >
> > PROBLEM:
> >
> > Is Encryption optional or not? See text saying "Verilog tools
> > THAT provide encryption services".
> >
> > RESOLUTION:
> >
> > Tools must be able to "ignore" encryption directives if not
> > performing encryption. Encryption support within a tool is
> > not a conformance requirement. Decryption support within a
> > tool is a conformance requirement if the specified encryption
> > algorithm is one of the mandatory set.
An open technical issue of first class importance.
> >
> > I007 Closed [was: agenda-20050119 4.g]
> >
> > PROBLEM:
> >
> > Typo in "`pragma reset protected".
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Replace "protected" with "protect".
OK, done.
> >
> > I008 Future [was: agenda-20050119 4.h]
> >
> > PROBLEM:
> >
> > Do we need line-wrapping text to ease formatting of the
> > example and for user convenience.
> >
> > RESOLUTION:
> >
> > Defer to future revision unless required editorially.
OK.
> >
> > I009 Action(dovich) [was: agenda-20050119 4.i]
> >
> > PROBLEM:
> >
> > Example is missing required "feature" argument.
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Provide updated example which includes the required "feature"
> > argument.
I need this for the ballot version.
> >
> > I010 Closed [was: agenda-20050119 4.j]
> >
> > Problem:
> >
> > Association of comma with optional args in the license pragma
> > expressions is incorrect.
> >
> > RESOLUTION:
> >
> > Editorial change.
> >
> > Use leading comma for each optional arg rather than trailing
> > comma on the preceding arg.
OK, done.
> >
> > I011 Dup(I004) [was: agenda-20050202 4.1]
> >
> > PROBLEM:
> >
> > About transforming protect pragma directives during encryption:
> >
> > The example shows how the directives preceding the encryption
> > envelope (i.e., preceding the begin keyword) are transformed
> > and/or moved.
> >
> > In this example, the directives came immediately before the
> > envelope.
> >
> > What happens if the directives are far away, many lines before
> > the encryption envelope?
> >
> > What happens if they are even in a different file?
> >
> > What happens if the directives are followed by more than one
> > encryption envelope?
> >
> > Are the answers to these in the current text?
> >
> > RESOLUTION:
> >
> > Resolution of I004 will address all of these issues. The I004
> > decision was to clarify through an updated example that no
> > relocation of directives is intended. Thus these issues are
> > now moot.
These questions illustrate the large scope of the issue.
Must be resolved.
> >
> > I012 Open [was: agenda-20050202 4.2]
> >
> > PROBLEM:
> >
> > 28.1.2 (now 28.2.2) says that decryption occurs "in a manner
> > similar to and at a translation phase consistent with that of
> > macro substitution".
> >
> > The phrases "in a manner similar to" and "at a translation
> > phase consistent with" are ambiguous?
> >
> > Is decryption substitution done before, together with, or
> > after macro substitution?
> >
> > Similarly, when is encryption done?
> >
> > RESOLUTION:
> >
> > Decryption is a form of textual substitution just like macro
> > substitution. They should both be handled at the same point in
> > the translation process. Encryption does not involve
> > compilation, as it is to be applied to the source text without
> > macro substitution, conditional compilation, etc.
> >
> > Appropriate text to express this expectation is needed.
Disagree with resolution. Decryption will certainly not be done by same
software routines as macro substitution. Suppose a protected envelope
contains a text macro, you will want the macro to be substituted after
the decryption. The issue is even more problematic in encryption. If code
to be encrypted contains a macro, is the substitution done before or after
macro substitution, for example?
> >
> >
> > I013 Open [was: agenda-20050202 4.3]
> >
> > PROBLEM:
> >
> > "Should" is used a number of times. "Should" means "is
> > recommended that". Please check that that is the intended
> > meaning everywhere it appears.
> >
> > RESOLUTION:
Important. I don't think enough care was taken in this in authoring the text.
> >
> >
> > I014 Open [was: agenda-20050202 4.4]
> >
> > PROBLEM:
> >
> > 28.2 (now 28.3) is "Envelope Directives": This is a term which
> > is not used anywhere else, and is thus ambiguous.
> >
> > Further, the intro to this clause says that pragma expressions
> > PRECEDING begin or begin_protected are called 'envelope
> > keywords' where those after those keywords are 'CONTENT
> > keywords'.
> >
> > A similar question applies to the name of the following
> > subclause which is called 'Envelope encoding keywords': What
> > does it refer to and what not?
> >
> > RESOLUTION:
Related to I004 and I011. Essential for unambiguity.
> >
> >
> > I015 Open [was: agenda-20050202 4.5]
> >
> > PROBLEM:
> >
> > Table 28-1 contains:
> >
> > data_decrypt_key Specifies the data encryption session key
> > digest_decrypt_key Specifies the digest encryption session key
> >
> > From the text in 28.3.14 and 28.3.20, it seems that these are
> > decryption keys, not encryption keys?
> >
> > RESOLUTION:
> >
> > -> These pragma expressions record the symmetric algorithm key
> > used during encryption. Does this need further explanation in
> > the text?
I answered this separately:
The term 'asymmetric encryption algorithm' is used a few times in the main text,
but not defined.
The term 'symmetric' is used a few times in Annex H, but also not defined.
You have to remember that while a tool implementor will probably give this section
to an employee who understands protection schemes,
this is not true of a user. The section has to be written so that a user who is a
designer or verifier can understand it. Most will probably have less
background in encryption/decryption schemes than I do. I have a little because
I had a little interest in it when I was in college.
I looked again at the description of data_decrypt_key. There is nothing there that
implies that the key is symmetric or that it is an encryption key. The entire
description relates to it only as a decryption key. These two keywords are also the
only two keywords which mix the encryption and decryption terminology.
> >
> > I016 Open [was: agenda-20050202 4.6]
> >
> > PROBLEM:
> >
> > Need to clarify allowing white space in pragma expressions.
> >
> > RESOLUTION:
> >
> > -> Grammar currently permits white-space. This issue was fixed
> > in draft d4, approved in committee and by the WG. Is further
> > clarification needed?
Yes, needs to be explicit. Goes into 19.10.
> >
> > I017 Open [was: agenda-20050202 4.7]
> >
> > PROBLEM:
> >
> > Need to review normative reference status:
> >
> > According to http://www.ietf.org/iesg/1rfc_index.txt,
> >
> > IETF RFC 2045 is updated by RFC2184, RFC2231.
> > RFC 2313 is obsoleted by RFC2437.
> >
> > Please advise ASAP, especially about 2313.
> >
> > RESOLUTION:
> >
> > The most recent applicable IETF document is acceptable, and
> > may be substituted editorially. Final approval for replacement
> > is pending review by committee.
I think RFC 2045 is OK. I think the updates don't invalidate the relevant part
of 2045. I think 2313 should be replaced by 2437.
> >
> > I018 Open
> >
> > PROBLEM:
> >
> > Need to review normative reference status:
> >
> > FIPS 180-1 (SHS) has been superceded by FIPS 180-2 (Aug
> > 2002). Please advise.
> >
> > RESOLUTION:
I think 180-2 should be used. It does not change SHA-1, but changes
terminology, a little.
-- 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 Fri Feb 4 02:03:33 2005
This archive was generated by hypermail 2.1.8 : Fri Feb 04 2005 - 02:03:37 PST