ietf-openpgp
[Top] [All Lists]

OpenPGP WG meeting minutes

1998-01-19 14:13:04
Here are the long delayed minutes from the IETF meeting in December.  Tony
Mione recorded them, and I've annotated them slightly.

40th IETF, Washington, DC
OpenPGP Working Group Meeting Minutes
8-Dec-1997

Antonino N. Mione

John Norenberg made openning comments and reviewed the agenda
for the meeting.

OpenPGP Meeting Agenda

        WG Goals (John Norenberg)
        Phil Zimmerman (Comments)
        Draft : PGP Message formats (Jon Callas)
        2015 OP/MIME
        Trust model documents (John Norenberg)
        Additional topics or other business?


WG Goals (John Norenberg)
        John read the Working Group Charter in order to review the
                goals of the group.

                John's comments: The goal of the OpenPGP group is to do two
things.
                o Develop a cryptographic exchange protocol based on PGP
packets.
                o Develop a protocol based on RFC 1873, RFC 2015 and PGP to
                  encrypt and sign email.


Phil Zimmerman (Comments)
        Phil Zimmerman was asked to make comments on PGP and the
                IETF working group.

        Phil's comments mainly revolved around his original design
                goals. He has resisted throwing in just "any"
                proposed block cipher. He is also trying to preserve
                the "Grass roots" architecture of the original PGP
                implementation.

        Question from WG attendee: Has X.509 compatibility been considered?
        Phil: I would like to avoid it. It is bloated & expensive to
                implement. However, we would like to peacefully coexist with
                this technology and provide users an upgrade path from X.509
                to OpenPGP.

        Question from WG attendee: Did you mean this for the OpenPGP
                standard or just for PGP Inc.?
        Phil: That is up to this Working group

        Question from WG attendee: Are you also designing a PKI and SPKI?
        John N.: We are dnt defining an infrastructure. Just how keys work.
                There will have to be continual heavy pressure from
                outside the working group in order for us to take that on.

        John N(Additional comments): A 'standard' must be well defined
                and widely deployed in order to be useful. Our goal
                is to have a standard for cryptographic message exchange.

Draft : PGP Message formats (Jon Callas)
        Jon discussed the most recent decisions on various open issues
                in the PGP Message formats draft
                (drafts-ietf-openpgp-formats-00.txt). There was some discussion
                on certain points. Some decisions by Jon, et al were reversed
                or modified during the discussion.

        2.4 Armor - This needs to be moved to a separate chapter.
                Chapter 2 will say that implementations SHOULD support ARMOR.
        Armor headers - We need to have a table of these. We also need to
                flesh out generation of the message ids for multi-part
messages.
        2.6 Cleartext signatures - We are removing this
        x.x Counted strings - This will be removed. The type is not used
                except for one or two places. We will define it in those places
                and declare it as a simple type.
        2.5.3.3 Iterated/Salted String-to-key - This is long, hairy and
                complicated to implement. We have considered removing it.
                The rationale for its use is that:
                        1-Salt perturbs encryption of strings (same string
                                encrypts to different values each time it
                                is used)
                        2-Iteration adds compute time for the craker program
                                running a dictionary attack.
                        We've seen 3 options mentioned
                                1) Remove it
                                2) Change 8-bit float to 32 bit int
                                3) Change it to a MAY
                        Request for comments from WG

                Comments from WG member: Options add complexity but is useful
                        and important. The member would not have a problem
                        with it if the float was changed to a 32-bit
