Re: Diffs for next draft

[Jon Callas <[e-mail]>]

Late last night, I replied to Werner, not to the list. Here's my reply to
him, and his reply to me (with permission).

	Jon

To: Werner Koch <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft

In our last episode ("Re: Diffs for next draft", shown on 8/23/01), Werner
Koch said:

>On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:
>
>> Here's everything I have. If there's something you want me to do and I've
>> been obtuse, let me know again, and it'll get in. I'm planning on
>
>Did someone else also checked that the OIDs for SHA-xxx are correct?
>

I haven't, myself. I'll put that on my list.

>I am a little bit curious, can you give a rational why the feature
>flags are not bit encoded?
>

No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
vector. Does anyone else have an opinion.

>What about the Klima/Rosa attack?  If this draft is going to be the
>next RFC we should do something about it.  IIRC, we had not much
>discussion about it. The obvious fix would be use a hash instead of
>the simple checksum.  The problem is how to indicate the use of this
>new format.
>
>The correct solution would be to introduce a version 5 of the secret
>key packet - this is a major change as we may also want to also
>introduce a v5 public key packet for symmetry reasons.  I guess this
>will break a lot of code.
>
>The hackish solution is to define a new S2K type identical to type 3
>(iterated and salted) which would then trigger the use of the new
>SHA-1 checksum.  It should be made clear that this S2K type is only to
>be used for the protection of the secret key and not for conventional
>encryption.
>
>I don't like any of these solutions but the latter one is easier to
>implement. Any other ideas?

Let's put this on the list of things to do after this draft for the next one.

John wants to push to a new RFC. Here are three open issues.

	Jon

To: Jon Callas <[e-mail]>
Subject: Re: Diffs for next draft
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus