Subject: [KEYPROV] Latest version of PSKC draft

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 14 Jun 2010 16:31:33 +0200

Ladies and Gentlemen,

Please find attached the latest version of the PSKC draft.

-         Added the Suite element under AlgorithmParameter: (please note
that this is a schema change but it is an optional additional element so
old messages will work)

"

<Suite>:

      The optional <Suite> element defines additional characteristics of

      the algorithm used, which are algorithm specific.  For example in

      HMAC based OTP algorithm it could designate the strength of the

      hash algorithm used (SHA1, SHA256, etc).  Please refer to

      algorithm profile specification Section 10 for the exact semantic

      of the value for each algorithm profile.

"

-         Changed the algorithm URNs to use ':' instead of '#' (Please
note that this makes ALL current implementations incompatible)

-         Added the PIN comparison algorithm definition

"

5.1.  PIN Algorithm definition

   The PIN algorithm is defined as:

   boolean = comparePIN(K,P)

   Where:

   'K':  Is the stored symmetric credential (PIN) in binary format.

   'P':  Is the proposed PIN to be compared in binary format.

   The function comparePIN is a straight octet comparison of K and P.

   Such comparison MUST yield TRUE (credentials matched) when the the

   octet length of K is the same as the octet length of P and all octets

   comprising K are the same as the octets comprising P.

"

Outstanding

-         The major outstanding discussion item is the KeyId

-         Ming you need to add the container URN registration necessary
for DSKPP otherwise the following has been addressed:

Official COMMENT and DISCUSS items addressed:

Russ Housley's comment 2010-05-06 has already been corrected in -06

Alexey Melnikov:

2) Changed for version 7 to be either coming from OATH manufacturer
prefix or IANA Private Enterprise Number registry.

"

<Manufacturer>:  This element indicates the manufacturer of the

      device.  Values for Manufacturer SHOULD be taken from either

      [OATHMAN] prefixes (i.e., the left column) or they SHOULD be taken

      from IANA Private Enterprise Number Registry [IANAPENREG], using

      the Organisation value.

"

4) Changed for version 7 to "Specification Required" for both section
12.4 and 12.6

6) Changed in version 7 to have a xml:lang attribute:

"

   <FriendlyName>:  A human readable name for the secret key for easier

      reference.  This element serves informational purposes only.  This

      element is a language dependent string hence it SHOULD have an

      attribute xml:lang="xx" where xx is the language identifier as

      specified in [RFC4646] .  If no xml:lang attribute is present

      implementations MUST assume the language to be English as defined

      by setting the attribute value to "en" (e.g. xml:lang="en").

"

Comment: 

13.1  This was already addressed in version -06

Peter Saint-Andre

2) Key Id

3) I believe this has been addressed as the description states:

"

      <Time>:  This element contains the time for time based OTP

         algorithms.  (If time interval is used, this element carries

         the number of time intervals passed from a specific start

         point, normally algorithm dependent).

"

6)       Added new test in section 1.2 changed title from Version to
Version Support::

"

   There is a provision made in the syntax for an explicit version

   number.  Only version "1.0" is currently specified.

   The numbering scheme for PSKC 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, "PSKC

   2.4" would be a lower version than "PSKC 2.13", which in turn would

   be lower than "PSKC 12.3".  Leading zeros (e.g., "PSKC 6.01") MUST be

   ignored by recipients and MUST NOT be sent.

   The major version number should be incremented only if the message

   format (E.g.  Element structure) has 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.

"

9) Addressed in version -07

"

   The second approach to protecting the confidentiality of the key data

   is based on using lower layer security mechanisms (e.g., [TLS],

   [IPSec]).  The secure connection established between the source

   secure perimeter (the provisioning server from the example above) and

   the target perimeter (the device attached to the end-user computer)

   utilizes encryption to protect the messages that travel across that

   connection.  No key data payload encryption is required in this mode.

   Secure connections that encrypt and digest each message provide an

   extra measure of security.

"

 

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

Telephone: +44 (0) 20 7960 0220

Fax: +44 (0) 20 7902 1985

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended
recipient,

you must not copy, distribute, discuss or take any action in reliance on
it.

If you have received this communication in error, please notify the
sender

