Subject: [openpgp] List problems?

From: Wyllys Ingersoll <[email-masked]>
Date: Mon, 18 May 2015 23:44:03 +0000

Just checking in - all traffic from this list suddenly stopped on May 7.
Seems odd...

---

From: Werner Koch <[email-masked]>
Date: Tue, 19 May 2015 12:02:21 +0200

> Just checking in - all traffic from this list suddenly stopped on May 7.

Well, we are all waiting for someone to do the first move.

I know that we do not have a charter yet but we agreed on developing
rfc4880bis.  This raises the question who will act as editor and what
format to use for editing.

How would the general procedure be: Convert 4880 into a source format
and put that into a public repo?  A good starting point might be to
merge 4880 with 5581 (Camellia) and 6637 (ECC).  With that all in one
document we can then deprecate v3 and other stuff before we start
working on a v5 key format or new features.

Although I am not a big fan of Markdown there is a nice tool to convert
a Markdown document to the RFC XML and finally to an I-D/RFC: pandoc2rfc
at tools.ietf.org.  The advantage is that a simple text file can be
easily diffed and put into git.  [It would be nice if the IETF could
provide such a public repo.]

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Werner Koch <[email-masked]>
Date: Wed, 27 May 2015 11:35:45 +0200

> merge 4880 with 5581 (Camellia) and 6637 (ECC).  With that all in one

Everyone to shy to comment on this?  I guess I have to take this then.

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Wed, 27 May 2015 18:05:14 +0200

Hi!

I took rfc4880, converted it to pandoc and applied the verified errata
items.  I have it in a git repo at:

<http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=history;f=misc/id/rfc4880bis>

This is a first step towards a RFC4880bis.  By running
    
  pandoc2rfc abstract.mkd middle.mkd back.mkd
    
you may create a draft.txt whcih should be mostly identical to RFC4880.
The biblio entries for the normative section are a bit different and
those from the informational section are missing.  Tables are used
instead of simple list to allow the use of references.  Some parts are
copied verbatim from the RFC without new pandoc markup.  Author
addresses and the boilerplate information may not be correct.

What's next?

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Wed, 27 May 2015 10:06:29 -0700

> On May 19, 2015, at 3:02 AM, Werner Koch <[email-masked]> wrote:
> 

I can get someone the original source, which is using Tim Dierks's markup language, which has a Perl translator. That should be easier than dealing with the RFC final.

	Jon

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Wed, 27 May 2015 13:55:17 -0700

Greetings,

	Thank's for the work Werner.

	Christopher

On 27 May 2015, at 9:05, Werner Koch wrote:

