Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC?

From: "Doherty, Andrea" <[email-masked]>
Date: Thu, 8 Nov 2007 15:31:15 -0500

Philip,

Thank you for your proposal.  Here are a few comments:

1. By <AccessRules userPIN="true"/> do you mean "PIN is enabled"?  Is
the reverse true, that <AccessRules userPIN="false"/> indicates PINless
operation from a server's point of view? 

2. Instead of <UserPIN position="APPEND/PREPEND"/>, providing a
PINUsageModeType would be more extensible and implementable:
<xs:complexType name="PINUsageModeType">
	<xs:choice maxOccurs="unbounded">
		<xs:element name="Local"/>
		<xs:element name="Prepend"/>
		<xs:element name="Embed"/>
	</xs:choice>
</xs:complexType>

3. Anders brought to my attention that a local PIN is needed instead of
a server PIN in some scenarios.  The device issuer, in this case, would
also have a PIN policy that could differ from the policy of a server
PIN.  Anders provided the following example, which is taken from another
standardization effort in the workings ("PKI for Web 2.0"):

// The following is sent down to the client by the issuer:

<KeyGenerationRequest ...>

// Request a key without PIN protection.

  <RequestedKey ID="Key.1" KeyUsage="encryption">
    <KeyAlgorithmData>
      <RSA KeySize="2048"/>
    </KeyAlgorithmData>
  </RequestedKey>

// Request a set of keys with PIN protection.
// The specified policy disallows 11122 but accepts 11223
// 654321 would not be accepted either (sequence)

  <PINProtection Type="numeric" MinLength="5" MaxLength="8"
                 PatternRestrictions="three-in-a-row  sequences">

// The next element is optional and is a way of grouping PINs
// so that the user either only has to specify a single PIN
// for a set of keys, or one unique PIN per key.

    <PINGroupProtection Shared="true">

      <RequestedKey ID="Key.2" KeyUsage="signature">
        <KeyAlgorithmData>
          <RSA KeySize="2048"/>
        </KeyAlgorithmData>
      </RequestedKey>
      <RequestedKey ID="Key.3" KeyUsage="authentication">
        <KeyAlgorithmData>
          <RSA KeySize="2048"/>
        </KeyAlgorithmData>
      </RequestedKey>

    </PINGroupProtection>

  </PINProtection>

</KeyGenerationRequest>

Your thoughts?
Andrea 

