Comments on 2nd try at Algorithms Section

> Just catching up on recent postings.  Here are comments on the 2nd
> draft Algorithm section.  
> 
> Block Encryption
> 
> I agree with Jim Schaad's suggestion that we follow the S/MIME WG lead
> in requring AES with 128 and 256 bit keys, with 192-bit being optional
> 
> IV Syntax
> 
> I agree with earlier comments that it is algorithm specific as to
> whether an IV is present as well as how it is communicated.  For the
> purposes of the required algorithms, which do use an IV, we should
> define a single syntax for communication the IV octet sequence to
> simplify implementation.  But, I don't particularly care if its
> prepended onto the cipher value or encoded in the EncryptionMethod
> element.
> 
> I must admit I've been somewhat puzzled by the recent discussions as
> to where the IV should live.  It wasn't until the most recent post I
> finally got some insight into why this was causing such consternation.
> Joe Ashwood stated "I never said that if they are in seperate
> locations then the IV will always be different, what I said was that
> if they are in the same location they must all be the same, and if
> they are in different locations they can be different."  If I'm
> reading this correctly Joe is confused as to the proposal for placing
> the IV in a separate location from the cipher value.  The earlier
> proposal was to place the IV in the EncryptionMethod element.  There
> is a separate EncryptionMethod element for each EncryptedData or
> EncrytpedKey and no syntax is defined for sharing a single
> EncryptionMethod (and by implication an IV) across multiple
> encryptions is defined.  So the IV for each encryption may be
> different using either approach.
> 
> Key Transport
> 
> I concur that we should specify RSA-v1.5 and RSA-OAEP as required.
> These are widely used and have well understood properties.
> 
> There was considerable discussion about weaknesses in these algorithms
> and what I took as a strong argument for specifying a different
> algorithm.  But since Joe Ashwood has recently stated he was not
> arguing against inclusion of PKCS1 v1.5, I would like to see us move
> forward with the algorithms proposed. 
> 
> Symmetric Key Wrap
> 
> As noted earlier by Jim Schaad, the RC2 Key Wrap should be deleted.
> 
> The remaining algorithms on the list are, however, problematic.  If we
> use the CMS defined key wrap then I believe we must respecify the
> encoding to use XML rather than ASN.1.  I am not opposed this being
> done given the lack of standardized alternatives in this area.  We
> also have a problem in that AES key wrap is not yet defined.  Would we
> be allowed to propose a standard with a required algotihm whose
> specification is TBD?  I don't think so.  So how to we clearly state
> it will become required at some point in the future?
> 
> There has been some discussion of using a key deriviation algorithm
> based on a shared symmetric key.  I'm not opposed to this as an
> alternative but would like to see a specific proposal based on a
> published standard, or de-facto standard.
> 
> Section 5.2.1
> 
> On the issue of 3DES keys.  I strongly prefer an assumed key encoding
> which includes the parity bits, i.e., each 56-bit key is encoded as an
> 8-byte sequence. This is key format supported by the crypto
> implementations I typical use and its inefficient if we have to
> constantly convert between the two representations.  I have no problem
> with specifying 3-key 3DES as the required algorthm
> 
> Section 5.5 wording
> 
> Of the alternatives to 'secret' proposed I would prefer 'symmetric'.
> I could also live with 'shared-secret'.
> 
> 
> Regards,
> Blair

Received on Wednesday, 6 June 2001 18:14:50 UTC