Subject: [TLS] draft-ietf-tls-oob-pubkey: Next Steps?

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 21 Dec 2012 16:15:41 +0100

Hi all, 

I am looking for some guidance regarding the next steps for draft-ietf-tls-oob-pubkey. 

I would like to hear your views regarding the following two items:

 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? 

 2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the registry or leave that to another document?

Ciao
Hannes

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 21 Dec 2012 15:53:27 +0000

> 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? 

[Joe]  I'm leaning towards using the existing registry.  I'm not sure what you mean by changing the semantics of the registry, can you clarify?  

> 2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the registry or leave that to another document?

[Joe] I we are defining a new registry I believe this should be done in a different document. 

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 21 Dec 2012 18:39:14 +0100

Hi Joe, 

thanks for your quick response. 

[Hannes] IMHO re-using the registry means to create a normative reference to RFC 6091/, i.e., a downref. Is that OK for you?

If we go for the current document, namely http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06, we have to populate the registry with the following values:

          X.509-Accept (a),
          X.509-Offer (b),
          RawPublicKey-Accept (c),
          RawPublicKey-Offer (d),

If we instead use two TLS extensions (namely cert-receive & cert-send as described in http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 or client_certificate_type & server_certificate_type as suggested by Nikos in http://www.ietf.org/mail-archive/web/tls/current/msg09093.html to carry the values) then we can go down to two values:

          X.509(a)
          RawPublicKey(b)

In either case it remains to be studied what this means for an update to RFC 6091.

Ciao
Hannes

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 21 Dec 2012 17:54:35 +0000

> [Hannes] IMHO re-using the registry means to create a normative reference to RFC 6091/, i.e., a downref. Is that OK for you?

[Joe] We're trying to avoid that, but at the same time we need to do something reasonable.  I'm not convinced that just reusing a registry means we must reference RFC 6091.  

> If we instead use two TLS extensions (namely cert-receive & cert-send as described in http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 or client_certificate_type & server_certificate_type as…

[Joe] So if were were going to reuse the same registry then I think we would want to use the second approach.   It doesn't seem like it would be fruitful to use the same registry and then register all new types.  

I think I'd summarize the two approaches as 

1) Define a new registry as in -06,  It would be up to a new document to define values and specific behavior for openpgp.

2) Use the existing registry, add new raw-key entry and go with the -04 or Nikos' suggestion.  A new (possibly very short) document can define how the new extension applies to openpgp.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 Dec 2012 10:43:29 +0100

"Joseph Salowey (jsalowey)" <[email-masked]> writes:

>>> 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the
>>> cert_type registry created by RFC 6091 or create a new registry?
>>> 
>> 
>> [Joe] I'm leaning towards using the existing registry.  I'm not sure
>> what you mean by changing the semantics of the registry, can you
>> clarify?
>> 
>> [Hannes] IMHO re-using the registry means to create a normative
>> reference to RFC 6091/, i.e., a downref. Is that OK for you?
>> 
>
> [Joe] We're trying to avoid that, but at the same time we need to do
> something reasonable.  I'm not convinced that just reusing a registry
> means we must reference RFC 6091.

RFC 6091 defines structures that is needed for implementing anything
that relies on those structures, so it has to be referenced.

I prefer to re-use existing work and thus to reference RFC 6091.  To
resolve the downref issue, I suggest to move RFC 6091 to Standards
Track.

/Simon

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 23 Dec 2012 17:36:33 +0000

Sent from my iPad

> that relies on those structures, so it has to be referenced.
[Joe] RFC 6091 structures and semantics do not meet the working group requirements for asymmetric use of certificate types.  The proposal is to use the 6091 defined registry for certificate type enumeration only.  If we can't use the registry without referencing the semantics and structures then I think a new registry is needed.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 23 Dec 2012 16:28:50 -0500

>  1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? 

I lean toward using the existing cert_type registry.

>  2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the registry or leave that to another document?

Use the existing registry, simplify the tls-oob-draft to use separate
offer- and accept-certtypes (as suggested by Nikos), and proceed from
there.  This would automatically include the OpenPGP certificate types
for those who want to use them.

	--dkg