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

Joe,

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

spt

On 12/17/12 4:23 PM, Joseph Salowey (jsalowey) wrote:
> 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
>
>
> On Dec 17, 2012, at 1:01 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
>   wrote:
>
>> On Mon, Dec 17, 2012 at 7:07 PM, Sean Turner <turners@ieca.com> 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.
>>
>> 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
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>