Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt

From: [email-masked]
Date: Mon, 15 Jul 2013 16:11:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title           : Out-of-Band Public Key Validation for Transport Layer Security (TLS)
	Author(s)       : Paul Wouters
                          Hannes Tschofenig
                          John Gilmore
                          Samuel Weiler
                          Tero Kivinen
	Filename        : draft-ietf-tls-oob-pubkey-08.txt
	Pages           : 15
	Date            : 2013-07-15

Abstract:
   This document specifies a new certificate type and two TLS
   extensions, one for the client and one for the server, for exchanging
   raw public keys in Transport Layer Security (TLS) and Datagram
   Transport Layer Security (DTLS) for use with out-of-band public key
   validation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oob-pubkey-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Hauke Mehrtens <[email-masked]>
Date: Tue, 16 Jul 2013 13:50:39 +0200

> https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey

Thanks for the new draft.

I have some comments to this version:

In section 3. New TLS Extension the link to Section 2.3.5 of RFC 5480
is wrong, this should be just Section 2.

RFC 5480 defines a lot more OIDs which could be used as an algorithm OID
than listen in Figure 3. ECDSA defines a different OID for every
standardized curve. I think naming the OID in Figure 3 should be removed
and there should just be a pinter to the RFC. It should also be made
clear that there could be further RFC than RFC 3279, RFC3279 and RFC5480
defining OIDs used in the SubjectPublicKeyInfo, like RFCs defining a new
public key type.

Could you add some list definition where the numbers assigned by the
IANA should be added later. I like how it is done in
draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0].

Are there some intermediate version of this draft available, like a
public readable svn repository where the work on this draft is happening?

Hauke

[0]: https://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06#section-2

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Jul 2013 14:19:57 +0200

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Hauke, 

thanks for your quick review. 

> is wrong, this should be just Section 2.
You are unfortunately correct. Fixed it. 

> defining OIDs used in the SubjectPublicKeyInfo, like RFCs defining a new

You are right that (a) there may be more OIDs defined in the future and that (b) RFC 5480 defines more OIDs than the single one listed in the table. 
However, the table just lists examples to illustrate common cases for the reader. I could, however, add a sentence to point out that these are just examples and more OIDs exist. 

> draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0].

The above-mentioned draft uses a different registry but I guess you are asking for a snapshot of the current registry. 
For example, something like this: 

- - ------------------------------------------------------
Value 	Description 	          Reference 
 0	           X.509	                  [RFC6091]
 1	         OpenPGP	          [RFC6091]
 3             Raw Public Key    [This RFC]
 3-223	 Unassigned	
224-255	 Reserved for         [RFC6091] 
                Private Use	
- - ------------------------------------------------------

Is this correct? 

> public readable svn repository where the work on this draft is happening?

Yes; here is the git repository:
https://github.com/hannestschofenig/tschofenig-ids/tree/master/raw-public-keys

Ciao
Hannes

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJR591UAAoJEGhJURNOOiAtVEYIAIFfPz+HEK4lBLNSe/2l2EYS
0GPWUduNo8/GcU/uiVxWEpFmKG0gvgTstj6AT2ima3JAgoWfglOdAh1N3/RJCNsf
+1Tyh91SUGH40v6ctdfuKalzfb8DOcSBiZ3DRVLI4FiuSBXUFK6Ru5mpNTSELvgF
2rY8kDd/UUIlrRSIq9Zb1B88k6ElP5vxrtZV5x4OGZaD63UfitHMZpXCJqFDpNyb
8HTqxrHrJeNURh8HH7RDfkw4I/Hrkw1hMuMmADQoYCCEADBRDSRW6QFL2bVewjr2
EAlyHNrK4c1BosEzXhInIA/2WY4CUdd6/PwNa50p6md0dJxgZnZy7RG1kA73ny4=
=JH/F
- -----END PGP SIGNATURE-----

---

From: Hauke Mehrtens <[email-masked]>
Date: Sat, 20 Jul 2013 17:27:15 +0200

