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
------------------------------------------------------------------