Re: [KEYPROV] Tentative Conclusion on XML Design Question

["Rundgren, Anders" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Philip Hoyer
Sent: Friday, February 22, 2008 10:57
To: Philpott, Robert; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [KEYPROV] Tentative Conclusion on XML Design Question

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: [e-mail] [mailto:[e-mail]] 
Sent: Friday, February 22, 2008 3:43 PM
To: [e-mail]; Philip Hoyer
Cc: [e-mail]; [e-mail]
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: [e-mail]  |  Office: [phone]  |  Mobile: [phone]


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Hannes Tschofenig
> Sent: Friday, February 22, 2008 8:40 AM
> To: Philip Hoyer
> Cc: [e-mail]; 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:[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


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

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