RE: New ASN.1 modules comments/questions

["Turner, Sean P." <turners@xxxxxxxx>]

Jim,

No worries on the delay. Some thoughts on your responses.

spt 

>> The definitions of AlgorithmIdentifier in the PKIX and SMIME modules 
>> are different - is there a reason for the difference? Does 
>it matter? 
>> In PKIX it's AlgorithmSet, in SMIME it's InfoObjectSet, in RFC2976 
>> it's IOSet, in ANSI X9 docs it's also IOSet, and in X.509 it's 
>> SupportedAlgorithms. If it matters, then I guess I lean 
>towards what's 
>> in RFC2976 since it's already in an RFC.
>
>There is no effective difference between the two definitions.  
>The two differences are 1) the name of a parameter and 2) 
>comments.  The name of the parameter makes no difference.  
>Just as the name of a parameter makes no difference if you are 
>writing a C function.  The same is true for comments.

I figured as much, but if we can control it I think they should be called
the same thing. Don't really care what it's called just that they're called
the same thing.

>> -------------------
>> 
>> In the 3370 section,
>> 
>>  2. You used alg- as tag for hash algs, sig- for signature 
>algs, kea- 
>> for key agreement algs, alg- for symmetric key encryption algs.  I 
>> think it might be easier to figure out which algs go where 
>if the tag 
>> matches the type of algorithm like mda- for MessageDigestAlgorithms, 
>> sa- for SignatureAlgorithms, and kaa- for KeyAgreementAlgorithms.
>
>Thanks for suggesting some potential tags to be used.  I agree 
>that we need some short simple notation to mark the different 
>types of algorithm objects.

Since I'm using some of these tags in other IDs, I'll try to make sure we're
in synch.

>>  3. Could we change SymmetricKeyEncryptionAlgorithms to just 
>> KeyWrapAlgorithms and use kwa- as the tag? There's also a 
>> KeyWrapAlgorithm that I think is supposed to be the same as the 
>> SymmetricKeyEncryptionAlgorithms so one or the other can get deleted 
>> (if you delete the later change SupportKeyWrapAlgorithms to 
>> KeyWrapAlgorithms)?
>
>I have no problems with this change.  There is a minor 
>question here about doing a good job of distinguishing Key 
>Wrap Algorithms and Key Transport Algorithms.  
>
>I added the Symmetric to the front to distinguish from Key 
>Transport algorithms which, as the KEA algorithm suggest, can 
>also be thought of as
>Key Encryption algorithms.    The use of Key Wrap might be 
>sufficient to
>distinguish between them, but CMS uses Key Encryption as the 
>name of these types of algorithms.
>
>Which is a better way to go?

I think it's a toss up.  I guess I was just confused because it wasn't clear
to me whether the keyEncryptionAlgorithm in 3852 was constrainted by
SymmetricKeyEncryption or KeyWrapAlgorithm.  Now that I think about it the
KeyWrapAlgorithms in this module is used to define the algorithm. This makes
me think that adding comments above each IOset to say what it's constraining
would help the reader a lot.
 
>>  4. Shouldn't SymmetricKeyEncryptionAlgorithms be extensible?
>> 
>
>Welcome to a long philosophical discussion.
>
>There are two different places where this extensibility can be 
>placed.  The two different locations imply different things.  
>This means that depending on how you look at things this 
>should or should not be extensible.
>
>If you place the extensibility here, you are saying that we 
>think that this document is going to be updated, and that we 
>are going to add new algorithms to this document.  
>
>Alternatively, if you place the extensibility in CMS, you are 
>saying that we are going to define new algorithms by creating 
>new documents with new modules and they should be "imported" 
>into the CMS document in one manner or another. 
>
>The compiler that we are working on has a planned directive to 
>allow for an object to be added to an extensible object set.  
>Part of the question at this point would be as follows.  Where 
>should the new algorithm be added, in this document - thus 
>potentially effecting more than just CMS - or in CMS thus 
>limiting where the changes are set.
>
>My personal beliefs are:
>- 1.  New algorithms should be added by creating new documents 
>not by updating this document
>- 2.  Changes in algorithm sets should be as narrow as 
>possible - thus the updates should be done in CMS not here. 
>
>The upshot of this is that I believe this object set is NOT 
>extensible, but the corresponding one in CMS should be extensible.

I agree with you. We're already on this track because we've not updated 3370
every time a new alg comes along - what we've done is define a new ID with a
new module. Don't see any reason to change from that course.

>> -------------------
>> 
>> In the 3852 section,
>> 
>>  2. Are you going to remove the version notations [[3:, [[4:, etc?
>
>It is my belief that having the version tags included adds 
>information to the ASN.1 module.  Thus I plan on keeping them 
>unless I get some large objections.

Still thinking about whether I should object ;)

>>  3. For consistency with 3370, can we change DigestAlgorithmList to 
>> MessageDigestAlgorithms?
>
>I don't want these to have the same names.  In the long run we 
>will do the
>following:
>    DigestAlgorithmList ALGORITHM ::= {MessageDigestAlgorithms,...}
>
>
>However I am open to the following:
>-  We create a standardized but descriptive method of naming 
>the sets of algorithms defined in a module - thus in 3370 we might say
>	CMSAlgs-MessageDigestAlgorithm
>
>- Do the suggested re-name here.

Okay

>>  10. For consistency, can we change KeyEncryptionAlgorithmList to be 
>> KeyEncryptionAlgorithms?
>
>The above note about matching the name in 3370 needs to be 
>taken into account.  I used List (but could have used Set) but 
>I am not wedded to this.
>I worry about using an 's' at the end as this could be a 
>sequence of algorithms as well.  There exists a potential 
>confusion in the future.

Sometimes we've used an 's' sometimes we've used 'list' - I guess I'd like
them to be the same for no other reason than consistency.

>> -------------------
>> 
>> In the 4998 section,
>> 
>>  3. Why is Extensions and EXTENSION imported?
>
>To use a single standardized version, as with Attribute

I might have missed it but I don't think it's used in the module?

>> -------------------
>> 
>> In the 5035 section,
>> 
>>  1. Why is Extensions and EXTENSION imported?
>> 
>
>See above

I might have missed it but I don't think it's used in the module?

>>  6. Is the note about the identical SecurityCategories encoding
>> required
>> anymore?
>
>I have no opinion one way or the other on this.  Being 
>conservative says it
>stays.

Okay