Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06

From: Sean Turner <[email-masked]>
Date: Mon, 17 Dec 2012 12:07:01 -0500

On 11/6/12 10:55 AM, Paul Wouters wrote:
> On Tue, 6 Nov 2012, Peter Sylvester wrote:
>
>> - What does is the problem to make the definitions compatible
>>  i.e. define a value for pgp?
>
> I believe the problem was that 6091 was not a standards track document.

Yep that's it.

>> - Besides that, a public key is not exactly a "certificate" type?
>
> It is how the TLS WG preferred the raw public key format to be
> supported.

I actually asked around if others really cared about this.  There was 
some grumbling but it didn't rise to the level of this is so broken 
please define a new extension type or I'd put a discuss on about this.

spt

>> - How would one add a sunrise hash chain as a new certificate type?
>
> One would not. If the rae public key certificate format does not satisfy
> your needs, use the existing PKIX certificate, or create a new
> certificate type?
>
> Paul
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 17 Dec 2012 23:01:42 +0200

>> I believe the problem was that 6091 was not a standards track document.

I don't understand how this can be a reason to have a deliberate
incompatibility with its certificate type registry. If 6091 isn't
standards track the new standards track can adopt the registry and
augment it (unless there is a technical reason for not to --which
isn't the case).

As I mention in
http://www.ietf.org/mail-archive/web/tls/current/msg09093.html it is
very easy to re-use the previous certificate type
definitions/registry. In fact this would simplify the current raw
pubkey draft, by (a) not using the accept/offer negotiation which
requires different interpretation of certificate types depending on
whether a client or server is reading a message (a foreign negotiation
to TLS), and (b) there is no need for a new registry.

regards,
Nikos

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 Dec 2012 21:23:55 +0000

Hi Sean,

I don't think the document would need to reference 6091, it would just need to reference the named registry.  Is there a problem with a standards track RFC reference a registry established by an informational document? According to the IANA assignment rules in 6091  a new RFC could update the registry with new values. 

Thanks,

Joe

---

From: Sean Turner <[email-masked]>
Date: Mon, 17 Dec 2012 16:28:39 -0500

Joe,

I can think problem to a standards track document assigning values i to 
a registry created by a non-standards track document.

spt

---

From: Sean Turner <[email-masked]>
Date: Mon, 17 Dec 2012 16:33:13 -0500

Trying once again...

I can't think of a problem for a standards track document assigning 
values in a registry created by a non-standards track document.

spt

On 12/17/12 4:28 PM, Sean Turner wrote:
>> I don't think the document would need to reference 6091, it would just
>> need to reference the named registry.  Is there a problem with a
>> standards track RFC reference a registry established by an
>> informational document? According to the IANA assignment rules in
>> 6091  a new RFC could update the registry with new values.
>>
>> Thanks,
>>
>> Joe
>>
>>