headers
Simon Josefsson | 2 Apr 2008 00:20
Favicon
Gravatar

OpenPGP mail/news header draft updated


Hi all!

I have updated the draft about OpenPGP: mail header, see:

http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-04.txt
http://josefsson.org/openpgp-header/

I have improved the ABNF which was the remaining open issue.

I believe the document is now ready for moving forward, so I'll approach
an AD about that.  Or is there any point in moving this forward via the
OpenPGP WG?

Comments on the document are still welcome, of course.

Thanks,
/Simon

Derek Atkins <derek <at> ihtfp.com> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> 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).
>
> I don't see why not.  I don't think it would be very contentious.
>
>> /Simon
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey Jivsov | 11 Apr 2008 12:16

ECC in OpenPGP ready to be submitted to IETF


... or so it seems.

I think there is rough consensus (or the lack of strong disagreement, if 
you prefer) on the scope of the draft, how it fits into RFC 4880, and 
expectations about interoperability arising from the use of ECC keys.

I plan to summit the document in a few days as an OpenPGP WG item to IETF.

I updated http://brainhub.googlepages.com/pgp , I hope I haven't 
overlooked anything substantial.

Thank you.
Permalink | Reply | 2 comments |
headers
David Crick | 11 Apr 2008 19:01
Picon

Re: ECC in OpenPGP ready to be submitted to IETF


>  ... or so it seems.

I saw the subject and my initial thought was "whoa, seems
a bit hasty!"

Believe me, I'm all in favour of getting ECC into OpenPGP
ASAP, but the above was my initial reaction.

>  I think there is rough consensus (or the lack of strong disagreement, if
> you prefer) on the scope of the draft, how it fits into RFC 4880, and
> expectations about interoperability arising from the use of ECC keys.

If you put it that way, then I suppose it could be "ready."

I do kind of feel discussions tailed off once we'd run out of
stream - or at least, once all the arguments (er, viewpoints ;))
had been voiced _ad nauseam_.

>  I plan to summit the document in a few days as an OpenPGP WG item to IETF.

I take it there's still "scope" for revision/refinement after that?

(I seem to recall 2440bis took an awful long time to go round
this bit, if it's that stage you're referring to.)

>  I updated http://brainhub.googlepages.com/pgp , I hope I haven't overlooked
> anything substantial.

I diff'ed ietf-00 with your pre-9 and didn't see anything major...
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Crick | 11 Apr 2008 20:01
Picon

Whirlpool


I've seen mention several times on this list (and others)
of Whirlpool's apparent pending inclusion into OpenPGP,
but have yet to see any actual drafts on here about it.

Is anyone willing to admit they are working on one? :)
Permalink | Reply | 2 comments |
headers
Andrey Jivsov | 11 Apr 2008 21:40

Re: ECC in OpenPGP ready to be submitted to IETF


David Crick wrote:
>>  ... or so it seems.
>>     
>
> I saw the subject and my initial thought was "whoa, seems
> a bit hasty!"
>
> Believe me, I'm all in favour of getting ECC into OpenPGP
> ASAP, but the above was my initial reaction.
>
>   
>>  I think there is rough consensus (or the lack of strong disagreement, if
>> you prefer) on the scope of the draft, how it fits into RFC 4880, and
>> expectations about interoperability arising from the use of ECC keys.
>>     
>
> If you put it that way, then I suppose it could be "ready."
>
> I do kind of feel discussions tailed off once we'd run out of
> stream - or at least, once all the arguments (er, viewpoints ;))
> had been voiced _ad nauseam_.
>
>   
>>  I plan to summit the document in a few days as an OpenPGP WG item to IETF.
>>     
>
> I take it there's still "scope" for revision/refinement after that?
>
> (I seem to recall 2440bis took an awful long time to go round
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Shaw | 11 Apr 2008 22:18

Re: Whirlpool


On Fri, Apr 11, 2008 at 07:01:24PM +0100, David Crick wrote:
> 
> I've seen mention several times on this list (and others)
> of Whirlpool's apparent pending inclusion into OpenPGP,
> but have yet to see any actual drafts on here about it.
> 
> Is anyone willing to admit they are working on one? :)

I think Len was working on one.

Len, you're welcome to the XML from my Camellia draft.  With that XML,
a Whirlpool draft is pretty much cut and paste.

