Subject: [KEYPROV] [issue4] Should TokenID and KeyID be string instead of binary?

From: Andrea Doherty <[email-masked]>
Date: Thu, 21 Jun 2007 16:32:59 +0000

Andrea Doherty <[email-masked]> added the comment:

The original reason for base64Binary was to allow for creating universally 
unique tokenIDs by, e.g. hashing together the vendor's DNS name together with a 
vendor-unique serial number. base64Binary allows for full usage of all bits in 
a byte. String does not, so you would have to come up with some other scheme 
then for guaranteeing token ID uniqueness - and it seems pretty ugly to me 
with, e.g. "rsa.com|0012324324". Or?

_________________________________________________________
KEYPROV Roundup Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/keyprov/issue4>
_________________________________________________________

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: "CHANG Shuh" <[email-masked]>
Date: Thu, 21 Jun 2007 19:43:18 +0200

>> Andrea wrote:
>> ... come up with some other scheme then for guaranteeing token ID
uniqueness - 

Maybe that's another reason for needing OATH ID namespace standardized
on EUI-64 which can be treated as string, other than the potential
benefit of using TokenID for key derivation.

On the other hand, I also see the reasons on advocating using
base64binary for TokenID and KeyID. Some existing industrial specs such
as WS-I (Basic Security Profile version 1.0) is already defining and
supporting base64binary as the *only* encoding type for KeyID, etc. For
example, the following text is borrowed from Section 7.4 Key Identifier
References of WS-I Basic Security Profile:

===============================================================
Base64Binary is the only encoding type specified by Web Services
Security: SOAP Message Security. Explicit specification of attribute
values simplifies XML processing requirements and as a general principle
the Basic Security Profile 1.0 requires that attributes be explicitly
specified rather than relying on default values. 

R3070 Any STR_KEY_IDENTIFIER that refers to a SECURITY_TOKEN other than
a SAML_TOKEN MUST specify an EncodingType attribute. 

R3071 Any STR_KEY_IDENTIFIER EncodingType attribute MUST have a value of
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-se
curity-1.0#Base64Binary". 

A wsse:KeyIdentifier may specify its encoding type. The Profile
restricts the encoding type to Base64Binary and requires its explicit
specification. 
===============================================================

Note that the WS-I's notion of a security token (such as an OTP token)
is different from what we refer to as the OATH token (a device) though.

Regards,
Shuh

> -----Original Message-----
> From: Andrea Doherty [mailto:[email-masked]] 
> Sent: Thursday, June 21, 2007 11:33 AM
> To: [email-masked]; [email-masked]
> Subject: [KEYPROV] [issue4] Should TokenID and KeyID be 
> string instead ofbinary?
> 
> 
> The original reason for base64Binary was to allow for 
> creating universally unique tokenIDs by, e.g. hashing 
> together the vendor's DNS name together with a vendor-unique 
> serial number. base64Binary allows for full usage of all bits 
> in a byte. String does not, so you would have to come up with 
> some other scheme then for guaranteeing token ID uniqueness - 
> and it seems pretty ugly to me with, e.g. "rsa.com|0012324324". Or?
>

---

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 21 Jun 2007 18:18:24 -0700

For an OTP token device or software tokens, if some registration process
for a token manufacturer is set, say using EUI-64 for a manufacturer
code, then the token ID can be unique and the entire ID can be decimal
string.

For all possible symmetric key type, however, a string may not be
sufficient and registration may not always fit, for example,
provisioning a 3DES key to clients within an organization with this
protocol.

In case of token device, a printable string token ID is often engraved
in the face of the token. It is more friendly to see it as is in XML
data. When my token ID is, for example, "RSA0012324324", seeing
"UlNBMDAxMjMyNDMyNA==" in XML for the token ID is not natural.

Challenge and revised question: 

Shall we define it in a way allowing the simple string format and also
binary format for non-typical case?

- Ming

-----Original Message-----
From: Andrea Doherty [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 9:33 AM
To: [email-masked]; Pei, Mingliang
Subject: [issue4] Should TokenID and KeyID be string instead of binary?

The original reason for base64Binary was to allow for creating
universally unique tokenIDs by, e.g. hashing together the vendor's DNS
name together with a vendor-unique serial number. base64Binary allows
for full usage of all bits in a byte. String does not, so you would have
to come up with some other scheme then for guaranteeing token ID
uniqueness - and it seems pretty ugly to me with, e.g.
"rsa.com|0012324324". Or?