and delete this message immediately.

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 14 Jun 2010 09:40:32 -0700

Hi Philip,
 
Thanks for the work. I will add the keycontainer URN registration on top
of this version.
 
- Ming

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Monday, June 14, 2010 7:32 AM
	To: Pei, Mingliang; Sean Turner; Tschofenig, Hannes (NSN -
FI/Espoo); Phillip Hallam-Baker; Salah Machani; [email-masked]
	Cc: KEYPROV
	Subject: Latest version of PSKC draft

	Ladies and Gentlemen,

	 

	-         Added the Suite element under AlgorithmParameter:
(please note that this is a schema change but it is an optional
additional element so old messages will work)

	"

	<Suite>:

	      The optional <Suite> element defines additional
characteristics of

	      the algorithm used, which are algorithm specific.  For
example in

	      HMAC based OTP algorithm it could designate the strength
of the

	      algorithm profile specification Section 10 for the exact
semantic

	"

	-         Changed the algorithm URNs to use ':' instead of '#'
(Please note that this makes ALL current implementations incompatible)

	"

	   Where:

	   'K':  Is the stored symmetric credential (PIN) in binary
format.

	   The function comparePIN is a straight octet comparison of K
and P.

	   Such comparison MUST yield TRUE (credentials matched) when
the the

	   octet length of K is the same as the octet length of P and
all octets

	"

	Outstanding

	-         Ming you need to add the container URN registration
necessary for DSKPP otherwise the following has been addressed:

	Russ Housley's comment 2010-05-06 has already been corrected in
-06

	Alexey Melnikov:

	2) Changed for version 7 to be either coming from OATH
manufacturer prefix or IANA Private Enterprise Number registry.

	"

	      device.  Values for Manufacturer SHOULD be taken from
either

	      [OATHMAN] prefixes (i.e., the left column) or they SHOULD
be taken

	      from IANA Private Enterprise Number Registry [IANAPENREG],
using

	      the Organisation value.

	"

	4) Changed for version 7 to "Specification Required" for both
section 12.4 and 12.6

	"

	   <FriendlyName>:  A human readable name for the secret key for
easier

	      reference.  This element serves informational purposes
only.  This

	      element is a language dependent string hence it SHOULD
have an

	      attribute xml:lang="xx" where xx is the language
identifier as

	      specified in [RFC4646] .  If no xml:lang attribute is
present

	      implementations MUST assume the language to be English as
defined

	      by setting the attribute value to "en" (e.g.
xml:lang="en").

	"

	Comment: 

	Peter Saint-Andre

	2) Key Id

	"

	         algorithms.  (If time interval is used, this element
carries

	         the number of time intervals passed from a specific
start

	"

	6)       Added new test in section 1.2 changed title from
Version to Version Support::

	"

	   There is a provision made in the syntax for an explicit
version

	   The numbering scheme for PSKC 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,
"PSKC

	   2.4" would be a lower version than "PSKC 2.13", which in turn
would

	   be lower than "PSKC 12.3".  Leading zeros (e.g., "PSKC 6.01")
MUST be

	   The major version number should be incremented only if the
message

	   format (E.g.  Element structure) has 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.

	"

	"

	   The second approach to protecting the confidentiality of the
key data

	   is based on using lower layer security mechanisms (e.g.,
[TLS],

	   [IPSec]).  The secure connection established between the
source

	   secure perimeter (the provisioning server from the example
above) and

	   the target perimeter (the device attached to the end-user
computer)

	   utilizes encryption to protect the messages that travel
across that

	   connection.  No key data payload encryption is required in
this mode.

	   Secure connections that encrypt and digest each message
provide an

	"

	 

	Philip Hoyer 

	ActivIdentity (UK)

	117 Waterloo Road

	London SE1 8UL

	Private and confidential: This message and any attachments may
contain

	privileged / confidential information. If you are not an
intended recipient,

	you must not copy, distribute, discuss or take any action in
reliance on it.

	If you have received this communication in error, please notify
the sender

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 13:14:34 -0400

Philip,

Thanks!

I received a response from Peter Saint-Andre regarding Section 1.2 on
Version Support, which matches the same information in your most
recently submitted PSKC draft.  He said:

"Do you envision needing minor version numbers in DSKPP? If not, you

could simplify the text a bit here. Also it might not make sense to have

text about message flows in DSKPP (that might be appropriate for XMPP

but not DSKPP). Perhaps for you something like this is better: "only if

the data formats or security algorithms"..."

As such, I propose to simplify the DSKPP text as follows:

   The numbering scheme for DSKPP versions is "<version number>.0". The 

   version number should be incremented only if the data formats or
security 

   algorithms have changed so dramatically that an older version
implementation 

   would not be able to interoperate with a newer version. Each version
number 

   MAY be incremented higher than a single digit.  Thus, "DSKPP 2.0"
would be a 

   lower version than "DSKPP 12.0".  Leading zeros (e.g., "DSKPP 06.0")
MUST be 

   ignored by recipients and MUST NOT be sent. Numbers after the decimal
place 

   that are not set to zero (e.g., "DSKPP 2.4") MUST be ignored by
recipients 

   and MUST NOT be sent.

Do you have any comments on the text and/or find it acceptable?

Andrea

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Monday, June 14, 2010 10:32 AM
To: Pei, Mingliang; Sean Turner; Tschofenig, Hannes (NSN - FI/Espoo);
Phillip Hallam-Baker; Salah Machani; Doherty, Andrea
Cc: KEYPROV
Subject: Latest version of PSKC draft

Ladies and Gentlemen,

 

"

<Suite>:

"

"

   Where:

"

Outstanding

 

Alexey Melnikov:

"

      the Organisation value.

"

"

"

Comment: 

Peter Saint-Andre

2) Key Id

"

"

"

   minor version number.

"

"

"

 

Philip Hoyer 

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

---

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 15 Jun 2010 19:08:57 +0200

Andrea,

I believe we need to consider this together with the question around
algorithm agility.

I remember from the discussion w Peter that new algorithm support
MANDATES a new verision.

Is this not the perfect case where a minor version change would happen?

Philip

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 14, 2010 6:15 PM
To: Philip Hoyer; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Latest version of PSKC draft

Philip,

Thanks!

   and MUST NOT be sent.

Andrea

Ladies and Gentlemen,

 

"

<Suite>:

"

"

   Where:

"

Outstanding

 

Alexey Melnikov:

"

      the Organisation value.

"

"

"

Comment: 

Peter Saint-Andre

2) Key Id

"

"

"

   minor version number.

"

"

"

 

Philip Hoyer 

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

---

From: <[email-masked]>
Date: Tue, 15 Jun 2010 13:37:13 -0400

Precisely, the issue...how does one define "perfect".  By only allowing
major version, different interpretations of what constitutes a major and
minor version increment will not create interop problems.  Note that the
XMPP RFC identifies algorithm changes as cause for major version
increment.  My thought is to keep this simple, as I don't anticipate
that we will see many version updates, esp. of a minor nature. 

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 1:09 PM
To: Doherty, Andrea; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Latest version of PSKC draft

Andrea,

Philip

Philip,

Thanks!

   and MUST NOT be sent.

Andrea

Ladies and Gentlemen,

 

"

<Suite>:

"

"

   Where:

"

Outstanding

 

Alexey Melnikov:

"

      the Organisation value.

"

"

"

Comment: 

Peter Saint-Andre

2) Key Id

"

"

"

   minor version number.

"

"

"

 

Philip Hoyer 

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

---

From: Sean Turner <[email-masked]>
Date: Tue, 15 Jun 2010 13:48:08 -0400

I sure hope we don't see a lot of versions.

spt

