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

[Jon Callas <[e-mail]>]

On 27 Jun 2006, at 7:17 AM, Werner Koch wrote:

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

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.

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

Yes, it should.

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

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