Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Mar 2008 10:40:02 -0800

The problem arises in advanced XML development enviroments that use reflextion to generate XML serlization factories such as Microsoft .NET. The same features could be implemented in any modern language that exposes class metadata.

To create a serlization object in .NET we simply call the serilization factory
   XmlSerializer s = new XmlSerializer (typeof (MyClass))

To parse a stream to an object:
   o = (MyClass) s.Deserialize (filestreamIn)

To write the object out as XML
   s.Serialize (o, filestreamOut)

Note however that in more recent versions of .NET, this objection no longer applies. Dealling with ANY elements is not exactly as simple as it could be, but it is relatively straightforward.

What you need to do in this case is to add in XmlNodeEventHandler objects to the serializer

   s += new XmlNodeEventHandler(unknownNode)
   s += new XmlNodeAttributeHandler(unknownAttribute)

And then code the fixups accordingly. Or at least that is how it appears to be the case from the documentation. I would have to experiment to find out and my development box has a hardware fault.

I don't think we should take architectural decisions on the basis of a fixable limitation in a programming environment. Particularly if it is documentation related. Better to ask Microsoft how to code for that particular case, they have to have considered it.

It would not be hard to make handling of ANY automatic. 

Although the range of schemas referenced by ANY is infinite for a given schema, the schemas supported by a given application and the range of behaviors are by necessity limited. It should not be hard to introduce a tagged union at the location of the ANY extension point. Perhaps .NET does this already, we really need a .NET expert.

Given the problems with using inheritance, I think it is worth asking the platform providers to deal with this issue as is possible.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 22, 2008 10:43 AM
To: [email-masked]; [email-masked]
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

> -----Original Message-----
> 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)
> Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question
> 
> 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:[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,
> >
> >
> > 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:[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
> >>
> >> 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:[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,
> >>>
> >>> 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)
> >>>> Cc: [email-masked]; [email-masked]; [email-masked]
> >>>> 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: [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,
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>> [email-masked] 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
> >>>>> [email-masked]
> >>>>> http://www.ietf.org/mailman/listinfo/keyprov
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> KEYPROV mailing list
> >>>> [email-masked]
> >>>> http://www.ietf.org/mailman/listinfo/keyprov
> >>>>
> >>>> _______________________________________________
> >>>> KEYPROV mailing list
> >>>> [email-masked]
> >>>> http://www.ietf.org/mailman/listinfo/keyprov
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> 
> _______________________________________________
> KEYPROV mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/keyprov

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Mar 2008 08:30:12 -0800

Looking back at the original comments from the XSL people, I think we have something of a difference between the scripting approach to Web services and the modern high level language approach (Java / C#).

In the C# approach we are looking to construct a schema in such a way that we can map the serialized data to our programming language structures directly.

In the XSL approach we don't have that capability, it is a very imperative approach to coding. It is probably not the best test even amongst the scripting approaches. Several of the Web services scripting environments (Perl, Ruby) are rather more like a less strictly typed variation of the C# approach.

As a matter of coding style people tend to fit into one camp or the other. System and network administrators tend towards the scripting approach. 

I don't think that looking at the consequences for scripting is the best test here, none of the scripts appear to be remotely readable as far as I am concerned. I don't think that the fine distinctions in readability are sufficiently large to be decisive.

The difference for the XML aware language platform are much more significant. I can map variant A onto my programming language data structures with a single call. Variant B requires me to do much more work, I lose the power of using an XML aware language and unlike for the <any> case I don't see a way to fix that.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
> Sent: Tuesday, March 04, 2008 1:40 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> The problem arises in advanced XML development enviroments 
> that use reflextion to generate XML serlization factories 
> such as Microsoft .NET. The same features could be 
> implemented in any modern language that exposes class metadata.
> 
> 
> Note however that in more recent versions of .NET, this 
> objection no longer applies. Dealling with ANY elements is 
> not exactly as simple as it could be, but it is relatively 
> straightforward.
> 
> What you need to do in this case is to add in 
> XmlNodeEventHandler objects to the serializer
> 
> And then code the fixups accordingly. Or at least that is how 
> it appears to be the case from the documentation. I would 
> have to experiment to find out and my development box has a 
> hardware fault.
> 
> 
> I don't think we should take architectural decisions on the 
> basis of a fixable limitation in a programming environment. 
> Particularly if it is documentation related. Better to ask 
> Microsoft how to code for that particular case, they have to 
> have considered it.
> 
> Although the range of schemas referenced by ANY is infinite 
> for a given schema, the schemas supported by a given 
> application and the range of behaviors are by necessity 
> limited. It should not be hard to introduce a tagged union at 
> the location of the ANY extension point. Perhaps .NET does 
> this already, we really need a .NET expert.
> 
> 
> Given the problems with using inheritance, I think it is 
> worth asking the platform providers to deal with this issue 
> as is possible.  
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 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
> Senior Technologist  |  e-Mail: [email-masked]  |  
> Office: +1 781-515-7115  |  Mobile: +1 617-510-0893
> 
> 
> > > Have a look at the following please that indicates my 
> problem with 
> > > the
> > 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/> ].
> > protocols. It would just take too long and you have to parse the 
> > message anyway.
> > 
> > 
> > > By having
> > >
> You loose 
> > > this.
> > able to transmit data values currently not envisaged, technical 
> > extensions and your concept of extending within the realms 
> of IETF/IANA and specs.
> > >
> > > 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.
> > 
> > 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.
> > * Put a namespace in front of the attribute Then, you accomplish 
> > uniqueness by ensuring that the name / semantic relationship works 
> > within a specific body.
> > 
> > extensibility question. This has been done many, many times in the 
> > IETF before.
> > 
> > 
> > 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
> > 
> > > 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.
> > >
> > >
> > 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:element 
> name="CardAppPersoProfileId" type="xs:string"
> > minOccurs="0"/>
> > can be extensions and we can specify in the spec that any extension 
> > MUST have the subelements of PlainValue, EncryptedValue and 
> ValueMAC.
> > >>
> > > I am fine with everything -- I just want to make sure that we 
> > > understand the tradeoffs and implications.
> > > 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.
> > >
> > >> The XML schema in PSKC contains an extension point For 
> example, it 
> > >> contains something like:
> > >> 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.
> > >> 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
> > >>
> > >>
> > 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.
> > >>>
> > >>> You need to check whether the data type for the element 
> reflects 
> > >>> what you
> > >>>> 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>
> > >>>>
> > >>>> 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
> > >>>>
> > >>>>
> > >>>> From: [email-masked] 
> [mailto:[email-masked]] 
> > >>>> On Behalf Of Hannes Tschofenig
> > >>>>> The KEYPROV working group would appreciate your input. Please 
> > >>>>> let us know which variant we should pick.
> > >>>>>
> > >>>>> Ciao
> > >>>>> Hannes
> > >>>>>

---

From: [email-masked]
Date: Fri, 7 Mar 2008 12:15:02 -0500

A remaining issue is that there is no way figuring out which extensions are understood and supported except by requesting vendor support.
 
In the X.509 world there is a concept known as "non-critical" extensions.  On the surface this looks like a great idea (just skip things you don't understand), but the reality is that if you don't support a bunch of these you cannot for example know if a certificate is revoked or not.
 
Anders
Not entirely convinced