Subject: OpenPGP keys and Suite-B

From: Andrey Jivsov <[email-masked]>
Date: Sat, 03 May 2008 14:11:07 -0700

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

---

From: "David Crick" <[email-masked]>
Date: Sat, 3 May 2008 22:26:21 +0100

>    C:

can we mark more than one box...?

---

From: Andrey Jivsov <[email-masked]>
Date: Sat, 03 May 2008 15:37:56 -0700

> 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.

---

From: "David Crick" <[email-masked]>
Date: Sun, 4 May 2008 15:56:07 +0100

On Sat, May 3, 2008 at 10:11 PM, Andrey Jivsov <[email-masked]> wrote:
>  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:
>

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

>  Key level   | Key preferences

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).

>  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.

>       These bits can be combined (i.e. they are not mutually

this is all good.

>  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.

> 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.

> 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.

>       specification of the policies to use ECC in OpenPGP

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).

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

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)

---

From: David Shaw <[email-masked]>
Date: Sun, 4 May 2008 11:41:24 -0400

On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote:
> The existence of 0x02 or 0x04 tells that the implicit default  
> algorithm TripleDES is replaced by (either of) corresponding AES  
> algorithm(s).
>
> 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

---

From: David Shaw <[email-masked]>
Date: Sun, 4 May 2008 12:13:27 -0400

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 Crick" <[email-masked]>
Date: Sun, 4 May 2008 17:25:06 +0100

> 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).

---

From: "David Crick" <[email-masked]>
Date: Sun, 4 May 2008 17:34:24 +0100

>  who need them.  There is precedence here: OpenPGP specifies DSA and

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).

---

From: David Shaw <[email-masked]>
Date: Sun, 4 May 2008 16:09:54 -0400

> 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.

> (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

---

From: David Shaw <[email-masked]>
Date: Sun, 4 May 2008 16:35:09 -0400

> 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.

> 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]>
Date: Sun, 4 May 2008 16:47:25 -0400

> 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: Werner Koch <[email-masked]>
Date: Mon, 05 May 2008 11:42:06 +0200

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

Too complicated.

Okay.

Werner:
   A:
   B:
   C: x

Shalom-Salam,

   Werner

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

---

From: Ian G <[email-masked]>
Date: Mon, 05 May 2008 11:55:22 +0200

David Shaw wrote:

> 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 

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 
> 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: Ian G <[email-masked]>
Date: Mon, 05 May 2008 12:43:57 +0200

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: "David Crick" <[email-masked]>
Date: Mon, 5 May 2008 14:52:05 +0100

>  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.

---

From: Jon Callas <[email-masked]>
Date: Mon, 5 May 2008 14:47:26 -0700

> / strange consensus counting, it looks like Andrey's C

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

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 06 May 2008 13:04:02 -0700

[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.

> 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.

> with a rule saying that 3DES is still a MUST-implement cipher, to 

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.

> 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.

> 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.

> 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 
> 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: Greg Troxel <[email-masked]>
Date: Wed, 07 May 2008 09:31:17 -0400

Andrey Jivsov <[email-masked]> writes:

> 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.

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 07 May 2008 17:37:43 -0700

> 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.
> 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
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: Jon Callas <[email-masked]>
Date: Mon, 19 May 2008 16:51:18 -0700

> 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.

> Or something else?  I don't mean to be difficult, but I really don't  

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