Subject: The discreet replica store

From: "Marshall Cassidy" <[email-masked]>
Date: Tue, 27 May 2008 13:56:26 -0500

A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today!
http://www%2Ejusiile%2Ecom/

From: Werner Koch <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: [email-masked]
Subject: Re: ECC curve ID
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 21 May 2008 18:27:09 +0200
Sender: [email-masked]

On Fri, 16 May 2008 08:59, [email-masked] said:

> 2. Different curve is not the same as different RSA key size.

What I want to express withn that comparision is that we already have a
wide range of parameters in addtion to the algorithm ID.  The curve ID
is just another parameter, or well a short-name for the curve
parameters.

> performance reasons. Implementations will achieve better performance
> by tuning the code for each underlying field at compile time, or, in
> case of hardware, this may be done by the manufacturing time.

They may still do this. I can't see that as an argument pro or con a
fixed list of curves.

> Conversely, even when RSA is implemented in hardware, a parameter to
> RSA key size is almost certainly a variable in software. There is
> nothing to gain by separately implementing RSA 2048 and RSA 4096
> operations.

I disagree.  Even pure software implementations are often tuned for
certain key sizes (e.g. to use the Karatsuba algorithm only for certain
sizes).  With hardware you even need to decide whether the hardware of
software implementation is faster for a certain size.

> support any other curve. Compare this with RSA support. To put this

Or compare that with DSA support.  How that we have DSA-2 many
implemtations fail because they can't cope with >1k DSA keys. That is a
similar interoperability issue as with new curve IDs.

> base, while my RSA implementation is capable of handling any key size
> within a reasonable range.

And what about DSA implementations?

> ==================================================================
> A: Keep current text regarding the procedure to approve new curves
>    (for/against)
> ==================================================================
> B: Keep current method to encode curve IDs as numeric IDs
>    (for/against)
> ==================================================================
> C: Need extension mechanism specified in the draft to add other
>    curves
>    (for/against)
> ==================================================================
>
>
> Andrey:
> 	A: for
> 	B: for
> 	C: against

==============================================================
D: Use an OIDs instead of an algorithm ID and define the NIST curves as MUST.
   (for/against)
==================

Werner:
        A: for (as long as that does not forbit other curves)
        B: against
        C: for (as second best choice)
        D: for

Shalom-Salam,

   Werner

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

Cc: "David Crick" <[email-masked]>, "Andrey Jivsov" <[email-masked]>, OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Greg Troxel <[email-masked]>
Subject: Re: I have a technical idea/change for the ECC draft
Date: Mon, 19 May 2008 17:00:10 -0700
Sender: [email-masked]

>
> I think there's a fundamental mismatch between OpenPGP-style key
> preferences and Suite B thinking.  As a sender, with labeled
> information, you can only use approved algorithms.  Thus, if a  
> recipient
> doesn't list the approved algorithm, you just can't send them mail.   
> The
> OpenPGP-style key preferences are in my view primarily to ensure
> interoperability and allow for algorithm transitions over long
> timescales.

It's not a mismatch, you just have a language that is more expressive  
than SuiteB allows.

>
> Are we proposing sender-side rules to match labels to approved
> algorithms?  It seems inadequate to put 'SuiteBOnly' as a key  
> preference
> on recipients.

No, we're trying to come up with an acceptable protocol.

There are some implementers who are going to want to do SuiteB within  
OpenPGP. We should make their lives easy.

But as Werner has noted, it's not our job as an international  
community to do things that forbid flexibility. It should be  
*possible* to use ECC and Camellia, as I noted in my other message.  
The *implementation* may disallow it, but the standard should not. It  
should be possible to use ECC and Whirlpool (which people keep  
threatening to do a draft for).

A SuiteBOnly pref makes an implementer's job easier if they care about  
SuiteB. They can detect it and act accordingly. It doesn't remove the  
requirement that an implementer know what they're doing.

	Jon

Cc: Andrey Jivsov <[email-masked]>, OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: Greg Troxel <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Mon, 19 May 2008 16:51:18 -0700
Sender: [email-masked]

On May 7, 2008, at 6:31 AM, Greg Troxel wrote:

>
> Andrey Jivsov <[email-masked]> writes:
>
>> Many of these issues, such as the security level of information, is
>> outside of traditional domain of OpenPGP. I suppose an e-mail
>> application in Suite-B environment might have a UI combobox with
>> SECRET/TOP SECRET choices in the compose window that magically (based
>> on content or at worst manually) are set to the correct level. The
>> rest is easier to program: this would allow software to check that
>> [TS] information is being sent to [S] key(s) and block it.
>
> I am a bit boggled as to the point of this discusion.  It seems rather
> unlikely that an OpenPGP software implementation will be approved to
> handle classified traffic, and even less likely that a user on a
> computer running a GUI will have available adequate MLS facilities to
> choose the level of a message.

Actually, I don't think it at all unlikely. Certainly it's unlikely  
without SuiteB in the protocol, an OpenPGP implementation would be at  
a disadvantage. Implementers of software often do things that other  
people think is unlikely.

>
>
> Are we talking about being able to have an OpenPGP implementation be
> configured to follow Suite B guidelines for S or TS, intended for use
> with unclassified information?  This would perhaps follow the  
> reasonable
> theory that such guidelines define best practices for algorithm  
> choice.
>
> Are we talking about hardened implementations that would implement  
> mail
> gateways between enclaves?
>
> Or something else?  I don't mean to be difficult, but I really don't  
> get
> it.
>

We're talking about the standards work that is needed for people who  
want to implement SuiteB within OpenPGP to be able to do so.

I think a number of your comments are in line with what I perceive the  
consensus to be. Building software is different from creating the  
protocol, and we seem to think that the protocol aspects should be  
minimal.

But we don't want to preclude quasi-SuiteB. Let me give as an example,  
the SuiteB ECC with Camellia rather than AES. The protocol should not  
preclude this.

So let's suppose I have an ECC key, and my symmetric cipher prefs say  
Twofish, Camellia, AES, [3DES]. Let's suppose that you implement  
Camellia and AES and 3DES.

The standard says you can pick any of those. You might pick Camellia,  
because I listed that before AES. If there were a "I-Like-SuiteB"  
flag, you might use that as a hint that I want you to use AES, even  
though Camellia is first. Or, you might be a system designed to do  
SuiteB, and you ignore all non-SuiteB algorithms, in which case you  
use AES, no matter what I say. You might even just use AES when I  
*don't* have it, even though it is a technical violation of the  
standard. We'd have to slap your wrist, but you might do it anyway.

The advantage of a SuiteB preference is that it would permit the  
implementation to make sense of options. If I create an ECC  
certificate with the SuiteB preference, then it makes sense to ensure  
that AES is in the preferences. If I see an ECC cert with SuiteB and  
no AES, I can throw an error, as this is inconsistent, or just deal.

The disadvantage of a SuiteB preference is that it's just more stuff  
to have to cope with. That's why I'm happy either way.

	Jon

Date: Thu, 15 May 2008 23:59:16 -0700
From: Andrey Jivsov <[email-masked]>
To: [email-masked]
Subject: Re: ECC curve ID
Sender: [email-masked]

I see three aspects of the issue.

1. The desire to control curves. What degree of freedom is appropriate?

Currently the document says:

"Future allocations in the registry will be done by IETF Expert Review 
process after general consensus between implementors of the standard is 
reached."

It doesn't allow other curves without general agreement (exact body that 
makes approval is not critical). The following item explains the reasons.

2. Different curve is not the same as different RSA key size.

The following argument will rely on implementation specifics that are 
unique to ECC.

Currently
http://www.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt only 
allows curves over prime underlying field. The primes selected for these 
fields are, forgive my exaggeration, weak primes. That is, they are 
primes very close to 2^m. The purpose of these primes is to construct 
finite fields with fastest operations for the given field size. This 
field is called underlying field of EC. The cryptography of ECC doesn't 
depend on the strength of operations in the underlying field, so the use 
of such special primes is justified. While it is possible to use 
general-purpose large-integer library to implement operations in the 
underlying field, this is not practical for performance reasons. 
Implementations will achieve better performance by tuning the code for 
each underlying field at compile time, or, in case of hardware, this may 
be done by the manufacturing time.

Conversely, even when RSA is implemented in hardware, a parameter to RSA 
key size is almost certainly a variable in software. There is nothing to 
gain by separately implementing RSA 2048 and RSA 4096 operations.

3. Finally, there is a question of how to reference a curve. Currently 
the draft uses numeric IDs, consistent with other IDs in RFC 4880.