[email-masked] wrote:
> Precisely, the issue…how does one define “perfect”.  By only allowing 
> increment.  My thought is to keep this simple, as I don’t anticipate 
> *From:* Philip Hoyer [mailto:[email-masked]]
> *Sent:* Tuesday, June 15, 2010 1:09 PM
> *To:* Doherty, Andrea; [email-masked]; [email-masked]; 
> *Cc:* [email-masked]
> *Subject:* RE: Latest version of PSKC draft
> 
>  
> 
> Andrea,
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Monday, June 14, 2010 6:15 PM
> *To:* Philip Hoyer; [email-masked]; [email-masked]; 
> *Cc:* [email-masked]
> *Subject:* RE: Latest version of PSKC draft
> 
>  
> 
> Philip,
> 
>  
> 
> Thanks!
> 
>  
> 
> “Do you envision needing minor version numbers in DSKPP? If not, you
> 
> the data formats or security algorithms"...”
> 
>  
> 
>    The numbering scheme for DSKPP versions is “<version number>.0”. The
> 
>    that are not set to zero (e.g., “DSKPP 2.4”) MUST be ignored by 
> recipients
> 
>    and MUST NOT be sent.
> 
>  
> 
> *From:* Philip Hoyer [mailto:[email-masked]]
> *Sent:* Monday, June 14, 2010 10:32 AM
> *To:* Pei, Mingliang; Sean Turner; Tschofenig, Hannes (NSN - FI/Espoo); 
> *Cc:* KEYPROV
> *Subject:* Latest version of PSKC draft
> 
>  
> 
> Ladies and Gentlemen,
> 
>  
> 
> –         Added the Suite element under AlgorithmParameter: (please note 
> “
> “
> –         Changed the algorithm URNs to use ‘:’ instead of ‘#’ (*Please 
> note that this makes ALL current implementations incompatible)*
> 
> –         Added the PIN comparison algorithm definition
> 
> “
> 
> ”
> *Outstanding*
> –         The major outstanding discussion item is the KeyId
> 
> –         Ming you need to add the container URN registration necessary 
> *Official COMMENT and DISCUSS items addressed:*
> 
>  
> 
> *Russ Housley*’s comment 2010-05-06 has already been corrected in -06
> 
>  
> 
> *Alexey Melnikov*:
> 
>  
> 
> “
> “
> 4) Changed for version 7 to “Specification Required” for both section 
> 12.4 and 12.6
> 
>  
> 
> “
> “
> *Peter Saint-Andre*
> “
> “
> “
> “
> “
> “
> privileged / confidential information. If you are not an intended recipient,
> 
> you must not copy, distribute, discuss or take any action in reliance on it.
> 
> If you have received this communication in error, please notify the sender
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Jun 2010 17:13:57 -0400

Introducing a new algorithm option should be a minor version number change.

Removing support for a previously mandatory to implement algorithm now
found to be insecure would be a major version number change.

Remember that adding algorithms does not improve security, only
stopping using broken algorithms actually improves security.

On Tue, Jun 15, 2010 at 1:08 PM, Philip Hoyer <[email-masked]> wrote:
> I remember from the discussion w Peter that new algorithm support MANDATES a
> new verision.
>
>
>
> Version Support, which matches the same information in your most recently
> submitted PSKC draft.  He said:
>
>    version number should be incremented only if the data formats or security
>
>    MAY be incremented higher than a single digit.  Thus, "DSKPP 2.0" would
> be a
>
>    lower version than "DSKPP 12.0".  Leading zeros (e.g., "DSKPP 06.0") MUST
> be
>
> that this is a schema change but it is an optional additional element so old
> messages will work)
>
>
>
> “
>
> <Suite>:
>
>
>
> –         Changed the algorithm URNs to use ‘:’ instead of ‘#’ (Please note
> that this makes ALL current implementations incompatible)
>
> –         Ming you need to add the container URN registration necessary for
> DSKPP otherwise the following has been addressed:
>
>
>
>
>
> Russ Housley’s comment 2010-05-06 has already been corrected in -06
>
>
>
> Alexey Melnikov:
>
>
>
> 2) Changed for version 7 to be either coming from OATH manufacturer prefix
> or IANA Private Enterprise Number registry.
>
> “
>
> 4) Changed for version 7 to “Specification Required” for both section 12.4
> and 12.6
>
>
>
> 6)       Added new test in section 1.2 changed title from Version to Version
> Support::
>
> “
>

-- 
Website: http://hallambaker.com/

---

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 15 Jun 2010 15:57:23 -0700

I like the text update that makes version check clearer (ignore leading 0 etc.) but would like to keep minor version. Despite we may not expect many version changes, does it hurt to keep the flexibility? We can make a call later whether it is a minor or major depending on scope of change.