Hi Hannes,

On 07/18/2013 02:19 PM, Hannes Tschofenig wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
> 
> Hi Hauke,
> 
>> RFC 5480 defines a lot more OIDs which could be used as an
>> algorithm OID than listen in Figure 3. ECDSA defines a different
>> OID for every standardized curve. I think naming the OID in
>> Figure 3 should be removed and there should just be a pinter to
>> the RFC. It should also be made clear that there could be further
>> RFC than RFC 3279, RFC3279 and RFC5480 defining OIDs used in the
>> SubjectPublicKeyInfo, like RFCs defining a new public key type.
> 
> You are right that (a) there may be more OIDs defined in the future
> and that (b) RFC 5480 defines more OIDs than the single one listed
> in the table. However, the table just lists examples to illustrate
> common cases for the reader. I could, however, add a sentence to
> point out that these are just examples and more OIDs exist.

Thanks for adding the sentence that makes it clear.

> 
>> Could you add some list definition where the numbers assigned by
>> the IANA should be added later. I like how it is done in 
> The above-mentioned draft uses a different registry but I guess you
> are asking for a snapshot of the current registry. For example,
> something like this:
> 
> - ------------------------------------------------------ Value
> Description 	          Reference 0	           X.509
> [RFC6091] 1	         OpenPGP	          [RFC6091] 3             Raw
> Public Key    [This RFC] 3-223	 Unassigned 224-255	 Reserved for
> [RFC6091] Private Use -
> ------------------------------------------------------
> 
> Is this correct?

Isn't the final number in the end of the standardization process added
to the draft? I was just thinking about adding a placeholder for that
number in the draft. For the Certificate Type there is already the
excepted number added in the draft, but for the
server_certificate_type and client_certificate_type there is a
placeholder missing.

>> Are there some intermediate version of this draft available, like
>> a public readable svn repository where the work on this draft is
>> happening?
> 

Thanks
for the link.

Hauke

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Jul 2013 15:50:07 +0200

Hi Hauke, 

> server_certificate_type and client_certificate_type there is a
I have not added the current snapshot of the registry to the draft at the moment. 
I am not convinced I should do it since the (more accurate) data will in the end be in the IANA repository. 

Ciao
Hannes

---

From: Hauke Mehrtens <[email-masked]>
Date: Tue, 30 Jul 2013 21:35:14 +0200

On 07/30/2013 03:50 PM, Hannes Tschofenig wrote:
>>>> Could you add some list definition where the numbers assigned
>>>> by the IANA should be added later. I like how it is done in 
>>> The above-mentioned draft uses a different registry but I guess
>>> you are asking for a snapshot of the current registry. For
>>> example, something like this:
>>> 
>>> Description 	          Reference 0	           X.509 [RFC6091] 1
>>> OpenPGP	          [RFC6091] 3             Raw Public Key
>>> [This RFC] 3-223	 Unassigned 224-255	 Reserved for [RFC6091]
>>> Private Use - 
>> Isn't the final number in the end of the standardization process
>> added to the draft? I was just thinking about adding a
>> placeholder for that number in the draft. For the Certificate
>> Type there is already the excepted number added in the draft, but
>> for the server_certificate_type and client_certificate_type there
>> is a placeholder missing.
> 
> I have not added the current snapshot of the registry to the draft
> at the moment. I am not convinced I should do it since the (more
> accurate) data will in the end be in the IANA repository.
> 

Hi Hannes,

yes, I also think you should not add a number into the draft till it
is assigned by the IANA.

Now I get the meaning of this block:
   Value: 2
   Description: Raw Public Key
   Reference: [[THIS RFC]]

I was a little bit confused, but this is nice. ;-)

Could you also add such a block for the TLS extensions?

   Value: TBD
   Extension name: client_certificate_type
   Reference: [[THIS RFC]]

   Value: TBD
   Extension name: server_certificate_type
   Reference: [[THIS RFC]]

Hauke