Fwd: OpenPGP WG meeting minutes

Robert Guerra az096 at freenet.toronto.on.ca
Mon Jan 19 19:15:21 CET 1998

--- begin forwarded text

X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date:	Mon, 19 Jan 1998 16:03:38 -0500
To:	minutes at ietf.org, OpenPGP mailing list <ietf-open-pgp at imc.org>
From:	"John  W. Noerenberg" <jwn2 at qualcomm.com>
Subject: OpenPGP WG meeting minutes
Cc:	Tony Mione <mione at virtuoso.rutgers.edu>
X-nder: owner-ietf-open-pgp at imc.org
Precedence: bulk

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

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
		o Develop a cryptographic exchange protocol based on PGP
		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

	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
	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. 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
		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
		John Norenberg: Yes, we have to be careful.  But if we stick to
		defining how to represent keys, and leave the protocols for
		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
	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
	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
				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.
		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
			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
			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
			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
			to the spec.
		Jon Callas : This is already done. 11 things are reserved for
			private algorithms.

		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
	New Draft will be in:

	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
	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-haval (15 variants)
	Parallel signatures are popular
		RFC1847 based parallel signatures on the same data have been
	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:

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.com
  -- John Irving, A Prayer for Owen Meany, 1989

--- end forwarded text

Robert Guerra - PGP public key available on PGP key servers
Email-> mailto:az096 at freenet.toronto.on.ca
Home Page-> http://www.geocities.com/CapitolHill/3378

More information about the Gnupg-devel mailing list