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