Subject: [KEYPROV] XML Design Question

From: <[email-masked]>
Date: Mon, 11 Feb 2008 10:48:55 +0200

Hi all, 

last week we had our IETF KEYPROV interim meeting and among many
security related issue we also ran into XML design questions. Hence, I
would like to solicit feedback from XML experts. In short, there seem to
be (at least two) ways to construct the XML schema to express that a key
contains of a secret and has a couple of meta data associated with it.
We would like to utilize XML encryption to selectively protect some of
the elements. 

Here are snippets from the two instance files:

* VARIANT A
===========

<Key ....> 

    <Secret>
        <EncryptedValue>
            <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
            <xenc:CipherData>
 
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=</xenc:CipherValue>
            </xenc:CipherData>
        </EncryptedValue>
    </Secret>
    <Counter>
        <PlainValue>1234</PlainValue>
    </Counter>

</Key>

* VARIANT B
===========

<Key ...>

    <Data Name="SECRET">
        <EncryptedValue>
            <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
            <xenc:CipherData>
 
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=</xenc:CipherValue>
            </xenc:CipherData>
        </EncryptedValue>
    </Data>
    <Data Name="COUNTER">
        <PlainValue>1234</PlainValue>
    </Data>
</Key>

I have put the schema/instance documents here:  
http://www.tschofenig.priv.at/xml/

The KEYPROV working group would appreciate your input. Please let us
know which variant we should pick. 

Ciao
Hannes

PS: I have simplified the schema to make it more convenient for you to
focus on the relevant parts. 
_______________________________________________
KEYPROV mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/keyprov

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Feb 2008 13:31:57 +0200

Hi all,

after our interim meeting I posted the mail below to the XML directorate 
mailing list. I got three responses for variant A so far, namely:

* Tim Bray: 
http://www.ietf.org/mail-archive/web/xml-dir/current/msg00174.html

* Phil Shafer: 
http://www.ietf.org/mail-archive/web/xml-dir/current/msg00176.html

* Andrew Newton (offlist):

-----

Without much background on the trade-offs and why each is being 
proposed, it is hard to tell which is better.

I do prefer variant A just because it seems simpler.

-andy

-----

Ciao
Hannes

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 21 Feb 2008 12:40:52 +0100

Hannes,
We can go with Variant A but still will need an element catalogue in the
spec since we do not want people to introduce elements that have the
same meaning eg <Counter> and <EventCounter>

Could you send the xsd snippet for the type definition to me for
inclusion.  
Also the plainvalue in the example is misleading since I believe in the
xsd it is base64 or did you envisage it to be String?
I am happy to use string and in the element catalogue describe how it is
serialised in the string. (eg for the secret it will be a string that
contains the base64 encoded binary of the value)

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Thursday, February 21, 2008 11:32 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [KEYPROV] Tentative Conclusion on XML Design Question

Hi all,

* Tim Bray: 

* Phil Shafer: 

-----

-andy

-----

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 21 Feb 2008 13:10:27 +0100

Hi Philip, 

The schema files are here: 
http://www.tschofenig.priv.at/xml/ 

PlainValue: What element name would you prefer? 

You need to check whether the data type for the element reflects what you had in mind for that element. 
If the <Secret> element has to use the data type "string" then that's fine. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von ext Philip Hoyer
> Gesendet: Donnerstag, 21. Februar 2008 13:41
> An: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo)
> Betreff: Re: [KEYPROV] Tentative Conclusion on XML Design Question
> 
> Hannes,
> > would like to solicit feedback from XML experts. In short, 
> there seem
> to

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 21 Feb 2008 16:51:39 +0100

Hannes,
I think your proposal has a major drawback.
For any extension you will have to update the schema, whereas being able to put as many Data elements as we can will leave the PSKC schema intact even if people add key attribute value that we have not foreseen.

I enclose the schemas of your proposal for better understanding my point:

    <xs:element name="Key">
        <xs:complexType>
        <xs:sequence>
            <xs:element name="Secret" type="pskc:base64BinaryType" minOccurs="0" maxOccurs="1"/>
            <!-- <xs:element name="Time" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>
            <xs:element name="TimeInterval" type="xs:double" minOccurs="0" maxOccurs="1"/>
            <xs:element name="TimeDrift" type="pskc:integerType" minOccurs="0" maxOccurs="1"/>
            -->
            <xs:element name="Counter" type="pskc:integerType" minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
        </xs:complexType>
    </xs:element>