With the exception of using less space to encode more RFC4880-aligned ID 
v.s. DER OID and slightly better lookup time, I see two approaches as 
similar. Some of pros and cons were mentioned earlier.

Given my opinion on 1., 3., and statement 2., and that the use of OID 
will need substantial rewrite of the draft, I prefer to use one byte 
curve ID. I see the difficulty of obtaining curve ID as a feature. I 
don't see the ease of introduction of new curve ID as a way to improve 
interoperability. If an implementation publicly stated that it 
implements IDs 1, 2, and 3, it's a loosing bet to expect that it will 
support any other curve. Compare this with RSA support. To put this 
differently, as an implementor I would like to hear in advance that 
another curve ID is going to be introduced into OpenPGP installation 
base, while my RSA implementation is capable of handling any key size 
within a reasonable range.

This issue is lingering unresolved between a few of us who expressed 
their opinions. I would appreciate opinion of the list on the following 
items. Please read the introduction above and mark your vote.

==================================================================
A: Keep current text regarding the procedure to approve new curves
    (for/against)
==================================================================
B: Keep current method to encode curve IDs as numeric IDs
    (for/against)
==================================================================
C: Need extension mechanism specified in the draft to add other
    curves
    (for/against)
==================================================================

Andrey:
	A: for
	B: for
	C: against

Thank you.

Werner Koch wrote:
> On Fri, 18 Apr 2008 20:47, [email-masked] said:
> 
>> Pros for OpenPGP IDs.
>>
>> 1) Vote of confidence for a particular curve. If it is included,
>> potential implementers have agreed on it. It will be more likely
>> widely supported. For example this is useful for hardware folks who
>> plan far ahead, plays in the decisions about which curve to use in key
>> self-signatures, and gives priorities to performance optimizations.
> 
> The same can be said of OIDs.
> 
>> 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()).
> 
> Well, okay.
> 
>> 3) consistency with the way OpenPGP references other algorithms.
> 
> Only if we agree that a curveID describes an OpenPGP algorithm.  In my
> view this is a parameter of the algorithm, much like p, q and g in DSA
> or even the key size of all aglgorithms.
> 
> For sure I do not want to convey all ECC curve parameters, thus using a
> way to describe the curve is important.
> 
>> 4) Named curves can be introduced as an extension. The core set of
>> curves will be encoded as integers, others as named curves.
> 
> I thought of that and was about to propose a format using an ID of 0 to
> identify a named curve.  However the specification as well as the code
> will be more complicated - even in the case that named curves are not
> supported by the implementation.  
> 
>> Do you see any value in having some approval process for new curves?
>> Does it bother you that I can use some questionable curve and it will
>> carry equal status per the spec to the three curves we discussed so
>> far (will we have a method to distinguish "next good" curve past P-521
>> from an experimental curve) ?
> 
> No.  We also don't approve implementations and have no real limits on
> key sizes.  It is easy to get things wrong.  Using a good curve is as
> important as to use sound parameters for RSA.
> 
>> Can we reach an agreement if the document also defined a method to
>> list named curves, along the lines of Werner's proposal?
> 
> If there is no other way to allow for arbitrary curves, I would agree to
> it. However, I still believe that an OID with a memcmp in the code is
> easier to implement than a numeric ID with a switch and a mechnism to
> cope withe the optional OID named curve.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 
> 

Date: Wed, 07 May 2008 17:37:43 -0700
From: Andrey Jivsov <[email-masked]>
To: Greg Troxel <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

Greg Troxel wrote:
> Andrey Jivsov <[email-masked]> writes:
>
>   
>> Many of these issues, such as the security level of information, is
>> outside of traditional domain of OpenPGP. I suppose an e-mail
>> application in Suite-B environment might have a UI combobox with
>> SECRET/TOP SECRET choices in the compose window that magically (based
>> on content or at worst manually) are set to the correct level. The
>> rest is easier to program: this would allow software to check that
>> [TS] information is being sent to [S] key(s) and block it.
>>     
>
> I am a bit boggled as to the point of this discusion.  It seems rather
> unlikely that an OpenPGP software implementation will be approved to
> handle classified traffic, and even less likely that a user on a
> computer running a GUI will have available adequate MLS facilities to
> choose the level of a message.
>   

This was an answer to a hypothetical question

"Now take real-world examples like that of Enigmail, which uses GPG as 
its crypto engine.  How on earth is GPG, the "OpenPGP implementation" in 
that system, supposed to stop Enigmail from doing that?".

I assumed as an axiom that Enigmail and gpg are running in this 
environment. I was trying to point out that we need another parameter -- 
the security level for the information -- and that it should come from 
"somewhere above" in reference to OpenPGP format. It cannot be deduced 
from recipient keys.
> Are we talking about being able to have an OpenPGP implementation be
> configured to follow Suite B guidelines for S or TS, intended for use
> with unclassified information?  This would perhaps follow the reasonable
> theory that such guidelines define best practices for algorithm choice.
>
> Are we talking about hardened implementations that would implement mail
> gateways between enclaves? 
>   
OpenPGP format can be used to encrypt any traffic. The proposal even has 
stronger public key algorithm P-521 beyond P-384 mandated by [TS].
> Or something else?  I don't mean to be difficult, but I really don't get
> it.
>   
So far, I think we are getting consensus that ECC in OpenPGP should be a 
format document. How an application is designed is beyond the scope of 
ECC. Gateway is probably easier to do right, but end-to-end has value in 
that users can be authenticated using multifactor authentication. I 
suppose you, Greg, don't argue that OpenPGP format can be used for any 
Suite-B traffic in properly designed application. ECC in OpenPGP is a 
format and the system itself can be implemented in hardware, or a 
combination of software and HSM (this should be our task to ensure this 
compatibility with smartcards and HSMs).

From: Greg Troxel <[email-masked]>
To: "David Crick" <[email-masked]>
Cc: "Andrey Jivsov" <[email-masked]>, "Jon Callas" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: I have a technical idea/change for the ECC draft
Date: Wed, 07 May 2008 09:39:04 -0400
Sender: [email-masked]

"David Crick" <[email-masked]> writes:

>> What do we loose if we
>> instead use "this key replaces TrippleDES implicit algorithm with AES-128"
>> notation? This would be beneficial for RSA keys too.
>
> what if we have:
>
> Alice: {AES256, AES128, AESover3DESflag [, 3DES implicitly]}
> Bob: {3DES [, AES128 implicitly]}
>
> Then Bob or his software could legitamately choose 3DES.
>
> whereas:
>
> Alice: ECC-384/521 key with {AES256, SuiteBOnly}  and
> Alice: ECC-256 key with { [AES128 implicit], SuiteBOnly}
>
> would refuse to encrypt with anything except AES256 and
> AES128 respectively.

I think there's a fundamental mismatch between OpenPGP-style key
preferences and Suite B thinking.  As a sender, with labeled
information, you can only use approved algorithms.  Thus, if a recipient
doesn't list the approved algorithm, you just can't send them mail.  The
OpenPGP-style key preferences are in my view primarily to ensure
interoperability and allow for algorithm transitions over long
timescales.

Are we proposing sender-side rules to match labels to approved
algorithms?  It seems inadequate to put 'SuiteBOnly' as a key preference
on recipients.

From: Greg Troxel <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Wed, 07 May 2008 09:31:17 -0400
Sender: [email-masked]

Andrey Jivsov <[email-masked]> writes:

> Many of these issues, such as the security level of information, is
> outside of traditional domain of OpenPGP. I suppose an e-mail
> application in Suite-B environment might have a UI combobox with
> SECRET/TOP SECRET choices in the compose window that magically (based
> on content or at worst manually) are set to the correct level. The
> rest is easier to program: this would allow software to check that
> [TS] information is being sent to [S] key(s) and block it.

I am a bit boggled as to the point of this discusion.  It seems rather
unlikely that an OpenPGP software implementation will be approved to
handle classified traffic, and even less likely that a user on a
computer running a GUI will have available adequate MLS facilities to
choose the level of a message.

Are we talking about being able to have an OpenPGP implementation be
configured to follow Suite B guidelines for S or TS, intended for use
with unclassified information?  This would perhaps follow the reasonable
theory that such guidelines define best practices for algorithm choice.

Are we talking about hardened implementations that would implement mail
gateways between enclaves?

Or something else?  I don't mean to be difficult, but I really don't get
it.

Date: Tue, 06 May 2008 13:04:02 -0700
From: Andrey Jivsov <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

[I sent it out incorrectly, re-sending]

A few comments to David Crick:
> I agree. In fact I would go further and say if A is the way forward 
> chosen then we should remove *all* mention of Suite-B from the
> OpenPGP ECC proposal, except for perhaps a paragraph noting that a 
> subset of OpenPGP ECC may be used as the basis for Suite B 
> implementations.

