Subject: key flag for authentication

From: Werner Koch <[email-masked]>
Date: Fri, 06 Jun 2003 10:39:30 +0200

Hi!

I know that we are short of releasing a new RFC and bis-08 looks
really good.  Due to the project I am currently working on I'd like to
suggest a small enhancement:

 5.2.3.21. Key Flags

     [...]   

     0x20 - This key may be used for authentication.

Usage notes are not necessary and it should be left to an
implementation on how to handle this key flag.

There are drafts and actual implementations to use OpenPGP keys with
TLS and ssh.  Thus, having a subkey specially for this purpose seems
to be a good idea.  A key with key flag 0x02 (sign data) could be used
for authentication too but this has the problem than there would be no
easy way to select the appropriate subkey for data signing or
authentication purposes.  As a workaround an implementation could use
notation data but this would be implementation dependend and a kind of
hack.

What do you think?

  Werner

-- 
  Nonviolence is the greatest force at the disposal of
  mankind. It is mightier than the mightiest weapon of
  destruction devised by the ingenuity of man. -Gandhi

---

From: Ian Grigg <[email-masked]>
Date: Fri, 06 Jun 2003 11:28:37 -0400

> notation data but this would be implementation dependend and a kind of

Not that I disagree with you, but I'd like to point out
alternative practice.

We (Systemics/Ricardo/SOX/WebFunds) have been using PGP keys
for authentication purposes for years (8, if anyone's counting,
with a couple of years gap where we got blindsided into
x.509).  (Something betwee 100k and a million transactions.)

To identify keys and their roles, we stick the following
into the keyId textual tag:

   [role]

where role could be one of certification, operator, server,
contract, ...

This appears to be much more flexible than looking for bits
in the key, as it allows lots of roles.  When one gets into
bigger protocols, one ends up with dozens of different keys
at different places in the PKI.  And they all need to have
their roles and characteristics encoded in them.

So, whilst I wouldn't necessarily disagree with the bit
being there, I'm not sure I see the need.

(And, thinking about it some more, I can see that the issue
you might have there is that once you have your authentication
bit in place, how do you show that the key is to be used for
SSH authentication and not TLS?)

Just some thoughts!

-- 
iang

---

From: Werner Koch <[email-masked]>
Date: Fri, 06 Jun 2003 19:56:56 +0200

>    [role]

That used to be the only way during PGP 2 times.  A German ISP with an
associated CA created pgp 2.63in to formalize their conventions on how
to encode more attributes in the User ID.  This made it even possible
to use separate signing and encryption keys as well as expiration
dates.

In contrast OpenPGP provides a more general way to encode more
information with a key.  Most notably notation data can be used
instead of tags encoded in the User ID.

> SSH authentication and not TLS?)

That is not the question I want to address.  The problem stems from
this:

If you have more than one encryption subkey, the most useful way is to
use the newest encryption subkey which has not been created in the
future.  This allows for an automatic key rollover.  Although it does
not make that much sense, the scheme can also be used for signing
subkeys.  To figure out what subkey to use, the implementation
computes the key capabilities from the used algorithm and the key
flags and decided on this.  If you add a subkey for authentication,
this one is probably the newest one and would be used for signing -
that is probably not what you want.

Shalom-Salam,

   Werner

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Sun, 15 Jun 2003 12:08:38 +0200

> implementation on how to handle this key flag.

At least a note that handling of this flag should be implementation defined 
should go in. Somebody implementing OpenPGP software needs to know at least 
that he needn't worry what to do with such keys (or perhaps that he should 
ignore such [sub]keys in most cases?)

> notation data but this would be implementation dependend and a kind of

Hmm. Using a flag which is not documented (except in that it exists) seems 
kind of a hack, too. If the correct behaviour of openpgp software is to be 
left to implementors, why not use a notation - which is more flexible than a 
one-bit flag anyway?

greets
-- vbi

-- 
featured link: http://fortytwo.ch/smtp

---

From: David Shaw <[email-masked]>
Date: Sun, 15 Jun 2003 09:19:46 -0400

> left to implementors, why not use a notation - which is more flexible than a 

It doesn't need much documentation.  This is similar to the "This key
may be used to encrypt communications" or "This key may be used to
encrypt storage" flags: a usage hint.

I think the proposed flag is a good idea.

David

---

From: "Michael Young" <[email-masked]>
Date: Sun, 15 Jun 2003 11:53:44 -0400

This discussion raises another concern I've had regarding new flags.

The description (in draft 7, anyway) reads:
>    This subpacket contains a list of binary flags that hold information
>    about a key. It is a string of octets, and an implementation MUST
>    NOT assume a fixed size. This is so it can grow over time. If a list
>    is shorter than an implementation expects, the unstated flags are
>    considered to be zero.
...

