Re: Clarifications for the ballot draft

From: Shalom Bresticker (Shalom.Bresticker@freescale.com)
Date: Thu Feb 10 2005 - 01:10:19 PST

  • Next message: Steven J. Dovich: "Re: Clarifications for the ballot draft"

    Steve,

    I have implemented the changes as specified (except for minor editing which you
    can see when you review the document).

    Comments:

    I004: You previously sent me a new example, which I implemented. It is OK.
    I006: I implemented the change specified below, but I still feel it isn't clear.
    I012: I implemented the change specified below. It is OK.
    I014: I implemented the change specified below. It is OK.
    I015: I implemented the change specified below. It is OK.

    I still need urgently:

    Final decisions about the reference versions.
    What I have done:
    IETF RFC 2045: left as is.
    IETF RFC 2313: Replaced by RFC 2437.
    FIPS 180-1: Replaced by FIPS 180-2.
    "three-key 3DES": Changed description to "Triple DES", left identifier as is.

    RIPE-MD-160: left as is, but it seems more correct without hyphen before "MD".
    Should it be capitalized? All other identifiers are not.

    Elgamal: It seems to be universally capitalized as in author's name: ElGamal.
    I have changed description to ElGamal, but not touched the identifier. It seems
    most correct to be either "elgamal" or "ElGamal", but not "Elgamal".

    Please contact me first thing in the morning.
    Email is OK.

    Thanks,
    Shalom

    Steven J. Dovich wrote:
    > After a conversation with Shalom, Tom Fitzpatrick, and Neil Korpusik,
    > we identified a set of clarifications that are intended to bettter
    > reflect the intent of the Encryption Committee. Shalom needs these
    > changes by the end of today in order to reflect them into the final
    > draft for ballot circulation. Further issues and changes will need
    > to be applied following ballot resolution, for the recirculation.
    >
    > With the consent of the committee (please object to any portion you
    > wish to discuss in committee before incorporation into the draft),
    > Shalom will update the final ballot draft with the attached changes.
    > Any items that for which an objection is expressed should not be
    > applied to the draft, and we will consider that issue for the
    > recirculation.
    >
    > I appreciate the committee's review on such short notice, and will
    > understand if anyone feels that action should be deferred until
    > the recirculation. However if there is consensus that these
    > changes are non-controversial, the ballot review should go much
    > more smoothly.
    >
    > /sjd
    >
    >
    >
    > ------------------------------------------------------------------------
    >
    > 1.
    >
    > To address the questions raised in I015, add the following text at
    > the end of the 3rd paragraph of 28.2.1 "Encryption":
    >
    > Encryption algorithms that use the same key to encrypt cleartext and
    > decrypt the corresponding ciphetext are said to be symmetric.
    > Algorithms that require a different keys to encrypt and decrypt are said
    > to be asymmetric. This description may be applied to both the algorithm,
    > and to the key.
    >
    > In Table 28-1 (for data_decrypt_key and digest_decrypt_key), replace:
    >
    > encryption session key
    >
    > with:
    >
    > encryption session key
    >
    > 1.
    >
    > To clarify the conformance expectations (see I006), add the
    > following paragraph immediately befor 28.2.1 "Encryption":
    >
    > Tools that process the Verilog HDL shall perform envelope decryption
    > for all decryption envelopes contained in the source text, where the
    > proper key is supplied by the user. Tools that perform envelope
    > encryption shall only be required to process the protect pragma
    > directives, and shall apply no other interpretation to text which is not
    > part of a protect pragma directive.
    >
    > 1. To help resolve questions raised in I014, replace the the
    > sub-clause title:
    >
    > 28.3 Envelope Directives
    >
    > with:
    >
    > 28.3 Envelope Directives protect Pragma Directive
    >
    > and replace sub-clause title:
    >
    > 28.3.1 Envelope encoding keywords
    >
    > with:
    >
    > 28.3.1 Envelope encoding keywords protect Pragma Keywords
    >
    > 1. To partially resolve I012, replace the first paragraph in 28.2.2
    > "Decryption" with:
    >
    > Verilog tools that support decrypting compilation shall transform source
    > text containing decryption envelopes by replacing each decryption
    > envelope with the decrypted source text according to the specified
    > pragma expressions. This substitution shall occur in a manner similar to
    > and at a translation phase consistent with that of macro substitution.
    > Unless otherwise specified, occurrences of the protect pragma directive
    > shall not be included in the decrypted source text which replaces the
    > decryption envelope.
    >
    > Verilog tools that support decrypting compilation shall transform source
    > text containing decryption envelopes by replacing each decryption
    > envelope with the decrypted source text from the data_block, according
    > to the specified pragma expressions. The substituted text may contain
    > usages of text macros, which shall be substituted after replacement of
    > the decryption envelope. The substituted text may also contain
    > decryption envelopes which shall be decrypted and substituted after
    > replacement of their enclosing decryption envelope.
    > 

    -- 
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 : Thu Feb 10 2005 - 00:52:09 PST and
    sponsored by Boyd Technology, Inc.