I agree that there is inconsistency in that if we go with "C", i.e. we 
anticipate another separate document (standard or just a best practices 
write-up), then Suite-B text from ECC in OpenPGP document can be moved 
elsewhere. At the same Suite-B and NSA are, as Jon Callas called them 
"big elephant in the room" and from this point of view I can see value 
in the current text that gives an idea of what is needed for Suite-B.

It seems that there is good consensus against increase in the text
referring to Suite-B in the document. I will wait and listen for a few
days regarding how to reduce/improve what currently have.

to David Shaw:
> I'm not sure that option (B) is really selectable here. Or put 
> another way, I think option (B) already exists as part of the current 
> cipher preferences system.
> 
> For example, take the entire installed user base of OpenPGP programs 
> to date. That's a non-trivial amount of code in active use. Those 
> programs will not know about the new feature flags, and will thus 
> ignore them (meaning they will use 3DES as the default algorithm).

I meant to introduce it with ECC keys. Here we have an advantage that
these keys can only be understood by new software. This is better than
circumstances before the adoption of MDC.

> Now take the case of an old key (default is 3DES) and a new key 
> (default is AES) as recipients to a message. Let's assume that there 
> is no agreement on ciphers, so the cipher of last resort must be 
> used. A sender using the 4880-compliant program will (correctly) use 
> 3DES, as it knows nothing about the feature flag telling it do behave 
> otherwise. A new OpenPGP program might not have 3DES (why bother 
> since AES is the new default), so one of the recipients won't be able
> to read the message. Okay, so we can fix that: we can enhance (B) 
> with a rule saying that 3DES is still a MUST-implement cipher, to 
> cover that case.

Correct, RFC4880 MUSTs are carried over in general.

> Now take the reverse case: the same two recipient keys, but the 
> sender is a new OpenPGP program that believes AES to be the default. 
> In the case above, the message will *still* be 3DES, as the older key 
> does not have the necessary feature flag, so the new program can't 
> use this new feature across the entire recipient set.

The though was that since the feature removes 3DES as implicit default, 
the two subsets of recipients -- one with 3DES common algorithm and 
another with AES -- will get empty intersection. This will result in a 
sending error.

> So given that new programs will need to have 3DES anyway to cover the 
> transition case, and given that messages sent to a mixture of old 
> and new keys that are forced to use the cipher of last resort will 
> end up as 3DES.... how is (B) different than the current cipher 
> preference system with AES listed before 3DES?

It is different in one important feature: it allows the removal of
legacy algorithm from the default. This is not a panacea and will break
interoperability in some cases.

> Unless I misunderstand, isn't A really the same as C (or to be very 
> accurate, isn't A a possible implementation of C?)

"A" is a way to have specific Suite-B flag, unlike B, which is more
aligned with RFC 4880 and really deals with 3DES-AES succession. There
are many "A"s possible, the one given is the bare minimum, since it
doesn't say much. C basically says that A and B are out of scope.

> This sort of thing risks putting restrictions in places that can't 
> always handle those restrictions. Take the restriction where the 
> implementation, in its Suite-B mode, must not allow the sending of 
> messages to keys that can't handle Suite-B: so much so that it's even 
> verboten to send two messages. Now take real-world examples like 
> that of Enigmail, which uses GPG as its crypto engine. How on earth 
> is GPG, the "OpenPGP implementation" in that system, supposed to stop 
> Enigmail from doing that? Forget GPG even - outside of a locked down 
> environment, how is any implementation supposed to stop the user 
> from doing that?

Yes, this thread shows that there is clearly more to Suite-B than a few
web pages that NSA has put up.

Many of these issues, such as the security level of information, is
outside of traditional domain of OpenPGP. I suppose an e-mail
application in Suite-B environment might have a UI combobox with
SECRET/TOP SECRET choices in the compose window that magically (based
on content or at worst manually) are set to the correct level. The rest 
is easier to program: this would allow software to check that [TS] 
information is being sent to [S] key(s) and block it.

Thank you everybody else, Jon, Werner, and Ian, for their comments.

From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Mon, 5 May 2008 14:47:26 -0700
Sender: [email-masked]

On May 5, 2008, at 6:52 AM, David Crick wrote:

>
>> Here is promised ballot. "x" for "yes".
>
> Well unless there is some Microsoft-style vote-stuffing
> / strange consensus counting, it looks like Andrey's C
> has carried.

Excuse me, but we operate by rough consensus, not voting. While it's  
appropriate to have a straw poll to get the feeling of what the  
consensus is, things do not "carry" -- and certainly ending a straw  
poll on Monday afternoon that went out on Saturday might look a lot  
like vote-stuffing to someone who worried about such things.

Having said that, I also like C. Rough consensus seems to be going  
that way, but we'd want to give people a week or so.

	Jon

Date: Mon, 5 May 2008 14:52:05 +0100
From: "David Crick" <[email-masked]>
To: "Andrey Jivsov" <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

>  Here is promised ballot. "x" for "yes".

Well unless there is some Microsoft-style vote-stuffing
/ strange consensus counting, it looks like Andrey's C
has carried.

I'm happy with that - I'd rather see Suite-B left out than
"put in with problems."

Andrey - do you want to start a re-write of the submitted
document "without" Suite-B?  I will be more than happy to
(then) do my long-promised clarity review - although I'm
sure removing Suite-B will just by itself reduce a lot of the
current complexity and verbiage.

Date: Mon, 05 May 2008 12:43:57 +0200
From: Ian G <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

Andrey Jivsov wrote:

> ===================================================================
>    C. Higher layers of application will govern compliance
>       with Suite B. "ECC in OpenPGP" document will define
>       reasonable superset of features required for Suite-B
>       or similar government documents, but exact
>       specification of the policies to use ECC in OpenPGP
>       is out of scope.
> ===================================================================

Iang:

   A:
   B:
   C: x.

iang

PS: the rest of the original post looks great for an intro 
to a document describing a potential Suite-B compatible profile.

From: Werner Koch <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: [email-masked]
Subject: Re: ECC curve ID
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 05 May 2008 12:06:15 +0200
Sender: [email-masked]

On Fri, 18 Apr 2008 20:47, [email-masked] said:

> Pros for OpenPGP IDs.
>
> 1) Vote of confidence for a particular curve. If it is included,
> potential implementers have agreed on it. It will be more likely
> widely supported. For example this is useful for hardware folks who
> plan far ahead, plays in the decisions about which curve to use in key
> self-signatures, and gives priorities to performance optimizations.

The same can be said of OIDs.

> 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()).

Well, okay.

> 3) consistency with the way OpenPGP references other algorithms.

Only if we agree that a curveID describes an OpenPGP algorithm.  In my
view this is a parameter of the algorithm, much like p, q and g in DSA
or even the key size of all aglgorithms.

For sure I do not want to convey all ECC curve parameters, thus using a
way to describe the curve is important.

> 4) Named curves can be introduced as an extension. The core set of
> curves will be encoded as integers, others as named curves.

I thought of that and was about to propose a format using an ID of 0 to
identify a named curve.  However the specification as well as the code
will be more complicated - even in the case that named curves are not
supported by the implementation.  

> Do you see any value in having some approval process for new curves?
> Does it bother you that I can use some questionable curve and it will
> carry equal status per the spec to the three curves we discussed so
> far (will we have a method to distinguish "next good" curve past P-521
> from an experimental curve) ?

No.  We also don't approve implementations and have no real limits on
key sizes.  It is easy to get things wrong.  Using a good curve is as
important as to use sound parameters for RSA.

> Can we reach an agreement if the document also defined a method to
> list named curves, along the lines of Werner's proposal?

If there is no other way to allow for arbitrary curves, I would agree to
it. However, I still believe that an OID with a memcmp in the code is
easier to implement than a numeric ID with a switch and a mechnism to
cope withe the optional OID named curve.

Salam-Shalom,

   Werner

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

Date: Mon, 05 May 2008 11:55:22 +0200
From: Ian G <[email-masked]>
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

David Shaw wrote:

>>> how is (B) different than the current cipher preference system with
>>> AES listed before 3DES?
>>
>> right - which is why my original proposal was for a stronger
>> suite B flag, which says implementations MUST NOT process
>> messages that fall outside of the Suite-B restrictions (that aside,
>> Andrey has written in "OpenPGP technical/documentation terms"
>> what I was originally trying to get across with my perhaps wrong
>> terminology of a Strict Suite-B "flag").
> 
> This sort of thing risks putting restrictions in places that can't 
> always handle those restrictions.  Take the restriction where the 
> implementation, in its Suite-B mode, must not allow the sending of 
> messages to keys that can't handle Suite-B: so much so that it's even 
> verboten to send two messages.  Now take real-world examples like that 
> of Enigmail, which uses GPG as its crypto engine.  How on earth is GPG, 
> the "OpenPGP implementation" in that system, supposed to stop Enigmail 
> from doing that?  Forget GPG even - outside of a locked down 
> environment, how is any implementation supposed to stop the user from 
> doing that?

Good example.  I don't believe it is possible to assert 
compliance with Suite-B, simply because we (whoever we are) 
are not the authorities on it.  Others are, NIST, I assume.

In such a situation, likely the best we can do is lay the 
framework for Suite-B *compatible* messages.  Get some 
formats out, get some code written.  And Enigmail will 
become (if it so desires) a Suite-B compatible client.

Then, others, perhaps PGP Inc's client, will become 
certified to do Suite-B by jumping through all the hoops. 
This will create a different messaging profile, perhaps 
compatible with the earlier, or perhaps not.

Suite-B public compatible profile, versus, Suite-B certified 
profile.

We'll likely end up with a schitzophrenic marketplace.  The 
first thing that will happen is that clients distribute 
compatible messages, to bootstrap the usage.  Then, someone 
will create a certification profile and get it certified. 
Then, there will be some tiny proportion of sales for the 
certification profile, and the vast mass will work to the 
compatible modes.

This is ok, as long as we end up with a large marketplace 
where the majority of clients speak a compatible mode.

The challenge is then only for the official certified 
version ... how does it switch between "compatible" and 
"certified" messages?  However, that challenge properly 
belongs to the commercial company that tries to take it 
through the certification process.

(I think I am now agreeing with Jon.  The best solution is 
to do nothing, state nothing in the document.  And leave it 
to the company that takes it through the certification 
process.  And let them create a new convention.  And they 
can share that profile with other *certified* 
implementations under the NIST process, or with the world, 
as they see fit.)

> I'm okay with some magic flag that says "I do Suite-B", if we leave the 
> implementation alone to deal with it (within the bounds of 
> interoperability).  I'm even more in favor of combining that with a 
> "OpenPGP Suite-B" document that lays out all the rules, whether they 
> pertain to the OpenPGP message format, or how a mail program is allowed 
> to send mail.  A separate document, where those who need those semantics 
> can have them all specified in detail, but those who don't need those 
> semantics are not encumbered with by them.

I'm ok with that.  I now see that it may have been just too 
complicated to do both ECC and Suite-B in the same document.

iang

From: Werner Koch <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Mon, 05 May 2008 11:42:06 +0200
Sender: [email-masked]

On Sat,  3 May 2008 23:11, [email-masked] said:

> ===================================================================
>    A. Use key notations "[email-masked]"
>       with values "top secret" and "secret".
> ===================================================================

Fine with me, but I see no need to mention it in the standard.

> ===================================================================
>    B. Use feature bits of a key 0x02, 0x4 of
>       "5.2.3.24. Features" as follows:
>       0x02: The default symmetric alg. of the key is AES-128
>       0x04: The default symmetric alg. of the key is AES-256
>       These bits can be combined (i.e. they are not mutually
>       exclusive).
> ===================================================================

Too complicated.

> ===================================================================
>    C. Higher layers of application will govern compliance
>       with Suite B. "ECC in OpenPGP" document will define
>       reasonable superset of features required for Suite-B
>       or similar government documents, but exact
>       specification of the policies to use ECC in OpenPGP
>       is out of scope.
> ===================================================================

Okay.

Werner:
   A:
   B:
   C: x

Shalom-Salam,

   Werner

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

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Sun, 4 May 2008 16:47:25 -0400
Sender: [email-masked]

On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote:
>
> ===================================================================
>   A. Use key notations "[email-masked]"
>      with values "top secret" and "secret".
> ===================================================================

> ===================================================================
>   C. Higher layers of application will govern compliance
>      with Suite B. "ECC in OpenPGP" document will define
>      reasonable superset of features required for Suite-B
>      or similar government documents, but exact
>      specification of the policies to use ECC in OpenPGP
>      is out of scope.
> ===================================================================

> In other words, A and B are really C+policies.

Unless I misunderstand, isn't A really the same as C (or to be very  
accurate, isn't A a possible implementation of C?)

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Sun, 4 May 2008 16:35:09 -0400
Sender: [email-masked]

On May 4, 2008, at 12:25 PM, David Crick wrote:

>> So given that new programs will need to have 3DES anyway to cover the
>> transition case, and given that messages sent to a mixture of old  
>> and new
>> keys that are forced to use the cipher of last resort will end up  
>> as 3DES....
>
> This is (mainly) about ECC keys,  and specifically about the
> implementations' [ability to enforce] Suite-B compliance.
>
> As old applications won't be able to understand ECC keys *at
> all*, we've "almost" got a clean sheet with what we do with
> ECC keys.  "Almost," because at present ECC keys inherit
> 3DES as the default cipher from 4880.

I understand that this is intended to be about ECC keys, but the slate  
isn't even "almost" clean so long as as we're playing alongside 4880.   
There are a bunch of messy cross cases that make this highly resistant  
to cleanliness.

>> how is (B) different than the current cipher preference system with
>> AES listed before 3DES?
>
> right - which is why my original proposal was for a stronger
> suite B flag, which says implementations MUST NOT process
> messages that fall outside of the Suite-B restrictions (that aside,
> Andrey has written in "OpenPGP technical/documentation terms"
> what I was originally trying to get across with my perhaps wrong
> terminology of a Strict Suite-B "flag").

This sort of thing risks putting restrictions in places that can't  
always handle those restrictions.  Take the restriction where the  
implementation, in its Suite-B mode, must not allow the sending of  
messages to keys that can't handle Suite-B: so much so that it's even  
verboten to send two messages.  Now take real-world examples like that  
of Enigmail, which uses GPG as its crypto engine.  How on earth is  
GPG, the "OpenPGP implementation" in that system, supposed to stop  
Enigmail from doing that?  Forget GPG even - outside of a locked down  
environment, how is any implementation supposed to stop the user from  
doing that?

I'm okay with some magic flag that says "I do Suite-B", if we leave  
the implementation alone to deal with it (within the bounds of  
interoperability).  I'm even more in favor of combining that with a  
"OpenPGP Suite-B" document that lays out all the rules, whether they  
pertain to the OpenPGP message format, or how a mail program is  
allowed to send mail.  A separate document, where those who need those  
semantics can have them all specified in detail, but those who don't  
need those semantics are not encumbered with by them.

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Sun, 4 May 2008 16:09:54 -0400
Sender: [email-masked]

On May 4, 2008, at 12:34 PM, David Crick wrote:

>
> On Sun, May 4, 2008 at 5:13 PM, David Shaw <[email-masked]>  
> wrote:
>>
>> On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote:
>>
>>> ===================================================================
>>>   C. Higher layers of application will govern compliance
>>>      with Suite B. "ECC in OpenPGP" document will define
>>>      reasonable superset of features required for Suite-B
>>>      or similar government documents, but exact
>>>      specification of the policies to use ECC in OpenPGP
>>>      is out of scope.
>>> ===================================================================
>>
>> I vote for C.  Keep the policies out of the standard and leave it up
>> to the implementers.  I'm not against having policies specified, but
>> I'd rather see them in a different document for use by those people
>> who need them.  There is precedence here: OpenPGP specifies DSA and
>> not DSS.
>>
>> David
>
> 4880 13.6 starts with:
>
> 13.6.  DSA
>
>   An implementation SHOULD NOT implement DSA keys of size less than
>   1024 bits.  It MUST NOT implement a DSA key with a q size of less
>   than 160 bits.  DSA keys MUST also be a multiple of 64 bits, and the
>   q size MUST be a multiple of 8 bits.
>
> and ends with:
>
>  Note that earlier versions of this standard only allowed a 160-bit q
>   with no truncation allowed, so earlier implementations may not be
>   able to handle signatures with a different q size or a truncated
>   hash.
>
> which I would say would be "on using DSA in OpenPGP." But then in
> the middle of those two bits has all of this:
>
> The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be
> used in one of the following ways:
>
>     * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
>       SHA-512 hash
>
>     * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
>       hash
>
>     * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
>
>     * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
>
>   The above key and q size pairs were chosen to best balance the
>   strength of the key with the strength of the hash.  Implementations
>   SHOULD use one of the above key and q size pairs when generating DSA
>   keys.  If DSS compliance is desired, one of the specified SHA hashes
>   must be used as well.  [FIPS186] is the ultimate authority on DSS,
>   and should be consulted for all questions of DSS compliance.
>
>
> which by your argument "shouldn't be in" OpenPGP.