-----Original Message-----
From: Philip Hoyer [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 6:16 AM
To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; [email-masked]
Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to
aclientviaPSKC?

Andrea,
You are right I have not addressed the Pin policy issue.

I would like to though. 

Since you seem to have a good idea of the requirements would you be able
to help?

I suggest we create a new type called PINPolicy that contains the data
required to be submitted.

So currently PIN usage I can think of is:
-KEY_ACCESS_CHECK (this check the pin on the device to allow access to a
key for algorithms)
-USED_IN_ALGO (used during calculation)

When you talk though about length I already have that in the <Usage>
part of the PIN 'key' see below

NEW->
       <Key KeyAlgorithm="userPIN"  KeyId="12345678">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="4"/>
         </Usage>
         <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
<-NEW

Also when we talk about server verified pins in otps are we not really
talking about the otp algo or usage here?

I was wondering hence if our usage element for the otp key should be
augmented to contain and optional

<UserPIN position="APPEND/PREPEND"/>

What do you think?

Philip

-----Original Message-----
From: Doherty, Andrea [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 1:28 AM
To: Philip Hoyer; KEYPROV Roundup Issue Tracker; [email-masked]
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Philip,
This looks ok except that a more complex PIN policy is needed (refer to
this comment I made to the previous version of the PSKC draft, Section
5.1.7:
"Recommend that you allow for a more complex PIN policy, esp., (a) how
the PIN is to be used in the OTP calculation (e.g., concatenated vs.
XOR's with the token code) and (b) PIN length. "

This doesn't seem to have been addressed yet based on feedback to my
review (see attached) and example below.  What is the status of this?  
Andrea

-----Original Message-----
From: Philip Hoyer [mailto:[email-masked]] 
Sent: Friday, September 28, 2007 11:48 AM
To: KEYPROV Roundup Issue Tracker; [email-masked]
Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a
clientviaPSKC?

Gentlemen,
Since PSKC will be used also to bulk provision from manufacturing to a
validation server and some of these devices do have a PIN pad there is
the concept of an initial PIN.

Since we have not yet defined how this initial PIN is transmitted in the
PSKC spec I would like to put forward a proposal for inclusion in the
spec for specifying the transmission of PINs.

The PIN is effectively another shared secret hence I propose to treat it
as a key in itself.

This has the advantage that we can leverage the Usage part of the schema
that can define things like length and format (alphanumeric etc). we
also can set an expiry etc. It also leverages the fact that the PIN
itself will be encrypted in transport in the same manner as other key
material.

I hence propose to extend the KeyAlgorithmType with a new type called
'userPIN' (inline with the name used in the access rules element already
present)

As an example a KeyContainer with a non encrypted HOTP key and a 4 digit
numeric PIN (please note that the value and valuedigest are just copy
and paste) ( I put the new section with NEW-> and <-NEW lines before and
after):

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
   xmlns="urn:ietf:params:xml:ns:keyprov:container"
   xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo"
   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container"
.\keyprov_pskc_schema_v1.1.xsd" version="1.1">
     <EncryptionMethod algorithm="NONE"/>
     <DigestMethod algorithm="HMAC-SHA1"></DigestMethod>
     <Device>
       <DeviceId>
         <Manufacturer>Token Manufacturer</Manufacturer>
         <SerialNo>98765432187</SerialNo>
         <Expiry>01/01/2008</Expiry>
       </DeviceId>
       <Key KeyAlgorithm="HOTP"  KeyId="98765432187">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="6"/>
         </Usage>
NEW->
         <AccessRules userPIN="true"/>
<-NEW
         <FriendlyName>MyFirstToken</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
         <Data Name="COUNTER">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
NEW->
       <Key KeyAlgorithm="userPIN"  KeyId="12345678">
         <Issuer>Credential Issuer</Issuer>
         <Usage>
          <ResponseFormat format="DECIMAL" length="4"/>
         </Usage>
         <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>
         <Data Name="SECRET">
           <Value>WldjTHZwRm9YTkhBRytseDMrUnc=</Value>
           <ValueDigest>WldjTHZwRm9YTkhBRytseDM=</ValueDigest>
         </Data>
       </Key>
<-NEW
     </Device>
   </KeyContainer>

Comments are welcome,

Philip

-----Original Message-----
From: Mingliang Pei [mailto:[email-masked]] 
Sent: Friday, September 21, 2007 9:58 AM
To: [email-masked]
Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client
viaPSKC?

New submission from Mingliang Pei <[email-masked]>:

PSKC provies support about carrying PIN usage policy. When PIN is used,
how do 
you actually transfer the initial PIN using PSKC? Should PIN be treated
as 
another credential, for example?

----------
assignedto: mpei
messages: 71
nosy: keyprov, mpei
priority: critical
status: chatting
title: How to transfer initial PIN to a client via PSKC?

_________________________________________________________
KEYPROV Roundup Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/keyprov/issue28>
_________________________________________________________

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

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

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

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

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 12 Nov 2007 17:48:06 -0800

I have chatted with Philip / Salah about my comments this afternoon
while I was almost done my reply of this email. I sent it anyway now for
broad review. Our meeting minutes from Philip later will contain other
proposed changes in our discussion.

1. A PIN is associated with a key; we need to define a better way to
associate with them when we carry PIN in a separate Key type.

- The current proposal assumes that all keys in the same "Device" type
will associate to the PIN credential in the same Device.
- This has a limitation for "PREPEND" case where a device may have
multiple keys, and each key has its own PIN as part of server
authentication.

2. There is use case when a PIN is per device, instead of per key, for
the "Local" access usage. 

So I prefer defining PIN credential inside DeviceType, and refered by
KeyType by an attribute or element, and DeviceType.

3. PIN policy is fine to have its own type. The AccessRule and
PINUsageModeType should combine to be a PIN usage policy. If we are
treating PIN as a separate credential, it is more consistent to make PIN
usage policy part of Usage, I think.

Thanks,

- Ming
 
> Sent: Thursday, November 08, 2007 12:31 PM
> Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to aclientviaPSKC?
> 
> Philip,
> 
> 1. By <AccessRules userPIN="true"/> do you mean "PIN is 
> enabled"?  Is the reverse true, that <AccessRules 
> userPIN="false"/> indicates PINless operation from a server's 
> point of view? 
> 
> 2. Instead of <UserPIN position="APPEND/PREPEND"/>, providing 
> a PINUsageModeType would be more extensible and implementable:
> 3. Anders brought to my attention that a local PIN is needed 
> instead of a server PIN in some scenarios.  The device 
> issuer, in this case, would also have a PIN policy that could 
> differ from the policy of a server PIN.  Anders provided the 
> following example, which is taken from another 
> // The specified policy disallows 11122 but accepts 11223 // 
> 654321 would not be accepted either (sequence)
> 
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to aclientviaPSKC?
> 
> Andrea,
> Since you seem to have a good idea of the requirements would 
> you be able to help?
> 
> I suggest we create a new type called PINPolicy that contains 
> the data required to be submitted.
> 
> -KEY_ACCESS_CHECK (this check the pin on the device to allow 
> access to a key for algorithms) -USED_IN_ALGO (used during 
> calculation)
> 
> When you talk though about length I already have that in the 
> <Usage> part of the PIN 'key' see below
> 
> NEW->
> Also when we talk about server verified pins in otps are we 
> not really talking about the otp algo or usage here?
> 
> I was wondering hence if our usage element for the otp key 
> should be augmented to contain and optional
> 
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to a clientviaPSKC?
> 
> Philip,
> This looks ok except that a more complex PIN policy is needed 
> (refer to this comment I made to the previous version of the 
> PSKC draft, Section
> 5.1.7:
> "Recommend that you allow for a more complex PIN policy, 
> esp., (a) how the PIN is to be used in the OTP calculation 
> (e.g., concatenated vs.
> This doesn't seem to have been addressed yet based on 
> feedback to my review (see attached) and example below.  What 
> is the status of this?  
> Andrea
> 
> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN 
> to a clientviaPSKC?
> 
> Gentlemen,
> Since PSKC will be used also to bulk provision from 
> manufacturing to a validation server and some of these 
> devices do have a PIN pad there is the concept of an initial PIN.
> 
> Since we have not yet defined how this initial PIN is 
> transmitted in the PSKC spec I would like to put forward a 
> proposal for inclusion in the spec for specifying the 
> transmission of PINs.
> 
> The PIN is effectively another shared secret hence I propose 
> to treat it as a key in itself.
> 
> This has the advantage that we can leverage the Usage part of 
> the schema that can define things like length and format 
> (alphanumeric etc). we also can set an expiry etc. It also 
> leverages the fact that the PIN itself will be encrypted in 
> transport in the same manner as other key material.
> 
> I hence propose to extend the KeyAlgorithmType with a new 
> type called 'userPIN' (inline with the name used in the 
> access rules element already
> present)
> 
> 
> As an example a KeyContainer with a non encrypted HOTP key 
> and a 4 digit numeric PIN (please note that the value and 
> valuedigest are just copy and paste) ( I put the new section 
> with NEW-> and <-NEW lines before and
> after):
> 
> Subject: [KEYPROV] [issue28] How to transfer initial PIN to a 
> client viaPSKC?
> 
>

---

From: "Philip Hoyer" <[email-masked]>
Date: Fri, 23 Nov 2007 17:08:21 +0100

Andrea and Ming,
As we discussed in the PSKC call I would like to explain a new proposal.

I would like to keep the way to transmit the PIN value as a key.

We though want the flexibility to define possibly multiple PINs and
which keys are protected by the PIN.

Hence I would like to introduce an element called PINPolicy

<PINPolicy PINRef="KeyId of the key containing the PIN">
	<PINUsageMode>
		Local
	</PINUsageMode>
</PINPolicy>

This will replace the accessrule element.

So to take the example of a PIN protected HOTP token with no encryption
based on the latest draft with highlights:

   <?xml version="1.0" encoding="UTF-8"?>
   <KeyContainer
     xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0
       keyprov-pskc-1.0.xsd" Version="1.0">
       <Device>
         <DeviceId>
           <Manufacturer>Token Manufacturer</Manufacturer>
           <SerialNo>98765432188</SerialNo>
           <Expiry>12/31/2012</Expiry>
         </DeviceId>
         <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
           KeyId="77654321871">
         <Issuer>Credential Issuer</Issuer>
           <Usage OTP="true">
             <ResponseFormat Format="DECIMAL" Length="6"/>
           </Usage>
           <FriendlyName>MyFirstToken</FriendlyName>
           <Data Name="SECRET">
             <Value>
               zOkqJENSsh6b2hdXz1WBK/oprbY=
             </Value>
           </Data>
           <Data Name="COUNTER">
             <Value>AAAAAAAAAAA=</Value>
           </Data>
           <Expiry>10/30/2012</Expiry>
	     <PINPolicy PINRef="77654321872">
            	<PINUsageMode>Local</PINUsageMode>
           </PINPolicy>		
         </Key>
         <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#PIN"
           KeyId="77654321872">
         <Issuer>Credential Issuer</Issuer>
           <Usage>
             <ResponseFormat Format="DECIMAL" Length="4"/>
           </Usage>
           <FriendlyName>RandomInitialTokenPIN</FriendlyName>
           <Data Name="SECRET">
             <Value>
               zOkqJENSsh6b2hdXz1WBK/oprbY=
             </Value>
           </Data>
         </Key>
       </Device>
   </KeyContainer>

In this way we can specifically say what keys are protected by which
PINs and re-use most of our constructs in Key that would apply to the
PIN such as the format the way to encrypt etc etc.

Thoughts?

Philip

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 1:48 AM
To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker;
[email-masked]

Thanks,

- Ming

---

From: "Salah Machani" <[email-masked]>
Date: Sun, 25 Nov 2007 10:37:44 -0500

Philip,

Thanks for sending this. Just a couple of comments:

1.	The purpose of the PINpolicy that is currently defined thought
the <accessRules> element is to indicate to the device client whether
the user must enter a PIN (local PIN)  in order to use the token secret
or not. I am for replacing the AccessRules definition with a new
PINPolicy taking into account other use cases but we need to make sure
that the original use case is still supported:  I am assuming in your
proposed definition the <PINPolicy> is optional and the PINRef is also
optional?  When the <PINPolicy> is omitted, it would imply that the user
PIN is not required and when included but the PINRef is omitted, it
would imply that a user PIN is required but there is no initial PIN. Is
this correct? 

2.	In addition to the flexibility you indicated below, the proposed
definition implies also that you want to allow for the same initial PIN
to be used for multiple Token secrets in bulk provisioning scenario.
This could be achieved by defining the PINPolicy as follows:

<PINPolicy>

<PINInitValue>zOkqJENSsh6b2hdXz1WBK/oprbY=</PINInitValue>

</PINPolicy>  

	a.	Is the reason you chose to use a reference to another
<key> element to avoid duplicating same PIN across multiple key data
blocks in the same the same container?

3.	What is the scope of the PINRef?  I am assuming this is within
the current PSKC container.  Could for example the PINref refer to a key
that has been provisioned from another 'previous' container?       

4.	if we use the <key> data to transmit the initial PIN as
proposed, we will need to add a new usage type to indicate the key data
value will be used as an initial pin to unlock the actual token secret.
I think it is better to have this explicit then implied by the PINRef
(being set to keyid).

Regards,

Salah

________________________________

From: Philip Hoyer [mailto:[email-masked]] 
Sent: Friday, November 23, 2007 11:08 AM
To: Pei, Mingliang; Doherty, Andrea; KEYPROV Roundup Issue Tracker;
[email-masked]
Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to
aclientviaPSKC?

Andrea and Ming,

        <PINUsageMode>

                Local

        </PINUsageMode>

</PINPolicy>

   <KeyContainer

       <Device>

         <DeviceId>

         </DeviceId>

           KeyId="77654321871">

           <Usage OTP="true">

           </Usage>

           <Data Name="SECRET">

             <Value>

             </Value>

           </Data>

           <Data Name="COUNTER">

           </Data>

           </PINPolicy>         

         </Key>

           KeyId="77654321872">

           <Usage>

           </Usage>

           <Data Name="SECRET">

             <Value>

             </Value>

           </Data>

         </Key>

       </Device>

   </KeyContainer>

Thoughts?

Philip

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]]
Sent: Tuesday, November 13, 2007 1:48 AM
To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker;
[email-masked]

authentication.

Thanks,

- Ming

> PSKC provies support about carrying PIN usage policy. When 

> PIN is used,

> you actually transfer the initial PIN using PSKC? Should PIN 

> be treated

Notice to Recipient:  The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors.  Thank you.

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 26 Nov 2007 12:36:27 -0800

It looks good for remote PIN usage case, i.e., one PIN per key where PIN
is used along with key for respective algorithm. Another point that we
touched was to handle a device PINPolicy in the following situation:
 
- A PIN is provisioned and used to login to a device. The device may
contain multiple keys. It would be redundant to include PINPolicy in
each Key element for the m-key elements in a device. We may allow Device
element to have a PINPolicy where PINUsageMode = Local.
 
Thus I consider a variation of this as follows.
 
I:
 
<Device>
    <LocalPINPolicy/>
    <Key KeyAlgorithm="...#PIN"     KeyId=1>...</Key>
    <Key KeyAlgorithm="...#HOTP" KeyId="2"><Issuer>Issuer
1</Issuer></Key>
    <Key KeyAlgorithm="...#HOTP" KeyId="3"><Issuer>Issuer
2</Issuer></Key>
</Device>
 
II:
 
<Device>
    <Key KeyAlgorithm="...#PIN" KeyId="1"><PINPolicy RefId="2"/></Key>
    <Key KeyAlgorithm="...#PIN" KeyId="2"></Key>
</Device>
 
I am not very satisfied with the two flavors of PINPolicy though.
Thoughts?
 
- Ming

	From: Philip Hoyer [mailto:[email-masked]] 
	Sent: Friday, November 23, 2007 8:08 AM
	To: Pei, Mingliang; Doherty, Andrea; KEYPROV Roundup Issue
Tracker; [email-masked]
	Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell
	Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to
aclientviaPSKC?

	Andrea and Ming,

	As we discussed in the PSKC call I would like to explain a new
proposal.

	We though want the flexibility to define possibly multiple PINs
and which keys are protected by the PIN.

	        <PINUsageMode>

	                Local

	        </PINUsageMode>

	</PINPolicy>

	So to take the example of a PIN protected HOTP token with no
encryption based on the latest draft with highlights:

	   <KeyContainer

	       <Device>

	         <DeviceId>

	         </DeviceId>

	         <Key
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"

	           KeyId="77654321871">

	           <Usage OTP="true">

	           </Usage>

	           <Data Name="SECRET">

	             <Value>

	             </Value>

	           </Data>

	           <Data Name="COUNTER">

	           </Data>

	           </PINPolicy>         

	         </Key>

	         <Key
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#PIN"

	           KeyId="77654321872">

	           <Usage>

	           </Usage>

	           <Data Name="SECRET">

	             <Value>

	             </Value>

	           </Data>

	         </Key>

	       </Device>

	   </KeyContainer>

	In this way we can specifically say what keys are protected by
which PINs and re-use most of our constructs in Key that would apply to
the PIN such as the format the way to encrypt etc etc.

	Thoughts?

	Philip

	-----Original Message-----
	From: Pei, Mingliang [mailto:[email-masked]]
	Sent: Tuesday, November 13, 2007 1:48 AM
	To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue
Tracker; [email-masked]
	Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell
	Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to
aclientviaPSKC?

	I have chatted with Philip / Salah about my comments this
afternoon

	while I was almost done my reply of this email. I sent it anyway
now for

	broad review. Our meeting minutes from Philip later will contain
other

	1. A PIN is associated with a key; we need to define a better
way to

	- The current proposal assumes that all keys in the same
"Device" type

	- This has a limitation for "PREPEND" case where a device may
have

	authentication.

	2. There is use case when a PIN is per device, instead of per
key, for

	So I prefer defining PIN credential inside DeviceType, and
refered by

	PINUsageModeType should combine to be a PIN usage policy. If we
are

	treating PIN as a separate credential, it is more consistent to
make PIN

	Thanks,

	- Ming