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

["Pei, Mingliang" <[e-mail]>]

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
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> KEYPROV mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyprov
> _______________________________________________
> KEYPROV mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyprov
>