glitches in Algorithms section

Mostly my fault:

1) Section 5.4.2, RSA-OAEP, Algorithm URI in example should be corrected
to Identifier given at start of section.

2) Section 5.5.2, Diffier-Hellman Key Agreement, example was not
updated as various changes were made earlier in 5.5. Suggest example
should be something like

<enc:AgreementMethod Algorithm="http://www.w3.org/2001/04/xmlenc#dh"
                     xmlns="http://www.w3.org/2000/09/xmldsig#">
<DigestMethod Algorith="http://www.w3.org/2000/09/xmldsig#sha1"/>
<enc:OriginatorKeyInfo>
     <X509Data><X509Certificate>
         ...
     </X509Certificate></X509Data>
</OriginatorKeyInfo>
<RecipientKeyInfo><KeyValue>
     ...
</KeyValue></RecipientKeyInfo>
</enc:AgreementMethod>

3) 5.4 (Key Transport), 5.5 (Key Agreement), and 5.6 (Symmetric Key
Warp) all claim that you can tell the algorithm the key you are
decrypting/wrapping/agreeing-on is intended for by looking at the
"Type" attribute of the ancestor EncryptedData or EncryptedKey.  Must
sound reasonable since no once has commented on it but I now think
this is nonsense. For 5.4 and 5.6, I don't know why you need to know
the algorithm the key is destined to be used in. As long as you
extract a bit/byte sequence of the right length, seems to me like it
should work. 5.5 is a different matter. You need to know how many bits
are needed...

I'd be interested in what other thoughts people have on this but I
think that all the stuff about the algorithm for which they key is
destined can be dropped from 5.4 & 5.6 except the
mandatory/recommended/optional stuff which could possibly be recast as
requiring support for certain lengths of key rather than certain
algorithm keys. For 5.5, perhaps KeySize should be a mandatory
parameter to AgreementMethod...

Alternatively, you could do some sort of more complex
navigation. These three things really do only occur inside KeyInfo
inside an EncryptedData or EncryptedKey and you could go to the
Algorithm attribute of the EncryptionMethod child of the EncryptedData
or EncryptedKey grandparent, but EncryptionMethod is optional!

Thanks,
Donald
=====================================================================
 Donald E. Eastlake 3rd                      dee3@torque.pothole.com
 155 Beaver Street                                +1 508-634-2066(h)
 Milford, MA 01757 USA                            +1 508-261-5434(w)

Received on Wednesday, 4 July 2001 23:11:43 UTC