[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

priority of clarity of specifications (was Re: OpenPGP should be called ClosedPGP)



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

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

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

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.

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

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?

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

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.

> We've also discussed having implementation guides. That is also something
> 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?