Not at all.  There is a very substantial difference between mentioning  
in passing the difference between the specification and a popular  
standard and the addition of new semantics to enforce a difference  
between the specification and a popular standard.  Notice we don't  
have a "Strict DSS" flag or anything like that.  If someone wants to  
enforce it and draw a distinction, that's fine.  OpenPGP gives people  
a lot of crypto parts they can put together in different ways.

> We've got the same thing with Suite-B, only the fact that it's not  
> just
> a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is
> of 4880), but that there's a conflict between the 4880 spec and  
> Suite-B
> (i.e. (at least) the issue of 3DES).

Then publish an additional RFC giving whatever semantics are desired.   
I wouldn't want to load down the basic "ECC in OpenPGP" spec with it,  
any more than I'd want to see the traditional PGP trust model  
specified in 4880.

David

Date: Sun, 4 May 2008 17:34:24 +0100
From: "David Crick" <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Cc: "David Shaw" <[email-masked]>
Sender: [email-masked]

On Sun, May 4, 2008 at 5:13 PM, David Shaw <[email-masked]> wrote:
>
>  On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote:
>
>  > ===================================================================
>  >    C. Higher layers of application will govern compliance
>  >       with Suite B. "ECC in OpenPGP" document will define
>  >       reasonable superset of features required for Suite-B
>  >       or similar government documents, but exact
>  >       specification of the policies to use ECC in OpenPGP
>  >       is out of scope.
>  > ===================================================================
>
>  I vote for C.  Keep the policies out of the standard and leave it up
>  to the implementers.  I'm not against having policies specified, but
>  I'd rather see them in a different document for use by those people
>  who need them.  There is precedence here: OpenPGP specifies DSA and
>  not DSS.
>
>  David

4880 13.6 starts with:

13.6.  DSA

   An implementation SHOULD NOT implement DSA keys of size less than
   1024 bits.  It MUST NOT implement a DSA key with a q size of less
   than 160 bits.  DSA keys MUST also be a multiple of 64 bits, and the
   q size MUST be a multiple of 8 bits.

and ends with:

  Note that earlier versions of this standard only allowed a 160-bit q
   with no truncation allowed, so earlier implementations may not be
   able to handle signatures with a different q size or a truncated
   hash.

which I would say would be "on using DSA in OpenPGP." But then in
the middle of those two bits has all of this:

The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be
used in one of the following ways:

     * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
       SHA-512 hash

     * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
       hash

     * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

     * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

   The above key and q size pairs were chosen to best balance the
   strength of the key with the strength of the hash.  Implementations
   SHOULD use one of the above key and q size pairs when generating DSA
   keys.  If DSS compliance is desired, one of the specified SHA hashes
   must be used as well.  [FIPS186] is the ultimate authority on DSS,
   and should be consulted for all questions of DSS compliance.

which by your argument "shouldn't be in" OpenPGP.

We've got the same thing with Suite-B, only the fact that it's not just
a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is
of 4880), but that there's a conflict between the 4880 spec and Suite-B
(i.e. (at least) the issue of 3DES).

Date: Sun, 4 May 2008 17:25:06 +0100
From: "David Crick" <[email-masked]>
To: "David Shaw" <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Cc: OpenPGP <[email-masked]>, "Andrey Jivsov" <[email-masked]>
Sender: [email-masked]

>  So given that new programs will need to have 3DES anyway to cover the
> transition case, and given that messages sent to a mixture of old and new
> keys that are forced to use the cipher of last resort will end up as 3DES....

This is (mainly) about ECC keys,  and specifically about the
implementations' [ability to enforce] Suite-B compliance.

As old applications won't be able to understand ECC keys *at
all*, we've "almost" got a clean sheet with what we do with
ECC keys.  "Almost," because at present ECC keys inherit
3DES as the default cipher from 4880.

> how is (B) different than the current cipher preference system with
> AES listed before 3DES?

right - which is why my original proposal was for a stronger
suite B flag, which says implementations MUST NOT process
messages that fall outside of the Suite-B restrictions (that aside,
Andrey has written in "OpenPGP technical/documentation terms"
what I was originally trying to get across with my perhaps wrong
terminology of a Strict Suite-B "flag").

(And to directly answer your question, Andrey's B is slightly different,
in that while the preference system *is* ordered, implementations
currently have free rein at how they use the intersection of
recipient preferences; Andrey's B says that AES should be used
in place of 3DES - but as you've (now) pointed out, for non-ECC
keys this may mean some people receiving AES messages when
in fact they can e.g. only process 3DES ones).

Date: Sun, 4 May 2008 12:13:27 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote:

> ===================================================================
>    C. Higher layers of application will govern compliance
>       with Suite B. "ECC in OpenPGP" document will define
>       reasonable superset of features required for Suite-B
>       or similar government documents, but exact
>       specification of the policies to use ECC in OpenPGP
>       is out of scope.
> ===================================================================

I vote for C.  Keep the policies out of the standard and leave it up
to the implementers.  I'm not against having policies specified, but
I'd rather see them in a different document for use by those people
who need them.  There is precedence here: OpenPGP specifies DSA and
not DSS.

David

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Date: Sun, 4 May 2008 11:41:24 -0400
Sender: [email-masked]

On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote:
> ===================================================================
>   B. Use feature bits of a key 0x02, 0x4 of
>      "5.2.3.24. Features" as follows:
>      0x02: The default symmetric alg. of the key is AES-128
>      0x04: The default symmetric alg. of the key is AES-256
>      These bits can be combined (i.e. they are not mutually
>      exclusive).
> ===================================================================
>
>   TOP SECRET (TS) must have 0x02
>   SECRET must have 0x02|0x04=0x06
>
> The existence of 0x02 or 0x04 tells that the implicit default  
> algorithm TripleDES is replaced by (either of) corresponding AES  
> algorithm(s).
>
> This specification may appeal to these who don't want to see Suite-B  
> mentioned in the "protocol/format" document. It also specifies  
> narrow feature using the concepts compatible with the scope of RFC  
> 4880.

I'm not sure that option (B) is really selectable here.  Or put  
another way, I think option (B) already exists as part of the current  
cipher preferences system.

For example, take the entire installed user base of OpenPGP programs  
to date.  That's a non-trivial amount of code in active use.  Those  
programs will not know about the new feature flags, and will thus  
ignore them (meaning they will use 3DES as the default algorithm).

Now take the case of an old key (default is 3DES) and a new key  
(default is AES) as recipients to a message.  Let's assume that there  
is no agreement on ciphers, so the cipher of last resort must be  
used.  A sender using the 4880-compliant program will (correctly) use  
3DES, as it knows nothing about the feature flag telling it do behave  
otherwise.  A new OpenPGP program might not have 3DES (why bother  
since AES is the new default), so one of the recipients won't be able  
to read the message.  Okay, so we can fix that: we can enhance (B)  
with a rule saying that 3DES is still a MUST-implement cipher, to  
cover that case.

Now take the reverse case: the same two recipient keys, but the sender  
is a new OpenPGP program that believes AES to be the default.  In the  
case above, the message will *still* be 3DES, as the older key does  
not have the necessary feature flag, so the new program can't use this  
new feature across the entire recipient set.

So given that new programs will need to have 3DES anyway to cover the  
transition case, and given that messages sent to a mixture of old and  
new keys that are forced to use the cipher of last resort will end up  
as 3DES.... how is (B) different than the current cipher preference  
system with AES listed before 3DES?

David

Date: Sun, 4 May 2008 15:56:07 +0100
From: "David Crick" <[email-masked]>
To: "Andrey Jivsov" <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

On Sat, May 3, 2008 at 10:11 PM, Andrey Jivsov <[email-masked]> wrote:
>
>  Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires
> that
>
>    TOP SECRET must use AES-256
>    SECRET must use AES-128 or AES-256
>
>  Labeled security is usually required with these standards. Information is
> labeled with certain classification, which assures that the processing of
> this information will match the label as data travels through the system.
> This results in:
>
>    TOP SECRET keys can receive TOP SECRET and SECRET information
>    SECRET keys can only receive SECRET information
>
>   Information |          |
>     level    |   Keys   | "Send to" action
>   --------------------------------------------
>    [TS]      | [TS],[S] | fail
>    [S]       | [TS],[S] | allow with AES-256
>    [TS]      |      [S] | fail
>    [S]       | [TS]     | allow with AES-256
>    [TS]      | [TS]     | allow with AES-256
>    [S]       |      [S] | allow with AES-256/128
>
>  Note that two first rows represent the same mix of keys but result in
> different behavior. This aspect is orthogonal to OpenPGP.

