Re: OpenPGP keys and Suite-B

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