Subject: SignerInfo Change

From: Russ Housley <[email-masked]>
Date: Thu, 10 Dec 1998 10:08:20 -0500

Blake:

At the face-to-face S/MIME working group session, the group decided to
make a chane to SignerInfo.  Since you were not at the meeting, I am
sending it to you to make a corresponging change in the MSG
document.

Below is the updates section 5.3.  The old issuerAndSerialNumber is
replaced with sid.  The MSG document must be updated to say:
S/MIME v3 requires the use of SignerInfo version 1, that is the
issuerAndSerialNumber CHOICE must be used for SignerIdentifier.

Please post the updated MSG document ASAP.  I would like to progress
to IETF Last Call before Christmas.

Russ

= = = = = = = = = =

5.3  SignerInfo Type

Per-signer information is represented in the type SignerInfo:

SignerInfo ::= SEQUENCE {

version CMSVersion,

sid SignerIdentifier,

digestAlgorithm DigestAlgorithmIdentifier,

signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,

signatureAlgorithm SignatureAlgorithmIdentifier,

signature SignatureValue,

unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {

issuerAndSerialNumber IssuerAndSerialNumber,

subjectKeyIdentifier [0] SubjectKeyIdentifier }

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {

attrType OBJECT IDENTIFIER,

attrValues SET OF AttributeValue }

AttributeValue ::= ANY

SignatureValue ::= OCTET STRING

The fields of type SignerInfo have the following meanings:

version is the syntax version number.  If the SignerIdentifier
is the CHOICE issuerAndSerialNumber, then the version shall be 1.
If the SignerIdentifier is subjectKeyIdentifier, then the version shall
be 3.

sid specifies the signer's certificate (and thereby the signer's
public key).  The signer's public key is needed by the recipient to
validate the signature.  SignerIdentifier provides two alternatives
for specifying the signer's public key.  The issuerAndSerialNumber
alternative identifies the signer's certificate by the issuer's
distinguished name and the certificate serial number; the
subjectKeyIdentifier identifies the signer's certificate by the X.509
subjectKeyIdentifier extension value.

digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer.  The message digest is
computed on either the content being signed or the content together with
the signed attributes using the process described in section 5.4.
The message digest algorithm should be among those listed in the
digestAlgorithms field of the associated SignerData.

signedAttributes is a collection of attributes that are signed.
The field is optional, but it must be present if the content type of the
EncapsulatedContentInfo value being signed is not id-data. Each
SignedAttribute in the SET must be DER encoded.  Useful attribute
types, such as signing time, are defined in Section 11.  If the
field is present, it must contain, at a minimum, the following two
attributes:

A content-type attribute having as its value the content type of the
EncapsulatedContentInfo value being signed.  Section 11.1 defines
the content-type attribute.  The content-type attribute is not
required when used as part of a countersignature unsigned attribute as
defined in section 11.4.

A message-digest attribute, having as its value the message digest of
the content.  Section 11.2 defines the message-digest
attribute.

signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by the signer to generate the digital
signature.

signature is the result of digital signature generation, using the
message digest and the signer's private key.

unsignedAttributes is a collection of attributes that are not
signed.  The field is optional.  Useful attribute types, such
as countersignatures, are defined in Section 11.

The fields of type SignedAttribute and UnsignedAttribute have the
following meanings:

attrType indicates the type of attribute.  It is an object
identifier.

attrValues is a set of values that comprise the attribute.  The
type of each value in the set can be determined uniquely by
attrType.

---

From: "Darren Harter" <[email-masked]>
Date: Thu, 10 Dec 1998 16:35:41 +0000

Russ,

Sorry if this is a no brainer.  I couldn't make the meeting this time, so what I'm about to ask may have come up in discussion in the WG session.  As we've taken this opportunity to modify SignerInfo, would it not be a good time to add a field that may  simplify the identification of the signer's certificate even more.

First of all let me confirm that I think it is good that the subjectKeyIdentifier has been added.  My concern is that I'm going to have to do a lot of work to find such a certificate in a simple repository that doesn't have good matching rule support.

I propose that we instead have the following structure:

SignerIdentifier ::= CHOICE {
   issuerAndSerialNumber IssuerAndSerialNumber,
   subjectKeyIdentifier [0] SubjectKeyIdentifier,
   subjectAndKeyIdentifier [1] SubjectAndKeyIdentifier }

where,

SubjectAndKeyIdentifer ::= SEQUENCE {
   subjectName Name,
   subjectKeyIdentifier [0] SubjectKeyIdentifier OPTIONAL }

This will allow simple subject name look-up should an application wish to do that.  Your proposed words for the MSG spec would still stand unaltered.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [email-masked]
Home: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Dec 1998 13:50:05 -0500

Darren:

The reasonf or the chane is CMC support.  In this case, the signer does not
have a certificate yet.  The point of the message is a certificate request.
 So, the signer does not have a issuer/serial number pair.  This change
lets CMC use the SignerInfo.

The reason for the MSG document change is to mangate the use of a
issuer/serial number pair with S/MIME v3.

Russ

At 04:35 PM 12/10/98 +0000, Darren Harter wrote:
>Russ,
>
>Sorry if this is a no brainer.  I couldn't make the meeting this time, so 
>what I'm about to ask may have come up in discussion in the WG session.  As 
>we've taken this opportunity to modify SignerInfo, would it not be a good 
>time to add a field that may  simplify the identification of the signer's 
>certificate even more.
>
>First of all let me confirm that I think it is good that the 
>subjectKeyIdentifier has been added.  My concern is that I'm going to have 
>to do a lot of work to find such a certificate in a simple repository that 
>doesn't have good matching rule support.
>
>This will allow simple subject name look-up should an application wish to do 
>that.  Your proposed words for the MSG spec would still stand unaltered.
>
>Regards,
>
>Darren
>

---

From: "Darren Harter" <[email-masked]>
Date: Fri, 18 Dec 1998 10:57:47 +0000

Russ,

Thanks for the clarification on the reason why it was added.  I believe we still have scope for extending this to a more useable form and bundling the changes together.

My developers complained like hell when they first encountered IssuerAndSerialNumber as it's a complete nightmare when working with subjectName based repositories.  Using SubjectAndKeyIdentifier would allow very easy location of certs whether they were in the received SignedData or not.

Regards,

Darren

>>> Russ Housley <[email-masked]> 12/16/98 06:50pm >>>
Darren:

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Dec 1998 15:13:15 -0500

Darren:

I understand your desire; however at this late stage, I a relucatnt to make
any further changes unless there is significant demand from the entire
working group.

All:

If you agree with Darren's suggestion, speak NOW!

Russ
Chair, S/MIME WG

At 10:57 AM 12/18/98 +0000, Darren Harter wrote:
>Russ,
>
>Thanks for the clarification on the reason why it was added.  I believe we 
>still have scope for extending this to a more useable form and bundling the 
>changes together.
>
>My developers complained like hell when they first encountered 
>IssuerAndSerialNumber as it's a complete nightmare when working with 
>subjectName based repositories.  Using SubjectAndKeyIdentifier would allow 
>very easy location of certs whether they were in the received SignedData or 
>not.
>
>Regards,
>
>Darren
>