integer (2).
        4.2 Encrypted Session Key - Will be changing the name of this
                to Public Encrypted Session Key to balance naming with
                Conventionally Encrypted Session Key.
        5.3 Signatures
                These will be put in a table and marked as required or optional
                as per comments on the mailing list.
                ISSUER ID subpacket - This will be added to hashed subpackets
                ARR subpacket - This will be defined as optional.
                        The draft will say explicitly that the implementation
                        can do anything it wants with this. It does not
                        have to use it.
                Comments from WG attendee: Agrees with consensus.
                        However, would like words to tell implementors what to
                        do if they do not want to handle it.
                Jon Callas response: Sounds good.
        Critical flag: This section is confusing. Will rewrite to say that
                        if the critical subpacket is not understood by the
                        implementation, the signature must be ignored.
                Comment from WG attendee: Criticality must be MUST. This means
                        if the implementation does not understand the critical
                        subpacket type, it must consider the signature
                        invalid.
                Phil: Disagrees. The signature is still valid and should be
                        considered such. However, use of any semantic
meaning of
                        the signature is lost.
        Preferred key server: Good to have a place to get most recent key.
                Comments from WG attendee: This is starting us down a slippery
                        slope.
                John Norenberg: Yes, we have to be careful.  But if we stick to
                defining how to represent keys, and leave the protocols for
