ietf-smime
[Top] [All Lists]

RE: New ASN.1 modules comments/questions

2008-05-06 09:39:49

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

<Prev in Thread] Current Thread [Next in Thread>