Re: Comments on CMC-09

Jim Schaad (Exchange) wrote:
> 
> 
> >
> > >15.  Section 12.6.2 - You have not modified the key wrap
> > algorithm to allow
> > >for arbitrary length RC2 key sources.
> >
> > Are you suggesting an explicit length field or something else?
> >
> We need to either put in an explicit length field or use a known padding
> algorithm.  I have no perference on which is used but something along this
> lines is absolutely required.
> 

Speaking personally I'd prefer known padding. Known padding at least
adds some consistency with the use of symmetric algorithms: they all use
the "padded" forms.

If an explicit length parameter is included the logical place to put it
is in the EncryptedContentInfo structure because its a property of the
content encryption key. You'd probably then have to make it OPTIONAL for
v2 compatability only include it when at least one recipient used key
agreement.

With known padding the following minor change should suffice:

   1.  Modify the content-encryption key to meet any restrictions on 
       the key. For example, adjust the parity bits for each DES key
       comprising a Triple-DES key.

RE: Comments on CMC-09

Comments in line

> -----Original Message-----
> From: Dr Stephen Henson [mailto:shenson <at> drh-consultancy.demon.co.uk]
> Sent: Monday, November 30, 1998 4:45 PM
> To: ietf-smime <at> imc.org
> Subject: Re: Comments on CMC-09
> 
> 
> Jim Schaad (Exchange) wrote:
> > 
> > 
> > >
> > > >15.  Section 12.6.2 - You have not modified the key wrap
> > > algorithm to allow
> > > >for arbitrary length RC2 key sources.
> > >
> > > Are you suggesting an explicit length field or something else?
> > >
> > We need to either put in an explicit length field or use a 
> known padding
> > algorithm.  I have no perference on which is used but 
> something along this
> > lines is absolutely required.
> > 
> 
> Speaking personally I'd prefer known padding. Known padding at least
> adds some consistency with the use of symmetric algorithms: 
> they all use
> the "padded" forms.

RE: Comments on MSG spec

Blake:

>>         3.  Section 2.6, first sentence:  Is the reference to 
>> [DES] dangling? 
>> It would seem that one reference to tripleDES would be sufficient.
>
>Not dangling -- [DES] tells you how to implement DES, [3DES] tells you how
>to implement triple-DES, but not DES.
>
>By the way, I think that the 3DES reference sucks (a 1979 IEEE Spectrum
>article?).  Any suggestions?

Here are the best reference I can find:

3DES       American National Standards Institute.  ANSI X9.52-1998,
           Triple Data Encryption Algorithm Modes of Operation. 1998.

DES        American National Standards Institute.  ANSI X3.106, 
           "American National Standard for Information Systems - Data
           Link Encryption".  1983.

Russ

Re: X942-03

Eric:

>> For consistency, please use the spelling that CMS inherited from PKCS#7
v1.5:
>> 	key-encryption key
>> 	content-encryption key
>All right.
Good.

>> I expected section 2.1.1 to include: g^q (mod p) == 1.
>I'm not sure that this is sufficient. However, it follows from
>the following criterion, (which I just added) which is listed 
>in FIPS-186
>
>      h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
>        (g has order q mod p)
Okay.

>> In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
>> symmetric algorithm with which this KEK will be used."  I think it would be
>> more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
>> algorithm identifier; no parameters associated with the symmetric algorithm
>> identifier are used.
>How about:
>algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 
>  this KEK will be used. Note that this is NOT an AlgorithmIdentifier,
>  but simply the OBJECT IDENTIFIER. No paramters are used.
This is fine.

>> Later in section 2.1.2, you say: "Note that pubInfo is required in

43rd IETF: S/MIME WG Agenda

S/MIME Mail Security WG Agenda

1530    Introductions                   Russ Housley
1540    CMS Draft Discussion            Russ Housley
1555    X9.42 Draft Discussion          Russ Housley
1610    MSG Draft Discussion            Blake Ramsdell
1620    CERT Draft Discussion           Blake Ramsdell
1630    ESS Draft Discussion            Paul Hoffman
1640    CERTDIST Draft Discussion       Jim Schaad
1650    SIGATTR Draft Discussion        Jim Schaad
1700    DOMSEC Draft Discussion         Bill Ottaway
1715    New Samples Document            Paul Hoffman
1725    Wrap up                         Russ Housley
1730    Adjourn

RE: Comments on CMC-09

Jim:

