Date: Tue Feb 01 2005 - 19:44:30 PST
I write these small comments from home and rather quickly, without deep thought:
> 4.1) 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
> 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?
> -> Duplicate of 4.d from last meeting
I think the questions here may widen the scope of the issue.
> 4.4) 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
> 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?
Was this resolved? I don't say it wasn't, I haven't time to check now.
> 4.5) 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?
> -> These pragma expressions record the symmetric algorithm key
> used during encryption. Does this need further explanation in
> the text?
I have not read the text in a systematic way. 'symmetric' means the same
key is used for both encryption and decryption? Where does the text say that?
Yes, if so, a reminder should be stated here. I'll add a few more words on this
> 4.6) Need to clarify allowing white space in pragma expressions.
> -> Grammar currently permits white-space. This issue was fixed
> in draft d4, approved in committee and by the WG. Is further
> clarification needed?
True, the BNF implies it. But the text should state it explicitly as well.
-- 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
This archive was generated by hypermail 2.1.4
: Tue Feb 01 2005 - 19:27:00 PST
sponsored by Boyd Technology, Inc.