Re: [KEYPROV] Tentative Conclusion on XML Design Question

[Hannes Tschofenig <[e-mail]>]

Hi Philip,

thanks for your response. Please find my comments inline:

Philip Hoyer wrote:
> 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.
>
>   
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.


> By having
>   
>>>     <xs:complexType name="KeyType">
>>>         <xs:sequence>
>>>             <xs:element name="Data" type="pskc:DataType" minOccurs="0" maxOccurs="unbounded"/>
>>>         </xs:sequence>
>>>     </xs:complexType>
>>>       
>
> 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.
>
>   
See above.
Not an issue in the real world.

> 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
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?


> Philip
>
>
>   
Ciao
Hannes

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: Friday, February 22, 2008 11:45 AM
> To: Philip Hoyer
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
> Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question
>
> Hi Philip,
>
>
> Philip Hoyer wrote:
>   
>> Hannes,
>> 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.
>
>   
>> 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?
>>
>>   
>>     
> 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
>
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: Thursday, February 21, 2008 6:38 PM
>> To: Philip Hoyer
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [e-mail]
>> Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question
>>
>> 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:
>>   
>>     
>>> 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:[e-mail]] 
>>> Sent: Thursday, February 21, 2008 12:10 PM
>>> To: Philip Hoyer; [e-mail]
>>> Cc: [e-mail]
>>> Subject: AW: [KEYPROV] Tentative Conclusion on XML Design Question
>>>
>>> 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: [e-mail] 
>>>> [mailto:[e-mail]] Im Auftrag von ext Philip Hoyer
>>>> Gesendet: Donnerstag, 21. Februar 2008 13:41
>>>> An: [e-mail]; Tschofenig, Hannes (NSN - FI/Espoo)
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> Betreff: Re: [KEYPROV] Tentative Conclusion on XML Design Question
>>>>
>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Hannes Tschofenig
>>>> Sent: Thursday, February 21, 2008 11:32 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> Subject: [KEYPROV] Tentative Conclusion on XML Design Question
>>>>
>>>> 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
>>>>
>>>>
>>>> [e-mail] wrote:
>>>>     
>>>>       
>>>>         
>>>>> 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
>>>>> [e-mail]
>>>>> http://www.ietf.org/mailman/listinfo/keyprov
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>> _______________________________________________
>>>> KEYPROV mailing list
>>>> [e-mail]
>>>> http://www.ietf.org/mailman/listinfo/keyprov
>>>>
>>>> _______________________________________________
>>>> KEYPROV mailing list
>>>> [e-mail]
>>>> http://www.ietf.org/mailman/listinfo/keyprov
>>>>
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>
>
>   

_______________________________________________
KEYPROV mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/keyprov