So to add a new attribute you would have to change the schema above to add:

<xs:element name="TimeDrift" type="pskc:integerType" minOccurs="0" maxOccurs="1"/>
    
Whereas with method B the schema is:

    <xs:complexType name="KeyType">
        <xs:sequence>
            <xs:element name="Data" type="pskc:DataType" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

Hence you can add as many 'Data' elements without changing the schema.

Philip

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]] 
Sent: Thursday, February 21, 2008 12:10 PM
To: Philip Hoyer; [email-masked]
Cc: [email-masked]
Subject: AW: [KEYPROV] Tentative Conclusion on XML Design Question

Hi Philip, 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Feb 2008 20:38:06 +0200

Hi Philip

there is no difference regarding extensibility with the two proposals.

Let me describe how the extensibility works for both approaches.

VARIANT 1

Assumption:
The XML schema in PSKC contains an extension point
For example, it contains something like:
<xs:any namespace="##other" processContents="lax"/>

How to extend it:

One extends it by defining a new schema (with the new element or 
whatever you want todo).
You would also describe what the new elements actually mean.

In essence, you would extend it an the same way as you extend the rest 
of the PSKC schema. This is the way how one extends XML.
There is no need to change the existing schema.

VARIANT 2

Assumption
The IANA consideration sections explains how these tokens and their 
semantic is registered.
I assume something like informational RFC with expert review for adding 
new tokens

How to extend it:

You write a document that defines the new token + the semantic. This is 
the same approach as extensions work for protocols like RADIUS or Diameter

What you want to ensure is that
* extensions are well described
* there is a way to deal with conflicts (e.g., I define the same 
extension as you but with a different semantic).

Does this make sense to you?

Ciao
Hannes

Philip Hoyer wrote:
>>> security related issue we also ran into XML design 
>>>       
>> questions. Hence, I
>>     
>>> be (at least two) ways to construct the XML schema to express that a
>>>       
>> key
>>     
>>> contains of a secret and has a couple of meta data 
>>>       
>> associated with it.
>>     
>>> We would like to utilize XML encryption to selectively 
>>>       
>> protect some of
>>     
>>> the elements. 
>>>
>>> PS: I have simplified the schema to make it more convenient 
>>>       
>> for you to
>>

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 22 Feb 2008 11:43:40 +0100

Hannes,
The schema that is on your server did not contain the extension point.

I am not a big fan of such extension points because of the more intricate parsing requirements they put on programmers. 

How should a parser distinguish between the existing defined elements within the Key entity and the extended ones?

Maybe we could come to a compromise whereby we have defined elements within key (such as the usage etc) and then have a sub element called KeyData which can only ever contain elements of the various DataTypes:

	<xs:complexType name="KeyType">
		<xs:sequence>
			<xs:element name="Issuer" type="xs:string" minOccurs="0"/>
			<xs:element name="Usage" type="pskc:UsageType"/>
			<xs:element name="CardAppPersoProfileId" type="xs:string" minOccurs="0"/>
			<xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>
			<xs:element name="Data" type="pskc:KeyDataType" minOccurs="0"/>
			<xs:element name="PINPolicy" type="pskc:PINPolicyType" minOccurs="0"/>
			<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
			<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
		</xs:sequence>
		<xs:attribute name="KeyId" type="xs:string" use="required"/>
		<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType" use="required"/>
	</xs:complexType>
	<xs:complexType name="KeyDataType">
		<xs:sequence>
             <xs:element name="Secret" type="pskc:base64BinaryType" minOccurs="0" maxOccurs="1"/>
             <!-- <xs:element name="Time" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>
             <xs:element name="TimeInterval" type="xs:double" minOccurs="0" maxOccurs="1"/>
             <xs:element name="TimeDrift" type="pskc:integerType" minOccurs="0" maxOccurs="1"/>
             -->
             <xs:element name="Counter" type="pskc:integerType" minOccurs="0" maxOccurs="1"/>
		</xs:sequence>
	</xs:complexType>

    <xs:complexType name="base64BinaryType">
        <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:complexType>
    <xs:complexType name="integerType">
        <xs:sequence>
            <xs:choice>
                <xs:element name="PlainValue" type="xs:integer"/>
                <xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>
            </xs:choice>
			<xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

 This way the parsers will know that ONLY inside the KeyData element there can be extensions and we can specify in the spec that any extension MUST have the subelements of PlainValue, EncryptedValue and ValueMAC.

