Re: [P1619-3] Approval of document for submission to IEEE 1619.3WG

[Arshad Noor <arshad.noor@strongauth.com>]

Logically it would, Bob.  However, I have the impression that
the IEEE dfinitions can stand alone by themselves.  But within
the SKSML, a client or server would not be able to identity a
key uniquely - even within a single Symmetric Key Management
System (SKMS) server - without all 3 components of the GKID.
Since all components are really needed to identify a key
uniquely, I put them all in the SO_HANDLE rather than break
them up.

I have no idea how the IEEE will specify that its own standard
should be implemented in applications/devices.  If you permit a
device to make a request with just the SO_HANDLE using the
SO_FAMILY, SO_DOMAIN and SO_CONTEXT from a previous call or
configuration, this might work within the IEEE specs.  But it
will certainly fail in SKSML unless the full GKID with the
DID-SID-KID triple is sent along.

On the last question, no, there is no service that automatically
does a DID lookup.  The list maintained by IANA is just a list of
registered numbers/companies.  It is anticipated that when an SKMS
is deployed, it will be configured to serve specific DIDs.  So, a
request for a key with a specific GKID will be rejected if the DID
in the GKID is not one of the configured DIDs on the server.  The
SKMS server itself need never lookup the DID anywhere.

Each SKMS client will be configured with the DID and server URLs
that serve that DID (much as resolv.conf lists out IP addresses
of DNS servers a client can contact).  It is unlikely - within
normal circumstances - that a client will ever request a GKID for
a DID that is not configured.  In any case, the server would reject
the request if it is not configured to serve that DID.

Arshad Noor
StrongAuth, Inc.

P.S.  You may need to forward this e-mail to your own listserv
as I do not have send privileges on it.

Robert Lockhart wrote:
> Arshad,
>  
> The GKID, DID, SID and KID would seem to map directly into SO_GUID, SO_Domain, SO_Context and SO_Handle one for one.
>  
> Is there any reason we wouldn't want to map these as follows for mapping EKMI variables:
> 
> 1.	
> 	GKID = SO_GUID
> 2.	
> 	??? = SO_Family
> 3.	
> 	DID = SO_Domain
> 4.	
> 	SID = SO_Context
> 5.	
> 	KID = SO_Handle
> 
> I need to do some further reading on the current draft of the standard to understand which of the values are required when a device requests keys of the server it originally stored it on.  Further conversation on this may be required.
>  
> Last note, is there a service that lookups can be performed against for the DID (IANA PEN) similar to DNS or is this just a list of vendors that has to be searched?
>  
> Thanks,
>  
> Bob Lockhart
>  
> Robert A. (Bob) Lockhart Sr. Solutions Architect
> nCipher, Inc. Data Security Solutions for Enterprises
> 1655 McCarthy Blvd., Milpitas, CA, 95035
> +1 (408) 473-1356 direct
> +1 (510) 410-0585 cellular
> +1 (408) 473-1310 fax
> 
> ________________________________
> 
> From: Matt Ball [mailto:matt.ball@IEEE.ORG]
> Sent: Mon 12/17/2007 6:07 AM
> To: P1619-3@LISTSERV.IEEE.ORG
> Subject: Re: [P1619-3] Approval of document for submission to IEEE 1619.3 WG
> 
> 
> Hi Group,
> 
> I would like to thank Arshad Noor and the rest of the EKMI group for helping provide an EKMI namespace proposal for the P1619.3 group.  You can find the proposal at this link:
> 
> http://www.oasis-open.org/committees/download.php/25671/P1619.3%20Name%20Space%20Subgroup%20Proposal%202007-08-24-Modified%20by%20AN-2007-10-11.doc
> 
> According to the proposal, an EKMI key identifier consists of the concatenation of three parts: 
> 
> 
> 1.	Domain Identifier (DID): An 8-byte Private Enterprise Number (PEN) assigned by IANA 
> 2.	Server Identifier (SID): An 8-byte locally-assigned value that identifies a particular key manager within the scope of the DID 
> 3.	Key Identifier (KID): An 8-byte locally-assigned value that identifiers a particular key within the scope of the key manager and DID.
> 	
> 
> The concatenate of all three of these fields, separated by hyphens (0x2D ASCII) forms the EKMI Global Key Identifier (GKID), for a total of 27 bytes (according to the proposal). 
> 
> Examples of an EKMI GKID:
> 
> 
> *	ek://0-0-0/
> 	
> *	ek://10514-22-344342232/
> 	
> *	ek://18446744073709551615-18446744073709551615-18446744073709551615/
> 
> Commentary:  There's a minor discrepancy in this draft, where it's unclear whether the GKID is represented in binary or ASCII-encoded decimal.  Based on the examples, I'm assuming that the representation is decimal, and that the actual size of the GKID is 20 characters, for a range of 0 to 2^64-1 (8 binary bytes).  With this minor change, the maximum size of the EKMI GKID becomes: 
> 
> 
> 5 bytes for prefix ('ek://')
> 3 * 20 bytes for each of DID, SID, and KID
> 2 hyphens
> 1 trailing slash
> 
> total = 68 bytes
> 
> 
> 
> After we get this minor clarification, I was hoping Bob Lockhart could incorporation this proposal into the latest NameSpace document.  I can help as well, if needed. 
> 
> We can discuss this proposal (among others) at the Jan 14th face-to-face meeting in Santa Ana.
> 
> Thanks!
> -Matt
> 
> 
> On Dec 16, 2007 7:46 PM, Arshad Noor < arshad.noor@strongauth.com <mailto:arshad.noor@strongauth.com> > wrote:
> 
> 
> 	The ballot to approve the submission of EKMI TC's input into
> 	the IEEE 1619.3 WG's work on their protocol, succeeded with
> 	5 of 8 TC voting members voting "Yes".  Ballot details are at:
> 	
> 	http://www.oasis-open.org/apps/org/workgroup/ekmi/ballot.php?id=1399
> 	
> 	This document (at the following URL) is now being sent to
> 	the Chair of the IEEE WG:
> 	
> 	http://www.oasis-open.org/committees/download.php/25671/P1619.3%20Name%20Space%20Subgroup%20Proposal%202007-08-24-Modified%20by%20AN-2007-10-11.doc
> 	
> 	Matt, please find enclosed the EKMI TC's input into your WG 
> 	efforts.  My apologies for the latency, but as Chair of your
> 	own WG, I'm sure you understand that process takes precedence
> 	over expedience in such matters.
> 	
> 	If you have any questions, please don't hesitate to contact me. 
> 	
> 	Regards,
> 	
> 	Arshad Noor
> 	StrongAuth, Inc.
> 	
> 	
> 
> 
> 
>