Nice work, the wording is really improved. However, I still have two comments:
1. The wording in A.4 is confusing. With RSASSA-PSS, the algorithm object identifier is always id-RSASSA- PSS, but the hash function is taken from the optional parameters, and is required. It is not the hash function or the optional parameters that are required but the OID id-RSASSA-PSS. Secondly, the "but" in the second part of the sentence indicates some contrast but I don't see one. Furthermore, not only the hash function is determined from the parameters but also the other options for the padding. Why not changing the text to With RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the optional parameters. 2. The wording in A.4.1 is also not unambiguous: Parameters are empty, but the ASN.1 part of the sequence must be there. This means default parameters are used (same as the next example). Here "next example" does not refer to the example following immediately after this paragraph but to the example in the next section. A reference to A.4.2 should be included. -- Johannes The IESG wrote on 01.07.2014 18:11: > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Signature Authentication in IKEv2' > <draft-kivinen-ipsecme-signature-auth-06.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2014-07-15. Exceptionally, comments may be > sent to [email protected] instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current version only includes support for three Elliptic Curve > groups, and there is a fixed hash algorithm tied to each group. This > document generalizes IKEv2 signature support to allow any signature > method supported by the PKIX and also adds signature hash algorithm > negotiation. This is a generic mechanism, and is not limited to > ECDSA, but can also be used with other signature algorithms. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > This draft updates RFC5996, however RFC5996 is in process of being updated in > RFC5996-bis and will likely be published before this draft. Each mention of > RFC5996 should be replaced with the new RFC number for RFC5996-bis once a > number has been assigned. > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Beratung, Elektronische Identitäten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 [email protected] www.secunet.com _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