>> >9.  Section 9.2:  Was there a reason for removing the "rather than the
>> >implcit [0] .." phrase.  This exists in the process for signed data and I
>> >think should be here as well.
>> 
>> For authenticated-data, digests are only computed on the content.  They are
>> never computed on the attributes.  The IMPLICIT [0] stuff was about the
>> attribute encoding.
>
>I don't follow your response.  What I am looking at is the text relating to
>the creation of the authenticatedAttributes blob over which the MAC will be
>computed.  This is yet another location where the ASN which is encoded and
>sent is not the same as the ASN which is acutally MAC-ed.  I think this
>should be very explicit like in the other cases.

The text was reworded do to the introduction of the authAttributesInfo
structure. Due to your previous comments regarding one pass processing, that
structure has been split up.  Now, text desling with IMPLICIT [2] will be
added.

Proposed text:
If authenctiatedAttributes field is present, the content-type attribute (as
described in Section 11.1) and the message-digest attribute (as described in
section 11.2) must be included, and the input to the MAC calculation process is
the DER encoding of authenticatedAttributes.  A separate encoding of the
authenticatedAttributes field is performed for message digest calculation.  The
IMPLICIT [2] tag in the authenticatedAttributes field is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER encoding of
the SET OF tag, rather than of the IMPLICIT [2] tag, is to be included in the

RE: More X942-03 Comments

Russ,

I have been thinking about this for a while and I want to make sure that I
have this correct.  

1.  The X9.42 document is the correct place to put sizing on the UKM
material as it is going to be tied to items such as the hash algorithm being
used.  I think this means that that the last sentence in the paragraph (on
pubInfo) should be alted to be 
"In CMS, it is provided as a parameter in the UserKeyingMaterial field
(encoded as an OCTET STRING).  If provided this pubInfo MUST contain 512
bits."

2.  The number 512 represents a minimum value which is determined by looking
at the hash function and making sure that a complete buffer has been filled.

3.  The number 512 is not a maximum number.  There is no real limit but 1023
would be the maximum number that could possibly make sense as there is no
additional benifit to filling the buffer more than twice.

4.  If (sizeof(ZZ) + sizeof(OtherInfo) - sizeof(pubInfo)) % 512 = 256, you
fill out this complete block size with random material.  You then fill half
of the next block with random material and half with fixed material.  Not
knowing enough about how these things work, is there any true benifit to
make sure that the half of fixed material is really random material?  From
your message it would appear that the first fill is the most important
portion and thus the minimum from step 1 is really what ever is needed to
fill out the last block following ZZ.

jim

goals and milestones up to date?

I recently visited the S/MIME web page at
http://www.ietf.org/html.charters/smime-charter.html and was a bit
confused with the "Goals and Milestones" section. All the milestones
seem to be referring to late 1997 and early 1998 dates. Is this the
right information?

Specifically, I was trying to find out the milestones/dates with respect
to the "S/MIME Version 3 Message Specification" and "Cryptographic
Message Syntax" I-Ds. 

- Sarbari Gupta
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
sgupta <at> cygnacom.com
=================================

Re: RecipientInfo vs SignerInfo key identification

Russ Housley <housley <at> spyrus.com> wrote:

>Further, some people argued that the key is not the only thing that is 
>important in verifying a signature.  Other fields in the certificate, like 
>policy, are important too.  If a signer has the same public key in two 
>certificates, then an attacker can swap the certificate carried in the 
>certificates field.  Since PKIX recommends a form of key identifier based on 
>hashing the public key, then the relying pary will probably not be able to 
>determine that the certificates were swapped.  Since the issuer / serial pair 
>specifies a certificate, not just a public key, it seems to be the prefered 
>method for signatures.

Ah, finally an explanation for the decision.  Thanks.

>Agreed, it could be added without breaking backward compatibility.  Support 
>for key identifiers could be added to SignerInfo, but as stated above, there 
>is less motivation to do so.

The reason I brought the issue up is that the lack of a key identifier in 
SignerInfo makes CMS impossible to use with SPKI and PGP.  There was a debate 
in two other lists a while back (OpenPGP and something else) in which someone 
commented on PGP <-> CMS compatibility, and I pointed out that it would 
*almost* work, but required the inclusion of a key identifier.  The same goes 
for SPKI, where the only way to identify a key is with the hash-of-key/key 
identifier.  In neither of these cases is it possible to use the 
issuerAndSerialNumber to specify the signers key, which means CMS is 
restricted to only one of the three IETF-standardised certificate management 
methods.  The addition of a key identifier would immediately extend this to 
both SPKI and PGP, since both already use an SHA-1 hash of the key as their 
identifier.  I think that extending the identifier in this way would be a 

Extensibility discussion