Subject: Re: Implementation doc.

From: [email-masked]
Date: Wed, 05 Jul 2000 01:21:44 +0900

sorry for the late response.

From: Erron Criddle <[email-masked]>
Subject: Implementation doc.
Date: Fri, 30 Jun 2000 10:26:19 +0800
Message-ID: <[email-masked]>

> Although implementation testing is very important and would require 2440bis 
> to remain reasonably static for the that to happen, it may be possible to 
> also implement a document in parallel that accompanies 2440 and would be 
> basically targeted at the implementor. This doc could provide 
> implementation guidelines in a "summarised" fashion and would refer to 2440 
> for further understanding.
>
> Basically it would be targeted at implementors that are starting
> from scratch.

i am not so sure of what form the output of such a process should take
-- but how about an "annotated rfc 2440" for starters?  we can use
whatever the latest document (bis or rfc) and provide annotations off
of that for clarifying matters.  perhaps some of the annotations can
be merged in a future rfc if people think there are relevant points
made.

> One possible way to move ahead with this document is to make an FTP site 
> available so that anybody could upload their own "summaries" or 
> implementation notes. From this, we can then consolidate the information 
> and create another doc that is a basic guideline for implementing OpenPGP.

i have no problem w/ the mechanism, but the "consolidator" of these
notes may have to be in a position where looking at various
implementation notes does not cause any legal difficulties (cf. the
discussion of being able to claim that one truly created an
independent implementation) -- unless some precautions are taken
w.r.t.  the content of what is uploaded.

---

From: Jon Callas <[email-masked]>
Date: Wed, 5 Jul 2000 00:21:38 -0700

One of the things to remember about 2440 -- and stated in the document
abstract -- is that it isn't a how-to guide for writing an application.
It's a description of how the data is laid out, and (more or less) what it
means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide."

Lots of things are assumed in the document. For example, it's assumed you
know what a cipher is. Many of the references to ciphers are pretty terse,
and I know I wouldn't want to implement from it and it alone. Just last
week, for example, someone pointed out to me that the reference for
Triple-DES was dangling. We all looked around for a good reference to 3DES,
and didn't come up with one! I was sure there was some RFC for it, myself,
and there isn't. This is amusing, since 3DES is the cross-group defacto
meta-standard algorithm in the IETF, and yet we don't have a good place to
say, "Hey, here's how 3DES is done." I changed the 2440bis reference to
point to Schneier, which is better than nothing, but still not great. As we
find those things, we'll shoot them.

Furthermore, there are things that we have agreed *not* to discuss here. A
close reading of 2440 will display references to key servers, trust, and
other things that are beyond its scope. Trust, in particular, is something
that the working group agreed not to put into 2440. At that time, we agreed
to let people write informational RFCs on various trust models. If someone
wants to write an informational RFC, that's a good one.

We've also discussed having implementation guides. That is also something
that would be great to do. But I don't think you should do an annotated
2440 or a re-organized one. We want to get to Standard as quickly as
possible, and there's already been a lot of work getting everyone to agree
that what we have is reasonable, if not perfect.

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Wed, 05 Jul 2000 10:13:31 +0100

Jon Callas wrote:
> This is amusing, since 3DES is the cross-group defacto

If you are going to point at books, you should point at Menezes et al.,
too.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: [email-masked]
Date: Thu, 06 Jul 2000 15:11:23 +0900

thanks for the response.  sorry for taking so long to reply.

From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP should be called ClosedPGP
Date: Wed, 5 Jul 2000 00:21:38 -0700
Message-ID: <p0431010eb5816651b39b@[172.20.1.38]>

> means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide."

sure.  i didn't miss out on that point.

the kinds of changes i had in mind have more to do w/ the particular
explanations, wording, order of introducing terms, etc.  i found parts
of the document difficult to understand and could be made easier to
understand for others who are still struggling w/ the document and for
future readers.  i have pointed out some of these things that occurred
to me already, but would it help to mention them again?  some of the
points have gone unaddressed, so i can only guess as to whether the
points are irrelevant, ignored, forgotten, etc.

as a side note, on other pgp-related mailing lists, i've seen people
ask questions about pgp and they are then referred to rfc 2440.  i
imagine it could be rather tough for many of these folks to understand
the rfc (it was for me, at least) -- perhaps some other document
should exist for such situations.

> and I know I wouldn't want to implement from it and it alone. 

that's what i found when i first went through it.  after sitting down
w/ schneier's book though, i was able to make a lot more sense of the
rfc, but even w/ improved understanding, i found sections hard to
understand more because of issues such as wording.

> Just last week, for example, someone pointed out to me that the
> reference for Triple-DES was dangling. We all looked around for a
> good reference to 3DES, and didn't come up with one! I was sure
> there was some RFC for it, myself, and there isn't. This is amusing,
> since 3DES is the cross-group defacto meta-standard algorithm in the
> IETF, and yet we don't have a good place to say, "Hey, here's how
> 3DES is done."

perhaps it's time for an informational rfc for triple des then.  but
may be that's an issue that is more general than for just this working
group...

> I changed the 2440bis reference to point to Schneier, which is
> better than nothing, but still not great. As we find those things,
> we'll shoot them.

out of curiosity, if schneier's book were freely available, then would
that still be a problem?

> other things that are beyond its scope. 

it might be helpful to have a list of what is and isn't in scope in
one place (say in the rfc or on among the working group web pages) --
this might make it clearer for those who weren't around for the
discussions.  i assume that newcomers are not unwelcome.

> that would be great to do. 

i think that would be interesting and worthwhile, but i'm not
primarily concerned w/ an implementation guide at this point.

> But I don't think you should do an annotated 2440 or a re-organized
> one.

i hear you, but i guess i don't see why an annotated version would be
a bad idea.  what kind of downside is there in producing such a thing?

> We want to get to Standard as quickly as possible, and there's
> already been a lot of work getting everyone to agree that what we
> have is reasonable, if not perfect.

what concerns me is that the standard that we get may be harder to
understand than necessary (i think it already is).  as has been
pointed out on numerous occasions already, the format is already
fairly complex (compared to what might be produced if one were to
start from scratch -- i am not suggesting that compatibility issues be
ignored, just clarifying my statement).

i would think that particularly in an area that is so focused on
security that one would want the format to be as simple as possible
and the descriptions to be as clear as possible to prevent
misunderstandings that might lead to misuse or misimplementation and
consequently to security problems.  my impression is that this does
not appear to be a high priority.  am i mistaken?

---

From: "L. Sassaman" <[email-masked]>
Date: Mon, 10 Jul 2000 14:52:38 -0700 (PDT)

> find those things, we'll shoot them.

Use X9.52.

X9.52 is the ANSI standard for 3DES. Menezes et al. references it when
discussing 3DES, and I believe Schneier does as well.

- --Len.

__

L. Sassaman

System Administrator                |  
Technology Consultant               |  "Credo quia absurdum."
icq.. 10735603                      |  
pgp.. finger://ns.quickie.net/rabbi |          --Tertullian