infrastructure
                to the infrastrucute folks, we'll be ok.
                Phil: This is good but we need more experience with protocols
                        i.e. an implementation that does this.

        Regular expressions: We need a syntax for regular expressions sub
                packet. Requested       pointers to a description of a reg exp
                library to which the draft can refer.
        Negative preferences? (Editor's question) : Did not recieve comments
                saying this was needed. As a result, we will not proceed with
                this.
        UserId revocation subpackets: These will be deferred to v2.
        Other subpacket types (Editor's notes) : Jon had noted some packet
                types that were described (or reserved) in an earlier PGP
                implementation. These were never actually implemented. The
                question was, should we do any of them. Since nobody responded
                that they could not live without these features, they will be
                deferred.
        5.2.2. Signature types
                Identifity : Generic,Personal,Casual,Positive
                        Other than Generic, no implementation has generated
                                or handled these. As a result there is no
history
                                or experience on what the symantics should be.
                                Personal, Casual, and Positive will be dropped
                                from the document.
                Timestamp signatures
                        We shouldn't be taking this on. This is another
                        Slippery Slope. We will, however, note that they exist.
                Signatures that bind keys with subkeys
                        We have not received a good definition of this.
                        If we don't get a solid definition, we will leave
                        this out.
        Secret keys
                Encryption is done in PGP's variant of CFB. (Other comments
                        not recorded).
        Marker packet
                We will change text so that an implementation can put anything
                it wants into this packet. We will also suggest it
                should contain the impelmentor's name.
        Trust packets
                These will explicitly mark them as implementation-defined.

                Comments from Jeff Shiller(back to marker packet) :
                        Can't this be used to leak out data (like the clear
                        text message xor'ed with something)? Why have this
                        at all. It is a security risk.
                Discussion followed.
                Jon Callas: We will state that it MUST be a constant to
                        avoid it being exploited to subvert security.

        Non-text UserIds : These will be deferred. They are not yet defined
                well enough.
                Comments from Phil: These are going to be important.
                        We need this in the spec now.
                Discussion followed concerning formatting problems, etc.
                Jon Callas (to Phil): Send a specification to the openpgp list.
        SDSI names : These will be deferred.
                Jon Callas : These are a good thing but we do not have
                enough time.
                Additional comments from Jon: This draft is supposed to go
                        to last call sometime in March 98. Ideally, we will
                        be AHEAD of that schedule. Jon is hoping to have a new
                        draft up shortly, handle additional comments over then
                        next month or so (through January) and go to last call
                        in February of 98.
        Comment packets : An implementation MAY display a comment but MUST
                NOT interpret contents.
                Jeff Shiller: You may want to reconsider using UTF-8 for
                        textbased userid's.
                Jon Callas: This has already been specified in the draft (at
                        least, he is pretty sure of this.)
                Chris : Recommends that comments be removed altogether.
                Jeff Shiller: agrees with this.
                Jon Callas: Fine. We will remove them.
        5.n:  Interoperability packets:
                These are desireable, but deferred. The existing definitions
                are insufficient.
        Subkeys (Comments unrecorded)
        7.2 BNF : We need additional BNF for how signatures are formed.
                Comments from WG attendee: Please include at least one example.
                Seconded...
                Jon Callas: Noted...
        Security considerations:
                We will be adding description of stealth-mode and
                packet analysis avoidance.
        Miscellaneous: (Comments not recorded)

                Comments on alogrithm lists from Phil: We have multiple
                        algoritms to ensure that if one breaks, users can
contine
                        operating securly by just changing preferences.
                        We should, however, shoot for minimal # of algoritms.
                        We should not just put in everyone's pet algorithms.
                Comment from WG attendee: Other specs give one MUST and
everything
                        else MAY. Market should drive the algorithm
selection. We should
                        not limit it.
                Phil: Maintained that WE should pick the algorithms.
                        Attitude is: "I know cryptography, you don't."
                Perry Metzger: Pick minimum # and types of algoritms for
                        interoperability. Let market drive rest.
                Chris?: We should provide a 'private algorithm #' with no
content
                        description. This allows others to use OIDs, etc to
                        implement anything they want.
                Ned: Agreed. Also, this is not the time to add tons of
algorithms
                        to the spec.
                Jon Callas : This is already done. 11 things are reserved for
                        private algorithms.

        Algorithms:
                Blowfish
                GOST, needs sboxes specified
                        Jon Callas: I can't specify these.
                AES : We have reserved an id
                Ellyptic Curve, IDEA-EDE - added.
        Speculative (stealth mode) keyIDs - Cut's traffic analysis.
        We need to write rationale sections

2015 OP/MIME
        Draft Status
        Technical Changes


Draft status: 80% complete
        www.imc.org/ietf-pgp-mime/mail-archive/0081.html
        New Draft will be in:
                www.imc.org/ietf-open-pgpg/draft-ietf-opengpg-mime-00.txt

        Draft has been submitted to IETF.

Technical changes:
        OP Msg formats now have details
        New MIME constant types have been defined
                - application/openpgp-encrypted
                - application/openpgp-signature
                Quick vote: Do we want these defined? : 4 against : 10+ for
                                                                2xx
abstentions?
        Content transfer encoding restrictions
                - generate strictly, accept liberally
        OpenPGP encrypted data
                Question : MIME or OP encryption first?
                Decision : MIME cannonicalized first, then encrypted
        OpenPGP signed data
                - protocol = application/openpgp-signature
                        = openpgp-md5
                        openpgp-sha1
                        openpgp-ripemd160
                        openpgp-haval (15 variants)
        Parallel signatures are popular
                RFC1847 based parallel signatures on the same data have been
                defined.
        Distribution of PGP keys
                This text will be moved to PGP certificate document.
        Ned Freed: Ongoing issue with multipart signed messages. The
                issues concern gateways. He encouraged people to read
                and comment on his draft concerning this:
                        drafts-freed-gsec-00.txt.

Trust model documents (John Norenberg)
        There are numerous types of trust models.
        It would probably be good to have a document on this. The
                document would cover:
                        - What trust models are available.
                        - How they work.
                        - How they are implemented in the context of PGP.
        Question for group: Do we need this?
        Paul Hoffman: Agrees. Would be good to have a separate
                document on this.
        John Norenberg : Should we vote here or defer this question
                to the list?
        Rodney: Let's take these questions to the list and decide there.

Any other business?
        Blue sheet...all signed? about 40 not yet on list.

John Norenberg summarized what was covered at the meeting. He then closed
the meeting at 3:10 PM (20 minutes ahead of schedule).

john  w noerenberg, ii
jwn2(_at_)qualcomm(_dot_)com
  ------------------------------------------------------------------
  "YOU THINK THEY GIVE YOU THE SHIVERS NOW," Owen said.
 "JUST WAIT UNTIL HE STARTS MAKING DECISIONS!"
  -- John Irving, A Prayer for Owen Meany, 1989
  ------------------------------------------------------------------



<Prev in Thread] Current Thread [Next in Thread>