- Ming 

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:[email-masked]] 
> Sent: Tuesday, June 15, 2010 2:14 PM
> To: Philip Hoyer
> Cc: [email-masked]; Pei, Mingliang; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Latest version of PSKC draft
> 
> Removing support for a previously mandatory to implement 
> algorithm now found to be insecure would be a major version 
> number change.
> 
> 
> Remember that adding algorithms does not improve security, 
> only stopping using broken algorithms actually improves security.
> 
> > but not DSKPP). Perhaps for you something like this is 
> better: "only 
> > if
> >
> >    would not be able to interoperate with a newer version. Each 
> > version number
> >
> >    lower version than "DSKPP 12.0".  Leading zeros (e.g., "DSKPP 
> > 06.0") MUST be
> >
> >    ignored by recipients and MUST NOT be sent. Numbers after the 
> > decimal place
> >
> FI/Espoo); 
> > -         Added the Suite element under AlgorithmParameter: (please 
> > note that this is a schema change but it is an optional additional 
> > element so old messages will work)
> >
> >
> >
> > "
> >
> > <Suite>:
> >
> >
> >
> characteristics 
> > of
> >       the algorithm used, which are algorithm specific.  
> For example 
> > in
> >
> Version to 
> > Version
> >    be lower than "PSKC 12.3".  Leading zeros (e.g., "PSKC 
> 6.01") MUST 
> > be
> >
> >    format (E.g.  Element structure) has changed so 
> dramatically that 
> > an
> >
> interoperate with 
> > a
> >    secure perimeter (the provisioning server from the 
> example above) 
> > and
> >

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 16 Jun 2010 07:25:19 +0200

What is minor and what is major is a rather subjective issue.  If any of the
parties needs to upgrade due to a version change it will be experienced
as major no matter what the version number says :-)

Fortunately, the browser invocation mechanism which is one of the KeyGen2/SKS
deliverables will ease the pain by offering a negotiation/discovery facility
where the parties can decide if they are compatible or not depending on
version data as well as XML name-space.  Yes, it is completely independent
of KeyGen2 because I don't believe in "protocol monopoly".   My hope is
rather that this scheme will spur innovation and competition in this space.

Maybe OATH or GlobalPlatform will launch an E2ES scheme one of these days?
There are many such efforts in the workings. Most of them are though
based on Java applets + SUN's smartcardio stuff which is a way "solving"
both the versioning and the [currently] pitiful state of browsers.

Anders

Pei, Mingliang wrote:
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyprov
>

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 09:18:22 -0400

Ok, let's keep <major>.<minor>.  The flexibility is a good thing to have.  

With respect to Peter's suggested text change from "message formats and flows" to "data formats or security algorithms", and Phillip's statement below re criteria for major/minor number change, I propose that we provide the following text (for PSKC doc, substitute "PSKC" for "DSKPP"):

   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 data formats 
   or security algorithms have changed so dramatically that
   an older version implementation would not be able to interoperate with a
   newer version (e.g., removing support for a previously mandatory-to-
   implement algorithm now found to be insecure).  The minor version number 
   indicates new capabilities (e.g., introducing a new algorithm option) 
   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."

Thoughts?
Andrea

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Tuesday, June 15, 2010 6:57 PM
To: Phillip Hallam-Baker; Philip Hoyer
Cc: Doherty, Andrea; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Latest version of PSKC draft

- Ming

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 09:25:30 -0400

Ming, Salah, etal:

Peter Saint-Andre, in latest IESG DISCUSS-ion, stated:

   > 2. Section 7.2 "presents a binding of the previous messages to
   > HTTP/1.1" but it is not clear if the HTTP binding is
   > mandatory-to-implement. This could be added to Section 9.
   > 
   > [Doherty, Andrea] As stated in Section 3.1, "The principal syntax
is
   > XML and it is layered on a transport mechanism such as HTTP."  As
   > such, it was not envisaged that HTTP would be
   > mandatory-to-implement.

   OK.

   How will we ensure interoperability if no transport mechanism is
   mandatory-to-implement?

I tend to agree with him, and would like to make this mechanism
mandatory-to-
Implement - if everyone else agrees.

Thoughts?

