Subject: Re: [KEYPROV] FW: New Version Notificationfor draft-ietf-keyprov-pskc-06

From: <[email-masked]>
Date: Tue, 1 Jun 2010 17:01:22 -0400

Here's how I propose to address Version Number increment in DSKPP (see
last 2 paragraphs):

1st - rename Section 1.2 from "Versions" to "Version Support"

2nd - Add the last two paragraphs to the end of the current section:

   The numbering scheme for DSKPP versions is
   "<major>.<minor>".  The major and minor numbers MUST be treated as
   separate integers and each number MAY be incremented higher than a
   single digit.  Thus, "DSKPP 2.4" would be a lower version than "DSKPP
   2.13", which in turn would be lower than "DSKPP 12.3".  Leading zeros
   (e.g., "DSKPP 6.01") MUST be ignored by recipients and MUST NOT be
   sent.

   The major version number should be incremented only if the message 
   formats or flows have changed so dramatically that
   an older version implementation would not be able to interoperate
with a
   newer version.  The minor version number indicates new capabilities,
   and MUST be ignored by an entity with a smaller minor version number,
   but used for informational purposes by the entity with the larger
   minor version number."

Note that I took this from a portion of RFC3920, Section 4.4.1.

We will have to make sure this and what is in Section 1.2 of PSKC are
aligned.  I haven't yet run the above text by Peter --- am preparing a
response to him now. 

Thoughts on the above text?

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sean Turner
Sent: Tuesday, May 18, 2010 9:49 AM
To: Philip Hoyer
Cc: [email-masked]; KEYPROV
Subject: Re: [KEYPROV] FW: New Version Notificationfor
draft-ietf-keyprov-pskc-06

Philip,

I cut out the ones I think we're square on.  Note that sending an 
email to those authors you're waiting on will probably pop it to the 
top of their stack.

Additional thoughts below with [spt].

Andrea,

There's one DSKPP/PSKC alignment issue.

Philip Hoyer wrote:
>> *	Pete SaintAndre comments (MOST) TODO and discuss:
>> o	Globally unique KeyId
> 
> Do we really need a globally unique KeyId? The examples in the 
> document definitely don't use one.  If we do, then I'd suggest we 
> generate the keyId using a hash algorithm and be done with it.
> [PH] I believe this is one item that warrants wider discussion. Do you
> know what they have done in KMIP? 

[spt]  I took this text from KMIP.  It's out for public comment:

Unique Identifier

The Unique Identifier is generated by the key management system to 
uniquely identify a Managed Object. It is only REQUIRED to be unique 
within the identifier space managed by a single key management system, 
however it is RECOMMENDED that this identifier be globally unique in 
order to allow for a key management domain export of such objects. 
This attribute SHALL be assigned by the key management system at 
creation or registration time, and then SHALL NOT be changed or 
deleted before the object is destroyed.

If we want to be globally unique then we're going to need to use 
something provides a reasonable distribution.  We could follow the 
PKIX lead and pick a couple of fields to hash (possibly truncating it).

>> o	Version number increment (needs alignment with DSKPP I think)

Andrea - any thoughts here?

>> o	Normative reference to TLS?
> 
> [PH] changed the text but could you point me at the right references
for
> TLS and IPsec?

[spt] sent in another email.

>> o	Definition of PIN algorithm
> 
> I think we're probably going to have to add it here.  Otherwise, we're

> going to have to wait for a new draft and that'll take forever.
> 
> [PH] what should we say here.
> It is a PIN in ASCII (1 byte per character) and a straight octet
> comparison? Or should we support UTF-8? What is your feeling?

The minute you use ASCII they're going to be all over you about 
character set support.  Because we've already got to do UTF-8 for 
other things - we should probably just go with that.
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: Sean Turner <[email-masked]>
Date: Wed, 02 Jun 2010 14:49:15 -0400

> Thoughts on the above text?

Sounds good to me.

spt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Jun 2010 13:04:59 -0600

>> Thoughts on the above text?

Works for me as well. Content reuse. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 16:09:38 -0400

Philip Hoyer wrote:

> #1) You're pointing to the List of OATH Manufacturer Prefixes.  There 
> are two columns in that list: prefixes and the manufacturer name. 
> It's not entirely clear which column the values should be taken from. 
>   It's either:
> 
> Values for Manufacturer SHOULD be taken from [OATHMAN] prefixes (i.e., 
> the left column).
> 
> [PH] adopted prefixes

Can anyone in OATH confirm that this list is open?  I.e., say I'd like 
a prefix do I have to pay money to get it added to the list?  And, how 
stable is the URL (I assume it as stable as OATH is, but I have to ask)?

spt

---

From: "Bajaj, Siddharth" <[email-masked]>
Date: Thu, 10 Jun 2010 17:36:00 -0700

Hi Sean, 

Don't know if anybody responded to your email. The OATH list is open to
both OATH members and non-members. You can find details about the Token
ID spec and list at - 

http://www.openauthentication.org/oath-id
http://www.openauthentication.org/oath-id/register/

There is a nominal one-time fee to register your prefix on the list. 

This is in-line with other programs such as IEEE OUI prefix
registration- 
https://standards.ieee.org/regauth/OUI36/OUI36.html

The intention is to maintain the URL below forever, but your observation
below is accurate. 

Hope that helps,

Siddharth
Chair, JCC, OATH. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sean Turner
Sent: Tuesday, June 08, 2010 1:10 PM
To: [email-masked]
Cc: KEYPROV
Subject: Re: [KEYPROV] FW: New Version Notificationfor
draft-ietf-keyprov-pskc-06

spt