As you can see though this is starting to make the schema more complex but I am ok with accepting a compromise.

What do you think?

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, February 21, 2008 6:38 PM
To: Philip Hoyer
Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

Hi Philip

VARIANT 1

Assumption:

How to extend it:

VARIANT 2

Assumption

How to extend it:

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:45:15 +0200

Hi Philip,

> The schema that is on your server did not contain the extension point.
I thought that this was a mistake.
Without extension points we would turn the "EXTENSIBLE Markup Language" 
into the "Non-Extensible Markup Language".

> I am not a big fan of such extension points because of the more intricate parsing requirements they put on programmers. 
I have never heard about that given how widely XML is being used.

> How should a parser distinguish between the existing defined elements within the Key entity and the extended ones?
There are various ways to ensure extensibility in a protocol. Note that 
they have nothing todo with the XML schema itself but are rather 
fundamental principles of protocol design.

For extensibility, you need to consider where extensions are possible 
and how you want the other party to react on them (ignore if not 
understood, abort if not understood, negotiate or discover new 
extensions, etc.).

Different protocols have different strategy depending on the desire of 
the protocol designers.

> As you can see though this is starting to make the schema more complex but I am ok with accepting a compromise.
I am fine with everything -- I just want to make sure that we understand 
the tradeoffs and implications.
Your initial schema is also fine  -- it did not, however, provide an 
answer on how to extend it. Without such a story we will (a) most likely 
not get the document through the IESG and (b) we will encounter interop 
problems later.

Btw, the above schema does not contain an extension point -- is this 
intentional?

Ciao
Hannes

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 22 Feb 2008 14:17:43 +0100

Hannes,
Have a look at the following please that indicates my problem with the proposed extension point (this is from section 3.1 of the xmlenc spec):

