Subject: RE: New ASN.1 modules comments/questions

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 May 2008 15:52:19 -0700

Sean,

Sorry for the delay in getting back to you.  I had some work that needed to
get finished.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] 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.

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 6 May 2008 12:09:49 -0400

Jim,

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

spt 

>> 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.

>> 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.

>> KeyWrapAlgorithm that I think is supposed to be the same as the 
>> (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
>distinguish between them, but CMS uses Key Encryption as the 
>name of these types of algorithms.
>

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.
 
>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.

>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 ;)

>-  We create a standardized but descriptive method of naming 
>the sets of algorithms defined in a module - thus in 3370 we might say

Okay

>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.

>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?

>>  1. Why is Extensions and EXTENSION imported?

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

>I have no opinion one way or the other on this.  Being 

Okay