In fact, the list of flags can grow *without* increasing the length.
we're contemplating adding new flags to the first octet.

I think it's inappropriate to change the meaning of an old signature
by adding flags to the specification.

>      0x20 - This key may be used for authentication.

An old signature didn't contemplate the meaning of this bit.
The key might be intended for authentication; it might not.
New software that looks at this bit can't tell whether: the
signer explicitly chose not to allow authentication; or, the
signer was using an old revision of the specification.

But, new flags can be structured to disambiguate new revisions
from old.  For example, here we can add two bits:
       0x20 - This key may be used for authentication.
       0x40 - (Bit 0x20 is explicitly set.)
Old signatures would have a zero in 0x40, so a new application
can apply its own default (rather than having one imposed by
the specification).  New signatures that actively decide on the
value for the 0x20 bit must set 0x40.  (A new signer could also
choose to accept the viewer's default by leaving 0x40 zero.)

I don't know whether this is the right time to start adopting this
sort of policy for new flags -- do implementations make use of
the existing key flags already?  If they do, then I strongly
encourage including disambiguation for new flags.

---

From: David Shaw <[email-masked]>
Date: Sun, 15 Jun 2003 17:11:11 -0400

> choose to accept the viewer's default by leaving 0x40 zero.)

I don't think this is really necessary.  The lack of a given flag
being set doesn't necessarily mean that the key *isn't* used for the
respective action.  The draft even uses the phrase "...stating a
preference...".

If anyone cares enough, they can certainly re-issue the signature with
the flag set.

David

---

From: "Imad R. Faiad" <[email-masked]>
Date: Mon, 16 Jun 2003 10:21:57 +0200

>notation data but this would be implementation dependend and a kind of
Hello Werner,

This is what I think:-

Why not just create a key dedicated for the purposes of TLS or SSH.

I would like to propose that signing sub keys be disallowed in OpenPGP.

While an encryption key concerns the key holder, a signing key is
of concern to others.  PGP users identify keys and publicize theirs
by the master key ID and fingerprint.  These are also the primary keys
used by key servers.

As I understand it, sub keys are only justified in the following
circumstances:-
1) When the public key algorithm does not support encryption (e.g. DSA).
2) In agreement with a school of thought, which recommends that
   it is good practice not to use the same key for signing and
   encryption.

Any other arguments beyond the above, are just eccentricities,
and will be better addressed by creating another key.

Therefore, for the sake of simplicity, please permit me to propose
that an OpenPGP key be a Master Key of an OpenPGP public key algorithm
suitable for signing, and ONE optional encryption sub key of an
OpenPGP public key algorithm suitable for encryption PERIOD.

It is evident that sub keys seem to be evolving beyond their
intended use.  Let's clean up that mess before it is too late.

What do you think?
>  Werner

Best Regards

Imad R. Faiad

---

From: Ian Brown <[email-masked]>
Date: Mon, 16 Jun 2003 09:18:09 +0100

> I would like to propose that signing sub keys be disallowed 