EncryptedType is the abstract type from which EncryptedData and EncryptedKey are derived. While these two latter element types are very similar with respect to their content models, a syntactical distinction is useful to processing. Implementation MUST generate laxly schema valid [XML-schema <http://www.w3.org/TR/xmlenc-core/> ] EncryptedData or EncryptedKey as specified by the subsequent schema declarations. (Note the laxly schema valid generation means that the content permitted by xsd:ANY need not be valid.) Implementations SHOULD create these XML structures (EncryptedType elements and their descendents/content) in Normalization Form C [NFC <http://www.w3.org/TR/xmlenc-core/> , NFC-Corrigendum <http://www.w3.org/TR/xmlenc-core/> ].
This is the biggest differences of the approaches.

By having
>>             <xs:element name="Data" type="pskc:DataType" minOccurs="0" maxOccurs="unbounded"/>

You can make sure that any data element will comply and can be validated against the current schema.

With <xs:any namespace="##other" processContents="lax"/>
You loose this.

I think we are getting confused here between extension of the schema, being able to transmit data values currently not envisaged, technical extensions and your concept of extending within the realms of IETF/IANA and specs.

When you say that I do not define how to extend it you refer to a mechanism by which new Key Data elements will be communicated and registered.

This problem though is independent of the two approaches.

If I am reading you right you want us to create an informational RFC that holds the Data Attribute semantic definition? So basically create a separate document for section 7 of the current spec?

I was more thinking that by putting it in a separate section we could extend it in future versions of the spec and Yes I agree that there is a risk of others introducing new names and definitions that will create interoperability problems. But this is only one of the aspects that will create interoperability problems and we will not get it 'right' the first time around.
The use of the xmlenc concepts in the spec will create more interoperability problems than this approach, unless we tie down the exact allowed ways to use those elements (currently missing from the spec but trying to sort this out by introducing a more detailed section 6 on which I would gratefully receive some comments).

Philip

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 11:45 AM
To: Philip Hoyer
Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

Hi Philip,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 15:39:46 +0200

Hi Philip,

thanks for your response. Please find my comments inline:

> This is the biggest differences of the approaches.
This limitation exists with the way how XML works. With Relax NG that 
would be different.

However, this is only a limition on paper: Nobody uses validation in 
protocols. It would just take too long and you have to parse the message 
anyway.

> With <xs:any namespace="##other" processContents="lax"/>
See above.
Not an issue in the real world.

> When you say that I do not define how to extend it you refer to a mechanism by which new Key Data elements will be communicated and registered.
Yep; see
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt

The document does not even have an IANA consideration section.

> This problem though is independent of the two approaches.
Unfortunately, it isn't. The details of the extensibility story is 
different for both mechanisms.

> If I am reading you right you want us to create an informational RFC that holds the Data Attribute semantic definition? So basically create a separate document for section 7 of the current spec?
No.

When you in the future want to define new elements that belong inside 
the Data attribute then you need to describe them somewhere.
How did you envision that is going to happen?

> I was more thinking that by putting it in a separate section we could extend it in future versions of the spec and Yes I agree that there is a risk of others introducing new names and definitions that will create interoperability problems. 
The later issue goes away if you do the following:

* Registration is only possible via a single authority (e.g., IANA)
They would resolve conflicts.
* Put a namespace in front of the attribute
Then, you accomplish uniqueness by ensuring that the name / semantic 
relationship works within a specific body.

> But this is only one of the aspects that will create interoperability problems and we will not get it 'right' the first time around.
>   
Why do you think we will not get it right? This is a basic protocol 
extensibility question. This has been done many, many times in the IETF 
before.

> The use of the xmlenc concepts in the spec will create more interoperability problems than this approach, 

That may be true. That's, however, a totally different aspect that has 
nothing todo with this question.

> unless we tie down the exact allowed ways to use those elements (currently missing from the spec but trying to sort this out by introducing a more detailed section 6 on which I would gratefully receive some comments).
>   
I am, unfortunately, not the xmlenc expert. I can, however, find one so 
that we can ensure that everything is OK. Do you want me todo that?

Ciao
Hannes

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 22 Feb 2008 16:57:26 +0100

Robert and all,
I think the discussion veered off track a bit.

I am completely in line with what you are saying I think we lost focus on the real point of the discussion.

I try to recap.

PSKC allows to transfer symmetric keys and associated attributes.

Since we will not be able to know all of these attributes and model them explicitly we need a way to carry any number of attributes.

My approach was to have a set of name-value pair attributes that can be transmitted in clear or in encrypted form and then have a section of the spec defining already reserved names and semantics for the values.

This is almost exactly what SAML does in an attribute assertion. Matter of fact looking at the SAML assertion schema we could almost import it:

	<element name="AttributeStatement" type="saml:AttributeStatementType"/>
	<complexType name="AttributeStatementType">
		<complexContent>
			<extension base="saml:StatementAbstractType">
				<choice maxOccurs="unbounded">
					<element ref="saml:Attribute"/>
					<element ref="saml:EncryptedAttribute"/>
				</choice>
			</extension>
		</complexContent>
	</complexType>
	<element name="Attribute" type="saml:AttributeType"/>
	<complexType name="AttributeType">
		<sequence>
			<element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
		</sequence>
		<attribute name="Name" type="string" use="required"/>
		<attribute name="NameFormat" type="anyURI" use="optional"/>
		<attribute name="FriendlyName" type="string" use="optional"/>
		<anyAttribute namespace="##other" processContents="lax"/>
	</complexType>
	<element name="AttributeValue" type="anyType" nillable="true"/>
	<element name="EncryptedAttribute" type="saml:EncryptedElementType"/>

What Hannes is advocating is that instead of having a generic way to transfer attributes (as in SAML) we use explicit XML modelling via the < xs:any/xs:anyAttribute> extension.

I advocate against this and rather use an approach as the one in SAML.

I hope that this clarifies a bit what exactly we were discussing under the generic term of extension.

I look forward to your thoughts on the above,

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 3:43 PM
To: [email-masked]; Philip Hoyer
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] Tentative Conclusion on XML Design Question

