Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs
"Philip Hoyer" <philip.hoyer@actividentity.com> Thu, 10 July 2008 08:55 UTC
Return-Path: <keyprov-bounces@ietf.org>
X-Original-To: keyprov-archive@optimus.ietf.org
Delivered-To: ietfarch-keyprov-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D933A68D0; Thu, 10 Jul 2008 01:55:37 -0700 (PDT)
X-Original-To: keyprov@core3.amsl.com
Delivered-To: keyprov@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AC73A6849 for <keyprov@core3.amsl.com>; Thu, 10 Jul 2008 01:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.052
X-Spam-Level: *
X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9GGxhbNeBrd for <keyprov@core3.amsl.com>; Thu, 10 Jul 2008 01:55:11 -0700 (PDT)
Received: from frhub1.activcard.fr (frhub1.activcard.fr [91.151.120.133]) by core3.amsl.com (Postfix) with ESMTP id 710733A68D0 for <keyprov@ietf.org>; Thu, 10 Jul 2008 01:55:10 -0700 (PDT)
Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id A85FD25ED3C; Thu, 10 Jul 2008 10:55:31 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 10 Jul 2008 10:55:27 +0200
Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC40203F16E@sur-corp-ex-02.corp.ad.activcard.com>
In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C9DF4501@mou1wnexmb10.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs
Thread-Index: Acihb52vIXPZfM+dQBGaWxrT4r5ocAAVy7xQAHs9/BAAB0GJoAAC0jWgARViyUAASBMeYAFfxKKAAAGFK/UAAAvvgANQaPGwAZRV6yADujT6IAG6oWTwATCmQMAA+mvdEAA5sAPgAB8N+EAABvosEA==
References: <9ED76AB595E4944BB33D8998DE448D110160C92D@CORPUSMX10B.corp.emc.com><5BFE9E473DBFC24CA87F18F29B3F0AC40203F0D3@sur-corp-ex-02.corp.ad.activcard.com><5BFE9E473DBFC24CA87F18F29B3F0AC40203F105@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F12D@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F159@sur-corp-ex-02.corp.ad.activcard.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40203F164@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C9DF4501@mou1wnexmb10.vcorp.ad.vrsn.com>
From: Philip Hoyer <philip.hoyer@actividentity.com>
To: "Pei, Mingliang" <mpei@verisign.com>, SMachani@diversinet.com, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, robert.philpott@rsa.com, andrea.doherty@rsa.com
Cc: keyprov@ietf.org
Subject: Re: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/keyprov>
List-Post: <mailto:keyprov@ietf.org>
List-Help: <mailto:keyprov-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0877723143=="
Sender: keyprov-bounces@ietf.org
Errors-To: keyprov-bounces@ietf.org
Ming, Thanks for the time to help out first. On the matter of URIs I actually agree with you and we should change the current spec to become: HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp <http://www.ietf.org/keyprov/pskc#hotp> OCRA: URI: http://www.ietf.org/keyprov/pskc#OCRA-1:(ocra_suite_parameters) TOTP: URI: http://www.ietf.org/keyprov/pskc#totp Since PSKC is mainly to transmit keys regarding a specific use I do not think we need to have the OCRA '-' means all approach. One will always have specific OCRA suite parameters. - Should we also use ExtensionsType in KeyDataType in place of the following? <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> No I strongly believe we should NOT do this here because of the consistency of the subelement structure. Everything underneath KeyData follows: <elementName> <PlainValue> <ENcryptedValue> </elementName> If we would add an Extensions tag this consistent structure would be broken. - Should we recommend <ValueMAC> in all key data where value is encrypted? In particular, should we add a ValueMAC for secxzgzbret data in PBE based example 11.4? We had it in v1.3. I prefer to add it. No we really discussed this with Magnus, ValueMAC should only be there for algorithms where integrity checks are not built in. Actually our examples using AES CBC from my understanding have integrity checks built into the algorithm so we would not need this either. Maybe it would be better to have a recommendation for which algorithms it should be there. Do you have an idea of which supported algorithms do have built in integrity checks? - Element name for type xs:ID KeyPropertiesId in <KeyPropertiesType> Id in <DerivedKeyType> Shall we also change them to "ID" for consistency? Yes you are right KeypropertisId should be just 'ID' I will change this. - Section 5.2 The following sentence doesn't sound smooth: "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm to use with the secret key, for profiles are described in Section 6.3" Should it be "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm to use with a secret key for the profiles described in Section 6.3" Agree will change it Philip ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com] Sent: Thursday, July 10, 2008 6:47 AM To: Philip Hoyer; SMachani@diversinet.com; Hannes Tschofenig; Hallam-Baker, Phillip; robert.philpott@rsa.com; andrea.doherty@rsa.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs Hi Philip, Here are some of my comments on the draft and a few minor fixes made. See the attached version including my few changes. Comments: - Three issues with regard to defining algorithm URI: 1. Shouldn't we use a permanent URI should be used instead of file location? For example TOTP and OCRA algorithm URI is defined by their current v00 RFC draft URL. When the draft changes, we have to change the URI again. URI: http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt <http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-00.txt> OCRA: http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-varian ts-07.txt#OCRA-1:HOTP-SHA512-8:C-QN08 <http://www.ietf.org/internet-drafts/draft-mraihi-mutual-oath-hotp-varia nts-07.txt#OCRA-1:HOTP-SHA512-8:C-QN08> 2. Consistency HOTP: URI: http://www.ietf.org/keyprov/pskc#hotp <http://www.ietf.org/keyprov/pskc#hotp> TOTP: URI: <RFC doc URL> Let us use either the RFC URL (when final) or the style of HOTP as above. Considering that hmac-sha1 URI isn't necessarily defined by its RFC URL http://www.ietf.org/rfc/rfc2104.txt but http://www.w3.org/2000/09/xmldsig#hmac-sha1 we don't have to use RFC draft URL for URI. We may continue to use the pattern for HOTP to define TOTP and OCRA as follows for a consistent approach. HOTP URI: http://www.ietf.org/keyprov/pskc#totp <http://www.ietf.org/keyprov/pskc#totp> OCRA URI: http://www.ietf.org/keyprov/pskc#OCRA-1:HOTP-SHA512-8:C-QN08 The pros of this pattern is the URI doesn't attach to a moving URL from draft to draft. The cons is that the URI is somehow associated with pskc. Suggest to track this an issue to discuss during IETF-72. 3. OCRA URI definition with regard to the parameters OCRA-1:HOTP-SHA512-8:C-QN08 Shall we just use "-" for all? Shall we list all options for registration here or we want the IANA to look at the OCRA document to find all options? - Should we also use ExtensionsType in KeyDataType in place of the following? <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> - Should we recommend <ValueMAC> in all key data where value is encrypted? In particular, should we add a ValueMAC for secxzgzbret data in PBE based example 11.4? We had it in v1.3. I prefer to add it. - Element name for type xs:ID KeyPropertiesId in <KeyPropertiesType> Id in <DerivedKeyType> Shall we also change them to "ID" for consistency? - Section 5.2 The following sentence doesn't sound smooth: "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm to use with the secret key, for profiles are described in Section 6.3" Should it be "KeyAlgorithm (OPTIONAL), the unique URI of the type of algorithm to use with a secret key for the profiles described in Section 6.3" - Changes made: 1. Section 11.4 and 11.5 Example change: <PlainValue>0</PlainValue> to <pskc:PlainValue>0</pskc:PlainValue> 2. Change all occurence of pskc:ExtensionType to pskc:ExtensionsType - Ming ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] Sent: Wednesday, July 09, 2008 7:39 AM To: Pei, Mingliang; SMachani@diversinet.com; Hannes Tschofenig; Hallam-Baker, Phillip; robert.philpott@rsa.com; andrea.doherty@rsa.com Cc: keyprov@ietf.org Subject: RE: [KEYPROV] [pskc] Latest draft of PSKC - no more name value pairs Another day another edition. I realized that the IntegerDataType was actually creating BigIntegers in java since it was of type xs:integer and hence have changed it to xs:int to more reflect what we need. And I have also renamed it to intDataType to be in line with the longDataType used for counters. The OCRA example was also corrected and some nits from Sean Turner abut different spelling of crypto modules in the use cases. Philip Please find attached the latest work in progress draft and related schema after the additions that address Robert Philpott's latest comments (if they resulted in changes to existing changes from draft -04 they have been prefixed [UPDATE]), TODOs: 1. Hannes to change the IANA section relating XML tag registry since not needed anymore 2. Review the spec (Salah, Hannes, Andrea) especially the wording around the new changes (please see KeyData Element definition in the new spec) 3. Add additional elements under KeyData based on input from Rob Philpot 4. Review extension points are correct Changes made from version 4 are: 1. [UPDATE] Added optional Id element to the container in case another document includes more than one container and wants to reference it uniquely, this is of type xs:Id named 'ID' 2. Made PINKeyId of PINPolicy optional (in version 4 it wrongly became mandatory) 3. Changed KeyPropertiesType:KeyPropertiesId from type xs:String to xs:ID 4. [UPDATE] Changed KeyType:KeyPropertiesId from type xs:string to be of type xs:IDREF as it refers to the ID of the element of (3) see directly above, also renamed to simply KeyProperties 5. [UPDATE] Removed PINPolicyId as not needed, Added optional PINPolicyId attribute of type xs:ID to PINPolicyType - 6. Added the KeyContainer:KeyProperties element that was missing from version -04 (oversight).This is where the common properties for a key are actually held within a container 7. Changed PINPolicyType: WrongPINtry into WrongPINTry so that it is proper camel-case but the discussed naming and changed to 'MaxFailedAttempts' 8. Changed PINUsageMode 'InAlgo' to 'Algorithmic' 9. Added description for added extension points (see below) 10. Changed DeviceIdType to DeviceInfoType (please see other email for rational to keep separate type and not move elements directly under Device) 11. Moved Keyporperties in front of device under KeyContainer for more readability 12. Changed Namespace as per Hannes proposal from "urn:ietf:params:xml:ns:keyprov:container:1.0" to "urn:ietf:params:xml:ns:keyprov:pskc:1.0" 13. Cleaned up the way that attributes (no angled brackets) and elements (angled brackets <elementName>) are described in the spec 14. Corrected some spelling and grammar 15. Changed schema and spec to new proposal that removes name value pairs 16. Added OCRA URI to the spec and added an example 17. Added TOTP URI to the spec and added an example 18. Added an example of KeyProperties 19. Added 'Append' to PIN for completeness. 20. Corrected the wrong 'MANDATORY' in the usage description of KeyType and KeyPropertiesType 21. Added the following comment the elements of type xs:dateTime: "MUST be expressed in UTC form, with no time zone component. Implementations SHOULD NOT rely on time resolution finer than milliseconds and MUST NOT generate time instants that specify leap seconds." 22. Moved StartDates before ExpiryDates for easier readability 23. Added the following sub-elements to PINPolicyType a. <MinLength (OPTIONAL)>, the minimum lenght of a PIN that can be set to protect this key. It MUST not be possible to set a PIN shorter than this value. If the Format element is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value. b. <MaxLength (OPTIONAL)>, the maximum lenght of a PIN that can be set to protect this key. It MUST not be possible to set a PIN longer than this value. If the Format element is 'DECIMAL', 'HEXADECIMAL' or 'ALPHANUMERIC' this value indicates the number of digits/characters. If the Format attribute is 'BASE64' or 'BINARY', this value indicates the number of bytes of the unencoded value. c. <Format (OPTIONAL)>, defines the format of the PIN and MUST be one of the values defined in Section 5.4.3 24. [Update] Extension points: Changed to model proposed by Rob Philpott declaring a new type: <xs:complexType name="ExtensionsType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="definition" type="xs:anyURI" use="optional"/> </xs:complexType> Which has been added as "<xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/>" To: 1. KeyContainerType 2. KeyPropertiesType 3. KeyType 4. PINPolicy 5. DeviceInfoType 6. DeviceType 7. UsageType Please NOTE that KeyData still has the existing "<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>" Because of the special nature of the KeyData element and subelements PINUsageMode too maintains the existing "<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>" Being an extensible enumeration Added a '<xs:anyAttribute namespace="##other"/>' to: 1. UsageType (since it contains the attributes of ' <xs:attribute name="OTP" type="xs:boolean" default="false"/> <xs:attribute name="CR" type="xs:boolean" default="false"/> <xs:attribute name="Integrity" type="xs:boolean" default="false"/> <xs:attribute name="Encrypt" type="xs:boolean" default="false"/> <xs:attribute name="Unlock" type="xs:boolean" default="false"/> So I thought it would be wise to be able to extend this Outstanding issues that need to be discussed: 1. Most of the examples have been hand-composed in XML so not verified 2. Some examples use explicit 'pskc:' namespace not sure we need to do this but maybe we should be consistent Philip ________________________________ From: andrea.doherty@rsa.com [mailto:andrea.doherty@rsa.com] Sent: Friday, May 30, 2008 4:36 PM To: keyprov@ietf.org Cc: Philip Hoyer Subject: FW: [KEYPROV] [pskc] Latest draft of PSKC Here is Philip Hoyer's response to Rob's comments (see below), which we initially handled offline, and then we decided it would be better to further the discussion on the mailing list. -- Andrea 1. Use of xs:ID attributes: a. The xs:ID datatype is only used in the DerivedKeyType complexType. xs:ID is the preferred mechanism for referring to other XML elements in an instance document. So why are custom attributes defined to be able to referto elements of the types KeyPropertiesType (the "KeyPropertiesId" attribute) and KeyType ("KeyId")? Why don't these use xs:ID attributes? [PH] good point I was thinking that xs:Id for KeyPropertiesId could be a good choice The KeyId on the other hand is not really used to be referred to. Do you think it would be better to use xs:ID for this aswell? And in case we use it now is it backwards compatible to what we have? b. Why doesn't a KeyContainer have an (optional) ID that could be used to reference it in an instance document? [PH] valid comment and I will think we should add this c. Same question for PINPolicy? [PH] agreed d. The use of the DeviceIdType is inconsistent with other "ID"'s (that are used for referential information). The elements in the DeviceIDType seem more appropriate for the DeviceType or KeyType elements. At a minimum, I would not call this a "DeviceIdType" (perhaps "DeviceInfoType"?) but really, I would just put its elements directly in the DeviceType complexType). I would also give <Device> elements an optional referential ID via xs:ID. [PH] so basically you are saying that any high level entity (Key, Device, KeyContainer etc) should have an ID that is xs:ID? The thought of DeviceId was to aggregate under a specific type the elements that comprise the compound key to look up the device e. Section 5.2.1 says that the DeviceIdType is an extensible type, but there are no extension points in it. [PH] agreed I think we should add an xs:any 2. We are really unhappy with the proposed extensibility mechanism. This goes against general XML schema best practice. Defining extension points via xs:any/xs:anyAttribute is vastly superior (IMO): [PH] this has been extensively discussed at IETF and there are pros and cons for all approaches. The pro's of the name value approach is that it will be re-usable for the ASN.1 spec and that we will have a semantic registry defined by IANA. a. The use of "Reserved data attribute names" as described in section 7 is really difficult to work with. First, <Data> elements should ONLY be used for "real" extensions... i.e. things that aren't already known at the time the spec is written. If we already know that the items defined in section 7 are needed, they should just be defined in the schema with their own element/attribute definitions. They should not be "reserved" uses of the <DATA> element. We just don't understand the desire to do it this way. Having explicitly defined elements also allows for more flexible datayping. [PH] this has been extensively discussed. And we opted for the name value pair approach. This mean that all elements in Data can be parsed in the same manner and individually be encrypted or not. There will be a centralized semantic registry by IANA, etc b. This mechanism only lets us create very simple name-value pair extensions. If we have some small groups of related extensions, we'd really like to be able to define them externally in a private schema via their own complexType definitions. With the current method, it's going to be very messy to add groups of extensions or extensions that have more complex data values. [PH] why do you say that, the name could be also be a namespace for an wholly encrypted or base64 encoded XML sub node. I see your point though in terms of parsing here. Could you give me an example of what you had in mind since we have considered quite a few use cases and not come across the requirement for grouped extensions. c. It is also a pain for implementers to deal with the limitation of the data typing available for unencrypted <Data> elements. For example, for a SecurID token with a display interval of 60 seconds, I cannot simply use an xml schema-defined datatype of xs:integer with a value of "60". I have to Base64-encode the big-endian 2-byte binary value for 60 seconds (and then decode it on the receiving end). Why is this necessary? I could define such an item with a single XML element, but here I need 3 or 4. [PH] using xs:string for plainvalue was discussed during the last IETF meeting (I personally am in favor of it) but Sean Turner and the rest of the people did not see much value in it. If we use string we will need to deice for specific data elements what the encoding rules are. For example do we say for 8 byte unsigned int to encode just string e.g. '60' or leading 0 examples '00000060'. I would appreciate your thoughts on this. Also how would we encode binary data in string form base64 encoded? d. This approach does not produce "readable" XML since the data values are always Base64-encoded. That is just crazy when the data is not sensitive in nature. Please do not underestimate the value of being able to look at data in an instance document and know what it is without having to run it through a Base64 decoder! This is a major drawback. [PH] agreed and see answer above 3. RE: PINPolicy: a. If I specify a PINPolicy, I am forced to specify a PINKeyID, which forces me to create another Key element (even if I don't have any additional PIN policy info that I need to pass along in that Key element). For 90% of the use cases, this referential style of description is overkill and makes the instance document much more complex than it needs to be. [PH] if you are referring to the fact that '<xs:attribute name="PINKeyId" type="xs:string" use="required"/>' is set to required I agree with you. We should set this to 'optional'. I do not agree with your 90% use case analysis since the main use cases I have come across where to transmit the initial random pin for PINPads tokens within the same PSKC document from manufacturing to the validation server. b. The PINPolicy element only contains "policy" attributes for "WrongPINtry" and "PINUsageMode" and the element is not directly extensible. Any extensions we need have to go in Data elements inside a separate Key element that the PINPolicy then references. IMO, PIN policy info should be in the PINPolicy element, not in a separate "Key" element! The only thing that should go in the Key element is a PIN value that is being expressly communicated with the instance document. That is, a PIN value IS a key; PIN policy information IS NOT a key. [PH] I agree we need to make PINPolicy extensible and not put stuff into the Data elements of the PINKey. Are there any other elements that you know of we should include now and not just as an xs:any extension? c. It seems to us that there are additional universally-known PIN policy attributes that should be included in the schema. Things such as the PIN's maximum and minimum length and it's data type (integer, alphanumeric). Unless these are part of the spec, we currently are forced to create custom Data elements for them (and put them in a referenced Key element). BTW - Just to be clear, I am talking about the POLICY information associated with whatever PIN a user uses with their token. I'm not talking about the attributes of a specific PIN value that can be expressed in a Key element. As an example, to express a min and max PIN length policy, we have to create custom Data elements in a separate Key element (and also Base64 encode the values). I'm sorry, but this is getting ridiculous. <Key KeyId="07552252661" KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin"> <Data Name="PIN_MIN_LENGTH"> <PlainValue>NA==</PlainValue> </Data> <Data Name="PIN_MAX_LENGTH"> <PlainValue>OA==</PlainValue> </Data> </Key> [PH] no the format and length would be in the UsageElement of the PINKey. I had hoped Example (Section 12.2 of the spec) would make that clear here is the XML fragment: <Key KeyId="07552252661" KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin"> <Usage> <ResponseFormat Length="4" Format="DECIMAL"/> </Usage> <Data Name="SECRET"> <PlainValue>MTIzNA==</PlainValue> </Data> </Key> Notes: a. If I had an xs:any extension point, I could express this in 2 lines of XML in the PinPolicy element. b. This example doesn't include the PIN format, which would require me to either: i. Use another custom Data element ii. Include a ResponseFormat element that then requires inclusion of a "Length" attribute. But what would the Length attribute really mean in this case? d. Why isn't a PINPolicy reusable across multiple tokens (it has no ID that can be used in a reference from a token definition). If I want to define a PINPolicy that applies to multiple tokens, the PINPolicy element needs its own ID. [PH] I see your point. If we make PINKeyId optional as in the comment above you can have a common PINPolicy as part of the shared KeyProperties. I believe that would serve your purpose. e. The "WrongPINtry" element name (in PINPolicyType) is not consistent with the other camel-case names ("try" should be "Try"). [PH] agreed, will change f. In general, it is undesirable to create abbreviations such as "InAlgo" (in PINUsageMode) to be used as XML keywords. To stay consistent with "Local" and "Prepend", I would strongly suggest something like "Embed" or "Algorithmic". [PH[ we had Embed before and people got confused by the meaning. So maybe Algorithmic is a better choice, that is why I tried to express the use of the PIN in the algorithm as InAlgo. I do not feel very strong about it. Maybe we can have a vote 4. The use of "ResponseFormat" for describing a PIN is very confusing. The spec defines ResponseFormat as follows "The ResponseFormat element defines the characteristics of the result of a computation. This defines the format of the OTP or of the response to a challenge." A PIN is not the result of a "computation", nor is it a response to a challenge. It seems quite odd to use this Key construct for a PIN. I think that either another usage type should be defined or the ResponseFormat definition should be changed to also reflect its use for describing a PIN. [PH] Yes I think we need to change the description. I am getting a lot of push back to include PIN requirements in the spec so I tried to convince people that tit was a good idea without having to introduce to many new schema types. Here you say it is odd to use the Key element for the PIN value but above you agree that a PIN IS a Key. So I would keep it in the Key element buy change description.
_______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www.ietf.org/mailman/listinfo/keyprov
- [KEYPROV] FW: [pskc] Latest draft of PSKC andrea.doherty
- [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Hallam-Baker, Phillip
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Turner, Sean P.
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC andrea.doherty
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- [KEYPROV] FW: [pskc] Latest draft of PSKC andrea.doherty
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC Philip Hoyer
- [KEYPROV] [pskc] Latest draft of PSKC - no more n… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… robert.philpott
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Pei, Mingliang
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… robert.philpott
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… andrea.doherty
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… andrea.doherty
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Latest draft of PSKC - no mo… Philip Hoyer
- Re: [KEYPROV] [pskc] Draft-05 of PSKC submitted t… Philip Hoyer
- Re: [KEYPROV] [pskc] Draft-05 of PSKC submitted t… Hannes Tschofenig