Andrey, I really appreciate you putting the effort in to
flesh this out.

>  For completeness,
>
>  Key level   | Key preferences
>  --------------------------------------------
>   [TS]      | {AES-256}
>   [S]       | {AES-256, AES-128}

Note, however, that the [TS]/[S] suites restrict not only the
symmetrical cipher but also the public key size and the size
of the SHA2 hash used too.

Your "key level" implicitly includes these further restrictions,
but it needs to be stated explicitly as well, and there would
be similar "fails" if the public key size was too small or (say)
you were doing conventional encryption and the hash used
for the passphrase was too small.

The current discussion has sprung from the "inheriting" of
3DES from 4880, however, so that was why the focus has
(so far) been on the fact that OpenPGP ECC COULD encrypt
using 3DES unless we provide some sort of mechanism or
policy to prevent this (and hence this particular document).

>  I see three approaches.
>
>    A. Use key notations "[email-masked]"
>  Leave the interpretation of these values to applications.

>  (If all we have to say is the sentence under A, I would say we keep it out
> of the document.)
I agree.  In fact I would go further and say if A is the way
forward chosen then we should remove *all* mention of
Suite-B from the OpenPGP ECC proposal, except for
perhaps a paragraph noting that a subset of OpenPGP ECC
may be used as the basis for Suite B implementations.

===================================================================
>    B. Use feature bits of a key 0x02, 0x4 of
>       "5.2.3.24. Features" as follows:
>       0x02: The default symmetric alg. of the key is AES-128
>       0x04: The default symmetric alg. of the key is AES-256
>       These bits can be combined (i.e. they are not mutually
>       exclusive).
>  ===================================================================
>
>    TOP SECRET (TS) must have 0x02
>    SECRET must have 0x02|0x04=0x06
>
>  The existence of 0x02 or 0x04 tells that the implicit default algorithm
> TripleDES is replaced by (either of) corresponding AES algorithm(s).

this is all good.

>  This specification may appeal to these who don't want to see Suite-B
> mentioned in the "protocol/format" document. It also specifies narrow
> feature using the concepts compatible with the scope of RFC 4880.
>
>  The Suite-B meaning need to be layered on top of these bits.

interesting - I would say this was "a little bit less" than I was
originally intending, i.e. you've made it "profile" (e.g. Suite-B)
independent.

I'm fine with that as a half-measure; it will help us "remove"
3DES.

>  Yet, the proposals A and B lack following details:
>
>  * It is not sufficient to rely on key holder to tell which information
> level it is eligible to receive. Everyone wants TOP SECRET. This statement
> must come from a trusted source, like a certification by a trusted key or
> looked up online. The above proposals A and B put data into a
> self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be
> needed. It is "may" because in some cases keys are managed, making this
> notary signatures unnecessary, or keys may be looked up in some online
> directory.

>  * Furthermore, what a sender does with the information and how it
> interprets the flags on a key is not enforceable by a recipient. This must
> be enforced by higher levels.

right, so this is where my original proposal was "stronger."

My original proposal was "strict suite-B flag[s] mean a
sender's implementation MUST NOT use anything other
than the appropriate ciphers [and hashes/public key sizes]
on the recipient[s]' key"

If you wish to add this as a further option to the ballot
then that's up to you.

>  Finally:

>    C. Higher layers of application will govern compliance
>       with Suite B. "ECC in OpenPGP" document will define
>       reasonable superset of features required for Suite-B
>       or similar government documents, but exact
>       specification of the policies to use ECC in OpenPGP
>       is out of scope.

Hmmm, your C reads very much like your A.

In fact now having looked at your C in more detail I actually
don't see any value in A - it's almost a "hint from the receiver"
that needs the human user on the sending side to see it
as such.

At least C means something to an implementer.

>  In other words, A and B are really C+policies. Regardless of which route we
> take, we will need "protocol/format" document. This is what implementors
> need first. This is what is needed to establish interoperability base. This
> is what will make messages flow. This layer alone may get incorrectly
> encrypted [TS] information with TripleDES, so higher layer will be needed.

This layer doesn't even care whether it's 3DES; it's not
"incorrect" at all for this layer.

Anyway, as with your "A" option, I see that if "C" is chosen
then (almost) all mention of Suite-B should be removed
from the OpenPGP ECC specification, aside from as I've
mentioned above ("a subset of OpenPGP ECC may be")

> However, as an implementor I see value in splitting a Suite-B cloud into
> layers that we can implement and test independently.

Well your original document was an AES strength ECC
with Suite-B capability along with it.  What's come out of
it was that we either need to deal fully/properly (i.e. we
need to enforce ciphers somehow), *or*, we junk all
notion of Suite-B in OpenPGP ECC.  If we don't "do" Suite-B
"properly" then we're not actually doing it at all (it either
supports Suite-B or it doesn't, i.e. there is scope for it to
wrongly-encrypt with 3DES, or there isn't).

>  Here is promised ballot. "x" for "yes".
>
>  As an editor I think that voting C will result in faster progress of the
> document.

Possibly, although the removal of Suite-B from the text
will probably take just as long (longer?) than adding the
"features bit" (or the "stronger" SSB bit) to the text!

So, my vote:

David Crick:

A: [_]  (meaningless for an implementation spec)
B: [x]  (ideally as a strict suite B MUST respect / MUST NOT deviate)
C: [_]  (may as well just remove notion of Suite-B)

Date: Sat, 03 May 2008 15:37:56 -0700
From: Andrey Jivsov <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Sender: [email-masked]

David Crick wrote:
>>  Here is promised ballot. "x" for "yes".
> 
>>    A:
>>    B:
>>    C:
> 
> can we mark more than one box...?

I suppose prioritized list will convey some information, as long as the 
best choice is obvious.

I also don't mean to suppress offer alternative proposals, but before we 
go there it would be interesting to see where we stand with this list.

Date: Sat, 3 May 2008 22:26:21 +0100
From: "David Crick" <[email-masked]>
To: "Andrey Jivsov" <[email-masked]>
Subject: Re: OpenPGP keys and Suite-B
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

>  Here is promised ballot. "x" for "yes".

>    A:
>    B:
>    C:

can we mark more than one box...?

Date: Sat, 03 May 2008 14:11:07 -0700
From: Andrey Jivsov <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: OpenPGP keys and Suite-B
Sender: [email-masked]

Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires 
that

    TOP SECRET must use AES-256
    SECRET must use AES-128 or AES-256

Labeled security is usually required with these standards. Information 
is labeled with certain classification, which assures that the 
processing of this information will match the label as data travels 
through the system. This results in:

    TOP SECRET keys can receive TOP SECRET and SECRET information
    SECRET keys can only receive SECRET information

  Information |          |
     level    |   Keys   | "Send to" action
  --------------------------------------------
    [TS]      | [TS],[S] | fail
    [S]       | [TS],[S] | allow with AES-256
    [TS]      |      [S] | fail
    [S]       | [TS]     | allow with AES-256
    [TS]      | [TS]     | allow with AES-256
    [S]       |      [S] | allow with AES-256/128

Note that two first rows represent the same mix of keys but result in 
different behavior. This aspect is orthogonal to OpenPGP.

For completeness,

Key level   | Key preferences
--------------------------------------------
   [TS]      | {AES-256}
   [S]       | {AES-256, AES-128}

I see three approaches.

===================================================================
    A. Use key notations "[email-masked]"
       with values "top secret" and "secret".
===================================================================

Leave the interpretation of these values to applications. The rationale 
is that we don't recite government documents in the document like "ECC 
in OpenPGP". There are other requirements that must be satisfied beyond 
the scope of the "ECC in OpenPGP" document, such as authentication and 
how the private keys are unlocked. For example, we cannot enforce the 
use of PIN pad devices.

(If all we have to say is the sentence under A, I would say we keep it 
out of the document.)

===================================================================
    B. Use feature bits of a key 0x02, 0x4 of
       "5.2.3.24. Features" as follows:
       0x02: The default symmetric alg. of the key is AES-128
       0x04: The default symmetric alg. of the key is AES-256
       These bits can be combined (i.e. they are not mutually
       exclusive).
===================================================================

    TOP SECRET (TS) must have 0x02
    SECRET must have 0x02|0x04=0x06

The existence of 0x02 or 0x04 tells that the implicit default algorithm 
TripleDES is replaced by (either of) corresponding AES algorithm(s).