Andrea

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Jun 2010 12:41:20 -0400

> Implement - if everyone else agrees.

I would have preferred for it to have been transport agnostic.  If we 
absolutely have to pick one, then I'd say HTTP is the one.

spt

---

From: "Salah Machani" <[email-masked]>
Date: Wed, 16 Jun 2010 13:14:39 -0400

I am in agreement that we make HTTP mandatory-to-implement to ensure
interoperability.  

Salah

-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: June 16, 2010 12:41 PM
To: [email-masked]
Cc: [email-masked]; Salah Machani; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [KEYPROV] Latest version of PSKC draft

spt

---

From: "Pei, Mingliang" <[email-masked]>
Date: Wed, 16 Jun 2010 10:25:18 -0700

Agreed. I believe that it is practically what people will support
anyway.

- Ming 

> From: Salah Machani [mailto:[email-masked]] 
> Sent: Wednesday, June 16, 2010 10:15 AM
> To: Sean Turner; [email-masked]
> Cc: Pei, Mingliang; [email-masked]; 
> Subject: RE: [KEYPROV] Latest version of PSKC draft
> 
> I am in agreement that we make HTTP mandatory-to-implement to 
> ensure interoperability.  
> 
> Salah
> 
> Cc: [email-masked]; Salah Machani; 
> [email-masked]; [email-masked]; [email-masked]
> I would have preferred for it to have been transport 
> agnostic.  If we absolutely have to pick one, then I'd say 
> HTTP is the one.
> 
> spt
>

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 28 Jun 2010 15:20:41 +0200

Ladies and Gentlemen,

A new version of PSKC as been submitted (-07) this addresses:

Keyprov mailing list discussion for Additional Algorithm Suite
parameter.

"

<Suite>:

"

Discussion about use of # in the URN

Changed the algorithm URNs to use ':' instead of '#' (Please note that
this makes ALL current implementations incompatible)

"

   Where:

"

Alexey Melnikov:

"

      the Organisation value.

"

"

"

Comment: 

Peter Saint-Andre

2) Key Id, not globally unique anymore:

"

'Id':  This attribute carries a unique identifier for the symmetric

      key in the context of key provisioning exchanges between two

      parties.  This means that if PSKC is used in multiple interactions

      between a sending and receiving party, using different containers

      referencing the same keys, the KeyId MUST use the same KeyId

      values (e.g. after initial provisioning, if a system wants to

      update key meta data values in the other system the KeyId value of

      the key where the meta data is to be updates MUST be the same of

      the original KeyId value provisioned).  The identifier is defined

      as a string of alphanumeric characters.

"

"

"

"

   minor version number.

"

"

"

 

Philip Hoyer 

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 28 Jun 2010 15:22:52 +0200

Additionally find attached the .xml and the revised schema.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Philip Hoyer
Sent: Monday, June 28, 2010 2:21 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); Phillip Hallam-Baker;
[email-masked]
Cc: KEYPROV; Salah Machani
Subject: [KEYPROV] PSKC-07 submitted

Ladies and Gentlemen,

"

<Suite>:

"

"

   Where:

"

Alexey Melnikov:

"

      the Organisation value.

"

"

"

Comment: 

Peter Saint-Andre

"

"

"

"

"

   minor version number.

"

"

"

 

Philip Hoyer 

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Jun 2010 09:26:25 -0400

Congrats and thanks to everyone for all the work they have put into this.

On Mon, Jun 28, 2010 at 9:20 AM, Philip Hoyer <[email-masked]>wrote:

> Keyprov mailing list discussion for Additional Algorithm Suite parameter.
>
> Changed the algorithm URNs to use ‘:’ instead of ‘#’ (*Please note that
> this makes ALL current implementations incompatible)*
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 15:51:34 -0600

> A new version of PSKC as been submitted (-07) this addresses:

The new version looks good. Thanks for your work on this. I have one
comment.

> this makes ALL current implementations incompatible)*

Based on the list discussion, I thought you were going to change "#" to
"-" instead of ":". I really don't have a preference, but perhaps you
want to verify this change with the WG.

However, given that I don't have a preference between "-" and ":", I
have cleared my DISCUSS.

Peter

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