Russ Housley wrote:
We want a fairly short (no more than one-half page of text) summary that
focuses on important decisions made during the meeting, and what is
expected to happen in the few months. The summary would be sent to the
WG or BoF mail list as well as the ADs (housley(_at_)vigilsec(_dot_)com and
hartmans-ietf(_at_)mit(_dot_)edu).
Working group status. There are four drafts that are currently in the
working group that have not become RFCs yet. symkeydist is still in the
RFC editor's queue with a missing reference, waiting for the CMC draft
to be released from PKIX. certcapa is in the RFC editor's queue and
requires no further action. gost has a new release that was made
recently, and is going to immediately progress to working group last
call. KEM is waiting on work to complete in X9.44.
The open milestones for the working group fall into two categories. One
category is progressing the CMS and S/MIME RFCs to draft standard
status. The first step towards this is the completion of an
interoperability report, which is waiting for interoperability work to
be published from the PKIX working group. The other category surrounds
the KEM algorithm draft, which is waiting for the X9.44 work to be
completed (as noted above).
John Biccum from Microsoft announced that they will be S/MIME digitally
signing security bulletins starting in February 2006. The root
certificate is the software signing authority certificate that has been
distributed with Windows essentially forever, and will be made available
from Microsoft for non-Windows clients.
Mark Schertler from Voltage Security discussed their Identity Based
Encryption (IBE) public key system, and proposed an integration with CMS
using the OtherRecipientInfo field. The underlying algorithms are being
discussed in the IEEE 1363.3 working group, and I expect that Voltage
will be releasing individual internet-drafts in the short term, and we
can further discuss the relevance to the S/MIME working group.
Russ Housley gave an overview of the algorithm transition we are
undertaking, and the "walk, don't run" attitude that we have towards
moving away from SHA-1 as a digest algorithm.
Jim Schaad presented a concern about the algorithm flexibility of the
ESSCertID field. Right now this field is limited to the use of the SHA-1
algorithm, and Jim proposed the addition of an AlgorithmIdentifier to
indicate the digest algorithm used to prepare the digest. Jim also
proposed an idea for handling signature algorithm transitions in CMS.
Basically, in each SignerInfo the signer would indicate the other
SignerInfos that were added by the signer. Jim's theory was that this
might help mitigate a downgrade attack where the signer applies both a
SHA-256 signature and a SHA-1 signature, and the attacker removes the
SHA-256 signature to force the receiver to use the SHA-1 signature.
Blake Ramsdell discussed a strawman for SHA-256 support in S/MIME. The
draft as it stands right now needs more work to discuss both the reasons
for the transition to SHA-256, as well as the considerations for
handling the transition and processing multiple signature values, as
well as using existing capabilities constructs for expressing support
for SHA-256.
ACTION ITEMS:
* gost to WG last call
* Continued pressure to get CMC released to get symkeydist moving again
* Continue discussion about SHA-256 transition
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com