David
Permalink | Reply | 1 comment |
headers
David Crick | 12 Apr 2008 23:21
Picon

I have a technical idea/change for the ECC draft


"11.3. Interoperability with Suite-B profile" currently states:

   "If TripleDES is the only shared algorithms for a set
   of recipients, no Suite-B compliant recipient can be added to the
   mentioned recipient set."

but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the
sender).

I therefore have a suggestion:

implement a key-packet preference flag that says "strict SuiteB"

If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.

This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.

Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox

thoughts people?

(as an aside, re my "editorial [readability] changes," I might be
able to sit down and have a go at them on Monday or Tuesday.)
(Continue reading)

Permalink | Reply | 25 comments |
headers
Ian G | 13 Apr 2008 12:48

Re: I have a technical idea/change for the ECC draft


David Crick wrote:
> "11.3. Interoperability with Suite-B profile" currently states:
> 
>    "If TripleDES is the only shared algorithms for a set
>    of recipients, no Suite-B compliant recipient can be added to the
>    mentioned recipient set."

I had to look at all of 11.3 to try and make sense of this, 
and found that whole subsection to be hopelessly confusing. 
  Can we have a simple statement as to whether an 
OpenPGP-ECC key can be used with TripleDES or not?  Can 
messages be mixed-mode or not?

It seems to me that if an application creates and exports an 
OpenPGP-ECC key (only) then that public key cannot be used 
with TripleDES, as the document does not suggest it anywhere 
(and implies it is ruled out).  Which means there should be 
a specific claim that this ECC draft overrules the 
"guarantee" of TripleDES intersection in RFC4880.

(To me, this seems like a reasonable price to pay to get a 
good, clear result.)

Alternatively, there should be a specific claim permitting 
use of TripleDES and describing how/what.

(I should note that I do not recall the discussions of a few 
months back.  This should be a "good thing" because it 
allows me to view it as a first time reader.  My routine
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrey Jivsov | 14 Apr 2008 20:14

Re: I have a technical idea/change for the ECC draft


You are saying there there is no way to remove 3DES from the set of
algorithm preferences, since it is implicitly there per RFC 4880.

If a key has {AES-128, AES-256} as a preference list, right now it is
effectively {AES-128, AES-256, 3DES}.

And I think it follows that the only logical intended action that your 
proposal seeks is to break the transmission if one of recipients is an 
ECC key that disallows 3DES, *if* 3DES is the only shared algorithm for 
the given set of recipients per RFC 4880.

It is possible to keep this feature limited to the mode of operation of 
the software (a command line option --cipher-algo, UI element, etc), 
v.s. making it depend on the attribute of a key.

This assumes that both sides "agree" to use the Suite-B profile. This is 
usually the case. Many other criteria must be met in order to be in 
highly regulated Suite-B profile, especially for Top Secret or 
classified category. These additional requirements include the type of 
authentication to local keys (which AFAIK must be hardware protected 
path authentication).

However, I do see the benefit of a feature. If it were to make into the 
document I suggest to make it more generic and not Suite-B specific. The 
following alternatives achieve the same what Davit proposed but are 
easier do understand:

* this key has no implicit default algorithms
* this key replaces 3DES implicit algorithm with AES-128
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Crick | 14 Apr 2008 20:26
Picon

Re: I have a technical idea/change for the ECC draft


>  However, I do see the benefit of a feature. If it were to make into the
> document I suggest to make it more generic and not Suite-B specific. The
> following alternatives achieve the same what Davit proposed but are easier
> do understand:
>
>  * this key has no implicit default algorithms
>  * this key replaces 3DES implicit algorithm with AES-128

This second one (AES-128 replaces 3DES) *really* appeals to me.

It should also further appeal to resource-constrained environments,
where (therefore) not having to implement (or use) 3DES would be
a bonus.

Actually, maybe we need to add / reconsider having a section
in the ECC doc that says

"if AES-128 is not explicitly in the set of preferred algorithms, then
it is implicitly added at the end.  If neither AES-128 or 3DES are
explicitly listed, then both of them are implicitly added, with 3DES
last."

NB, this is weaker than the idea of a "strict suiteB flag" (my original
proposal), and slightly weaker than your "AES128 replaces 3DES."

>  David Crick wrote:
>
> > "11.3. Interoperability with Suite-B profile" currently states:
> >
(Continue reading)

Permalink | Reply | 2 comments |

Gmane