Re: [KEYPROV] FW: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp

[Peter Saint-Andre <[e-mail]>]

As long as we're compliant with URN syntax, I don't have a strong
preference, although I agree that prf-aes-128 is slightly cleaner.

On 6/15/10 10:18 AM, Pei, Mingliang wrote:
> 
> I prefer the style 
> 
>  urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
> 
> to
> 
>  urn:ietf:params:xml:ns:keyprov:dskpp:prf:aes-128
> 
> The later style makes prf a category. If we use this style, we may want
> to categorize all others, e.g. key algorithm, prf, key wrap etc. as
> 
>  urn:ietf:params:xml:ns:keyprov:pskc:alg:hotp
>  urn:ietf:params:xml:ns:keyprov:dskpp:container:pkcs12
>  urn:ietf:params:xml:ns:keyprov:dskpp:keywrap:transport
> 
> prf-aes-128 looks more intuitive to me without introducing the category
> in URN space.
> 
> - Ming
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Philip Hoyer
>> Sent: Tuesday, June 15, 2010 8:19 AM
>> To: [e-mail]; [e-mail]
>> Subject: Re: [KEYPROV] FW: DISCUSS and COMMENT: 
>> draft-ietf-keyprov-dskpp
>>
>> Andrea,
>> Just wondering if
>>
>> urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
>> urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
>>
>> Might not be better expressed as
>>
>> urn:ietf:params:xml:ns:keyprov:dskpp:prf:aes-128
>> urn:ietf:params:xml:ns:keyprov:dskpp:prf:sha256
>>
>> And maybe the 
>>
>>> URNs: urn:ietf:params:xml:schema:keyprov:dskpp:transport
>>> urn:ietf:params:xml:schema:keyprov:dskpp:wrap
>>> urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
>>
>> urn:ietf:params:xml:schema:keyprov:dskpp:wrap:transport
>> urn:ietf:params:xml:schema:keyprov:dskpp:wrap:simple
>> urn:ietf:params:xml:schema:keyprov:dskpp:wrap:passphrase
>>
>> you know to distinguish the URNs directly.
>>
>> I also agree with Peter that for interoperability we might 
>> need to mandate that DSKPP server MUST implement a HTTP 
>> binding of DSKPP.
>>
>> Philip
>>
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of [e-mail]
>> Sent: Monday, June 14, 2010 6:14 PM
>> To: [e-mail]
>> Subject: [KEYPROV] FW: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp
>>
>> All,
>> Here is feedback that I received from Peter Saint-Andre 
>> regarding my point-to-point responses to him of last week.
>> Andrea
>>  
>>
>> -----Original Message-----
>> From: Peter Saint-Andre [mailto:[e-mail]]
>> Sent: Wednesday, June 09, 2010 12:05 AM
>> To: Doherty, Andrea
>> Cc: [e-mail]; [e-mail]; 
>> [e-mail]
>> Subject: Re: DISCUSS and COMMENT: draft-ietf-keyprov-dskpp
>>
>> On 6/8/10 11:28 AM, [e-mail] wrote:
>>> Peter,
>>>
>>> Thank you for your thoughtful and thorough review.  Below 
>> please find 
>>> point-by-point responses.
>>>
>>> Regards, Andrea
>>>
>>> -----Original Message----- From: Peter Saint-Andre 
>>> [mailto:[e-mail]] Sent: Wednesday, May 05, 2010 11:32 PM
>>> To: [e-mail] Cc: [e-mail]; 
>>> [e-mail] Subject: DISCUSS 
>> and COMMENT:
>>> draft-ietf-keyprov-dskpp
>>>
>>> Discuss: 1. The defined and referenced identifiers are described as 
>>> URIs of the form xmlns:foo="someUri" and each identifier 
>> specifies a 
>>> prefix such as "foo". For example:
>>>
>>> The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
>>>
>>> xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
>>>
>>> References to qualified elements in the DSKPP schema defined herein 
>>> use the prefix "dskpp".
>>>
>>> The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the 
>>> "xmlns:dskpp=" preceding the URI so to reduce confusion it would be 
>>> best to include only the URI. Also, is the prefix "dskpp" 
>> hardcoded, 
>>> or are developers allowed to use any prefix? The point of XML 
>>> namespaces was not to hardcode prefixes, so it would be best to say 
>>> that the "dskpp" prefix is used in examples here but any prefix is 
>>> allowed.
>>>
>>> [Doherty, Andrea] Agree; will reword to state:
>>>
>>> The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
>>>
>>> "urn:ietf:params:xml:ns:keyprov:dskpp"
>>>
>>> References to qualified elements in the DSKPP schema defined herein 
>>> use the prefix "dskpp", but any prefix is allowed.
>>
>> Good.
>>
>>> 2. In Section 2.1, the Authentication Code is defined as follows:
>>>
>>> Authentication Code (AC):  User Authentication Code comprised of a 
>>> string of numeric characters known to the device and the server and 
>>> containing a client identifier and a password.  This 
>> ClientID/password 
>>> combination is used only once, and then discarded.
>>>
>>> However, in Section 3.4.1.1 the Authentication Code format does not 
>>> seem to be strictly numeric, because it is a series of 
>>> Type-Length-Value triads encoded as hexadecimal.
>>>
>>> [Doherty, Andrea] Yes, there are inconsistencies between how the 
>>> Authentication Code was defined (Section 2.1), and how it was being 
>>> used (Section 3.4.1.1).  Please refer to the attached text, 
>> which is 
>>> how we propose to change these sections to address this issue.
>>
>> That text is excellent. I especially appreciate the detailed examples.
>>
>>> 3. In Section 3.4.1.1, the Password TLV is defined as follows:
>>>
>>> The Password is a mandatory TLV the contains a one-time use shared 
>>> secret known by the user and the Provisioning Server.  The password 
>>> value is unique and SHOULD be a random string to make AC more 
>>> difficult to guess.  The string MUST be UTF-8 encoded in accordance 
>>> with [RFC3629].  For example, suppose password is set to 
>> "3582", then 
>>> the TLV would be {0x2, 0x4, UTF-8("3582")}.
>>>
>>> Does the Password really need to be UTF-8? Is it expected that 
>>> characters outside the US-ASCII range will be used? Given that the 
>>> next paragraph talks about "the typed password", this 
>> document seems 
>>> to assume that a user will input this password using a 
>> keyboard. Can 
>>> we safely assume that a user will be able to input any UTF-8 
>>> character, such as U+233B4 (from RFC 3629)? To ensure that the 
>>> user-typed password matches what is on file at the Provisioning 
>>> Server, this document might need to specify normalization 
>> of the typed 
>>> password using Net-Unicode, SASLprep, or some other string 
>> preparation 
>>> technology.
>>>
>>> [Doherty, Andrea] Please refer to the attached text, which 
>> is how we 
>>> propose to change Section 3.4.1.1. Our intent is that the new text 
>>> will, among other things, address the issue raised here 
>> with respect 
>>> to the Password TLV.
>>
>> Your proposed text addresses my concerns.
>>
>>> In addition to the attached text, I'll add
>>> draft-resman-idna2008-mappings-01 as an informative reference and 
>>> insert the correct ref# in the text.
>>
>> OK. I need to think a bit about whether the mappings in that 
>> document are always desirable for your usage. Consider, for 
>> example, the mapping of upper case characters to lower case 
>> characters (which makes sense for domain names but not 
>> necessarily for client IDs or passwords).
>>
>>> 4. In Section 5.1.2, the key wrapping algorithms are confusingly 
>>> identified, because it appears on a cursory reading that "KW-AES128 
>>> without padding" and "KW-AES128 with padding" have the same 
>>> identifier, when in fact they are identified by id-aes128-wrap and 
>>> id-aes128-wrap-pad respectively in 
>>> draft-housley-aes-key-wrap-with-pad-02.
>>>
>>> [Doherty, Andrea] Yes, the references in this section are incorrect.
>>> This is easier to reconcile now that the originally 
>> referenced I-D is 
>>> an RFC (#3394) and since the latest version of XML Encryption now 
>>> includes a reference to this RFC.  XMLENC is, however, a normative 
>>> reference, and the version that references id-aes128-wrap-pad is a 
>>> Working Draft, due out of W3C LC June 10 (Candidate Draft not ready 
>>> until the Fall of 2010).  As such, here's how I propose to 
>> change the
>>> text:
>>>
>>> AES128 KeyWrap - refer to id-aes128-wrap in [RFC5649] and
>>> http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
>>>
>>> AES128 KeyWrap with Padding - refer to id-aes128-wrap-pad 
>> in [RFC3394] 
>>> and http://www.w3.org/2001/04/xmlenc#kw-aes128 in [XMLENC]
>>>
>>> AES-CBC-128 - refer to [FIPS197-AES] and 
>>> http://www.w3.org/2001/04/xmlenc#aes128-cbc in [XMLENC]
>>
>> That's better.
>>
>>> 5. Appendices D.2.1 and D.3.1 define the following algorithm
>>> identifiers:
>>>
>>> http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
>>> http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256
>>>
>>> It's not clear what the IETF policy is on the use of 
>> ietf.org URIs as 
>>> identifiers, but these URIs appear to be used without authorization.
>>>
>>> [Doherty, Andrea] Agree; will switch these to URNs in the keyprov 
>>> parameters space and ask IANA to create a sub registry for 
>> each.  The 
>>> URNs will appear as:
>>> urn:ietf:params:xml:ns:keyprov:dskpp#dskpp-prf-aes-128
>>> urn:ietf:params:xml:ns:keyprov:dskpp#dskpp-prf-sha256
>>
>> I'm sorry, but now we have a second issue: as I have recently 
>> discovered, the '#' character is not recommended in URNs, see Section
>> 2.3.2 of RFC 2141:
>>
>>    RFC 1630 [2] reserves the characters "/", "?", and "#" for 
>> particular
>>    purposes. The URN-WG has not yet debated the applicability and
>>    precise semantics of those purposes as applied to URNs. Therefore,
>>    these characters are RESERVED for future developments.  Namespace
>>    developers SHOULD NOT use these characters in unencoded form, but
>>    rather use the appropriate %-encoding for each character.
>>
>> Thus I would suggest the following:
>>
>>    urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
>>    urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
>>
>>> 6. Section 5 mentions a URN of
>>> urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined 
>> in [PSKC] 
>>> but that URN is not to be found in
>>> draft-ietf-keyprov-portable-symmetric-key-container-03
>>>
>>> [Doherty, Andrea] Thanks for catching this.  The PSKC authors have 
>>> agreed to register a new URN for KeyContainer in the soon 
>> next draft 
>>> of the PSKC I-D.  Note also that I will update the 
>> reference to PSKC 
>>> accordingly.
>>
>> And note also that the same issue with the '#' character applies here.
>> I've followed up with the PSKC authors about that.
>>
>>> 7. Several URNs containing fragment identifiers are defined in 
>>> Sections 5.1.1, 5.1.2, and 5.1.3:
>>>
>>> urn:ietf:params:xml:schema:keyprov:dskpp#transport
>>> urn:ietf:params:xml:schema:keyprov:dskpp#wrap
>>> urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap
>>>
>>> However, the "#" character is discouraged in URNs according to RFC
>>> 2141:
>>>
>>> RFC 1630 [2] reserves the characters "/", "?", and "#" for 
>> particular 
>>> purposes. The URN-WG has not yet debated the applicability 
>> and precise 
>>> semantics of those purposes as applied to URNs.
>>> Therefore, these characters are RESERVED for future developments.
>>> Namespace developers SHOULD NOT use these characters in unencoded 
>>> form, but rather use the appropriate %-encoding for each character.
>>>
>>> Therefore it seems preferable to change "#" to ":" (or some other 
>>> non-reserved character) in these URNs.
>>>
>>> [Doherty, Andrea] Agree; will change "#" to ":" in the following
>>> URNs: urn:ietf:params:xml:schema:keyprov:dskpp:transport
>>> urn:ietf:params:xml:schema:keyprov:dskpp:wrap
>>> urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
>>
>> Thanks. See above.
>>
>>> 8. Given that "the principal syntax is XML", a normative 
>> reference to
>>> http://www.w3.org/TR/2006/REC-xml-20060816 is needed.
>>>
>>> [Doherty, Andrea] Agree; will add a normative reference to [XML].
>>> Note that I'll update the reference to point to the latest 
>> published 
>>> version of the W3C Recommendation, 
>>> http://www.w3.org/TR/2008/REC-xml-20081126/.  I also note that the 
>>> Informative Reference to [XMLNS] should be updated to the latest 
>>> edition http://www.w3.org/TR/2009/REC-xml-names-20091208/.
>>
>> Good catch.
>>
>>> 9. Section 3.1 says that DSKPP "is layered on a transport mechanism 
>>> such as HTTP" but Section 3.2.2 says that "DSKPP messages 
>> ... are sent 
>>> over HTTPS", so a reference to RFC 2616 (probably along with RFC
>>> 2818) would be appropriate.
>>>
>>> [Doherty, Andrea] Agree; will add reference to RFC2616 and RFC2818 
>>> here.  Note that per Alexey's DISCUSS #9, I will be making the
>>> RFC2616 reference Normative.  However, as there is not a normative 
>>> mapping to HTTPS, I will be making the reference to RFC2818 
>>> Informative.
>>
>> Agreed.
>>
>>> 10. Section 3.2.2 states the following about certificate 
>> validation or 
>>> server identity checking:
>>>
>>> In Step 1, the client establishes a TLS connection, and 
>> authenticates 
>>> the server (that is, validates the certificate, and 
>> compares the host 
>>> name in the URL with the certificate)
>>>
>>> Section 4.2.3 states:
>>>
>>> If K is equivalent to K_SERVER, then the cryptographic 
>> module SHOULD 
>>> verify the server's certificate before using it to encrypt R_C in 
>>> accordance with [RFC5280].
>>>
>>> However, no details are provided regarding certificate validation.
>>> Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is 
>>> needed.
>>>
>>> [Doherty, Andrea] As per DISCUSS #9, I will be adding an 
>> Informative 
>>> Reference to RFC2818 in Section 3.1.  Does this address 
>> your concern?
>>> By "a reference to Section 3.1" did you mean here that a 
>> reference to 
>>> Section 3.1 should be added to Sections 3.2.2 and Section 4.2.3?
>>
>> I think it would be appropriate to reference Section 3.1 of 
>> RFC 2818 whether you talk about certificate validation (that 
>> would be from Sections 3.2.2 and 4.2.3 of your document).
>>
>>> 11. In Section 3.4.3, "the resultant string is hashed using 
>> SHA-256 in 
>>> accordance with [FIPS180-SHA]"; has any thought been given to hash 
>>> agility?
>>>
>>> [Doherty, Andrea] Yes, esp. as this was raised as a DISCUSS item by 
>>> Russ Housley and Brian Carpenter.  I responded to both 
>> Brian and Russ 
>>> to their satisfaction (I also updated the draft to v11; Brian 
>>> confirmed that the change is acceptable, as did Russ through email; 
>>> however, the IESG DISCUSS has not yet been removed).  
>> Here's how the 
>>> topic was addressed in the latest draft:
>>>
>>> * Change Section 1.2, "Versions", to read:
>>>
>>> "There is a provision made in the syntax for an explicit version 
>>> number.  Only version "1.0" is currently specified.
>>>
>>> The purpose for versioning the protocol is to provide a 
>> mechanism by 
>>> which changes to required cryptographic algorithms (e.g., 
>> SHA-256) and 
>>> attributes (e.g., key size) can be deployed without disrupting 
>>> existing implementations; likewise out-dated implementations can be 
>>> de-commissioned without disrupting operations involving 
>> newer protocol 
>>> versions."
>>
>> Aha, I see that you have addressed algorithm agility via 
>> protocol versioning. That's perhaps a bit heavy-handed (do 
>> you really need to rev the entire protocol whenever you need 
>> to upgrade the algorithms used in the protocol?), but it will work.
>>
>>> * Add the following to the Security Considerations Section 10.6 on 
>>> "Miscellaneous Considerations"
>>>
>>> "Many protocols need to be algorithm agile.  One reason for this is 
>>> that in the past many protocols had fixed sized fields for 
>> information 
>>> such as hash outputs, keys, etc.  This is not the case for DSKPP, 
>>> except for the key size in the computation of DSKPP-PRF.
>>> Another reason was that protocols did not support algorithm 
>>> negotiation.  This is also not the case for DSKPP, except 
>> for the use 
>>> of SHA-256 in the MAC confirmation message.  Updating the 
>> key size for 
>>> DSKPP-PRF or the MAC confirmation message algorithm will 
>> require a new 
>>> version of the protocol, which is supported with the Version 
>>> attribute."
>>
>> Yes, that's fine.
>>
>>> 12. Section 4.2.1 states:
>>>
>>> 3.  The web application processes the request and returns an 
>>> authentication code to the user, e.g., in the form of an 
>> email message
>>>
>>> Is it considered a best practice to send the authentication 
>> code via 
>>> email? Nothing is said here about protection of this 
>> message (whether 
>>> sent via email or some other method).
>>>
>>> [Doherty, Andrea] We agree that the example in Section 4.2.1 is not 
>>> the best example. I propose to change the text to: 3.  The web 
>>> application processes the request and returns an 
>> authentication code  
>>> to the user, e.g., in response to an enrollment request via 
>> a secure 
>>> web session.
>>
>> That's better.
>>
>>> 13. Section 10.1 says:
>>>
>>> DSKPP SHOULD, therefore, be run over a transport providing 
>>> confidentiality and integrity, such as HTTP over Transport Layer 
>>> Security (TLS) with a suitable ciphersuite, when such threats are a 
>>> concern.
>>>
>>> Why not MUST?
>>>
>>> [Doherty, Andrea] Will change to MUST.
>>
>> Thanks.
>>
>>> 14. Section 10.6.3 says:
>>>
>>> DSKPP servers MUST authenticate themselves...
>>>
>>> Does this mean that a DSKPP client MUST authenticate the server to 
>>> which it connects?
>>>
>>> [Doherty, Andrea] Yes.  Here is how I plan to reword Section 10.6.3.
>>>  Whenever a successful DSKPP 2-pass protocol run would result in an 
>>> existing K_TOKEN being replaced by a K_TOKEN', the DSKPP client and 
>>> server MUST do the following to prevent a denial-of-service attack 
>>> where an unauthorized DSKPP server replaces a K_TOKEN with another
>>> key: * The DSKPP server MUST use the AuthenticationDataType 
>> extension 
>>> to transmit a second MAC, calculated as described in 
>> Section 5.2.2. * 
>>> The DSKPP client MUST authenticate the server using the MAC 
>> contained 
>>> in the AuthenticationDataType extension received from the 
>> DSKPP server 
>>> to which it is connected.
>>
>> Good.
>>
>>> 15. Section 11 states:
>>>
>>> The DSKPP protocol is mostly meant for machine-to-machine 
>>> communications; as such, most of its elements are tokens 
>> not meant for 
>>> direct human consumption.  If these tokens are presented to the end 
>>> user, some localization may need to occur.
>>>
>>> Because localization methods are not specified, it is doubtful that 
>>> developers will be able to produce interoperable implementations.
>>> More details are needed here.
>>>
>>> [Doherty, Andrea] These tokens will not be presented to the users.
>>> Therefore, I propose to remove the words, "mostly" and 
>> "most of", and 
>>> the sentence, "If these tokens are presented to the end user, some 
>>> localization may need to occur."
>>
>> If these tokens will not be presented to users, then we don't 
>> need to care about localization. See RFC 2277: 
>> "Internationalization is for humans." Problem solved. :)
>>
>>> The new paragraph will look like
>>> this: The DSKPP protocol is meant for machine-to-machine 
>>> communications; as such, its elements are tokens not meant 
>> for direct 
>>> human consumption. DSKPP exchanges information using XML. All XML 
>>> processors are required to understand UTF-8 [RFC3629] and UTF-16 
>>> [RFC2781] encoding, and therefore all DSKPP clients and 
>> servers MUST 
>>> understand UTF-8 and UTF-16 encoded XML.  Additionally, 
>> DSKPP servers 
>>> and clients MUST NOT encode XML with encodings other than UTF-8 or 
>>> UTF-16.
>>
>> Do we really need to support both UTF-8 and UTF-16?
>>
>>> 16. Section 12.3 (MIME Media Type Registration) has the following
>>> deficiencies:
>>>
>>> - the optional parameter field specifies "charset", but the 
>> default is 
>>> "UTF-8", which is not a character set according to RFC 2277.
>>>
>>> [Doherty, Andrea] In his DISCUSS #8, Alexey pointed out that, "I 
>>> believe the last sentence is in violation of MIME, which requires 
>>> US-ASCII to be the default charset value. This is also in 
>> violation of 
>>> HTTP, which requires ISO-8859-1." So he suggested removing the last 
>>> quoted sentence.  As such, I plan to remove "Default is 
>> UTF-8 from the 
>>> optional parameter field.
>>
>> I'll leave that for Alexey.
>>
>>> - the encoding considerations field needs to mention that 
>>> implementations need to support both UTF-8 and UTF-16
>>
>> See above.
>>
>>> [Doherty, Andrea] I will append the following after "See [RFC3203], 
>>> Section 3.2":  "Implementations need to support both UTF-8 
>> [RFC3629] 
>>> and UTF-16 [RFC2781]."
>>>
>>> - the security considerations field needs to reference this 
>>> specification (especially Section 10), rather than trying 
>> to address 
>>> all security issues in just a few words.
>>>
>>> [Doherty, Andrea] Good point.  I'll append the following 
>> sentence to 
>>> the security consideration field: "Refer to Section 10 of the 
>>> Published Specification for more details".
>>
>> +1
>>
>>> - the interoperability considerations field says "this content type 
>>> provides a basis for a protocol" but that text is not helpful. Are 
>>> there any actual or potential problems with 
>> interoperability? If not, 
>>> say "None" here.
>>>
>>> [Doherty, Andrea] I'll replace "this content type provides 
>> a basis for 
>>> a protocol" with "None".
>>
>> +1
>>
>>> Comment: 1. Section 6 says that "the use of extensions SHOULD be 
>>> carefully considered" but capitalized key words apply to protocols, 
>>> not protocol designers. Suggested text: "protocol designers are 
>>> advised to carefully consider the use of extensions".
>>>
>>> Similar considerations apply to Section 10.4 "Implementers 
>> SHOULD also 
>>> be aware that cryptographic algorithms become weaker with time."
>>>
>>> [Doherty, Andrea] Will rephrase Section 6 to state, "protocol 
>>> designers are advised to carefully consider the use of extensions", 
>>> and Section 10.4 to state, "Implementers are advised that 
>>> cryptographic algorithms become weaker with time."
>>
>> OK.
>>
>>> 2. Section 7.2 "presents a binding of the previous messages to 
>>> HTTP/1.1" but it is not clear if the HTTP binding is 
>>> mandatory-to-implement. This could be added to Section 9.
>>>
>>> [Doherty, Andrea] As stated in Section 3.1, "The principal 
>> syntax is 
>>> XML and it is layered on a transport mechanism such as HTTP."  As 
>>> such, it was not envisaged that HTTP would be 
>> mandatory-to-implement.
>>
>> OK.
>>
>> How will we ensure interoperability if no transport mechanism 
>> is mandatory-to-implement?
>>
>>> 3. Section 1.2 makes provision for versioning, but no guidance is 
>>> provided regarding when the major and minor versions shall be 
>>> incremented, how to compare version numbers, etc. You might 
>> be able to 
>>> borrow some text from Section 4.4.1 of RFC 3920 or some similar 
>>> specification.
>>>
>>> [Doherty, Andrea] Good suggestion.  I'll rename Section 1.2 from 
>>> "Versions" to "Version Support" and append the following paragraphs 
>>> after the sentence, "The purpose for versioning the protocol is to 
>>> provide a mechanism by which changes to required cryptographic 
>>> algorithms (e.g., SHA-256) and attributes (e.g., key size) can be 
>>> deployed without disrupting existing implementations; likewise, 
>>> out-dated implementations can be de-commissioned without disrupting 
>>> operations involving newer protocol versions.  The numbering scheme 
>>> for DSKPP versions is "<major>.<minor>".  The major and 
>> minor numbers 
>>> MUST be treated as separate integers and each number MAY be 
>>> incremented higher than a single digit.  Thus, "DSKPP 2.4" 
>> would be a 
>>> lower version than "DSKPP 2.13", which in turn would be lower than 
>>> "DSKPP 12.3".  Leading zeros (e.g., "DSKPP 6.01") MUST be 
>> ignored by 
>>> recipients and MUST NOT be sent.
>>>
>>> The major version number should be incremented only if the message 
>>> formats or flows have changed so dramatically that an older version 
>>> implementation would not be able to interoperate with a 
>> newer version.  
>>> The minor version number indicates new capabilities, and MUST be 
>>> ignored by an entity with a smaller minor version number, 
>> but used for 
>>> informational purposes by the entity with the larger minor version 
>>> number."
>>
>> Do you envision needing minor version numbers in DSKPP? If 
>> not, you could simplify the text a bit here. Also it might 
>> not make sense to have text about message flows in DSKPP 
>> (that might be appropriate for XMPP but not DSKPP). Perhaps 
>> for you something like this is better: "only if the data 
>> formats or security algorithms"...
>>
>> Thanks for your attention to detail.
>>
>> Peter
>>