- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: 2002年2月26日 11:08:18 -0500
- To: merlin <merlin@baltimore.ie>
- cc: xml-encryption@w3.org
- Message-Id: <200202261608.LAA0000021645@torque.pothole.com>
Hi, From: merlin <merlin@baltimore.ie> To: reagle@w3.org Cc: xml-encryption@w3.org In-reply-to: <200202252055.PAA25765@tux.w3.org> Date: 2002年2月26日 14:48:04 +0000 Message-Id: <20020226144804.7D51143CEA@yog-sothoth.ie.baltimore.com> >Minor nit in 5.5.2, DH Key Agreement; it is still not completely >clear what is the input to KM: > >. The examples need to match their field ordering with the > definition. Example should chang, I think, to SHA-1 ( ZZ01Example:Block/Algfoo80 ) and the text above it should refer back to the EncryptionMethod example above, NOT the AgreementMethod example. This makes the numeric example be SHA-1 ( 0xDEADBEEF30314578616D706C652F416C67666f6f3830 ) I'll try doing this and getting the output value later today. >. The field descriptions (DigestAlg/EncryptionAlg/...) > should ideally match the ordering in the definition. Yes. >. The counter encoding needs to specify upper/lower case hex. Suggest: "A one byte counter starting and one can incrementing by one. It is expressed as two hex digits where letters A through F are in upper case." >. The first example encodes the counter as "001", should be "01". Sorry, typo. >. Digest method is optional; what happens when none is specified? You have to know what it is, same as you have to know the Originator or Recipient info if they are not specified. >. Should we specify operation with hmac (key length == mac output > length)? I don't think the added complexity is worth it. >Merlin Thanks, Donald >r/reagle@w3.org/2002.02.25/15:55:41 >> >>In preparation for publication as CRs next week, I'm working on getting all >>the documents up to date. For instance, I've removed the red diff from [1], >>updated the references, and made the tweak I suggested to Don in the last >>email (note this changes some of the section numbers). A part of these the >>final tweaks is the population of the "good standing" WG participants and >>last call thank you's. If you see any errors in the draft please let me >>know ASAP (including any questions about participation/standing). >> >> >>[1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html >>[2] >>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview.html#sec-Acknowl >>edgements >> >> >>-- >> >>Joseph Reagle Jr. http://www.w3.org/People/Reagle/ >>W3C Policy Analyst mailto:reagle@w3.org >>IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ >>W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ >> > > >----------------------------------------------------------------------------- >Baltimore Technologies plc will not be liable for direct, special, indirect >or consequential damages arising from alteration of the contents of this >message by a third party or as a result of any virus being passed on. > >This footnote confirms that this email message has been swept by >Baltimore MIMEsweeper for Content Security threats, including >computer viruses. > http://www.baltimore.com >
Received on Tuesday, 26 February 2002 11:11:25 UTC