This specification may appeal to these who don't want to see Suite-B 
mentioned in the "protocol/format" document. It also specifies narrow 
feature using the concepts compatible with the scope of RFC 4880.

The Suite-B meaning need to be layered on top of these bits.

Yet, the proposals A and B lack following details:

* It is not sufficient to rely on key holder to tell which information 
level it is eligible to receive. Everyone wants TOP SECRET. This 
statement must come from a trusted source, like a certification by a 
trusted key or looked up online. The above proposals A and B put data 
into a self-signature. OpenPGP "0x50: Third-Party Confirmation 
signature" may be needed. It is "may" because in some cases keys are 
managed, making this notary signatures unnecessary, or keys may be 
looked up in some online directory.

* Furthermore, what a sender does with the information and how it 
interprets the flags on a key is not enforceable by a recipient. This 
must be enforced by higher levels.

* I thought about how a [TS] information might be encrypted to a Suite-B 
recipient with hypothetical command line tool. For example, like this:

  openpgpcmd --suite-B-information=secret 
--trusted-certifier-top-secret=XXX -trusted-certifier-secret=YYY  recipients

v.s.

  openpgpcmd --suite-B-information=secret --trusted-certifier=ZZZ recipients

In one case the type of certifier ([TS]/[S]) is determined from key 
properties, in another case  the types of certifiers are passed 
explicitly. The commands look similar, especially if there are two 
trusted certifiers in each case.

Finally:

===================================================================
    C. Higher layers of application will govern compliance
       with Suite B. "ECC in OpenPGP" document will define
       reasonable superset of features required for Suite-B
       or similar government documents, but exact
       specification of the policies to use ECC in OpenPGP
       is out of scope.
===================================================================

In other words, A and B are really C+policies. Regardless of which route 
we take, we will need "protocol/format" document. This is what 
implementors need first. This is what is needed to establish 
interoperability base. This is what will make messages flow. This layer 
alone may get incorrectly encrypted [TS] information with TripleDES, so 
higher layer will be needed. However, as an implementor I see value in 
splitting a Suite-B cloud into layers that we can implement and test 
independently.

Here is promised ballot. "x" for "yes".

As an editor I think that voting C will result in faster progress of the 
document.

Andrey:
    A:
    B:
    C: x

Cc: "Derek Atkins" <[email-masked]>, "Andrey Jivsov" <[email-masked]>, OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
To: David Crick <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
Date: Fri, 2 May 2008 15:08:44 -0700
Sender: [email-masked]

On May 2, 2008, at 7:01 AM, David Crick wrote:

>
> On Fri, May 2, 2008 at 2:32 PM, Derek Atkins <[email-masked]> wrote:
>> David,
>>
>>> The submitted version doesn't (yet) have mention of the
>>> proposed (and generally, it seems, well-received notion of)
>>> a StrictSuiteB flag / flags.
>>
>> Actually, it was not well received.
>
> oh.  I counted at least (quick search of the archive):
>
> Jon Callas:
> I don't think this is a bad idea at all

Since I'm being invoked, I must clarify. I don't think it's a bad idea  
at all. But I think in the interests of minimalism, nothing is better  
than something.

In other words, leaving as much to the implementation as possible is  
good.

But that also includes some flag that says the implementation does  
SuiteB strictly. It's good to have it, but I'm not sure much more  
needs to be said. It isn't our job to go into the gory details of what  
that means.