I've been lurking for some time and have usually fed my comments on DSKPP through my co-worker, Andrea Dougherty.  In this instance she suggested that I go ahead and send my comments directly to the list. By way of introduction, like some of you, I've spent a fair amount of time on schema design for security-based protocols, having co-chaired the OASIS SSTC for SAML 1.1 and 2.0 and having collaborated on a number of the WS-* specs both before and after they were submitted to standards bodies.

First, forgive me if you guys have heavily debated this in f2f meetings, but I haven't seen much discussion of this point on the list. But the approach of establishing extension points via the <xs:any ...> construct has been fairly well established as a precedence in other security-related XML-based protocols.  This approach is used in SAML, the WS-* protocols, Liberty Alliance protocols, etc. These standards also ALL make heavy use of XMLSIG and XMLENC. There are numerous implementations of these specs that have proven to be quite interoperable and that deal with custom extensions quite well.  So an argument I think I'm hearing that using one form of schema extension over another impedes interoperability is, IMO, not really true. Like Hannes, I also am not familiar with the argument that the use of such extension points makes it a lot harder on the programmers. Given the fairly wide use of these specs today, I don't see that there's a strong case to be made for choosing an extension mechanism that deviates from the accepted industry norm.

Obviously, building in extensibility is a necessary evil for these types of specs. We all know that. No matter which of the 2 debated approaches is chosen, dealing with them in practice will always be tricky.  But the hard work is not in processing the XML structures in one of the 2 forms; it's in the extension profiling that is necessary to ensure the integrity and security of the spec is maintained.  As an aside, I'm not all that enamored with making it too easy to add custom extensions to security protocols, but that's not really germane to the discussion.

By the way, I haven't seen this mentioned on the list, but where appropriate, it is also quite useful to add XML attribute extension points to certain schema elements as well.  The generally accepted form for this is to use the <xs:anyAttribute namespace="##other" processContents="lax"/> construct. How would one propose doing this with a alternative approach that is consistent with the alternative element extension?

Next, IMO, extension points in schemas can certainly be overused.  There are some WS-* examples where just about every complexType definition includes an element extension and almost every element includes an attribute extension.  I think this was overkill. I think it is far more prudent to identify only the central constructs where extensibility would be desirable and add them there. I consider the SAML specs to be a good example of this approach.  It makes the job of profiling and negotiating acceptable extensions considerably easier.

As you can tell, I advocate the use of the xs:any/xs:anyAttribute extension mechanism.  It's not ideal, but it is widely used today, programmers and most tools do know how to deal with them, and I guess I just haven't seen sufficient strength in the counter-argument to justify that approach.

BTW - I will also point out that it is not true that "nobody uses validation in protocols".  While it isn't always done, I am aware of several SAML implementations that perform schema validation and also handle custom schema extensions without a problem.

Cheers,

