Subject: [KEYPROV] [PSKC] Unencrypted Data values in String or base64

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 17 Apr 2008 18:12:07 +0200

Ladies and Gentlemen,

One of the open issues I forgot to mention is if we want to change the
type in the XML schema for unencrypted Data value for a key from
base64binary to String.

Currently our schema is as follows:

<xs:complexType name="DataType">

                        <xs:sequence>

                                    <xs:choice>

                                                <xs:element
name="PlainValue" type="xs:base64Binary"/>

                                                <xs:element
name="EncryptedValue" type="xenc:EncryptedDataType"/>

                                    </xs:choice>

                                    <xs:element name="ValueMAC"
type="xs:base64Binary" minOccurs="0"/>

                        </xs:sequence>

                        <xs:attribute name="Name" type="xs:string"
use="required"/>

            </xs:complexType>

That means that PLainValue is of type base64Binary.

This means that an unencrypted counter for example is:

               <Data Name="COUNTER">

                   <PlainValue>AprkuA==</PlainValue>

               </Data>

If we would make it a String it would be:

               <Data Name="COUNTER">

                   <PlainValue>0</PlainValue>

               </Data>

We then obviously would need to change our semantic definitions. Again
for the counter example:

      COUNTER: the event counter for event based OTP algorithms. 8 bytes

      unsigned integer in big endian (i.e. network byte order) form

      base64 encoded

to 

COUNTER: the event counter for event based OTP algorithms. 8 bytes
unsigned integer in big endian (i.e. network byte order). 

When transmitted as unencrypted the PlainValue element will carry the
string presentation that can be parsed by STRTOUL ANSI C function.

I prefer the String representation for testing.

In case of production systems I assume that most people will encrypt all
values anyway.

Comments very welcome,

Philip

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

109 Borough High Street

London SE1 1NL

Telephone: +44 (0) 20 7744 6248

Direct: +44 (0) 20 7744 6455

Fax: +44 (0) 20 7744 6249

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.

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

---

From: "Pei, Mingliang" <[email-masked]>
Date: Thu, 17 Apr 2008 18:51:35 -0700

The argument between the two choices was about "readability" vs.
"consistency and extensibility". Base64 encoding was considered OK
because the value is mostly consumed by a machine / software;
readability isn't a concern. Moreover, Base64 encoding allows binary
source values. When a string is used, encoding should be indicated
somewhere in case the raw value is binary data. So I would like the
string type but an optional encoding type. This provides both
readability and binary data support.
 
- Ming

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Thursday, April 17, 2008 9:12 AM
	To: Pei, Mingliang; Salah Machani; Hannes Tschofenig;
Hallam-Baker, Phillip; [email-masked]
	Cc: [email-masked]
	Subject: [PSKC] Unencrypted Data values in String or base64

	Ladies and Gentlemen,

	One of the open issues I forgot to mention is if we want to
change the type in the XML schema for unencrypted Data value for a key
from base64binary to String.

	                        <xs:sequence>

	                                    <xs:choice>

	                                                <xs:element

	                                                <xs:element

	                                    </xs:choice>

	                        </xs:sequence>

	                        <xs:attribute name="Name"
type="xs:string" use="required"/>

	            </xs:complexType>

	               <Data Name="COUNTER">

	               </Data>

	               <Data Name="COUNTER">

	               </Data>

	We then obviously would need to change our semantic definitions.
Again for the counter example:

	      COUNTER: the event counter for event based OTP algorithms.
8 bytes

	      unsigned integer in big endian (i.e. network byte order)
form

	      base64 encoded

	to 

	COUNTER: the event counter for event based OTP algorithms. 8
bytes unsigned integer in big endian (i.e. network byte order). 

	When transmitted as unencrypted the PlainValue element will
carry the string presentation that can be parsed by STRTOUL ANSI C
function.

	In case of production systems I assume that most people will
encrypt all values anyway.

	Comments very welcome,

	Philip

	Philip Hoyer 

	ActivIdentity (UK)

	109 Borough High Street

	London SE1 1NL

	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