> 	User-Agent*(Gnus+v5.13), 0.01000,
> 	In-Reply-To*message, 0.01000,
> 	User-Agent*Gnus/5.13, 0.01000,
> 	User-Agent*Gnus/5.13+(Gnus, 0.01000,
> 	From*Koch, 0.01000,
> 	Subject*Converted, 0.01000,
> 	regelt, 0.01000,
> 	In-Reply-To*of+"Mon, 0.01000,
> 	boilerplate+information, 0.01000,
> 	Gedanken+sind, 0.01000,
> 	sind+frei, 0.01000,
> 	In-Reply-To*of, 0.01000,
> 	Die+Gedanken, 0.01000,
> 	In-Reply-To*23, 0.01000,
> 	User-Agent*(Gnus, 0.01000,
> 	Url*gnupg, 0.01000,
> 	User-Agent*v5.13), 0.01000,
> 	In-Reply-To*message+of, 0.01000,
> 	In-Reply-To*18, 0.01000,
> 	List-Help*ietf.org?subject=help>, 0.98857,
> 	List-Help*request+ietf.org?subject=help>, 0.98857
>
> Hi!
>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

-- 
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf
keybase: https://keybase.io/liljenstolpe

---

From: Derek Atkins <[email-masked]>
Date: Thu, 28 May 2015 12:33:58 -0400

> Everyone to shy to comment on this?  I guess I have to take this then.

I'm not sure we need to merge in 5581 and 6637.  I think it's perfectly
reasonable to leave those as separate documents, unless you're expecting
to make them MTI?

>    Werner

-derek

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

---

From: Werner Koch <[email-masked]>
Date: Thu, 28 May 2015 19:20:41 +0200

> reasonable to leave those as separate documents, unless you're expecting

Well, 5581 has only the algorithm numbers for Camellia.  These are just
3 lines and one new reference.  We did the same for AES in rfc2440bis.

I assumed that ECC will at least be a SHOULD algorithm and thus merging
6637 seems to be appropriate.  

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Thu, 28 May 2015 13:51:42 -0400

> 6637 seems to be appropriate.  

I'm fine with that; just wanted to make sure we included them for a good
reason.  For example, I don't expect that we would include
draft-atkins-openpgp-algebraic-eraser in 4880bis, although I do want to
see it progress.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 19:26:19 +0100

> 6637 seems to be appropriate.  

I'd say most folks here are aware of it but just in case...

It'd be good if the WG(-to-be) considered if they want to
incorporate the work on new curves being done by CFRG. That
might mean waiting a little longer as CFRG aren't done at
that although they seem to be making good progress now.

Wearing no hats, I think it'd be good to include the new
curves in this work.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 May 2015 18:29:30 -0400

> Wearing no hats, I think it'd be good to include the new

Exactly what I was about to say.

I don't actually care very much which ECC we do. What I care about is that
instead of having fifty different variations and curlicues we have one high
strength and one ridiculously high strength approach. And I want to use
that same approach for S/MIME, TLS, SSH and OpenPGP.

This provides many benefits. First off, it means that instead of tracking
five separate sets of implementation experience, we have one. If someone
comes up with a TLS attack we can look at OpenPGP and see if the same sort
of thing might apply. TLS is going to get orders of magnitude more
implementation experience than anything else so chances are we will have a
solid implementation there long before we could gain experience on any
other application.

Another reason for the change is that then 'support for CFRG ECC' becomes
shorthand for 'support for crypto vNext'. Checking protocol version numbers
is quite tricky. Checking to see if they do an algorithm, much easier.
Problem is that security comes from removing features that seemed like a
good idea at the time. But that doesn't appear in marketing collateral.
Support for new algorithms does.

And finally, biggest problem with ECC has been that it is just too much new
complexity for too little reward many of us. When I see crypto with a
bazillion options, I see 'needs further work'. One of the main reasons RSA
is so dominant is that there is one algorithm and the way to implement it
has changed only three times in twenty years.

---

From: Werner Koch <[email-masked]>
Date: Fri, 29 May 2015 14:32:09 +0200

> might mean waiting a little longer as CFRG aren't done at

This is actually a no-brainer.  We can easily add new curves by adding
their OIDs and adjust MUST/SHOULD/MAY keywords at any stage of the
development.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Fri, 29 May 2015 11:38:55 -0400

> Wearing no hats, I think it'd be good to include the new

There is already an I-D on Ed25519.  Because it has a different form
than the NIST curves it requires a different parameter.  Is the
intention to include that by value in RFC4880bis?  (I'm certainly not
opposed to the answer being "yes" -- I just want us to be clear that
we're going to do that too in addition to 6637).

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 22:07:10 +0100

> we're going to do that too in addition to 6637).

I hope we hold off a wee bit there - CFRG are just now discussing
signature scheme issues and they might or might not land on
precisely Ed25519. But so long as we recognise there might be a
non-interoperable change then we're fine.

S.

---

From: Werner Koch <[email-masked]>
Date: Sat, 30 May 2015 12:03:56 +0200

> than the NIST curves it requires a different parameter.  Is the

Well, the I-D is on EdDSA which is a different signature algorithm than
ECDSA.  This is the reason why we need another public key algorithm
identifier.  Although Ed25519 is currently the only defined curve for
use with EdDSA we should keep algorithms and curves separate.

> opposed to the answer being "yes" -- I just want us to be clear that

Obviously I would vote with yes, but it is not an issue right now.
There are other things on out TODO list which I consider easier to
decide and more important. 

For example a new "Issuer Fingerprint" signature subpacket to be used in
favor of the "Issuer" signature subpacket (5.2.3.5).  Even now, without
having settled for a new fingerprint format we could already start
defining that subpacket: It's length would be a sufficient indication on
whether this is the old or new fingerprint format (I don't expect a new
fingerprint format will stay at 20 octets).

Salam-Shalom,

   Werner