by way of Russ Housley | 3 Apr 22:29 2007

Gen-ART review of draft-martin-ibcs-03


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-martin-ibcs-03
Reviewer: David L. Black
Review Date: April 3, 2007
IETF LC End Date: April 9, 2007

Summary:

This draft is on the right track, but has open issues, described
in the review.

Comments:

The draft contains an immense amount of cryptographic mathematics,
beyond what is reasonably possible for me to review in detail.
The draft needs detailed review by an expert cryptographer to
look for subtle errors in the notation and mathematics - this
is not such a review.

The draft has a number of open issues - the most important are:
[1] Lack of hash agility
[2] Lack of IPR disclosures
[3] Use of a stream cipher without discussion of protection
(Continue reading)

Internet-Drafts | 5 Apr 21:50 2007
Picon

I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-03.txt
	Pages		: 11
	Date		: 2007-4-5
	
This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-cms-auth-enveloped-03.txt".
(Continue reading)

Russ Housley | 5 Apr 22:56 2007

Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt


I believe that this document and the companion document that tells 
how to use AES-CCM and AES-GCM are ready for WGLC.

Russ

At 03:50 PM 4/5/2007, Internet-Drafts <at> ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the S/MIME Mail Security Working Group 
>of the IETF.
>
>         Title           : Cryptographic Message Syntax (CMS) 
> Authenticated-Enveloped-Data Content Type
>         Author(s)       : R. Housley
>         Filename        : draft-ietf-smime-cms-auth-enveloped-03.txt
>         Pages           : 11
>         Date            : 2007-4-5
>
>This document describes an additional content type for the
>    Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
>    content type is intended for use with authenticated encryption modes.
>    All of the various key management techniques that are supported in
>    the CMS enveloped-data content type are also supported by the CMS
>    authenticated-enveloped-data content type.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-03.txt

(Continue reading)

Eric Rescorla | 6 Apr 20:30 2007

AlgorithmIdentifier, SHA-1, etc.


I'm trying to get a handle on how one ought to encode AlgorithmIdentifier.

As people will perhaps remember, the ASN.1 is:

AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                -- contains a value of the type
                                -- registered for use with the
                                -- algorithm object identifier value

Present hash functions do not take any useful parameters, leaving
us with two encoding options:

  - omit the parameter.
  - include a NULL

To make things more complicated, there are (at least) two different
contexts in which this production appears:

  - The S/MIME DigestAlgorithmIdentifier production.
  - Inside the DigestInfo of the S/MIME signature.

RFC 3370's guidance is to omit the parameter for SHA-1 and include
a NULL for MD5 (see S 2.1 and 2.2.).

However, the current PKCS#1 errata
(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)
recommend that when one is encoding DigestInfo, one should
(Continue reading)

Blake Ramsdell | 6 Apr 22:02 2007

Re: AlgorithmIdentifier, SHA-1, etc.


Eric Rescorla wrote:
> Technically these don't conflict, but obviously, it's undesirable to
> have the encoding in the message not match that in the DigestInfo,
> since doing binary comparisons is common practice here. So, what's the
> right answer here?

