Subject: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt

From: Joe Salowey <[email-masked]>
Date: Wed, 25 Apr 2012 17:35:55 -0700

This is an announcement of working group last call for draft-ietf-tls-oob-pubkey-03.txt.  Please complete reviews and send comments to the TLS list by Friday May 18, 2012.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Apr 2012 10:22:53 +0200

I generally support the idea behind this document, and the document
looks in reasonable good shape.  Please find my review comments below.

Major concerns:

1) Section 3.1 and 3.2 more or less duplicate section 3.1 and 3.2 of RFC
6091.  Wouldn't it be better to describe the RawPublicKey
CertificateType alone, rather than duplicating the entire
CertificateType extension?  There is a risk that this document says
something different than RFC 6091, which ought to be the canonical place
for the definition of the "cert_type" extension.  If this document moves
forward, we'll effectively have two specifications of the "cert_type"
extension.  The IANA registry points at RFC 6091.  This seems bad from a
standards process point of view.  My suggestion is to normatively
reference RFC 60961 (and call out that in the LC announcement) and
specify the RawPublicKey "cert_type" extension only.

2) The "Security Considerations" says that the main challenge with raw
public keys over keys in X.509/OpenPGP is how to associate the public
key with a specific entity.  However, I believe the problem is larger
than that, and there is a similar challenge for several other forms of
metadata about a public key.  It is not only the identity of a key that
can have significant impact on system security.  Other kind of metadata
(for example "do not use this public key after the year 2015") can be
critical for secure deployments.  I suggest to add a final paragraph to
discuss this.

Minor concerns:

1)
   Currently, TLS authentication can only occur via X.509-based Public
   Key Infrastructure (PKI) or OpenPGP certificates.  By specifying a

Replace 'TLS authentication' with 'TLS public-key authentication', as
TLS supports several non-X509/OpenPGP forms of authentication.

2)
   One such alternative public key valiation method is offered by the
                                       ^

typo

3)
   The support for raw public keys is introduced into TLS via a new non-
   PKIX certificate type.

I suggest to drop 'non-PKIX'.  It is non-OpenPGP too, but neither is
relevant.  The document define a new certificate type, period.

4)
   to-server communication.  As part of the manufacturing process, the
   embeded device may be configured with the address and the public key
   of a dedicated CoAP server, as well as a public key for the client
                                            ^^^^^^^^^^
   itself.  The usage of X.509-based PKIX certificates [PKIX] may not

Shouldn't that be 'private key'?  Or at least 'public and private key'.

5)
Section 3:
   the certificate payloads only contain the SubjectPublicKeyInfo

There should be a reference to [PKIX] here, since SubjectPublicKeyInfo
is defined there and it is important to be able to find that definition.

/Simon

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Apr 2012 13:57:44 -0400 (EDT)

On Thu, 26 Apr 2012, Simon Josefsson wrote:

> CertificateType extension?

I think you are right. This was originally done because it started as
a new TLS extension, and then also covered what has now been moved to
cached-objects.

> critical for secure deployments.  I suggest to add a final paragraph to

Sounds reasonable. Will do.

> Minor concerns:

All fixed as per your suggestions.

Paul