Subject: More on the closing of the OpenPGP WG

From: Derek Atkins <[email-masked]>
Date: Mon, 10 Mar 2008 14:21:46 -0400

Hi,

I sat down with Sam, Tim, and Pasi yesterday to talk about this.
Basically, it's still possible to have a "standards track" document
without a working group.  They still need to go through an IETF
Last Call but the AD can sponsor the draft (instead of having a
WG Group).  So long as the drafts are not very contentious (which
MOST of our proposed work is), we can just continue to drafts
as individual submissions and an AD (Tim?) could sponsor that
once we have rough consensus on this list.

This list can (and will) remain alive.  So we can continue to discuss
Camillia, ECC, and Whirlpool on this list and then get documents
passed through the IETF/IESG Last Call process.

If it turns out that we do have some contentious work (e.g. the
HTTP-PGP work), then we might need something more.  Note that
we do not necessarily need a BOF in order to get a new working
group.  It's not a requirement.  So, if we DO have work that really
does require a WG, then it COULD be reformed.

So, a summary:

1) This List will remain open and as active as we make it.
2) We can continue to do OpenPGP work in the IETF
3) We can continue to get I-Ds and Standards-track RFCs published
4) We can get a new group constituted if we need to, but Tim assures
   me that based on the proposed work we probably don't need to.

Please let me know how you feel about this.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Mar 2008 21:44:15 +0100

> Please let me know how you feel about this.

I'm curious whether we can get the OpenPGP header document published
without a WG or not.  A few MUAs parses the header (Gnus, enigmail,
squirrelmail, if I understand correctly).

/Simon

---

From: Ian G <[email-masked]>
Date: Mon, 10 Mar 2008 22:28:55 +0100

> once we have rough consensus on this list.

That sounds fine to me.  Is the only reason for a WG that we 
have to have an open forum if there is contention?

> Please let me know how you feel about this.

I vote yes, let's go informal on this list.

iang

---

From: Derek Atkins <[email-masked]>
Date: Tue, 11 Mar 2008 10:01:47 -0400

> squirrelmail, if I understand correctly).

I don't see why not.  I don't think it would be very contentious.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 11 Mar 2008 10:04:39 -0400

Ian G <[email-masked]> writes:

> That sounds fine to me.  Is the only reason for a WG that we have to
> have an open forum if there is contention?

I don't think that's the only reason..  It's mainly provides a means
to gauge consensus before it gets to the whole IETF, and provides a
means to streamline the process so it's not all on the AD's shoulders.

-derek

---

From: David Shaw <[email-masked]>
Date: Tue, 11 Mar 2008 14:02:00 -0400

> once we have rough consensus on this list.

[..]

> Please let me know how you feel about this.

I think that is just fine, and thanks for working this out.

I have a minor process question though: I've done a couple of Camellia
drafts as "draft-ietf-openpgp-camellia".  Do I need to convert that to
"draft-shaw-openpgp-camellia" (i.e. an individual submission) and
re-submit?

David

---

From: Derek Atkins <[email-masked]>
Date: Wed, 12 Mar 2008 13:29:49 -0400

David Shaw <[email-masked]> writes:

[snip]
> "draft-shaw-openpgp-camellia" (i.e. an individual submission) and

No, it can stay as 'draft-ietf-openpgp-'.  No need to rename and
resubmit as an individual.

-derek

---

From: David Shaw <[email-masked]>
Date: Thu, 13 Mar 2008 11:23:41 -0400

> resubmit as an individual.

Great, thanks.

I think we're ready for the final push on Camellia.  All of the
suggested changes have been incorporated, and if folks could give it a
final read, I'd appreciate it:
  http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt

I would particulary appreciate comments on the choice of 128 and
256-bit keys (that is, lacking 192).  I tend to agree with Jon that
192 is neither here nor there, but I'm also a major fan of
consistency.  If we're going to include 192 for the ECC work, then
it's odd to leave it out here.

David

---

From: "David Crick" <[email-masked]>
Date: Thu, 13 Mar 2008 19:56:15 +0000

>   http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt

I had a look over this (-01) when you first posted it, and couldn't
find fault.

>  it's odd to leave it out here.

I suggested in my comments on the most recent (-07) ECC draft
that we should explicitly deprecate AES-192 in ECC; I'd be tempted
to say the same about Camellia-192, but I equally see the point of
having an alternative to *each* of the three AES cipher lengths.

So I think I'm abstaining on Camellia-192 - I'm not going to speicifically
ask/vote for it to be included, but at the same time I won't protest if
others wanted it in.

---

From: Ian G <[email-masked]>
Date: Fri, 14 Mar 2008 15:04:13 +0100

>   http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt

I just skimmed it.

I am confused about one language difference between Camellia 
doc and ECC doc.  In Camellia, there are MAYs.  In ECC, 
there are MUSTs, SHOULDs, MAYs.

The way I interpret it, Camellia is *incorporated within* 
RFC4880 and adds MAY algorithms.  But ECC is *appended as a 
MAY* ... the entire appendix is a MAY, within which there 
are choices guided by RFC2119.

Maybe I'm wrong about my interpretation, and if so, stop 
reading here.

It would be nice if we could agree on a more unified way of 
treating this.

Personally I prefer the ECC style, as it allows for some 
richness within.  However, there should be a line at the top 
of the document describing the relationship to the mother 
document.  Something like:

    This document is an optional appendix to [RFC4880] which
    makes the entire Camellia addition a MAY.  If you do add
    Camellia then you must follow the recommendations below
    using the normal language of [RFC2119].