In my case when I receive a digest AlgorithmIdentifier, I bust it open 
and get the OID out and discard the wrapper (the outer 
AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.

But yeah, short of normalizing the values in some way, you're pretty 
much done. That is, there's no binary comparison, and you perform an 
equivalence check by converting both values in such a way that the same 
answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
the same answer.

Blake
--

-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Eric Rescorla | 6 Apr 22:09 2007

Re: AlgorithmIdentifier, SHA-1, etc.


At Fri, 06 Apr 2007 13:02:58 -0700,
Blake Ramsdell wrote:
> 
> Eric Rescorla wrote:
> > Technically these don't conflict, but obviously, it's undesirable to
> > have the encoding in the message not match that in the DigestInfo,
> > since doing binary comparisons is common practice here. So, what's the
> > right answer here?
> 
> In my case when I receive a digest AlgorithmIdentifier, I bust it open 
> and get the OID out and discard the wrapper (the outer 
> AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.
> 
> But yeah, short of normalizing the values in some way, you're pretty 
> much done. That is, there's no binary comparison, and you perform an 
> equivalence check by converting both values in such a way that the same 
> answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
> the same answer.

Yeah, my thinking is that it would be better for these to match
so that naive implementations work.

-Ekr

Russ Housley | 6 Apr 22:09 2007

Re: AlgorithmIdentifier, SHA-1, etc.


Note that the DigestInfoValue is part of the structure that is 
"encrypted" with the RSA private key when generating a signature.  It 
is recovered by "decrypting" the signature value with the RSA public key.

An implementation should check that the expected digest algorithm was 
used.  As Eric point out, this check is easier to perform if the two 
values are encoded in exactly the same manner.

One needs to look deeper into signatures in certificates and CMS 
SignerInfo to see where these comparisons are really performed.

The certificate signature has this structure:

    Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signatureValue       BIT STRING  }

In practice, the signature algorithm tells the digest algorithm as 
well as the digital signature algorithm. The ones that are relevant 
to this question are:

    sha1WithRSAEncryption
    sha224WithRSAEncryption
    sha256WithRSAEncryption
    sha384WithRSAEncryption
    sha512WithRSAEncryption

There is no filed that explicitly carries a digest algorithm 
(Continue reading)

Russ Housley | 6 Apr 22:09 2007

Re: AlgorithmIdentifier, SHA-1, etc.


Note that the DigestInfoValue is part of the structure that is 
"encrypted" with the RSA private key when generating a signature.  It 
is recovered by "decrypting" the signature value with the RSA public key.

An implementation should check that the expected digest algorithm was 
used.  As Eric point out, this check is easier to perform if the two 
values are encoded in exactly the same manner.

One needs to look deeper into signatures in certificates and CMS 
SignerInfo to see where these comparisons are really performed.

The certificate signature has this structure:

    Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signatureValue       BIT STRING  }

In practice, the signature algorithm tells the digest algorithm as 
well as the digital signature algorithm. The ones that are relevant 
to this question are:

    sha1WithRSAEncryption
    sha224WithRSAEncryption
    sha256WithRSAEncryption
    sha384WithRSAEncryption
    sha512WithRSAEncryption

There is no filed that explicitly carries a digest algorithm 
(Continue reading)

Peter Gutmann | 7 Apr 09:01 2007
Picon
Picon
Picon

Re: AlgorithmIdentifier, SHA-1, etc.


Eric Rescorla <ekr <at> networkresonance.com> writes:

>So, what's the right answer here?

Read the OID and hash value, toss the rest.  Doing anything else is just
asking for trouble.

(There's really no question here: There are two ways to do this, knowing in
 advance what you'll encounter in the field isn't possible, so the only
 workable solution is to not compare the encoded value, or if you must,
 compare two pre-encoded alternatives for each possible hash algorithm.  This
 still breaks though if someone gets the encoding slightly wrong... comparing
 a pre-built value is just asking for trouble).

>My understanding from discussions in Prague is that this reflects NIST's
>current guidance as well.

This would put them in conflict with ISO, who (the last time I checked) say
the parameter should be omitted.  In any case though it doesn't really matter
which side wants to hold their breath the longest, if you read the OID and
hash and work with that you can't go wrong.

Peter.

Peter Gutmann | 7 Apr 09:06 2007
Picon
Picon
Picon

Re: I-D ACTION:draft-ietf-smime-cms-auth-enveloped-03.txt


Russ Housley <housley <at> vigilsec.com> writes:

>I believe that this document and the companion document that tells how to use
>AES-CCM and AES-GCM are ready for WGLC.

Uhhmmm, I beg to differ... it still doesn't contain the changes I sent some
time ago to handle encrypt + MAC combinations (e.g. AES + HMAC), and there was
no agreement about handling of auth.attributes - two people pointed out that
the existing scheme has problems, but this hasn't been resolved yet.

Peter.


Gmane