Re: [KEYPROV] PSKC-07 submitted

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>wrote;wrote:

>  Ladies and Gentlemen,
>
>
>
> A new version of PSKC as been submitted (-07) this addresses:
>
>
>
> Keyprov mailing list discussion for Additional Algorithm Suite parameter.
>
> –         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.
>
> “
>
>
>
> Discussion about use of # in the URN
>
> 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.
>
> ”
>
>
>
>
>
> *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, 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.
>
> “
>
>
>
>
>
> 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: [phone]
>
> Fax: [phone]
>
>
>
> 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.
>
>
>



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