OK, that's really crappy language but I hope you get the idea.

> it's odd to leave it out here.

I agree with dropping 192.  I see no consistency argument 
here, the notion of having consistent sets across algorithms 
seems esthetic only.  Real users won't understand these 
notions of esthetics.

The sensible reason for including 192 in ECC was outlined by 
Jon.  There are checkboxes that big corps and big TLAs 
follow when buying this stuff.  They do not understand what 
they are doing, they simply tick boxes (by definition, as if 
they knew what they were doing, they wouldn't have boxes to 
tick).  In that world, you need to have the checkboxes.

However, no case has been made that Camellia is in that 
world.  Camellia is not on Suite B, it isn't going to win 
any USG sales.  So it doesn't need the checkbox, and we can 
revert back to our own judgement.

The rough consensus in this group today (that I see) is that 
we are aiming at two markets at once, being the 
"small/mobile" and the "big/secure" sectors.  Which means 
the biggest and the smallest:  128 + 256.

iang

PS: That rough consensus is what *I* see here today.  Others 
might view it differently!

---

From: David Shaw <[email-masked]>
Date: Fri, 14 Mar 2008 11:16:11 -0400

> I am confused about one language difference between Camellia doc and ECC 
> doc.  In Camellia, there are MAYs.  In ECC, there are MUSTs, SHOULDs, MAYs.
>
> The way I interpret it, Camellia is *incorporated within* RFC4880 and adds 
> MAY algorithms.  But ECC is *appended as a MAY* ... the entire appendix is 
> a MAY, within which there are choices guided by RFC2119.
>
> Maybe I'm wrong about my interpretation, and if so, stop reading here.

I disagree with that interpretation.  There is nothing special about
Camellia here.  Both Camellia and ECC are the same: new RFCs that
specify new functionality.  Whatever they may specify, they can only
specify that in regards to themselves.

> OK, that's really crappy language but I hope you get the idea.

The draft more or less says that:

   OpenPGP applications MAY implement Camellia.  If implemented,
   Camellia may be used in any place in OpenPGP where a symmetric
   cipher is usable, and is subject to the same usage requirements
   (such as its presence in the Preferred Symmetric Algorithms
   signature subpacket) as the other symmetric ciphers in OpenPGP.

Note that the whole draft has only one "MAY" (and no MUSTs, SHOULDs,
etc) with regards to Camellia.  That is appropriate for a simple
algorithm RFC.  It's "you MAY implement this, but doing so doesn't get
you out of the various MUSTs and other rules from 4880."

> I agree with dropping 192.  I see no consistency argument here, the notion 
> of having consistent sets across algorithms seems esthetic only.  Real 
> users won't understand these notions of esthetics.

I just thought of another reason to leave Camellia-192 out: if we
leave it out and then change our minds, it's pretty easy to add it
later (just write a tiny RFC and get an algorithm number for it).  If
we do put it in now and then change our minds, it's nearly impossible
to get rid of it later.

David

---

From: Jon Callas <[email-masked]>
Date: Fri, 14 Mar 2008 13:17:10 -0700

> we do put it in now and then change our minds, it's nearly impossible

As much as I think that 192-bit encryption is stupid, many people have  
impressed upon me reasons it exists, none of which are technical.

I grit my teeth and hold my nose as I say this, but we have to have it.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Mon, 17 Mar 2008 20:30:37 +0100

> 256-bit keys (that is, lacking 192).  I tend to agree with Jon that

Drop Camellia-192.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: David Shaw <[email-masked]>
Date: Mon, 17 Mar 2008 17:03:53 -0400

> I grit my teeth and hold my nose as I say this, but we have to have it.

Ok, it's a mild ugliness, but it isn't actually harming anything.
I'll rev the draft and add it.

David

---

From: Ian G <[email-masked]>
Date: Tue, 18 Mar 2008 14:00:42 +0100

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

I can understand this for Suite B because there is a defined 
and controlled market for it, so the non-technical domain 
does rule.

But for Camellia?  As far as I can see this is a boutique 
algorithm that someone is adding for the love of it.

Well, ok, so if it is in, how does it go in?

Is it possible to put 192-bit encryption in under some sort 
of "COMPLIANCE-ONLY" label that means that you should only 
implement this is if you've moved out of the technical domain?

E.g., something below MUST, SHOULD, MAY, that suggests there 
are issues here which are well outside the spec.

iang

---

From: David Shaw <[email-masked]>
Date: Tue, 18 Mar 2008 09:11:11 -0400

On Mar 18, 2008, at 9:00 AM, Ian G wrote:

>> As much as I think that 192-bit encryption is stupid, many people  
>> have  impressed upon me reasons it exists, none of which are  
>> technical.
> I can understand this for Suite B because there is a defined and  
> controlled market for it, so the non-technical domain does rule.
>
> But for Camellia?  As far as I can see this is a boutique algorithm  
> that someone is adding for the love of it.
>
> Is it possible to put 192-bit encryption in under some sort of  
> "COMPLIANCE-ONLY" label that means that you should only implement  
> this is if you've moved out of the technical domain?
>
> E.g., something below MUST, SHOULD, MAY, that suggests there are  
> issues here which are well outside the spec.

That overloads additional semantics into the simple and elegant RFC  
keyword system.  We already have a concept of "You don't have to do  
this.  The spec doesn't require it.  If you do choose do to it,  
however, do it like this."  That's MAY.  We don't need another way to  
say the same thing.

David