This would stop people keeping their master signing key on a more secure
offline machine, and using it to sign shorter-lifetime signing subkeys
which can be used on a day-to-day basis to sign messages :(

>    it is good practice not to use the same key for signing and

(2) is vital in countries where decryption but not signature keys can be
seized by law enforcement agencies and others:
http://www.acsac.org/2000/papers/47.pdf

> Any other arguments beyond the above, are just 
> eccentricities, and will be better addressed by creating another key.

Another "eccentricity" I am fond of is short-lifetime encryption subkeys
that can be deleted once they have expired, reducing the impact of the
above-mentioned key seizure powers. I currently (manually) generate such
keys valid for one month; if I ever got round to automating this, I
would go for a week or less...
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5

---

From: Werner Koch <[email-masked]>
Date: Mon, 16 Jun 2003 11:56:08 +0200

> which can be used on a day-to-day basis to sign messages :(

That is exactly what I would like to do.  Today I still use a separate
certification key but it is a problem WoT wise and annoying to tell
people how to send me encrypted mail, because they usually have
problems with the sign-only certification key.

---

From: "Imad R. Faiad" <[email-masked]>
Date: Mon, 16 Jun 2003 14:20:42 +0200

Greetings,

>which can be used on a day-to-day basis to sign messages :(
If you are so paranoid, why don't you keep all your PGP keys
in a "more secure offline machine" and use PGP solely on it?
Should you have a need for shorter-lifetime signing keys,
just generate master keys explicitly for that purpose.
>http://www.acsac.org/2000/papers/47.pdf
If indeed you have such needs, there is nothing to preclude from generating
two distinct keys, one for signing and the other for encryption.
>http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5
I think there is a very serious flaw in the OpenPGP WOT when
it comes to v4 keys, sub keys literally have blown a hole in it,
and created a nice backdoor resulting in what I call a Web of Mistrust...

Whatever one feels about sub keys, I think that this WOT
issue ought to be addressed.

my 2c

Best Regards

Imad R. Faiad

---

From: "Imad R. Faiad" <[email-masked]>
Date: Mon, 16 Jun 2003 14:30:08 +0200

Hello Ian,

>which can be used on a day-to-day basis to sign messages :(
Let me add, and no offence of course, from the fact that you are
relegating those short-lifetime signing sub keys to a less secure
environment, I infer that you have no confidence in them, so how
do you expect others to trust such keys, or signatures generated
by them for that matter?  You might as well not sign at all.

my 2c

Best Regards

Imad R. Faiad

---

From: Ian Brown <[email-masked]>
Date: Mon, 16 Jun 2003 13:35:21 +0100

> in a "more secure offline machine" and use PGP solely on it? 

Because for the vast majority of messages that I send, the increased
security would not be worth the extra effort. Whereas the compromise of
a key used to certify other keys has a much greater effect, and so to
many people it would.

> just generate master keys explicitly for that purpose.

The point of the master key/subkey structure is that you shouldn't have
to do this, with the Web of Trust complications it introduces -- as
Werner said.

> If indeed you have such needs, there is nothing to preclude 
> from generating two distinct keys, one for signing and the 
> other for encryption.

Nor is there anything to preclude me using the existing master
key/subkey structure to do this.

> Let me add, and no offence of course, from the fact that you 
> are relegating those short-lifetime signing sub keys to a 
> less secure environment, I infer that you have no confidence 
> in them,

Confidence is not a binary issue. I trust the environment they are used
in less; therefore I would give them a shorter lifetime, so that their
compromise would have a smaller impact.

Ian.

---

From: "Richard Laager" <[email-masked]>
Date: Mon, 16 Jun 2003 08:27:40 -0500

> by them for that matter?  You might as well not sign at all.

Less secure = less confidence != no confidence. Here's an example
(fictional, but this is what I would do if I could):

I store my long term primary key on a floppy. When I need the primary key
(to create a new subkey or to sign another key), I do that signing on a
secure stand-alone workstation. When I'm not using that floppy, I store the
key off-site in a safe-deposit box. The less secure subkeys are stored on a
laptop. Now, I believe my laptop is secure, but it's subject to theft. If
it's stolen, I can simply revoke that signing subkey. Now, what happens if
I leave for a lunch break and someone steals my signing subkey? If I notice
it, I can revoke the subkey. By having short-term subkeys, I can limit the
number of legitimate signatures that are invalidated by this. Also, if the
subkey expires in a week or month, the attacker will have to repeat the
subkey theft. This increases their chances of getting caught.

This is no worse than people who keep their primary key on said laptop and
use it for signing. It's quite obviously more secure.

Richard Laager

---

From: Derek Atkins <[email-masked]>
Date: 16 Jun 2003 09:31:26 -0400

> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA127BBD5

You clearly don't archive your encrypted email...

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Ian Brown <[email-masked]>
Date: Mon, 16 Jun 2003 14:38:25 +0100

> You clearly don't archive your encrypted email...

Indeed -- I decrypt messages before saving them (and use separate
storage encryption to protect the mail store.) Nor do I save every
message sent and received (which I know some people do).

---

From: Werner Koch <[email-masked]>
Date: Mon, 16 Jun 2003 15:58:40 +0200

> environment, I infer that you have no confidence in them, so how

There is a huge difference in chances to get compromised between a
networked and daily used box and a non-networked box somewhere else
used only for certification.  You can't remotely attack that
certification box as long as you take simple precautions like
transferring the data on a floppy etc.

All software has bugs and there are almost always known or not yet
known exploits.  Cutting the connection between a possible attacker by
manually transferring data is a sound precaution against most exploits
- it would be a bit annoying for the bulk of everydays work, though.

---

From: Derek Atkins <[email-masked]>
Date: 16 Jun 2003 10:21:57 -0400

> message sent and received (which I know some people do).

I've still got messages encrypted with PGP 2.0 sitting in my
mail storage.  The pgp encryption is better than any disk
encryption I could get -- especially considering that I dont
maintain my disk storage or backups myself. ;)

The wonders of "distributed computing"...

-derek

---

From: Adam Back <[email-masked]>
Date: Mon, 16 Jun 2003 16:12:35 +0100

The format of your mail storage encryption is an orthoganl issue.  (If
you prefer it there is nothing stopping you protecting your mailbox as
a whole, or mails within it with pgp formats).  Just decrypt with the
communications private key and re-encrypt with the storage public key,
or symmetric key (it is after all a message to your self where public
key is not necessarily needed).

In this way you have separated the key management of storage keys vs
communications keys vs signing keys.  Storage keys and signing keys it
is usually convenient to have long lived.  Encryption keys it is more
secure to have short lived.  (Think forward secrecy.)

The fact that your storage key is necesarrily long lived presents a
much leser risk: to make use of storage decryption keys, the attacker
first has to seize your machine (or in your case ask the university /
ISP for the encrypted mailbox).  Encrypted emails on the other hand
can be eavesdropped by the ISP, hackers and law-enforcement.  There
are many people who use their PGP keys only on systems they control.

There are at least 3 different ways to achieve storage encryption:
store the mailbox in an encrypted filesystem (convenient on linux,
windows etc); decrypt and re-encrypt (with a storage key) each mail as
you read it storing the modified re-encrypted mail back in the
mailbox; find or patch a mail client to automatically work from PGP
(or otherwise) storage key encrypted mail box.

If on the other hand you rely on message encryption to protect your
mail, you have to retain the corresponding private key esentially
indefinately which is a long term security risk.  Were the key you
have since 2.0 days compromised and someone were out to get you,
they'd get every mail you ever received since 91 or 92.  I'd argue
that this is a bad idea, but I guess it depends on your perceived
threats.  For me at least I intentionally revoked and deleted the
private key of my older key to achieve forward secrecy.  (First I had
to re-encrypt a few things encrypted with it).

Adam

---

From: "Imad R. Faiad" <[email-masked]>
Date: Mon, 16 Jun 2003 18:29:46 +0200

Dear Ian,

Now, this defeats the purpose of your "short-lifetime encryption
subkeys"!

You are assuming that law enforcers are inept morons!

This is a false sense of security.

Unless you can outsmart them, which very few can indeed,
never contemplate to circumvent the law by resorting
to such naive tricks.  The mere fact that they are being
discussed in a public forum such as this makes them useless.
I am sure that those authorized to seize Keys would
have been trained to spot all sorts of techniques that
a key holder will resort to in order to frustrate their effort.

Do yourself a favor, and don't ever use this technique
again, it is now public knowledge!

my 2c

Best Regards

Imad R. Faiad

---

From: "Imad R. Faiad" <[email-masked]>
Date: Mon, 16 Jun 2003 18:29:06 +0200

Dear Ian,

my 2c

Best Regards

Imad R. Faiad

---

From: Ian Brown <[email-masked]>
Date: Mon, 16 Jun 2003 17:12:57 +0100

> You are assuming that law enforcers are inept morons!

Nope. But if you no longer have a specific private key yourself, it
can't be seized no matter what rubber-hose cryptanalysis is applied.
Therefore any ciphertext that has previously been captured on-the-wire
cannot be decrypted.

Any message that you still have stored can be requisitioned. As I said,
I don't keep the majority of messages for any length of time.

>The mere fact that they are being discussed in a public forum 
>such as this makes them useless.

You obviously didn't read them carefully enough.

---

From: Werner Koch <[email-masked]>
Date: Mon, 16 Jun 2003 18:38:08 +0200

> You are assuming that law enforcers are inept morons!

It is a matter of the law and the loopholes it has.  IIRC, the British
RIP act does not allow to seize a computer but allow a police officer
to demand the decryption key for a message they have intercepted of
somehow else got access to.  There is even no need to pass them the
entire PGP key over including the passphrase, there must be simply a
mechanism to decrypt a message they "own".  This is also the reason
GnuPG provides the --{show,override}-session-key options.

> again, it is now public knowledge!

I am pretty sure that Ian - who is FIPR director and co-author of the
PFS draft - knows very well what is doing.

Salam-Shalom,

   Werner

---

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 17 Jun 2003 22:45:07 +0200

Hello Werner,

>PFS draft - knows very well what is doing.
I think you are need of some education, so I am going to take some
time to broaden your perspective...

Haven't you ever heard of the following:-

We are all sprung from the same stock, partakers of the same
nature, and sharers in the same hope;  and although distinctions
among men are necessary to preserve subordination, yet ought
no eminence of situation make us forget that we are all
in the same boat, for he who is placed on the lowest spoke of
fortune's wheel is equally entitled to our regards, as time
will come, and wisest of us knows not how soon, when all
distinctions, save those of goodness and virtue, shall cease,
and death, the grand leveler of all human greatness, reduce
us to the same state.

I do sincerely hope that you will be inspired by the above
and apply it forthwith ;)

Best regards

Imad R. Faiad

---

From: Len Sassaman <[email-masked]>
Date: Tue, 17 Jun 2003 16:20:57 -0700 (PDT)

> I think the proposed flag is a good idea.

Agreed.