Subject: [Russ Housley] Fwd: [TLS] Last Call: 'Using OpenPGP keys for TLS authentication' to Experimental RFC (draft-ietf-tls-openpgp-keys)

From: Derek Atkins <[email-masked]>
Date: Tue, 27 Jun 2006 09:21:33 -0400

Hey, all.

I'm forwarding this on from Russ, who specifically asked for
OpenPGP participants to review this document.  As this is an
IETF Last Call, everyone should try to take a little time to
make this this document fits into the 2440/2440bis model reasonably.

Comments can be sent to me, to Russ, to the TLS list, or to the
IETF list depending on how you feel.  Note that if you send it
to me, I assume you just want it anonymized and I'll forward
it on without your name attached.

Happy reading!

-derek

Subject: Fwd: [TLS] Last Call: 'Using OpenPGP keys for TLS authentication' to Experimental RFC (draft-ietf-tls-openpgp-keys)
From: Russ Housley <[email-masked]>
To: Derek Atkins <[email-masked]>
Date: Mon, 26 Jun 2006 13:40:22 -0400

Derek:

It would be good to have some OpenPGP participants review this document.

Russ

>To: IETF-Announce <[email-masked]>
>From: The IESG <[email-masked]>
>Date: Mon, 26 Jun 2006 11:50:44 -0400
>Cc: [email-masked]
>Subject: [TLS] Last Call: 'Using OpenPGP keys for TLS authentication' to
>  Experimental RFC (draft-ietf-tls-openpgp-keys)
>
>The IESG has received a request from the Transport Layer Security WG to
>consider the following document:
>
>- 'Using OpenPGP keys for TLS authentication '
>    <draft-ietf-tls-openpgp-keys-10.txt> as an Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2006-07-10.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-10.txt

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

---

From: Werner Koch <[email-masked]>
Date: Tue, 27 Jun 2006 16:17:18 +0200

Hi,

I can't comment on TLS specific things but here are a few minor
things:

   1.  Introduction

   [...]

   OpenPGP keys (sometimes called OpenPGP certificates), provide
   security services for electronic communications.  They are widely
   deployed, especially in electronic mail applications, provide public
   key authentication services, allow distributed key management and can
   be used with a non hierarchical trust model called the "web of trust"
   [WOT].

Because OpenPGP does not define any trust model, a wording like

... and allows the use in non hierarchical trust models, for
example the "Web of Trust"[WOT].

seems to better to me.

   [...]

   2.3.  Server Certificate

   [...]

      DHE_RSA                 RSA public key which can be used for
                              signing.

Shouldn't this say: "RSA public key which can be used for
authentication"?  Recall that OpenPGP features a key flag to indicate
an authentication key (0x20).

   [...]

   3.  Security Considerations

   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
   parsers.  Care must be taken to make those parsers safe against
   maliciously modified keys, that could cause arbitrary code execution.

That is superfluous as this is (or well, should) be standard
programming practise.  It is in no way special to TLS or OpenPGP.

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Tue, 27 Jun 2006 09:02:03 -0700

> example the "Web of Trust"[WOT].

The important thing is that trust models are not part of OpenPGP.

I think it should also say, "OpenPGP certificates (often called  
OpenPGP keys), ..." for reasons I'll state more fully after my  
comments on Werner's comments.

> an authentication key (0x20).

Yes, it should.

> programming practise.  It is in no way special to TLS or OpenPGP.

I concur. It might as well have another paragraph as well that says:

     This RFC specifies the use of data. Improper use of data can cause
     arbitrary code execution. Care must be taken to prevent this.

I think that paragraph can go.

----------

There is one other issue that I think should be cleaned up. It  
concerns the use of the words, "key" and "certificate." The term "PGP  
Key" was invented by Whit Diffie, and has a number of desirable  
characteristics. It's one syllable, it's an easy word to say.  
However, "PGP Keys" are in fact certificates that contain at least  
one key and at least one certification.

In RFC2440 and beyond, we have used the colloquial term "key" but I  
think in this document the more precise term "certificate" is called  
for. Strictly speaking, the objects that TLS is using in this draft  
is a PGP Certificate with a Public Key Packet (tag 6) or Public  
Subkey Packet (tag 14) that is enabled for authentication implicitly  
or explicitly.

This is why a little bit of over-precision is called for. I might  
present you with a single-key OpenPGP certificate that is enabled for  
authentication with a key flags subpacket. But I might also present  
you with an OpenPGP certificate that has a subkey with no key flags,  
which would also be reasonable.

So I recommend changing "OpenPGP key" or "OpenPGP public key" to  
"OpenPGP certificate" throughout the document. It might be good to  
point out the fact that it can be a subkey. Minimally, one could  
change the text in 2.3:

    An OpenPGP public key appearing in the Certificate message will be
    sent using the binary OpenPGP format.  The term public key is  
used to
    describe a composition of OpenPGP packets to form a block of data
    which contains all information needed by the peer.  This includes
    public key packets, user ID packets and all the fields described in
    section 10.1 of [OpenPGP].

to

    An OpenPGP certificate appearing in the Certificate message will
    be sent using the binary OpenPGP format.  The term certificate is
    used to describe a composition of OpenPGP packets to form a block
    of data which contains all information needed by the peer.  This
    includes public key packets, subkey packets, user ID packets and
    all the fields described in section 10.1 of [OpenPGP].

That would work just fine and would preserve the virtue of terseness  
that the present draft has.

	Jon