Sean,
Sorry for the delay in getting back to you. I had some work that needed to
get finished.
Jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Turner, Sean P.
Sent: Monday, April 21, 2008 9:18 AM
To: 'Ietf-Smime'
Subject: New ASN.1 modules comments/questions
Jim and Paul,
Here are some comments/questions on the ASN.1 modules.
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.
-------------------
In the 3370 section,
1. Shouldn't AlgorithmIdentifier be imported from the PKIX module?
Long term, AlgorithmIdentifier will be imported from the new Algorithm
Information module. So this should become moot.
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.
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?
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.
5. Do we need to add a MessageAuthenticationCodeAlgorithms for the
hmac
alg? Then we could use maca- in front of the hMAC-SHA1.
I have no issues with this.
6. Some of the IOSets are {...} (like SignatureAlgorithms) while
others
lists algorithms (like MessageDigestAlgorithms) - shouldn't all of them
list
algorithms or none?
This has to do with the fact that the module updates are not finished, but
the symbols needed to be defined for different reasons. These will become
closed sets with the appropriate algorithm objects in them.
-------------------
In the 3565 section, I think the algorithms need to be defined using
the new
syntax, import ALGORITHM, and define the algs as follows:
ContentEncryptionAlgorithms ALGORITHM ::= {
cea-aes128-cbc |
cea-aes192-cbc |
cea-aes256-cbc,
... -- Extensible
}
cea-aes128-cbc ALGORITHM ::= {
OID id-aes128-CBC PARMS AES-IV }
cea-aes192-cbc ALGORITHM ::= {
OID id-aes192-CBC PARMS AES-IV }
cea-aes256-cbc ALGORITHM ::= {
OID id-aes256-CBC PARMS AES-IV }
KeyWrapAlgorithms ALGORITHM ::= {
kwa-aes128 |
kwa-aes192 |
kwa-aes256,
... -- Extensible
}
kwa-aes128 ALGORITHM ::= {
OID id-aes128-wrap PARMS ABSENT }
kwa-aes192 ALGORITHM ::= {
OID id-aes192-wrap PARMS ABSENT }
kwa-aes256 ALGORITHM ::= {
OID id-aes256-wrap PARMS ABSENT }
Module has not be updated to reflect what is going on in modules. I was
waiting to get the Algorithm Information module finished first.
-------------------
In the 3851 section, shouldn't SMimeAttributeSet be extensible? r/{
attr-smimeCapabilities | attr-encrypKeyPref }/{ attr-smimeCapabilities
|
attr-encrypKeyPref, ... }
See discussion above about whether we think we are going to add new
attributes to a future version of this document.
-------------------
In the 3852 section,
1. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I
think it
should be id-pkix-explict(19) instead of (18).
First, at some point we are going to replace all of the module numbers. We
have just not yet gotten to that point. Based on the documents that I
looked at, the explicit module is 18.
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.
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.
4. For consistency, can we change UnsigedAttributes to
UnsignedAttributesSet and UnprotectedAttributes to
UnprotectedAttribuesSet?
No problems
5. In AuthenticatedData, SupportedAttributes is used in AuthAttributes
and
UnauthAttributes. In AuthAttributes, can we change SupportAttributes to
AuthAttributesSet and in UnauthAttributes can we change
SupportedAttributes
to UnauthAttributesSet?
No problems
6. For consistency with the 3370 section, can we change
SignatureAlgorithmList to SignatureAlgorithms, DigestAlgorithmList to
MessageDigestAlgorithms, KeyAgreementAlgorithmList to
KeyAgreementAlgorithms, and ContentEncryptionAlgorithmLists to
ContentEncryptionAlgorithms?
See above note
7. Can we change KeyDerivationAlgorithmIdentifier to use
KeyDerivationAlgorithms instead of AlgorithmList?
Yes this should be done.
8. Can we change MessageAuthenticationCodeAlgorithm to use
MessageAuthenticationCodeAlgorithms instead of AlgorithmList?
Yes this should be done
9. Don't we want to define an OriginatorPKAlgorithms instead of using
AlgorithmList in OriginatorPublicKey:
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier {{OriginatorPKAlgorithms}},
publicKey BIT STRING
}
OriginatorPKAlgorithms ALGORITHM ::= {
... -- Extensible
}
Yes this should be done in the end.
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.
-------------------
In the 4108 section, can we make FirwareContentTypes and
FirmwareSignedAttrs
extensible?
See discussion on the question - do we think this module will be updated in
the future.
-------------------
In the 4998 section,
1. Shouldn't we constrain the digestAlgorithms and digestAlgorithm?
Probably - this is actually not a CMS module. I was waiting to figure out
how algorithms are actually done first
2. Should the import for Attribute come from PKIX or RFC3852 update
module?
This has been moved to the PKIX-COMMON module
3. Why is Extensions and EXTENSION imported?
To use a single standardized version, as with Attribute
-------------------
In the 5035 section,
1. Why is Extensions and EXTENSION imported?
See above
2. Should the import for Attribute come from PKIX or RFC3852 update
module?
See above
3. OID for PKIX1 module doesn't match the new PKIX asn ID OID - I
think it
should be id-pkix-explict(19) instead of (18).
See above note
4. Should EssSignedAttributes be SignedAttributes? Should it also be
extensible?
See both above philosophy discussion and discussions on naming of items
5. Should EssContentTypes be just ContentSet?
Same as above.
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.
7. Shouldn't we say HashAlgorithms ::= MessageDigestAlgorithms instead
of
HashAlgorithms ::= AlgorithmIdentifier {{...}}?
Yes it should - it also needs to import it - which is a new module.
8. Shouldn't we import the shaa256 alg?
Yes - it would be wise - I did not do it originally so that I did not import
a new module.
-------------------
In the 5084 section, we should import ALGORITHM from PKIX and define
the
algorithms as follows:
ContentEncryptionAlgorithms ALGORITHM ::= {
cea-aes128-ccm |
cea-aes192-ccm |
cea-aes256-ccm |
cea-aes128-gcm |
cea-aes128-gcm |
cea-aes128-gcm,
... -- Extensible
}
cea-aes128-ccm ALGORITHM ::= {
OID id-aes128-CCM PARMS CCMParameters }
cea-aes192-ccm ALGORITHM ::= {
OID id-aes192-CCM PARMS CCMParameters }
cea-aes256-ccm ALGORITHM ::= {
OID id-aes256-CCM PARMS CCMParameters }
cea-aes128-gcm ALGORITHM ::= {
OID id-aes128-GCM PARMS GCMParameters }
cea-aes192-gcm ALGORITHM ::= {
OID id-aes192-GCM PARMS GCMParameters }
cea-aes256-gcm ALGORITHM ::= {
OID id-aes256-GCM PARMS GCMParameters }
This is waiting on the new Algoirthm Information module.