Rob Philpott 
RSA, the Security Division of EMC
Senior Technologist  |  e-Mail: [email-masked]  |  Office: +1 781-515-7115  |  Mobile: +1 617-510-0893

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
> Sent: Friday, February 22, 2008 8:40 AM
> To: Philip Hoyer
> Cc: [email-masked]; Tschofenig,Hannes (NSN - FI/Espoo)
> > Have a look at the following please that indicates my problem with the
> proposed extension point (this is from section 3.1 of the xmlenc spec):
> >
> > EncryptedType is the abstract type from which EncryptedData and EncryptedKey
> are derived. While these two latter element types are very similar with
> respect to their content models, a syntactical distinction is useful to
> processing. Implementation MUST generate laxly schema valid [XML-schema
> <http://www.w3.org/TR/xmlenc-core/> ] EncryptedData or EncryptedKey as
> specified by the subsequent schema declarations. (Note the laxly schema valid
> generation means that the content permitted by xsd:ANY need not be valid.)
> Implementations SHOULD create these XML structures (EncryptedType elements and
> their descendents/content) in Normalization Form C [NFC
> <http://www.w3.org/TR/xmlenc-core/> , NFC-Corrigendum
> <http://www.w3.org/TR/xmlenc-core/> ].
> > I think we are getting confused here between extension of the schema, being
> able to transmit data values currently not envisaged, technical extensions and
> your concept of extending within the realms of IETF/IANA and specs.
> >
> > When you say that I do not define how to extend it you refer to a mechanism
> by which new Key Data elements will be communicated and registered.
> >
> Yep; see
> > If I am reading you right you want us to create an informational RFC that
> holds the Data Attribute semantic definition? So basically create a separate
> document for section 7 of the current spec?
> >
> No.
> 
> > I was more thinking that by putting it in a separate section we could extend
> it in future versions of the spec and Yes I agree that there is a risk of
> others introducing new names and definitions that will create interoperability
> problems.
> > But this is only one of the aspects that will create interoperability
> problems and we will not get it 'right' the first time around.
> >
> > unless we tie down the exact allowed ways to use those elements (currently
> missing from the spec but trying to sort this out by introducing a more
> detailed section 6 on which I would gratefully receive some comments).
> >
> >> I am not a big fan of such extension points because of the more intricate
> parsing requirements they put on programmers.
> >>
> >>
> >> How should a parser distinguish between the existing defined elements
> within the Key entity and the extended ones?
> >>
> >>
> >>
> >> Maybe we could come to a compromise whereby we have defined elements within
> key (such as the usage etc) and then have a sub element called KeyData which
> can only ever contain elements of the various DataTypes:
> >>
> >>  This way the parsers will know that ONLY inside the KeyData element there
> can be extensions and we can specify in the spec that any extension MUST have
> the subelements of PlainValue, EncryptedValue and ValueMAC.
> >>
> >>> For any extension you will have to update the schema, whereas being able
> to put as many Data elements as we can will leave the PSKC schema intact even
> if people add key attribute value that we have not foreseen.
> >>>

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 21 Feb 2008 06:48:00 -0800

I prefer using XML namespace qualified names for extensible enumerated
sets of values, much more than using either attributes with string values
or content.

So I much prefer <secret> to <Data Name="SECRET"> because (presumably)
"secret" is one of an enumerated set.

One "test" is that if you take a fragment of the resulting XML and
translate it (from English, presumably) to another language, words
in attributes and content would translate, but namespace-qualified
names would not. (Of course, base64-encoded data in element values
don't count.)

Larry

---

From: [email-masked]
Date: Fri, 22 Feb 2008 10:42:38 -0500

Cheers,

Rob Philpott

---

From: "Rundgren, Anders" <[email-masked]>
Date: Fri, 22 Feb 2008 19:05:31 -0000

The extension methodology used in KEYPROV depends on that clients and servers are in perfect harmony.  Converted to real-world lingo this means that the client and server software in most cases needs to be delivered by the same entity.  That is, KEYPROV cannot realistically be shipped as an integral part of computing platforms like Windows, Symbian, or Java.  

This limitation may be completely satisfactory for the current KEYPROV stake-holders, so there is no real problem to solve.  Both proposals would AFAICT work fine given the mentioned constraint.

Anders Rundgren

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Hoyer
Sent: Friday, February 22, 2008 10:57
To: Philpott, Robert; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

Robert and all,

I try to recap.

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 3:43 PM
To: [email-masked]; Philip Hoyer
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] Tentative Conclusion on XML Design Question

Cheers,

Rob Philpott

---

From: "Philip Hoyer" <[email-masked]>
Date: Sat, 23 Feb 2008 00:23:55 +0100

Anders,
Do you think we need to make a distinction here between DSKPP and the PSKC payload?

I mean agreeing on what the two parties can understand should be part of the protocol (hence DSKPP) once they have agreed the ability to exchange the payload with an arbitrary set of attributes (PSKC) is surely a good feature.

Do you have a suggestion for the transmission of key-related attributes that we should take into consideration?

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rundgren, Anders
Sent: Friday, February 22, 2008 7:06 PM
To: [email-masked]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

Anders Rundgren

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Hoyer
Sent: Friday, February 22, 2008 10:57
To: Philpott, Robert; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

Robert and all,

I try to recap.

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 3:43 PM
To: [email-masked]; Philip Hoyer
Cc: [email-masked]; [email-masked]
Subject: RE: [KEYPROV] Tentative Conclusion on XML Design Question

Cheers,

Rob Philpott