>
> ...
> * I like David Crick's suggestion of a preference that says, "I'm
> going to be strict about Suite B." This is a legislative solution, and
> it would work well, it's simple, and elegant. End of story.
>
> Werner Koch (quoting the "i like David Crick's" paragraph above):
> I support this.
>
>
> Further, Andrey Jivsov continued the discussion:
> One additional issue I realized that we didn't address is the mixing
> of keys for two levels of Suite-B profile. It is similar to the issue
> of mixing non-Suite-B and Suite-B keys.
>
> TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We
> cannot make TOP SECRET keys use AES-128, yet this is what happens with
> implicit AES-128. Making AES-256 implicit will not work either,
> because now SECRET keys will be picked as compatible with TOP SECRET
> keys. Finally, having no implicit preferences disallows TOP SECRET
> keys to receive SECRET information.
>
> Do we now need two Suite-B flags?
> (end quoting Andrey)
>
>
> so I thought this had some momentum behind it?
>
>> The "OpenPGP way" of doing this
>> is an application putting in the "accepted ciphers" into the public
>> key notation.  This document doesn't need to describe that because
>> it's already well documented in RFC 4880.
>
> but the problem was that a recipient currently has no
> way of saying "strict suite B" beyond setting one/both
> of the AESes as higher up in their preference list and
> then *hoping* all of the implementations that ever
> send messages use this "advisory" information rather
> than (legitimately) taking some other arbitrary intersection
> of recipient preferences and choosing something other
> than the AES of the correct length.
>
>> Using the notation packet also allows us to support different "Strict
>> Suites"..  If some other country wants their own stuff in there we  
>> don't
>> need to extend anything; applications just set the appropriate
>> supported cipher list.  Et Voila, you've got your "flag".
>
> perhaps I'm not using correct terminology here?  My "flag"
> (or "flags," if we decide we need one for each of the Suite
> B profiles, as per Andrey's last message, quoted above)
> was intended to be "something" on the key that the user
> can set to say "Strict Suite-B."  Is my "flag"/key "something"
> the same as what you are calling a "notation packet" ?
>
> I don't think it is?
>
> But I emphasis again that the key cipher preference list
> *cannot* be guaranteed to make us Suite-B compliant,
> as implementations can choose their own intersections.
>
> So we need something "more."
>
>> -derek
>> --
>>       Derek Atkins                 617-623-3745
>>       [email-masked]             www.ihtfp.com
>>       Computer and Internet Security Consultant
>>
>

Date: Fri, 2 May 2008 19:00:24 +0100
From: "David Crick" <[email-masked]>
To: "Andrey Jivsov" <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

On Fri, May 2, 2008 at 6:29 PM, Andrey Jivsov <[email-masked]> wrote:
> David Crick wrote:
>
> > The submitted version doesn't (yet) have mention of the
...
> > StrictSuiteB flag / flags.

>  Given later comments by Derek and your subsequent replies, I think we may
> need separate discussion on this.

An alternative that I've just thought of is to do some sort of
"layering":

rfc4880 (base)
   -> OpenPGP ECC ("anything goes")
      -> Suite-B, and other (e.g. national) "profiles"

So the current "OpenPGP ECC" doc could be completely
re-written, stripping out references to Suite-B (but still
retaining a "relative strengths" section).  This would also
simplify the specification.

*Then* we could write a standalone Suite-B doc, which
would specify a constrained sub-set of OpenPGP ECC.

Note, we'd *still* have the "how to make Suite-B strict"
problem, so *still* might require some sort of kludge.

And/*or* we could even just "avoid" the Strict Suite B
issue altogether, and leave it for the implementers!
Since Suite-B users will (by definition) only want to
communicate with other Suite-B users, then they will be
a self-contained userbase, and so can simply not
implement 3DES [and other ciphers].

Meanwhile the rest of us just set AES-256 and AES-128
at the head of our cipher preferences and put up with the
fact that someone may send us 3DES messages (or using
any other cipher for that matter, if they over-ride using
[e.g., in gnupg] --cipher-algo and disregard the warning).

Date: Fri, 02 May 2008 10:29:57 -0700
From: Andrey Jivsov <[email-masked]>
To: David Crick <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
Sender: [email-masked]

David Crick wrote:
>>  The discussions we had on pre-submission version of the specification can
>> continue with the draft.
> 
> The submitted version doesn't (yet) have mention of the
> proposed (and generally, it seems, well-received notion of)
> a StrictSuiteB flag / flags.  Discussions tailed off on this, but we
> (still) need(ed) to give the whole interoperability thing a long
> hard look, as per your last message on this topic.
> 

Given later comments by Derek and your subsequent replies, I think we 
may need separate discussion on this. Without assumption that additional 
key properties is the way to go and where this description should be, I 
thought it will be helpful to submit more detailed proposal on how this 
could be done and what are the issues we need to worry about. I will do 
this before coming Monday. We can then have some sort of vote on this 
subject.

> 
> Some comments from me on the (latest) submitted draft:
> 
> |    While TripleDES ensures interoperability between applications
> |    complaint with OpenPGP and ECC specifications, it doesn't help
> |    interoperability with Suite-B profile.  Suppose TripleDES is the
> |    only shared algorithm within a set of recipients.  If Suite-B
> |    compliant recipient is added to the mentioned recipient set, the
> |    sender SHALL NOT send out a message.
> 
> shouldn't this be MUST NOT?

Will do.

> 
> (continuing to quote section so people can see the context)
> |    This is because TripleDES is
> |    excluded from Suite-B and sending out two copies of the same
> |    message, one encrypted with TripleDES and another with AES-128 or
> |    AES-256, would mean that the same information that must have been
> |    protected with Suite-B compliant algorithm was protected instead
> |    with non-compliant TripleDES.  This restriction covers other cases
> |    in which none of recipients' shared algorithms are allowed by
> |    Suite-B.  One of available methods to a recipient to help ensure
> |    interoperability with Suite-B is to include one of two Suite-B
> |    symmetric algorithms, AES-128 or AES-256, or both, in the set of
> |    preferred algorithms.
> (end of that section).
> 
> But how *on earth* are you going to "enforce" people NOT sending
> two copies of the same message under different ciphers??!

I meant to provide a warning to implementors that once crypto/messaging 
layer detects sending conflict to a group of recipients, the conflict 
cannot be resolved by sending two separate messages. While each of two 
messages with appropriate subset of recipients can satisfy constrains of 
  crypto/messaging layer, this is not the right thing to do from the 
point of view of information protection.

For example, I thought that the following message misses this point:

Len Sassaman wrote this in Mar 2008:
> Breaking compatibility on the protocol level doesn't mean breaking it on
> the actually application level. In a different thread, there as discussion
> of people using "regular" DSA/EG keys and then adding a recipient who uses
> ECC. So what? The application can encrypt twice, and send the properly
> encrypted messages to the appropriate people.

> 
> 
> Meanwhile, this new bit:
> 
> |    While some statements in this specification refer to TripleDES
> |    algorithm, this is only done to help interoperability with existing
> |    application and already generated keys; AES-256 is the recommended
> |    alternative to TripleDES in all circumstances when AES-256 is
> |    available.
> 
> I (really) like, but probably needs to have added onto the end of it:
> 
> Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC,
> and may be preferred in more constrained environments.  However,
> AES-128 is not allowable when the larger Suite-B profiles are required,
> so AES-256 may still need to be implemented for this interoperability.
> 
> (But, as I stated at the start of this email, this whole topic still needs
> further thought.)

I would say that, overall, AES-128 should remains the lowest common 
denominator in this specification. It is needed to cover the mix of 
recipients with smartcards, cellphones, etc. Hopefully, "TOP SECRET 
Suite-B profile keys" will not be issued on constrained smartcards. 
Another point, when TOP SECRET keys receive TOP SECRET information, this 
is when AES-256 must be used, only TOP SECRET keys can be in the list of 
recipients. AES-256 SHOULD be in the set of preferred algorithms on each 
key in this case.

Date: Fri, 2 May 2008 15:01:56 +0100
From: "David Crick" <[email-masked]>
To: "Derek Atkins" <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
Cc: "Andrey Jivsov" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Fri, May 2, 2008 at 2:32 PM, Derek Atkins <[email-masked]> wrote:
> David,
>
>  > The submitted version doesn't (yet) have mention of the
>  > proposed (and generally, it seems, well-received notion of)
>  > a StrictSuiteB flag / flags.
>
>  Actually, it was not well received.

oh.  I counted at least (quick search of the archive):

Jon Callas:
I don't think this is a bad idea at all
...
* I like David Crick's suggestion of a preference that says, "I'm
going to be strict about Suite B." This is a legislative solution, and
it would work well, it's simple, and elegant. End of story.

Werner Koch (quoting the "i like David Crick's" paragraph above):
I support this.

Further, Andrey Jivsov continued the discussion:
One additional issue I realized that we didn't address is the mixing
of keys for two levels of Suite-B profile. It is similar to the issue
of mixing non-Suite-B and Suite-B keys.

TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We
cannot make TOP SECRET keys use AES-128, yet this is what happens with
implicit AES-128. Making AES-256 implicit will not work either,
because now SECRET keys will be picked as compatible with TOP SECRET
keys. Finally, having no implicit preferences disallows TOP SECRET
keys to receive SECRET information.

Do we now need two Suite-B flags?
(end quoting Andrey)

so I thought this had some momentum behind it?

> The "OpenPGP way" of doing this
>  is an application putting in the "accepted ciphers" into the public
>  key notation.  This document doesn't need to describe that because
>  it's already well documented in RFC 4880.

but the problem was that a recipient currently has no
way of saying "strict suite B" beyond setting one/both
of the AESes as higher up in their preference list and
then *hoping* all of the implementations that ever
send messages use this "advisory" information rather
than (legitimately) taking some other arbitrary intersection
of recipient preferences and choosing something other
than the AES of the correct length.

>  Using the notation packet also allows us to support different "Strict
>  Suites"..  If some other country wants their own stuff in there we don't
>  need to extend anything; applications just set the appropriate
>  supported cipher list.  Et Voila, you've got your "flag".

perhaps I'm not using correct terminology here?  My "flag"
(or "flags," if we decide we need one for each of the Suite
B profiles, as per Andrey's last message, quoted above)
was intended to be "something" on the key that the user
can set to say "Strict Suite-B."  Is my "flag"/key "something"
the same as what you are calling a "notation packet" ?

I don't think it is?

But I emphasis again that the key cipher preference list
*cannot* be guaranteed to make us Suite-B compliant,
as implementations can choose their own intersections.

So we need something "more."

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

To: "David Crick" <[email-masked]>
Cc: "Andrey Jivsov" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
From: Derek Atkins <[email-masked]>
Date: Fri, 02 May 2008 09:32:51 -0400
Sender: [email-masked]

David,

"David Crick" <[email-masked]> writes:

>>  The discussions we had on pre-submission version of the specification can
>> continue with the draft.
>
> The submitted version doesn't (yet) have mention of the
> proposed (and generally, it seems, well-received notion of)
> a StrictSuiteB flag / flags.  Discussions tailed off on this, but we
> (still) need(ed) to give the whole interoperability thing a long
> hard look, as per your last message on this topic.

Actually, it was not well received.  The "OpenPGP way" of doing this
is an application putting in the "accepted ciphers" into the public
key notation.  This document doesn't need to describe that because
it's already well documented in RFC 4880.

Using the notation packet also allows us to support different "Strict
Suites"..  If some other country wants their own stuff in there we don't
need to extend anything; applications just set the appropriate
supported cipher list.  Et Voila, you've got your "flag".

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

Date: Thu, 1 May 2008 22:44:53 +0100
From: "David Crick" <[email-masked]>
To: "Andrey Jivsov" <[email-masked]>
Subject: Re: ECC in OpenPGP -00.txt is posted as a draft
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

>  The discussions we had on pre-submission version of the specification can
> continue with the draft.

The submitted version doesn't (yet) have mention of the
proposed (and generally, it seems, well-received notion of)
a StrictSuiteB flag / flags.  Discussions tailed off on this, but we
(still) need(ed) to give the whole interoperability thing a long
hard look, as per your last message on this topic.

Some comments from me on the (latest) submitted draft:

|    While TripleDES ensures interoperability between applications
|    complaint with OpenPGP and ECC specifications, it doesn't help
|    interoperability with Suite-B profile.  Suppose TripleDES is the
|    only shared algorithm within a set of recipients.  If Suite-B
|    compliant recipient is added to the mentioned recipient set, the
|    sender SHALL NOT send out a message.

shouldn't this be MUST NOT?

(continuing to quote section so people can see the context)
|    This is because TripleDES is
|    excluded from Suite-B and sending out two copies of the same
|    message, one encrypted with TripleDES and another with AES-128 or
|    AES-256, would mean that the same information that must have been
|    protected with Suite-B compliant algorithm was protected instead
|    with non-compliant TripleDES.  This restriction covers other cases
|    in which none of recipients' shared algorithms are allowed by
|    Suite-B.  One of available methods to a recipient to help ensure
|    interoperability with Suite-B is to include one of two Suite-B
|    symmetric algorithms, AES-128 or AES-256, or both, in the set of
|    preferred algorithms.
(end of that section).

But how *on earth* are you going to "enforce" people NOT sending
two copies of the same message under different ciphers??!

Meanwhile, this new bit:

|    While some statements in this specification refer to TripleDES
|    algorithm, this is only done to help interoperability with existing
|    application and already generated keys; AES-256 is the recommended
|    alternative to TripleDES in all circumstances when AES-256 is
|    available.

I (really) like, but probably needs to have added onto the end of it:

Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC,
and may be preferred in more constrained environments.  However,
AES-128 is not allowable when the larger Suite-B profiles are required,
so AES-256 may still need to be implemented for this interoperability.

(But, as I stated at the start of this email, this whole topic still needs
further thought.)