Subject: [KEYPROV] <KeyProfileId> Element and Extensibility

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Jan 2009 10:37:30 +0200

Hi all, 

As mentioned in my mail last week, see
http://www.ietf.org/mail-archive/web/keyprov/current/msg00577.html,
Philip and I ran into a question regarding extensibility that requires
discussion within the group. 

Here is the story: We tried to provide a bit more context around the
<KeyProfileId> element and to add an example. Below is the text from the
draft about the <KeyProfileId> element. In short, it is essentially a
reference to key data. Instead of transmitting the key data in the PSKC
document one can obviously agree on the specific values of the
individual elements and attributes and reference them with a pointer
instead. 

----------------

6.4.  Transmission of Key Derivation Values 

   <KeyProfileId> element, which is a child element of the <Key>
   element, carries a unique identifier used between the sending and
   receiving party to establish a set of key attribute values that are
   not transmitted within the container but agreed between the two
   parties out of band.  This element will then represent the unique
   reference to a set of attribute values.  For example, a smart card
   application personalisation profile id related to attributes present
   on a smart card application that have influence when computing a
   response.  The sending and the receiving party would agree to a set
   of values related to the MasterCard's Chip Authentication Protocol
   (CAP) [CAP].

   For example, sending and receiving party would agree that
   KeyProfileId='1' would represent a certain set of values (e.g.,
   Internet authentication flag set to a specific value).  When sending
   keys these values would not be transmitted as key attributes but only
   referred to via the <KeyProfileId> element set to the specific agreed
   profile (in this case '1').  When the receiving party receives the
   keys it can then associate all relevant key attributes contained in
   the out of band agreed profile with the imported keys.  Often this
   methodology is used between the manufacturing and the validation
   service to avoid transmission of mainly the same set of values.

   <MasterKeyId> element uniquely references an external master key when
   key derivation schemes are used and no specific key is transported
   but only the reference to the master key used to derive a specific
   key and some derivation data (e.g., the PKCS#11 key label).

---------------

It is also possible to combine the reference concept with transmitting
some values. 

In some sense, this is a expansion of the already existing concept of
PSKC algorithm profiles. One could imagine that, for the application
mentioned below, the credit card industry registers a profile and then
adds parameters to it that are meaningful only "locally" for their
usage. Maybe something to think about ...

Anyway, there is also a question regarding extensibility. This is the
example Philip came up with: 

-------------

<?xml version="1.0" encoding="UTF-8"?> 
<KeyContainer Version="1.0" 
    xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">
    <Device>
        <DeviceInfo>
            <Manufacturer>anEMVcardManufacturer</Manufacturer>
            <SerialNo>cardserialNumber00001</SerialNo>
        </DeviceInfo>
        <Key
            KeyAlgorithm="http://www.emvco.com/
               2008/04/algorithms/CAP_MChip2.1"
            KeyId="12345677">
            <Issuer>anIssuer</Issuer>
            <Usage OTP="true">
                <ResponseFormat Length="8" Format="DECIMAL"/>
            </Usage>
            <KeyProfileId>CAP_Appp_Personalisation_01</KeyProfileId>
            <MasterKeyId>CAPMasterKeyLabel1</MasterKeyId>
            <Data>
                <PAN>
                    <PlainValue> 1234567891234567 </PlainValue>
                </PAN>
                <PSN>
                    <PlainValue>01</PlainValue>
                </PSN>
            </Data>
        </Key>
    </Device>
</KeyContainer>

-------------

I suggested the following example instead: 

-------------

<?xml version="1.0" encoding="UTF-8"?>
 <KeyContainer Version="1" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
     xmlns:cap="urn:ietf:params:xml:ns:keyprov:pskc:cap">
    <Device>
        <DeviceInfo>
            <Manufacturer>anEMVcardManufacturer</Manufacturer>
            <SerialNo>cardserialNumber00001</SerialNo>
        </DeviceInfo>
        <Key KeyAlgorithm="urn:ietf:params:xml:ns:keyprov:pskc#cap" 
            KeyId="12345677">
            <Issuer>anIssuer</Issuer>
            <Usage>
                <ResponseFormat Length="8" Encoding="DECIMAL"/>
            </Usage>
            <KeyProfileId>CAP_Appp_Personalisation_01</KeyProfileId>
            <MasterKeyId>CAPMasterKeyLabel1</MasterKeyId>
            <Data>
                <cap:PAN>
                    <PlainValue> 1234567891234567 </PlainValue>
                </cap:PAN>
                <cap:PSN>
                    <PlainValue>01</PlainValue>
                </cap:PSN>
            </Data>
        </Key>
    </Device>
</KeyContainer>

-------------

As you can see, the difference is the way how the PAN and the PSN
elements are qualified. In the latter example I indicated the namespace
where they came from, namely
xmlns:cap="urn:ietf:params:xml:ns:keyprov:pskc:cap". This namespace
would be defined in a specification that describes what these additional
elements and attributes actually mean. There is no need to define an
additional XML schema (as there is no requirement in general to define
an XML schema or Relax NG schema for any XML document). But some folks
might want todo that.

So, from an implementation point of view one has todo the following: 

* Add code to recognize the new PSKC algorithm profile. This then
provides the program with further information about the semantic of the
elements and with an indication what elements and attributes have to be
present or have to be omitted. 

* If there are new elements or attributes that are required for a
specific profile then these have to be recognized. This is fairly simple
specifically since the token for these elements are known already and
their location as well. In our example above the two elements <PAN> and
<PSN> have to be present as child elements of <Data>. It is useful to
check whether the indicated namespace, namely "cap" in our example
matches "urn:ietf:params:xml:ns:keyprov:pskc:cap" to avoid the case that
two different profiles define the same element names.

I believe that this procedure would be consistent with extensibility in
other places in the PSKC document, such as for the <Policy> element,
<KeyDerivationMethod> element, <KeyContainer> element, <Key> element,
<DeviceInfo> element, <Device> element, 

It is also interesting to see that the <KeyContainer>, <Key>,
<DeviceInfo>, <Device> elements contain an <Extensions> element that
contains the extensions whereas the other elements don't. This does not
look consistent. 

What do others think? 

Ciao
Hannes

PS: I also think that the subject heading of Section 6.4 "Transmission
of Key Derivation Values " is not correct as only the <MasterKeyId>
element refers to a unique reference to an external master key when key
derivation schemes are used.
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 21 Jan 2009 10:37:25 +0100

All makes sense. BTW do you think that the urn of the extension might
want to refer the 'other' information spec we have submitted in terms of
profiles.  So maybe we can use '
urn:ietf:params:xml:ns:keyprov:pskc:algorithm:profiles:cap'

I would also want to add that the structure of the new elements MUST be
<NewELEMENT> and the type of them MUST be of the defined types in terms
of having the value as either PLainValue or EncryptedValue.

Your question on extension points, it was discussed by the authors where
extension points were needed and made sense hence they were added.

We did not want to have extensions everywhere as with some elements it
will not make sense.

Is there a particular element you had in mind that would require
extensions and which has not got an extension point yet?

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, January 20, 2009 8:38 AM
To: [email-masked]
Subject: [KEYPROV] <KeyProfileId> Element and Extensibility

Hi all, 

----------------

---------------

-------------

-------------

-------------

-------------

What do others think? 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 24 Jan 2009 13:41:48 +0200

Hi Philip, 

>Hannes,
>All makes sense. BTW do you think that the urn of the 
>extension might want to refer the 'other' information spec we 
>have submitted in terms of profiles.  So maybe we can use '

That would be possible. Alternatively, it would be possible to put the
<KeyProfileId> element into the same document that defines how the URN
and how it is supposed to be used. 

In fact, I believe one can rid of the <KeyProfileId> element by defining
a URN that looks like: 
urn:ietf:params:xml:ns:keyprov:pskc#cap-VendorID
                                        ^^^^^^^^
                                        This value would be the one
placed 
                                        in the <KeyProfileId>.

This would make sense inline with the usage of PSKC algorithm profiles. 

What do you think? Would this make sense to you? I could also provide an
example to make it easier to see the differences. 

>
>I would also want to add that the structure of the new 
>elements MUST be <NewELEMENT> and the type of them MUST be of 
>the defined types in terms of having the value as either 
>PLainValue or EncryptedValue.

I agree with the PLainValue or EncryptedValue statement. In fact the
current document already says that: 

"
      All these elements listed above (and those defined in the future)
      obey a simple structure in that they MUST support child elements
      to convey the content in plaintext and in encrypted format:

      Plain Text:  The <PlainValue> element carries plaintext content
         that is typed, for example to xs:integer.

      Encrypted Content:  The <EncryptedValue> element carries encrypted
         content.
"

What exactly do you mean by "structure of the new elements MUST be
<NewELEMENT>"? 

>
>Your question on extension points, it was discussed by the 
>authors where extension points were needed and made sense 
>hence they were added.

It make sense to have these extension points at the indicated places in
the XML schema. 
It was just the question why there some of them are child element of the
<Extensions> element and others aren't. Additionally, extensions are
easy to recognize in an XML document and hence they don't need to
additionally indicated in that way. 

So, why do you need the <Extensions> element? 

>
>We did not want to have extensions everywhere as with some 
>elements it will not make sense.

Sure. When you define an extension you certainly have to indicate where
to put that extension and what the semantic of it is. 

>
>Is there a particular element you had in mind that would 
>require extensions and which has not got an extension point yet?

No, I think the current extension points look fine to me. 
It was just the different approaches in a single document. I wanted to
check back why they were there. 

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Tschofenig, 
>Hannes (NSN - FI/Espoo)
>Philip and I ran into a question regarding extensibility that 
>requires discussion within the group. 
>
>Here is the story: We tried to provide a bit more context 
>around the <KeyProfileId> element and to add an example. Below 
>is the text from the draft about the <KeyProfileId> element. 
>In short, it is essentially a reference to key data. Instead 
>of transmitting the key data in the PSKC document one can 
>obviously agree on the specific values of the individual 
>elements and attributes and reference them with a pointer instead. 
>
>----------------
>
>It is also possible to combine the reference concept with 
>transmitting some values. 
>
>In some sense, this is a expansion of the already existing 
>concept of PSKC algorithm profiles. One could imagine that, 
>for the application mentioned below, the credit card industry 
>registers a profile and then adds parameters to it that are 
>meaningful only "locally" for their usage. Maybe something to 
>think about ...
>
>Anyway, there is also a question regarding extensibility. This 
>is the example Philip came up with: 
>
>-------------
>
>As you can see, the difference is the way how the PAN and the 
>PSN elements are qualified. In the latter example I indicated 
>the namespace where they came from, namely 
>xmlns:cap="urn:ietf:params:xml:ns:keyprov:pskc:cap". This 
>namespace would be defined in a specification that describes 
>what these additional elements and attributes actually mean. 
>There is no need to define an additional XML schema (as there 
>is no requirement in general to define an XML schema or Relax 
>NG schema for any XML document). But some folks might want todo that.
>
>* Add code to recognize the new PSKC algorithm profile. This 
>then provides the program with further information about the 
>semantic of the elements and with an indication what elements 
>and attributes have to be present or have to be omitted. 
>
>* If there are new elements or attributes that are required 
>for a specific profile then these have to be recognized. This 
>is fairly simple specifically since the token for these 
>elements are known already and their location as well. In our 
>example above the two elements <PAN> and <PSN> have to be 
>present as child elements of <Data>. It is useful to check 
>whether the indicated namespace, namely "cap" in our example 
>matches "urn:ietf:params:xml:ns:keyprov:pskc:cap" to avoid the 
>case that two different profiles define the same element names.
>
>I believe that this procedure would be consistent with 
>extensibility in other places in the PSKC document, such as 
>for the <Policy> element, <KeyDerivationMethod> element, 
><KeyContainer> element, <Key> element, <DeviceInfo> element, 
><Device> element, 
>
><DeviceInfo>, <Device> elements contain an <Extensions> 
>element that contains the extensions whereas the other 
>elements don't. This does not look consistent. 
>
>What do others think? 
>
>Ciao
>Hannes
>
>PS: I also think that the subject heading of Section 6.4 
>"Transmission of Key Derivation Values " is not correct as 
>only the <MasterKeyId> element refers to a unique reference to 
>an external master key when key derivation schemes are used.

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 26 Jan 2009 14:53:50 +0100

Hannes,
I believe this is becoming a different meaning and intended usage to the
initial intention of KeyProfileId

Let's go back to the current explanation:

The main point here is ' key attribute values that are
   not transmitted within the container '

So basically what this means is a set of value relating to this kind of
key that have been established out of band or pre-established.

This is very different from your usage where the profileId is basically
the profile of what the DATA element and sub elements MUST contain to be
valid.

We intitially thought that the profile as you call it would be
determined by the Algorithm URN/URL as we have put in the other draft
the elements that MUST be present relating to a special algorithm.

What you are proposing is a separate ProfileID that would allow variance
even within the same algorithm URL.

This is definitely interesting but maybe we need to cater for both.

See other comments [PH] inline

Philip

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo)
[mailto:[email-masked]] 
Sent: Saturday, January 24, 2009 11:42 AM
To: Philip Hoyer; [email-masked]
Subject: RE: [KEYPROV] <KeyProfileId> Element and Extensibility

Hi Philip, 

"

[PH] sorry for wording what I meant is what you understood above. 

[PH] this was discussed as best practice on the list and was a comment
from Anders

[PH] anywhere we have explicit element extension point we use
<Extensions>. Since Data was the effective Name value pair list and all
elements under data doe obey the structure we used <xs:any
namespace="##other" minOccurs="0" maxOccurs="unbounded"/>

Actually I noticed that based on the rule above the <any .. in
PolicyType would need to be changed to <Extensions in the current draft
schema.

Ciao
Hannes