Subject: Re: CMS Key Wrapping
From: Dr Stephen Henson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 31 May 1998 15:12:26 +0100

Given that key transport and key agreement (with arbitrary checksum) are
vulnerable to attacks at either a single or multiple recipients (some
undetectable except that garbage is received) I'm not completely
convinced that the checksum adds any useful security from tampering.

IMHO that's what signing should is used for.

I would suggest the simpler alternative of just encrypting the (padded)
content encryption key and having an additional
EncryptionAlgorithmIdentifier field to give the encryption algorithm and
IV used. That way a different encryption algorithm and IV can be used
for encrypting the content encryption key (though why this is useful is
not immediately obvious).

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Sat, 30 May 1998 22:10:48 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: ESS EquivalentLabel Proposal
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> wrote:

> Do others on the list agree with Jim that, even if we can define
> EquivalentLabels, they will not be of enough value to add them in at this
> late date?

Paul,

    No, I think this sounds like a valuable feature.  I've been concerned about label policy mapping since it was raised earlier this year, and this gives us a much better (and more appropriate) alternative to wrapping successive layers of SignedData.

    I say accept John's proposal.

Chris

 -----------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.  |
 |  Christopher D. Bonatti             Principal Engineer  |
 -----------------------------------------------------------

_____________________

> Subject:      RE: ESS EquivalentLabel Proposal
> Date:          Thu, 28 May 1998 17:31:04 -0700
> From:         Paul Hoffman / IMC <[email-masked]>
> To:            <[email-masked]>
>
>
> At 05:11 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
> >I don't believe that this solves a large enough set of problems to be
> >interesting.
>
> This I might agree with. On the other hand, many of the things in ESS might
> fall into that category as well.
>
> Do others on the list agree with Jim that, even if we can define
> EquivalentLabels, they will not be of enough value to add them in at this
> late date?
>
> >I would hardly call items 1 and 2 irrelevant.  These are
> >normal cases which will show up in day to day actvities.
>
> Sure. But there are lots of other things we would want to do with inner
> signatures that we can't, such as add countersignatures. I don't see the
> desire to add EquivalentLabels as different from other desires.
>
> >You need to do more than this.  You must also verify (somehow) that the
> >signer of the equivalence label is trusted to do equivalence mapping, or you
> >must ignore the mapping.
>
> Sorry, I thought that was obvious. A recipient would have a list of trusted
> mappers. The new addition now reads:
>
> When processing an EquivalentLabels attribute, the receiving agent MUST
> validate the signature onthe EquivalentLabels to determine if there are
> additional security labels it wishes to use. A receiving agent MUST NOT act
> on EquivalentLabels for which the signature could not be validated or
> EquivalentLabels not signed by entities trusted to add or change access
> policies; determining who is allowed to specify equivalence mappings is a
> local policy. A receiving agent SHOULD process the ESSSecurityLabel before
> processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
> understood by the receiving agent, it SHOULD process that label and ignore
> the EquivalentLabels.
>
> >You covered half of my issue  What if two different signers have two
> >different ESSEquivalentLabels on them.  Do I check both or must they be
> >identical.
>
> See the wordiing above. You check both, and they do not need to be
> identical. If both check out and both are authorized to do mappings and
> both are different, you pick either. It's just like a single policy that
> has an "or" in it.
>
> >Not enough text.  This had to do with the case of adding an equivlance
> >mapping when no security label existed on the message, i.e. no label is the
> >same as un-marked.  There is no real need to have the equivalence label to
> >support this configuration.
>
> I agree. On the other hand, I don't think it hurts, and it helps a bit
> because it labels the new policy as a mapped one, not an original. But I'm
> not particularly attached to it.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Date: Sat, 30 May 1998 21:56:46 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: ietf-smime <[email-masked]>
Subject: Re: Fw: ESSSecurityLabel Version Deletion
Sender: [email-masked]

I concur.  Delete it.  I didn't see the point to a version field in an attribute anyway.

Chris

________________

> From: Darren Harter <[email-masked]>
> To: John Pawling <[email-masked]>
> Date: Sunday, May 24, 1998 12:10
> Subject: Re: ESSSecurityLabel Version Deletion
>
> >John,
> >
> >Thanks for re-raising this one.  The DER encoding order for v2 labels has
> >changed slightly since my original posting which makes the removal of
> >version even more necessary, IMHO.  The UTF8String in the Privacy marking
> >choice is not now tagged as [1] (0x81), and will appear before the Version
> >(0x80) as it now uses the native UTF8String tag (which I can't remember).
> >
> >The order would be
> >
> >>>     Classification - tag 0x02
> >>>     PolicyId - tag 0x06
> >>>     Privacy - tag 0x1??
> >>>     Categories - tag 0x30
> >>>     Version - 0x80
> >
> >i.e. an app only expecting v1 labels would choke on receiving the
> UTF8String
> >tag before the version tag..
> >
> >I agree that we should remove the version field from ESSSecurityLabel, as
> it
> >serves no useful purpose.
> >
> >Darren
> >
> >
> >

Date: Fri, 29 May 1998 15:26:46 -0400
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: CMS Key Wrapping
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

S/MIME 3 requires a function to encrypt one Triple-DES key in another.  I
posted a proposed method several weeks ago, and I got a fair amount of
feedback.  The most common concern was the lack of flexibility.  may people
prefered a technique that was algorithm independent.  Below, I propose an
algorithm independent function, and I am writing to request review of
that function.  I propose a function that provides confidentiality and
integrity.

As background, here is refresher about how S/MIME 3 will use the function. 
S/MIME 3 locally generates a random content-encryption key.  As the name
implies, this key will be used to encrypt the message content.  Then,
Diffie-Hellman will be used to generate a pairwise key-encryption key with
each
message recipient, and the content-encryption key will be encrypted under the
pairwise key-encryption key.

The blocksize of the key-encryption algorithm can be determined from the CMS
KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
exception here; the same identifer is used for both 2-key and 3-key Triple
DES.  This is probably easily handled by always wrapping three keyes, even if
the first and third keys match.

Please do not propose improvements that are covered by any issued or pending
patents.

Thanks for your assistance,
  Russ

- - - - - - - - - - 

KEY CHECKSUM ALGORITHM:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant octet to least significant octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         8 zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

KEY WRAP ALGORITHM:

1.  Adjust the parity bits on DES and Triple-DES keys.
2.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
3.  Generate a 4-octet random salt value.
4.  Concatenate the salt, content-encryption key, and key 
    checksum value.
5.  Generate the number of pad octets necessary to make the
    result a multiple of the key-encryption algorithm block
    size, then append them to the result.
6.  Encrypt the result with the key-encryption key.  If the
    algorithm requires an IV, use an IV with each octet equal
    to 'A5' hexidecimal.

KEY UNWRAP ALGORITHM:

1.  Decrypt the wrapped ciphertext using the key-encryption key.
    If the algorithm requires an IV, use an IV with each octet 
    equal to 'A5' hexidecimal.
2.  Check the parity of DES and Triple-DES keys.  If any is 
    incorrect then there is an error.
3.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
4.  If computed key checksum value does not match the decrypted
    key checksum value, then there is an error.

Date: Fri, 29 May 1998 13:09:57 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Support for Anonymous Diffie-Hellman
Sender: [email-masked]

Dear S/MIME WG:

>From the discussion on the list, I am convinced that there is concensus for
support of anonymous Diffie-Hellman.  I proose the following syntax for this
support.

I prefer this syntax to others that have been proposed on the list because
irequires a certificate identifier or a public key, and it does not permit
someone to make a mistake by omitting both.

Russ

= = = = = = = = = = 

KeyAgreeRecipientInfo ::= SEQUENCE {
  version Version,  -- always set to 3
  originator [0] EXPLICIT OriginatorIdentifierOrKey,
  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  recipientEncryptedKeys RecipientEncryptedKeys }

OriginatorIdentifierOrKey ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  subjectKeyIdentifier [0] SubjectKeyIdentifier,
  originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  publicKey BIT STRING }

RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE {
  rid RecipientIdentifier,
  encryptedKey EncryptedKey }

RecipientIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  rKeyId [0] IMPLICIT RecipientKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
  subjectKeyIdentifier SubjectKeyIdentifier,
  date GeneralizedTime OPTIONAL,
  other OtherKeyAttribute OPTIONAL }

SubjectKeyIdentifier ::= OCTET STRING

Date: Fri, 29 May 1998 12:38:44 -0400
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: ESS EquivalentLabel Proposal
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Jim:

>I don't believe that this solves a large enough set of problems to be
>interesting.   I would hardly call items 1 and 2 irrelevant.  These are
>normal cases which will show up in day to day actvities.  I forward a piece
>of mail to you which was signed and labeled by the originator --- you can't
>open the message because you don't understand the policy involved.  This is
>exactly the type of thing I though this was suppose to solve.

For simplicity, lets assume that there is not any encryption.  I think it
just clouds the issues associated with atributes in SignerInfo.

I think that you are poiting out the difference between one SignedData
being encapsulated in another as opposed to two SignerInfo values that are
part of one SignedData.  The two have very differnt properties.  And, both
are useful in different conexts.

As you point out, one SignedData encapsualted in another is used in
forwarding.  The recipient might be very confused by conflicting security
labels on the two SignedDatas; however, it is clear which content is overed
by any access control decision made based on the label.

Parallel SignerInfos, on the other hand, relate to the same content.  The
ESSSecurityLabels must match.  If an intermediate system knows that some
recipients cannot handle the security policy within the ESSSecurityLabel,
it provides the equivalent label for those recipients.  The recipient ets
to choose which SignerInfo to process.  This capability permits the
originator to sign with more than one algorithm, say DSS and RSA.  Thus,
the recipient can process the SignerInfo associated with the algorithm it
implements, and the recipient ignores the other SignerInfo.  Similarly, the
recipient can choose the SignerInfo that includes the equivalent labels
instead of the one with just the original originator provided
ESSSecurityLabel.

Russ

Date: Fri, 29 May 1998 14:22:22 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: New CMS Signed Attribute for binding Attribute Certificate
Cc: [email-masked]
Sender: [email-masked]

Steve Henson wrote:
>
>Might this not be better handled as an extension to the
>SigningCertificate signed attribute? IMHO this seems to be fulfilling
>the same purpose for the signers certificate and defeat similar attacks.
>
>If this was extended to allow arbitrary certificates (attribute or
>otherwise) to be included it would fulfil both purposes and foil some
>potential (though admittedly difficult) attacks as well.
>
>That still leaves the thorny issue of how to identify the certificates:
>i.e. hash of certificate only, hash and other properties or just other
>properties. 
>
>As I've said before I personally prefer hash only because it is compact
>and guaranteed to be unique. It will also bind anything whatever the
>final syntax e.g. attribute certificates, "normal" certificates or any
>other kind of certificate that might be used in the future. 
>
I agree with Steve that the SigningCertificate signed attribute might be
another approach to handle this requirement for binding Attribute Certificate.

Although a hash only might be sufficient for a public key certificate since
it is also identified through the SignerInfo issuerAndSerialNumber field,
attribute certificates are NOT identified anywhere except by being included
in the SignedData certificates field. The situation gets even worst when
the SignedData optional certificates field is purposely left empty or does
not include attribute certificates since it is expected that recipients
have alternate means of obtaining them.

Because of this, a set of hashes alone will not suffice to identify
particular attribute certificates. In Addition, contrary to public key
certificates that are identified by the distinguished name of their issuer,
attribute certificates are identified by the GeneralNames of their issuer.
Any new generic syntax for the SigningCertificate signed attribute would
have to address both of these issues.

Francois Rousseau

Date: Fri, 29 May 1998 17:09:13 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: New CMS Signed Attribute for binding Attribute Certificate
Sender: [email-masked]

Francois Rousseau wrote:
> 
> So far the consensus is to accommodate the transfer of Attribute
> Certificates but not to mandate anything further about them under S/MIME.
> However just transferring Attribute Certificates under the SignedData
> certificates field might not be sufficient for future business applications
> using S/MIME as a transport mechanism.
> 

Might this not be better handled as an extension to the
SigningCertificate signed attribute? IMHO this seems to be fulfilling
the same purpose for the signers certificate and defeat similar attacks.

If this was extended to allow arbitrary certificates (attribute or
otherwise) to be included it would fulfil both purposes and foil some
potential (though admittedly difficult) attacks as well.

That still leaves the thorny issue of how to identify the certificates:
i.e. hash of certificate only, hash and other properties or just other
properties. 

As I've said before I personally prefer hash only because it is compact
and guaranteed to be unique. It will also bind anything whatever the
final syntax e.g. attribute certificates, "normal" certificates or any
other kind of certificate that might be used in the future. 

In this way even if an implementation does not handle attribute
certificates itself (e.g. does not parse them) it can still check for
tampering by treating such certificates as a "blob".

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Fri, 29 May 1998 10:15:49 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: New CMS Signed Attribute for binding Attribute Certificate
Sender: [email-masked]

As suggested by Russ Housley, because there does not seem to be a consensus
on this one, I am starting a separate thread to discuss this topic.

So far the consensus is to accommodate the transfer of Attribute
Certificates but not to mandate anything further about them under S/MIME.
However just transferring Attribute Certificates under the SignedData
certificates field might not be sufficient for future business applications
using S/MIME as a transport mechanism.

Because a signer may have multiple Attribute Certificates, it should be up
to the signer to indicate which ones he/she is wishing the recipient to
use. The recipient should only be allowed to use what is possible within
the choice of the signer. The context alone might not be sufficient for the
recipient to determine which particular Attribute Certificate must be used.

There are currently no means for a signer to bind particular Attribute
Certificate(s) to a signed content from the many attribute certificates
he/she may have. To fix this, without mandating anything further
requirements under S/MIME, I would like to suggest a new signed attribute
under CMS.

Section 11 of CMS should contain a new signed attribute as suggested in my
previous messages that binds particular Attribute Certificate(s) with a
signed content to convey the signer's privilege. Note this new signed
attribute would only be processed by the recipient's application.

It would read as follows:

"11.6 Signer Privileges

The signer-privilege attribute type specifies the attribute certificate
that must be considered to be bound with the ContentInfo value being signed
in signed-data and/or in a countersignature attribute.  The
signer-privilege attribute helps in conveying the signer's privilege to the
recipient's application.

The signer-privilege attribute may be a signed attribute; it cannot be an
unsigned attribute, an authenticated attribute, or an unauthenticated
attribute.

The following object identifier identifies the signerPrivilege attribute type:

 	id-aa-signerPrivilege OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) <TBD> }

Signer-privilege attribute values have ASN.1 type SignerPrivilege:

SignerPrivilege ::= IssuerSerial

IssuerSerial ::= SEQUENCE {
         issuer		GeneralNames,
         serialNumber	CertificateSerialNumber,
         issuerUID		UniqueIdentifier OPTIONAL }

Where the fields of IssuerSerial have the following meanings:
 
The issuer is the name of the Attribute Authority that created the
attribute certificate.

The serialNumber is the serial number that uniquely identifies the
attribute certificate.
 
The issuerUID may be used to identify the issuer of the attribute
certificate in instances where the issuer name is not sufficient.  This may
be required because of the use of GeneralNames to identify the issuer of
the attribute certificate.

Note: The definition of IssuerSerial matches the one specified in the 1997
version of X.509 for an attribute certificate.

A signerPrivilege attribute can have multiple attribute values.

Until the use of attribute certificates gets better defined, the processing
of the signerPrivilege attribute should left to the recipient's application."

Francois Rousseau

Date: Fri, 29 May 1998 08:56:20 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: CMS-05 Comments
Cc: [email-masked]
Sender: [email-masked]

Russ,

I have three other minor comments:

1) Sec 6.2.3, "mlKeyId" was replaced by "mlid".

2) Sec 9.1, the definition for the originatorInfo field indicates that it
may contain user keying material (UKMs), as defined in Section 6.1.
However, UKMs are not contained in the originatorInfo field, but instead
are contained in the KeyAgreeRecipientInfo field defined in Sec 6.2.2.

3) Sec 9.1, the last sentence indicates that useful attribute types are
defined in Section 11. You should probably indicate that of the attributes
defined in Section 11, none currently apply for unauthenticatedAttributes. 

Francois Rousseau

Date: Thu, 28 May 1998 17:31:04 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS EquivalentLabel Proposal
Sender: [email-masked]

At 05:11 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
>I don't believe that this solves a large enough set of problems to be
>interesting.

This I might agree with. On the other hand, many of the things in ESS might
fall into that category as well.

Do others on the list agree with Jim that, even if we can define
EquivalentLabels, they will not be of enough value to add them in at this
late date?

>I would hardly call items 1 and 2 irrelevant.  These are
>normal cases which will show up in day to day actvities.

Sure. But there are lots of other things we would want to do with inner
signatures that we can't, such as add countersignatures. I don't see the
desire to add EquivalentLabels as different from other desires.

>You need to do more than this.  You must also verify (somehow) that the
>signer of the equivalence label is trusted to do equivalence mapping, or you
>must ignore the mapping.

Sorry, I thought that was obvious. A recipient would have a list of trusted
mappers. The new addition now reads:

When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature onthe EquivalentLabels to determine if there are
additional security labels it wishes to use. A receiving agent MUST NOT act
on EquivalentLabels for which the signature could not be validated or
EquivalentLabels not signed by entities trusted to add or change access
policies; determining who is allowed to specify equivalence mappings is a
local policy. A receiving agent SHOULD process the ESSSecurityLabel before
processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
understood by the receiving agent, it SHOULD process that label and ignore
the EquivalentLabels.

>You covered half of my issue  What if two different signers have two
>different ESSEquivalentLabels on them.  Do I check both or must they be
>identical.

See the wordiing above. You check both, and they do not need to be
identical. If both check out and both are authorized to do mappings and
both are different, you pick either. It's just like a single policy that
has an "or" in it.

>Not enough text.  This had to do with the case of adding an equivlance
>mapping when no security label existed on the message, i.e. no label is the
>same as un-marked.  There is no real need to have the equivalence label to
>support this configuration.

I agree. On the other hand, I don't think it hurts, and it helps a bit
because it labels the new policy as a mapped one, not an original. But I'm
not particularly attached to it.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, ietf-smime <[email-masked]>
Subject: RE: ESS EquivalentLabel Proposal
Date: Thu, 28 May 1998 17:11:12 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Thursday, May 28, 1998 3:28 PM
> To: ietf-smime
> Subject: RE: ESS EquivalentLabel Proposal
> 
> 
> At 02:28 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
> >It appears that this would be something that is added by 
> gateways and not by
> >senders.
> 
> Correct. The sender would put what they thought the right label the
> recipient could use. I envision that it would be incoming 
> gateways that
> would be putting on EquivalentLabels. That is, for
> SenderA -> STMPX -> the Internet -> STMPY -> RecipientB
> the equivalent labels would go on at SMTPY or after.
> 
> >The problem is that gateways cannot solve the problem without
> >completely breaking security.
> 
> I disagree. It cannot solve all problems, but 
> EquivalentLabels solves some
> of them without breaking anything.

I don't believe that this solves a large enough set of problems to be
interesting.   I would hardly call items 1 and 2 irrelevant.  These are
normal cases which will show up in day to day actvities.  I forward a piece
of mail to you which was signed and labeled by the originator --- you can't
open the message because you don't understand the policy involved.  This is
exactly the type of thing I though this was suppose to solve.

> 
> >1.  It is not possible to modify the security label on an 
> embedded message
> >without breaking the outer message's signature.
> 
> True, but irrelevant. In the case of a wrapped message, inner security
> labels are untouchable.
> 
> >2.  It is not posible to modify the security label on a 
> message which has
> >encryption applied to it, unless the gateway is one of the encryption
> >receipients or it has a copy of all users keys.
> 
> True, but irrelevant. This is true for any attribute added to 
> an encrypted
> message anywhere in the stream.
> 
> >3.  One must construct a set of rules to decide if the signer of the
> >ESSEquivalentLabel knows what they are talking about.  There 
> is nothing to
> >prevent random originators from including this attribute.
> 
> Correct. However, it's up to the recipient to determine what 
> to do with
> random EquivalentLabels. I propose adding the following text:
> 
> When processing an EquivalentLabels attribute, the receiving 
> agent MUST
> validate the signature onthe EquivalentLabels to determine if 
> there are
> additional security labels it wishes to use. A receiving 
> agent MUST NOT act
> on EquivalentLabels for which the signature could not be validated or
> EquivalentLabels not signed by entities trusted to add or 
> change access
> policies. A receiving agent SHOULD process the ESSSecurityLabel before
> processing the EquivalentLabels. If the policy in the 
> ESSSecurityLabel is
> understood by the receiving agent, it SHOULD process that 
> label and ignore
> the EquivalentLabels.

You need to do more than this.  You must also verify (somehow) that the
signer of the equivalence label is trusted to do equivalence mapping, or you
must ignore the mapping.

> 
> >4.  This proposal does nothing to allow for dynamic changes 
> in the policy.
> >If I receive the mail before the mapping goes into effect or 
> if the mapping
> >is removed after I receive the mail, no changes in the 
> equivalence can be
> >updated.
> 
> Er, so what? That's true of all security labels, not just 
> mapped ones. If I
> send a message which refers to a policy that gets changed before the
> message is received, I'm in the same boat.
> 
Yes that is true, however it is far more likely that I will change my
understanding of YOUR security policy than I will make an incompatable
change in MY security policy.  Most of the time when policies are changed
locally they are not done in a "drastic" way.  You add a new level or maybe
colapse together a couple of levels.  You don't make a change along the
lines of "secret just became un-marked".  You break secret into two
different levels.

> >5.  Depending on the speed that CMS gets finished, I think 
> this is going to
> >slow ESS from last call.  I think this is going to be an item of
> >controversy.
> 
> Unfortunately, I disagree: we have a fair of time while we 
> wait for patent
> issues with CMS and PKIX to settle.

You may be right about this.

> 
> >6.  If I have two policy modules installed on the system, 
> one for OID A and
> >one for OID B, do I check all possible policys for 
> acceptance?  You now have
> >introduced a degree of ambiguitiy since there are multiple 
> possible policies
> >which apply.
> 
> Good point. I believe my additional text above covers this.

You covered half of my issue  What if two different signers have two
different ESSEquivalentLabels on them.  Do I check both or must they be
identical.

> 
> >7.  There is now a question about forwarding of messages 
> between different
> >orgs which may or may not agree on policy mappings.  What 
> happens if I send
> >a message from A to B, which adds an equivalence label, and 
> then from B to
> >C, which adds an equilvance label, I now have multiple conflicting
> >equivalency labels.  How do I select the correct one and do 
> the mapping?
> 
> I don't see them as conflicting. I think the scenario you 
> meant to describe
> was you receive a message with an ESSSecurityLabel, an 
> EquivalentLabels
> signed by B, and an EquivalentLabels signed by C. If you 
> don't know the
> policy in the ESSSecurityLabel, and you verify and trust both 
> B and C, you
> can pick either of the EquivalentLabels to use in processing.
> 
> >8.  The adding of a security label by the gateway can be 
> accomplished by
> >just adding a security label, there is no need to have an 
> equivalency label
> >in this case.
> 
> I have no idea what you mean here. You can't "just add" a conflicting
> security label in the same level as on that is already there. 
> Could you be
> more specific about this scenario?

Not enough text.  This had to do with the case of adding an equivlance
mapping when no security label existed on the message, i.e. no label is the
same as un-marked.  There is no real need to have the equivalence label to
support this configuration.

> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

jim

Date: Thu, 28 May 1998 15:27:57 -0700
To: ietf-smime <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: ESS EquivalentLabel Proposal
Sender: [email-masked]

At 02:28 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
>It appears that this would be something that is added by gateways and not by
>senders.

Correct. The sender would put what they thought the right label the
recipient could use. I envision that it would be incoming gateways that
would be putting on EquivalentLabels. That is, for
SenderA -> STMPX -> the Internet -> STMPY -> RecipientB
the equivalent labels would go on at SMTPY or after.

>The problem is that gateways cannot solve the problem without
>completely breaking security.

I disagree. It cannot solve all problems, but EquivalentLabels solves some
of them without breaking anything.

>1.  It is not possible to modify the security label on an embedded message
>without breaking the outer message's signature.

True, but irrelevant. In the case of a wrapped message, inner security
labels are untouchable.

>2.  It is not posible to modify the security label on a message which has
>encryption applied to it, unless the gateway is one of the encryption
>receipients or it has a copy of all users keys.

True, but irrelevant. This is true for any attribute added to an encrypted
message anywhere in the stream.

>3.  One must construct a set of rules to decide if the signer of the
>ESSEquivalentLabel knows what they are talking about.  There is nothing to
>prevent random originators from including this attribute.

Correct. However, it's up to the recipient to determine what to do with
random EquivalentLabels. I propose adding the following text:

When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature onthe EquivalentLabels to determine if there are
additional security labels it wishes to use. A receiving agent MUST NOT act
on EquivalentLabels for which the signature could not be validated or
EquivalentLabels not signed by entities trusted to add or change access
policies. A receiving agent SHOULD process the ESSSecurityLabel before
processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
understood by the receiving agent, it SHOULD process that label and ignore
the EquivalentLabels.

>4.  This proposal does nothing to allow for dynamic changes in the policy.
>If I receive the mail before the mapping goes into effect or if the mapping
>is removed after I receive the mail, no changes in the equivalence can be
>updated.

Er, so what? That's true of all security labels, not just mapped ones. If I
send a message which refers to a policy that gets changed before the
message is received, I'm in the same boat.

>5.  Depending on the speed that CMS gets finished, I think this is going to
>slow ESS from last call.  I think this is going to be an item of
>controversy.

Unfortunately, I disagree: we have a fair of time while we wait for patent
issues with CMS and PKIX to settle.

>6.  If I have two policy modules installed on the system, one for OID A and
>one for OID B, do I check all possible policys for acceptance?  You now have
>introduced a degree of ambiguitiy since there are multiple possible policies
>which apply.

Good point. I believe my additional text above covers this.

>7.  There is now a question about forwarding of messages between different
>orgs which may or may not agree on policy mappings.  What happens if I send
>a message from A to B, which adds an equivalence label, and then from B to
>C, which adds an equilvance label, I now have multiple conflicting
>equivalency labels.  How do I select the correct one and do the mapping?

I don't see them as conflicting. I think the scenario you meant to describe
was you receive a message with an ESSSecurityLabel, an EquivalentLabels
signed by B, and an EquivalentLabels signed by C. If you don't know the
policy in the ESSSecurityLabel, and you verify and trust both B and C, you
can pick either of the EquivalentLabels to use in processing.

>8.  The adding of a security label by the gateway can be accomplished by
>just adding a security label, there is no need to have an equivalency label
>in this case.

I have no idea what you mean here. You can't "just add" a conflicting
security label in the same level as on that is already there. Could you be
more specific about this scenario?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 28 May 1998 17:35:07 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CMS-05 Comments
Cc: [email-masked]
Sender: [email-masked]

Francois:

>1) Sec 5, the last paragraph should read:
>
>"This section is divided into six parts.  The first part describes the
>top-level type SignedData, the second part describes the
>EncapsulatedContentInfo, the third part describes the per-signer
>information type SignerInfo, and the fourth, fifth, and sixth parts
>describe the message digest calculation, signature generation, and
>signature validation processes, respectively."

Obviously correct.  Fixed.

>2) Sec 5.2, the first should read:
>
>"The actual content is represented in the type EncapsulatedContentInfo:"

Also obviously correct.  Fixed.

>3) Sec 11 should contain a new signed attribute as suggested in my previous
>messages that binds particular Attribute Certificate(s) with a signed
>content to convey the signer's privilege. It would read as follows:
>
>"11.6 Signer Privileges
>
>The signer-privilege attribute type specifies the attribute certificate
>that must be considered to be bound with the ContentInfo value being signed
>in signed-data and/or in a countersignature attribute.  The
>signer-privilege attribute helps in conveying the signer's privilege to the
>verifier's application.
>
>The signer-privilege attribute may be a signed attribute; it cannot be an
>unsigned attribute, an authenticated attribute, or an unauthenticated
>attribute.
>
>The following object identifier identifies the signerPrivilege attribute
type:
>
> 	id-aa-signerPrivilege OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) <TBD> }
>
>Signer-privilege attribute values have ASN.1 type SignerPrivilege:
>
>SignerPrivilege ::= IssuerSerial
>
>IssuerSerial ::= SEQUENCE {
>         issuer		GeneralNames,
>         serialNumber	CertificateSerialNumber,
>         issuerUID		UniqueIdentifier OPTIONAL }
>
>Where the fields of IssuerSerial have the following meanings:
> 
>The issuer is the name of the Attribute Authority which created the
>attribute certificate.
>
>The serialNumber is the serial number that uniquely identifies the
>attribute certificate.
> 
>The issuerUID may be used to identify the issuer of the attribute
>certificate in instances where the issuer name is not sufficient.  This may
>be required because of the use of GeneralNames to identify the issuer of
>the attribute certificate.
>
>Note: The definition of IssuerSerial matches the one specified in the 1997
>version of X.509 for an attribute certificate.
>
>A signerPrivilege attribute can have multiple attribute values.
>
>Until the use of attribute certificates gets better defined, the processing
>of the signerPrivilege attribute should left to the verifier's application."

I am not sure that there is concensus on this one.  Please start a separate
thread to discuss this topic.

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Darren Harter'" <[email-masked]>, ietf-smime <[email-masked]>, "John Pawling (E-mail)" <[email-masked]>
Subject: RE: ESS EquivalentLabel Proposal
Date: Thu, 28 May 1998 14:28:52 -0700
Sender: [email-masked]

John and Darren,

I am afraid that I am going to have to disagree.  After spending some more
time looking at the proposal, many of my original fears are now fleshed out.

It appears that this would be something that is added by gateways and not by
senders.  The problem is that gateways cannot solve the problem without
completely breaking security.

1.  It is not possible to modify the security label on an embedded message
without breaking the outer message's signature.

2.  It is not posible to modify the security label on a message which has
encryption applied to it, unless the gateway is one of the encryption
receipients or it has a copy of all users keys.

3.  One must construct a set of rules to decide if the signer of the
ESSEquivalentLabel knows what they are talking about.  There is nothing to
prevent random originators from including this attribute.

4.  This proposal does nothing to allow for dynamic changes in the policy.
If I receive the mail before the mapping goes into effect or if the mapping
is removed after I receive the mail, no changes in the equivalence can be
updated.

5.  Depending on the speed that CMS gets finished, I think this is going to
slow ESS from last call.  I think this is going to be an item of
controversy.

6.  If I have two policy modules installed on the system, one for OID A and
one for OID B, do I check all possible policys for acceptance?  You now have
introduced a degree of ambiguitiy since there are multiple possible policies
which apply.

7.  There is now a question about forwarding of messages between different
orgs which may or may not agree on policy mappings.  What happens if I send
a message from A to B, which adds an equivalence label, and then from B to
C, which adds an equilvance label, I now have multiple conflicting
equivalency labels.  How do I select the correct one and do the mapping?

8.  The adding of a security label by the gateway can be accomplished by
just adding a security label, there is no need to have an equivalency label
in this case.

-----Original Message-----
From: Darren Harter [mailto:[email-masked]]
Sent: Monday, May 25, 1998 9:02 PM
To: ietf-smime
Subject: Fw: ESS EquivalentLabel Proposal

Sorry, Forgot to CC the list on my reply....

Darren

-----Original Message-----
From: Darren Harter <[email-masked]>
To: John Pawling <[email-masked]>
Date: Sunday, May 24, 1998 12:25
Subject: Re: ESS EquivalentLabel Proposal

>John,
>
>IMO, I think this is an excellent proposal.  I personally send paper-based
>messages marked under different labelling policies every day - sometimes
>these messages are marked under different labelling schemes for each
>recipient, although the labels themselves are semantically equivalent (i.e.
>All recipients understand them as meaning the same thing).
>
>I was concerned as to how I would implement this using S/MIME, but your
>proposal solves the problem with, I believe, an added bonus.  If I connect
>to domains together that operate under different labelling policies, and
the
>management of those domains can agree on a mapping between the different
>elements of the labels employed, a single gateway device could add an
>ESSEquivalentLabel  to each message as it passed between domains.
>Applications in the receiving domain would not process the ESSSecurityLabel
>as they would not understand the policy OID in it, but they would process
>the ESSEquivalentLabel  as they would understand the policy OID in that.
>The advantage being that when you connect domains together you don't have
to
>upgrade each end system to understand the new labelling policies, they only
>have to understand their own.
>
>I believe this is a simple and obvious addition to ESS, and probably one
>that the IESG would have raised on submission for an RFC.
>
>Darren
>
>
>

Date: Thu, 28 May 1998 16:56:07 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: CMS-05 Comments
Cc: [email-masked]
Sender: [email-masked]

Russ,

Great work but I have two minor comments and a suggestion for new signed
attribute:

1) Sec 5, the last paragraph should read:

"This section is divided into six parts.  The first part describes the
top-level type SignedData, the second part describes the
EncapsulatedContentInfo, the third part describes the per-signer
information type SignerInfo, and the fourth, fifth, and sixth parts
describe the message digest calculation, signature generation, and
signature validation processes, respectively."

2) Sec 5.2, the first should read:

"The actual content is represented in the type EncapsulatedContentInfo:"

3) Sec 11 should contain a new signed attribute as suggested in my previous
messages that binds particular Attribute Certificate(s) with a signed
content to convey the signer's privilege. It would read as follows:

"11.6 Signer Privileges

The signer-privilege attribute type specifies the attribute certificate
that must be considered to be bound with the ContentInfo value being signed
in signed-data and/or in a countersignature attribute.  The
signer-privilege attribute helps in conveying the signer's privilege to the
verifier's application.

The signer-privilege attribute may be a signed attribute; it cannot be an
unsigned attribute, an authenticated attribute, or an unauthenticated
attribute.

The following object identifier identifies the signerPrivilege attribute type:

 	id-aa-signerPrivilege OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) <TBD> }

Signer-privilege attribute values have ASN.1 type SignerPrivilege:

SignerPrivilege ::= IssuerSerial

IssuerSerial ::= SEQUENCE {
         issuer		GeneralNames,
         serialNumber	CertificateSerialNumber,
         issuerUID		UniqueIdentifier OPTIONAL }

Where the fields of IssuerSerial have the following meanings:
 
The issuer is the name of the Attribute Authority which created the
attribute certificate.

The serialNumber is the serial number that uniquely identifies the
attribute certificate.
 
The issuerUID may be used to identify the issuer of the attribute
certificate in instances where the issuer name is not sufficient.  This may
be required because of the use of GeneralNames to identify the issuer of
the attribute certificate.

Note: The definition of IssuerSerial matches the one specified in the 1997
version of X.509 for an attribute certificate.

A signerPrivilege attribute can have multiple attribute values.

Until the use of attribute certificates gets better defined, the processing
of the signerPrivilege attribute should left to the verifier's application."

Francois Rousseau

Date: Thu, 28 May 1998 15:24:02 -0400
To: "Capt Y. Theriault" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: cms-05 comments
Cc: [email-masked]
Sender: [email-masked]

Yves:

>Sect 6.2: should not the RecipientInfo CHOICE elements be tagged?  All the
>elements of the CHOICE are SEQUENCE type with a common first element:
>version.  Would not this make the decoding ambiguous?  I am not sure that
>the version value is sufficient to remove the ambiguity if a compiler is
>used to create decoding routines.  I would like to check that myself but I
>do not have an ASN.1 development environment.

The ktri alternative cannot be tagged and maintain backward compatability with
PKCS#7 v1.5.  Therefore, I propose:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  mlri [2] MailListRecipientInfo }

>Sect 6.2.1, version field description:  I think that EntityIdentifier now
>replaces RecipientIdentifier and rKeyId is replaced by SubjectKeyIdentifier.

You are correct.

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-cms-05.txt
Date: Thu, 28 May 1998 12:41:13 -0700
Sender: [email-masked]

At the December working group meeting, this was expressed as a desire from
the S/MIME side of CMS.  People working for groups like Amnesty
International wanted to be able to send anonymous mail which could not be
traced back to them without having decrypted the message.

Jim

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]]
Sent: Thursday, May 28, 1998 9:30 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-05.txt

Russ Housley wrote:
> 
> Steve:
> 
> I understand your point.  Without a certified originator public key, the
> recipient would not be able to determine the source of the message.  This
> is always true in the key transport case.
> 
> Do we want to permit this case?  At this point, I see no reason to have
the
> syntax preclude it, but I want to hear from other WG members.
> 

Yes I do want to permit this case. I think forcing a "signature" on
every key agreement enveloped message would be undesirable. 

It might discourage people from using key agreement and stick with key
transport (which as you say does not have this property).

There is also the practical issue of there being a mixture of RSA and DH
key carrying certificates. Someone with an RSA key carrying certificate
should not have to get a DH one (and possible CA expense) in order to
send enveloped data to a DH recipient.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Thu, 28 May 1998 17:29:48 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-05.txt
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve:
> 
> I understand your point.  Without a certified originator public key, the
> recipient would not be able to determine the source of the message.  This
> is always true in the key transport case.
> 
> Do we want to permit this case?  At this point, I see no reason to have the
> syntax preclude it, but I want to hear from other WG members.
> 

Yes I do want to permit this case. I think forcing a "signature" on
every key agreement enveloped message would be undesirable. 

It might discourage people from using key agreement and stick with key
transport (which as you say does not have this property).

There is also the practical issue of there being a mixture of RSA and DH
key carrying certificates. Someone with an RSA key carrying certificate
should not have to get a DH one (and possible CA expense) in order to
send enveloped data to a DH recipient.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Thu, 28 May 1998 11:35:19 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-05.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

I understand your point.  Without a certified originator public key, the
recipient would not be able to determine the source of the message.  This
is always true in the key transport case.  

Do we want to permit this case?  At this point, I see no reason to have the
syntax preclude it, but I want to hear from other WG members.

Russ

At 02:08 AM 5/28/98 +0100, Dr Stephen Henson wrote:
>> Section 6.2.2
>
>>       originatorCert is a CHOICE with two alternatives specifying the
>>       sender's certificate, and thereby the sender's public key.  The
>>       sender's certificate must contain a key agreement public key, and
>>       the sender uses the corresponding private key and the recipient's
>>       public key to generate a pairwise key.  
>
>Is it really necessary that the sender posesses a certificate containing
>a key agreement key?
>
>IMHO it need not be and a sender not posessing a certificate with a key
>agreement key should still be able to send a message to someone who has
>by generating a random key: ukm could (does?) support this. A sender
>might want to do this anyway to avoid an "implied signature".
>
>Maybe orignatorCert should be OPTIONAL to permit this: if not then isn't
>the explicit tag redundant?
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

Date: Thu, 28 May 1998 10:13:09 -0400
To: Russ Housley <[email-masked]>
From: "Capt Y. Theriault" <[email-masked]>
Subject: cms-05 comments
Cc: [email-masked]
Sender: [email-masked]

Russ,

Sect 6.2: should not the RecipientInfo CHOICE elements be tagged?  All the
elements of the CHOICE are SEQUENCE type with a common first element:
version.  Would not this make the decoding ambiguous?  I am not sure that
the version value is sufficient to remove the ambiguity if a compiler is
used to create decoding routines.  I would like to check that myself but I
do not have an ASN.1 development environment.

Sect 6.2.1, version field description:  I think that EntityIdentifier now
replaces RecipientIdentifier and rKeyId is replaced by SubjectKeyIdentifier.

Yves Theriault.

At 07:08 PM 5/27/98 -0400, you wrote:
>Section 6.2 has some major changes, and I would appreciate a quick review.
>
>Thanks,
>  Russ
>

>
>
Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

Date: Thu, 28 May 1998 02:08:35 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-05.txt
Sender: [email-masked]

> Section 6.2.2

>       originatorCert is a CHOICE with two alternatives specifying the
>       sender's certificate, and thereby the sender's public key.  The
>       sender's certificate must contain a key agreement public key, and
>       the sender uses the corresponding private key and the recipient's
>       public key to generate a pairwise key.  

Is it really necessary that the sender posesses a certificate containing
a key agreement key?

IMHO it need not be and a sender not posessing a certificate with a key
agreement key should still be able to send a message to someone who has
by generating a random key: ukm could (does?) support this. A sender
might want to do this anyway to avoid an "implied signature".

Maybe orignatorCert should be OPTIONAL to permit this: if not then isn't
the explicit tag redundant?

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 27 May 1998 19:08:01 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-05.txt
Sender: [email-masked]

Section 6.2 has some major changes, and I would appreciate a quick review.

Thanks,
  Russ

>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
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-smime-cms-05.txt
>	Pages		: 41
>	Date		: 26-May-98
>	
>   This document describes the Cryptographic Message Syntax.  This
>   syntax is used to digitally sign, digest, authenticate, or encrypt
>   arbitrary messages.
> 
>   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
>   [RFC 2315].  Wherever possible, backward compatibility is preserved;
>   however, changes were necessary to accommodate attribute certificate
>   transfer and key agreement techniques for key management.
> 
>   This draft is being discussed on the 'ietf-smime' mailing list.  To
>   join the list, send a message to <[email-masked]> with
>   the single word 'subscribe' in the body of the message.  Also, there
>   is a Web site for the mailing list at <http://www.imc.org/ietf-
>   smime/>.
>
>Internet-Drafts are 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-05.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-05.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-cms-05.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-05.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-05.txt>
> 

Date: Wed, 27 May 1998 12:25:35 -0700 (PDT)
From: Yahya Al-Salqan <[email-masked]>
Reply-To: Yahya Al-Salqan <[email-masked]>
Subject: Call for participation (FYI)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Content-MD5: SCk4v9pjCPXd6BFIFnKHgg==
Sender: [email-masked]

Today is the deadline for the early registration ... take advantage of it.

My appology if you receive this e-mail more than once!

 =================================================
                Call for Participation:

                  IEEE  WET ICE '98
            Third International Workshop
                         on
                 Enterprise Security

          Stanford University, Palo Alto, USA
                   June 17-19 1998
 =================================================

On behalf of the Workshop Program and Organizing Committees, I would like to 
invite you to participate in The 3rd IEEE International Enterprise Security 
Workshop will be held June 17-19, Stanford University, Palo Alto, California.  
The Workshop includes paper presentations, panel discussions, keynote speeches 
and invited talks covering all aspects of enterprise security.  Topics to be 
covered include: Public key infrastructure, intrusion detection, Web security, 
application security (e.g. digital library and healthcare), and access control.   

Highlights of the program:
	o Keynote speech by Dr. Li Gong, Java Security Architect, Sun 			
          Microsystems;
	o Industrial security expertise from: Microsoft NT security 		 
          group, Sun Microsystems, Entrust, Certicom, Verisign, SSH 				
          Communication security and many others.  It is an unprecedented 				
          opportunity to put all these companies in one room.  Don't miss it.
	o Participation of IETF security group leaders;  
	o Participation of NSA (National Security Agency);
	o Two panel discussions:
		- "State-of-the-art Enterprise Security: Practice and Future"
		- "Intrusion Detection: Present and Future"
	o Workshop held in conjunction with other WETICE workshops: 	
		"Web-based infrastructure for collaborative 			
		  Enterprises," 
		"Collaboration in Presence of Mobility," 
	
	o Two social events.

The Workshop Preliminary program can be found at:					
	http://www.ida.liu.se/labs/iislab/SECWK/agenda.html

The Registration form can be found at:
	http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html
	(Please mark the Enterprise Security on the registration form)
	
The Workshop main page can be found at:
	http://www.ida.liu.se/labs/iislab/SECWK/
		
I look forward to meeting you at the Workshop. 

Sincerely,

Yahya Al-Salqan, Ph.D.
Workshop General Chair
Sun Microsystems

------------- End Forwarded Message -------------

------------- End Forwarded Message -------------

Date: Wed, 27 May 1998 12:04:05 -0700
From: Kurt Stammberger <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RSA'99 Deadline
Sender: [email-masked]

Dave's NDSS note reminded me to remind y'all:

D E A D L I N E !        D E A D L I N E !

The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). 
For more information, or to propose a talk or submit a paper for
presentation, visit www.rsa.com/conf99

Questions?  E-mailez-moi.

Kurt Stammberger
Conference Director 
RSADSI

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-05.txt
Date: Wed, 27 May 1998 10:16:55 -0400
Sender: [email-masked]

--NextPart

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
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-05.txt
	Pages		: 41
	Date		: 26-May-98
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   [RFC 2315].  Wherever possible, backward compatibility is preserved;
   however, changes were necessary to accommodate attribute certificate
   transfer and key agreement techniques for key management.
 
   This draft is being discussed on the 'ietf-smime' mailing list.  To
   join the list, send a message to <[email-masked]> with
   the single word 'subscribe' in the body of the message.  Also, there
   is a Web site for the mailing list at <http://www.imc.org/ietf-
   smime/>.

Internet-Drafts are 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-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-05.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 27 May 1998 08:52:07 -0400
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99)
Cc: [email-masked]
Sender: [email-masked]

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

	    C  A  L  L       F  O  R       P  A  P  E  R  S

			  The Internet Society
	1999 Network and Distributed System Security Symposium
			       (NDSS'99)

Where: Catamaran Resort, San Diego, California
When: February 3-5, 1999

GOAL: The symposium will foster information exchange among hardware and
  software developers of network and distributed system security
  services.  The intended audience includes those who are interested in
  the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable the
  Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium will
  be published by the Internet Society.

  Topics for the symposium include, but are not limited to, the
  following:

* Security in malleable systems: mobile code, mobile agents, active
  networks, dynamic policy updates, etc.
* Special problems: e.g. interplay between security goals and other
  goals such as efficiency, usability, reliability, interoperability,
  resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies --
  very large systems, e.g., the Internet, high-speed systems, e.g., the
  gigabit testbeds, wireless systems, personal communication systems,
  and large-scale, heterogeneous distributed systems.

* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary
  services; endorsement, licensing, bonding, and other forms of
  assurance; rights management and other forms of intellectual property
  protection
* Implementation and management of network security policy 
* Security for voice over IP
* Security for routing

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CHAIRS:
  Stephen Kent, BBN Technologies
  Gene Tsudik, USC/Information Sciences Institute

TUTORIAL CHAIR:
  Doug Maughan, National Security Agency

PROGRAM COMMITTEE:
  David Balenson, TIS Labs at Network Associates
  Steve Bellovin, AT&T Labs -- Research
  Matt Bishop, University of California at Davis
  Bob Blakley, IBM
  Doug Engert, Argonne National Laboratories
  Warwick Ford, VeriSign
  Li Gong, Sun Microsystems
  Rich Graveman, Bellcore
  Ari Juels, RSA Laboratories
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Michael Roe, Cambridge University
  Jeffrey Schiller, MIT
  Wolfgang Schneider, GMD Darmstadt
  Christoph Schuba, Purdue University
  Win Treese, Open Market
  Jonathan Trostle, Cisco

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: The committee invites technical papers and panel proposals,
  for topics of technical and general interest.  Technical papers should
  be 10-20 pages in length.  Panel proposals should be two pages and
  should describe the topic, identify the panel chair, explain the
  format of the panel, and list three to four potential panelists.
  Technical papers will appear in the proceedings.  A description of
  each panel will appear in the proceedings, and may at the discretion
  of the panel chair, include written position statements from each
  panelist.

  Each submission must contain a separate title page with the type of
  submission (paper or panel), the title or topic, the names of the
  author(s), organizational affiliation(s), telephone and FAX numbers,
  postal addresses, Internet electronic mail addresses, and must list a
  single point of contact if more than one author.  The names of authors,
  affiliations, and other identifying information should appear only on
  the separate title page.

  Submissions must be received by 31 July 1998, and must be made via
  electronic mail in either PostScript or ASCII format.  If the
  committee is unable to print a PostScript submission, it will be
  returned and hardcopy requested.  Therefore, PostScript submissions
  must arrive well before 31 July.

  All submissions and program related correspondence (only) should be
  directed to the program chair:  
	Stephen Kent
	c/o BBN Technologies
	70 Fawcett Street
	Cambridge, Mass. 02138
	Email:[email-masked]
	Phone: +1 (617) 873-1996
	FAX: +1 (617) 873-4086

  Dates, final call for papers, advance program, and registration
  information will be available at the URL: http://www.isoc.org/ndss99.

  Each submission will be acknowledged by e-mail.  If acknowledgment is
  not received within seven days, please contact the program chair as
  indicated above.  Authors and panelists will be notified of acceptance
  by 18 September 1998.  Instructions for preparing camera-ready copy
  for the proceedings will be sent at that time.  The camera-ready copy
  must be received by 16 October 1998.

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363
--=====================_896287927==_--

From: "Darren Harter" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Fw: ESSSecurityLabel Version Deletion
Date: Tue, 26 May 1998 17:23:56 +0100
Sender: [email-masked]

I must have been on a bad day on Friday, I forgot to CC this one to the list
as well ;-)

Darren

-----Original Message-----
From: Darren Harter <[email-masked]>
To: John Pawling <[email-masked]>
Date: Sunday, May 24, 1998 12:10
Subject: Re: ESSSecurityLabel Version Deletion

>John,
>
>Thanks for re-raising this one.  The DER encoding order for v2 labels has
>changed slightly since my original posting which makes the removal of
>version even more necessary, IMHO.  The UTF8String in the Privacy marking
>choice is not now tagged as [1] (0x81), and will appear before the Version
>(0x80) as it now uses the native UTF8String tag (which I can't remember).
>
>The order would be
>
>>>     Classification - tag 0x02
>>>     PolicyId - tag 0x06
>>>     Privacy - tag 0x1??
>>>     Categories - tag 0x30
>>>     Version - 0x80
>
>i.e. an app only expecting v1 labels would choke on receiving the
UTF8String
>tag before the version tag..
>
>I agree that we should remove the version field from ESSSecurityLabel, as
it
>serves no useful purpose.
>
>Darren
>
>
>

Date: Tue, 26 May 1998 21:34:25 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS EquivalentLabel Proposal
Cc: [email-masked]
Sender: [email-masked]

Francois:

It seems to me that the certificate (or attribute certificate) would
contain the authorizations held by a particular user.  The security label
is different.  The security label specifies the handling requirements for a
particular message.  The proposed attribute states the label under
different policies that offer equal protection.

Russ

At 09:30 AM 5/25/98 -0400, Francois Rousseau wrote:
>I would like to suggest that this mapping could eventually be accomplished
>through a proposed extension for Attribute Certificates instead of an
>authenticated attribute. The following document on these proposed attribute
>certificate extensions contains an extension specifically for that purpose.
>
>ftp://ftp.bull.com/pub/OSIdirectory/Helsinki97Output/21DIR4.DOC
>
>"The attribute value mappings extension, which is for use in attribute
>certificates issued to Attribute Authorities only, allows a certificate
>issuer to indicate that, for the purposes of the user of a delegation path
>containing this certificate, one of the issuer's attribute values can be
>considered equivalent to a different attribute value used in the subject
>Attribute Authority's domain."
>
>As suggested by Jim Schaad, through using this attribute certificate
>extension to convey this mapping is something that should be implemented in
>policy verification code.
>
>Francois Rousseau
> 

Date: Tue, 26 May 1998 11:10:12 -0400
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESSSecurityLabel Version Deletion
Cc: [email-masked]
Sender: [email-masked]

I agree, the version is not adding any value.  It should be removed.

Russ

At 04:11 PM 5/22/98 -0400, John Pawling wrote:
>All,
>
>In March, Darren Harter correctly pointed out a problem with the
>ESSSecurityLabel syntax (see attached snip of Darren's msg).    The version
>number was added to ESSSecurityLabel as an indicator that the syntax is
>different than the X.411 securityLabel syntax (i.e. when privacyMark
>UTF8String CHOICE is present).  Darren correctly pointed out that when the
>ESSSecurityLabel SET is DER encoded, then the version number will appear
>after the majority of the fields in the ESSSecurityLabel.  I propose that
>the version component should be deleted from the ESSSecurityLabel syntax
>because it does not serve a useful purpose because it is not the first field
>to appear in the DER-encoded ESSSecurityLabel.  The id-aa-securityLabel OID
>identifies the ESSSecurityLabel syntax when it is used in an authenticated
>attribute.  If the ESSSecurityLabel syntax is changed after ESS becomes
>stable, then a new OID can be assigned to indicate the changed syntax.   
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>
>
>Darren Harter wrote:
>>
>>John,
>>
>>There is a further flaw in the scheme.  Because the ESSSecurityLabel is a
>>SET, it will be sorted when DER is used.
>>
>>This means that the set elements will appear in the following order in
the DER
>>encoding:
>>
>>When Printable String Used - v1
>>
>>     Classification - tag 0x02
>>     PolicyId - tag 0x06
>>     Privacy - tag 0x13
>>     Categories - tag 0x30
>>
>>When UTF8 String Used - v2
>>
>>     Classification - tag 0x02
>>     PolicyId - tag 0x06
>>     Categories - tag 0x30
>>     Version - 0x80
>>     Privacy - tag 0x81
><snip>
> 

From: "Darren Harter" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: Fw: ESS EquivalentLabel Proposal
Date: Tue, 26 May 1998 05:02:20 +0100
Sender: [email-masked]

Sorry, Forgot to CC the list on my reply....

Darren

-----Original Message-----
From: Darren Harter <[email-masked]>
To: John Pawling <[email-masked]>
Date: Sunday, May 24, 1998 12:25
Subject: Re: ESS EquivalentLabel Proposal

>John,
>
>IMO, I think this is an excellent proposal.  I personally send paper-based
>messages marked under different labelling policies every day - sometimes
>these messages are marked under different labelling schemes for each
>recipient, although the labels themselves are semantically equivalent (i.e.
>All recipients understand them as meaning the same thing).
>
>I was concerned as to how I would implement this using S/MIME, but your
>proposal solves the problem with, I believe, an added bonus.  If I connect
>to domains together that operate under different labelling policies, and
the
>management of those domains can agree on a mapping between the different
>elements of the labels employed, a single gateway device could add an
>ESSEquivalentLabel  to each message as it passed between domains.
>Applications in the receiving domain would not process the ESSSecurityLabel
>as they would not understand the policy OID in it, but they would process
>the ESSEquivalentLabel  as they would understand the policy OID in that.
>The advantage being that when you connect domains together you don't have
to
>upgrade each end system to understand the new labelling policies, they only
>have to understand their own.
>
>I believe this is a simple and obvious addition to ESS, and probably one
>that the IESG would have raised on submission for an RFC.
>
>Darren
>
>
>

Date: Tue, 26 May 1998 17:42:24 +0100
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: S/MIME collected ASN.1?
Sender: [email-masked]

Folks,

Is there a publicly available collected ASN.1 for all the elements of
S/MIME V3, as they currently stand?  (Including those imported from X.509,
etc.)

Thanks,

#g

------------
Graham Klyne

Date: Mon, 25 May 1998 11:11:36 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS EquivalentLabel Proposal
Sender: [email-masked]

Francois,

Thank you for you response and the valuable information that you have
provided.  I would like to point out that the equivalentLabel attribute
would be used to express equivalencies between security label values applied
to a content, whereas the AC attribute that you mention conveys
equivalencies between users' authorizations.  Therefore, the two mechansims
serve different purposes.  Furthermore, the use of ACs is not widespread, so
AC attributes can currently only be used be a limited set of folks.  The use
of ACs needs to be discussed and defined by the PKIX WG.  Recommend that you
initiate a discussion on the PKIX WG list to begin defining the use of ACs.

- John Pawling

At 09:30 AM 5/25/98 -0400, Francois Rousseau wrote:
>I would like to suggest that this mapping could eventually be accomplished
>through a proposed extension for Attribute Certificates instead of an
>authenticated attribute. The following document on these proposed attribute
>certificate extensions contains an extension specifically for that purpose.
>
>ftp://ftp.bull.com/pub/OSIdirectory/Helsinki97Output/21DIR4.DOC
>
>"The attribute value mappings extension, which is for use in attribute
>certificates issued to Attribute Authorities only, allows a certificate
>issuer to indicate that, for the purposes of the user of a delegation path
>containing this certificate, one of the issuer's attribute values can be
>considered equivalent to a different attribute value used in the subject
>Attribute Authority's domain."
>
>As suggested by Jim Schaad, through using this attribute certificate
>extension to convey this mapping is something that should be implemented in
>policy verification code.
>
>Francois Rousseau
>

Date: Mon, 25 May 1998 11:03:06 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS EquivalentLabel Proposal
Sender: [email-masked]

Jim (and friends),

Thank you for your response.  I have a few comments:

1) Please remember that this is an optional feature, not every S/MIME
implementor would be forced to implement the equivalentLabel attribute.  It
is not that hard to write software that performs equivalency mapping.  Van
Dyke has developed code that performs equivalency mapping using a
configuration file that indicates the equivalencies between the security
classifications and security categories in a one domain with those in one or
more remote domains.  The source code is available at
http://www.armadillo.huntsville.al.us/software if you would like to take a
look.  

2) This is an optional feature, a recipient can totally ignore the
equivalentLabel attribute if it so desires.  Because the original signer's
ESSSecurityLabel is present in every signerInfo, the original signer's
security label selections are unambiguous.  The receiving software can act
solely on the original signer's security label selections.  

3) I was hoping that this proposal would be non-controversial and that we
could quickly reach consensus that it should be added to the ESS I-D.  If
the WG can't reach consensus quickly, then I agree with you that the
equivlentLabel should not slow down progression of the ESS I-D.

- John Pawling

At 01:56 PM 5/23/98 -0700, Jim Schaad (Exchange) wrote:
>John,
>
>I'm going to think about and read this a few more times, but at first blush
>I am againist this for a couple of different reasons.
>
>1.  It sounds really hard, my first impression is that this is something
>that should be implemented in policy verification code rather than on the
>message being sent.
>2.  Just because Acme and Widget have agreed these are equivalent, does not
>mean that a third party would agree that they are the same.  Again this
>agrues that Acme and Widget should modify their policy verifers to allow for
>each other security policies.
>3.  It is new.  At this point I would rather not see drastic changes (and I
>would argue that this is drastic) be added to the ESS draft.  I would rather
>get them into last call and sable and put this into a new draft if we are
>going to do it.
>
>jim
>
>

Date: Mon, 25 May 1998 09:46:40 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESSSecurityLabel Version Deletion
Sender: [email-masked]

Jim (and friends),

The current ESSSecurityLabel syntax is backwards compatible with the X.411
securityLabel syntax except when the privacyMark UTF8String CHOICE is
present.  IMHO, there is significant value in maximizing backward
compatibility of the ESSSecurityLabel syntax with the X.411 securityLabel
syntax .  There are many security protocols (such as MSP 3.0, ACP120, X.411)
which use the X.411 securityLabel.  IMHO, it is beneficial to maximize the
consistency of the security label syntaxes used in these various security
protocols to make life easier for the users and for the implementors of
these various protocols.

Furthermore, there are folks that would like to see a standard security
label syntax used in all security protocols (e.g. X.411, S/MIME v3, etc).
They have selected the ESSSecurityLabel as their candidate to serve as the
standard security label.  They are planning to propose a change to the X.411
syntax that would add support for the privacyMark UTF8String CHOICE. If they
are successful, then the X.411 securityLabel and ESSSecurityLabel syntaxes
would be identical.  They are also planning to propose the ESSSecurityLabel
to ISO as the international standard security label.  Maximizing
compatibilty with X.411 is important to this group.

Also, there are organizations that would like to achieve interoperability
between S/MIME v3 applications and legacy applications that use the X.411
securityLabel.  Maximizing the backward compatibility of the
ESSSecurityLabel with the X.411 securityLabel makes their job easier.

In summary, I don't believe that changing the ESSSecurityLabel from a SET to
a SEQUENCE is a necessary change.  I believe that the version number should
be deleted from the ESSSecurityLabel syntax because the attribute OID
uniquely identifies the syntax.  Furthermore, changing the ESSSecurityLabel
from a SET to a SEQUENCE significantly decreases the backward compatibility
of the ESSSecurityLabel syntax with the X.411 security label syntax, so I
oppose the proposal.

- John Pawling

At 01:46 PM 5/23/98 -0700, Jim Schaad (Exchange) wrote:
>Once upon a time in the vague recesses of my mind I remember this issue
>coming up.  While I agree there are a number of good reasons for not having
>the version field anyway (versioning could be done by just using a new OID
>if necessary), I though that we had agreed that we were going to fix this by
>turning the SET into a SEQUENCE and thus getting the version field first.
>We have already made the break with the old encoding of security labels so
>there should be no problem with this.
>
>jim
>

Date: Mon, 25 May 1998 09:30:27 -0400
To: [email-masked] (John Pawling), [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: ESS EquivalentLabel Proposal
Cc: [email-masked]
Sender: [email-masked]

I would like to suggest that this mapping could eventually be accomplished
through a proposed extension for Attribute Certificates instead of an
authenticated attribute. The following document on these proposed attribute
certificate extensions contains an extension specifically for that purpose.

ftp://ftp.bull.com/pub/OSIdirectory/Helsinki97Output/21DIR4.DOC

"The attribute value mappings extension, which is for use in attribute
certificates issued to Attribute Authorities only, allows a certificate
issuer to indicate that, for the purposes of the user of a delegation path
containing this certificate, one of the issuer's attribute values can be
considered equivalent to a different attribute value used in the subject
Attribute Authority's domain."

As suggested by Jim Schaad, through using this attribute certificate
extension to convey this mapping is something that should be implemented in
policy verification code.

Francois Rousseau

Date: Sat, 23 May 1998 13:55:32 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS EquivalentLabel Proposal
Sender: [email-masked]

I think John's proposal is a good one. It causes no confusion for the
recipient about what the originator's security policy intentions are, and
it answers the desires of a few others on the list for a way to say "I
think that policy X is the same as the policy Y in the message". This
should lead to more organizations wanting to use S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESS EquivalentLabel Proposal
Date: Sat, 23 May 1998 13:56:24 -0700
Sender: [email-masked]

John,

I'm going to think about and read this a few more times, but at first blush
I am againist this for a couple of different reasons.

1.  It sounds really hard, my first impression is that this is something
that should be implemented in policy verification code rather than on the
message being sent.
2.  Just because Acme and Widget have agreed these are equivalent, does not
mean that a third party would agree that they are the same.  Again this
agrues that Acme and Widget should modify their policy verifers to allow for
each other security policies.
3.  It is new.  At this point I would rather not see drastic changes (and I
would argue that this is drastic) be added to the ESS draft.  I would rather
get them into last call and sable and put this into a new draft if we are
going to do it.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 22, 1998 12:36 PM
To: [email-masked]
Subject: ESS EquivalentLabel Proposal

All,

Recommend adding the following text as ESS Section 3.4:

"3.4.  Equivalent Security Labels 

Because organizations are allowed to define their own security policies,
many different security policies will exist. Some organizations may wish to
create equivalencies between their security policies with the security
policies of other organizations. For example, the Acme Company and the
Widget Corporation may reach a bilateral agreement that the "Acme private"
security-classification value is equivalent to the "Widget sensitive"
security-classification value.

The EquivalentLabel authenticated attribute is defined as:

EquivalentLabel ::= SEQUENCE OF ESSSecurityLabel

The id-equivalentLabel OID (TBD value) identifies the EquivalentLabel
attribute.

As stated earlier, the ESSSecurityLabel contains the sensitivity values
selected by the original signer of the signedData. If an ESSSecurityLabel
is present in a signerInfo, all signerInfos in the signedData MUST contain
an ESSSecurityLabel and they MUST all be identical. In addition to an
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabel
authenticated attribute. If present, the equivalentLabel attribute MUST
include one or more security labels that are believed by the signer to be
semantically equivalent to the ESSSecurityLabel attribute included in the
same signerInfo. 

All security-policy object identifiers (OID) MUST be unique in the set of
ESSSecurityLabel and EquivalentLabel security labels.  Before using an
EquivalentLabel attribute, an agent MUST ensure that all security-policy
OIDs are unique in the security label(s) included in the EquivalentLabel.
Once the agent selects the security label (within the EquivalentLabel) to be
used for processing, then the security-policy OID of the selected
EquivalentLabel security label MUST be compared with the ESSSecurityLabel
security-policy OID to ensure that they are unique.

In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabel attribute may still be included.  For
example, in the Acme security policy, the absence of an ESSSecurityLabel
could be defined to equate to a security label composed of the Acme
security-policy OID and the "unmarked" security-classification.

Please note that equivalentLabel MUST NOT be used to convey security labels
that are semantically different from the ESSSecurityLabel included in the
signerInfo(s) in the signedData.  If an entity needs to apply a security
label that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the
ESSSecurityLabel.

If present, the equivalentLabel attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute.  A signerInfo MUST NOT
include multiple instances of the equivalentLabel attribute.  CMS defines
the ASN.1 syntax for the authenticated attributes to include attrValues SET
OF AttributeValue.  A equivalentLabel attribute MUST only include a single
instance of AttributeValue.  There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESSSecurityLabel Version Deletion
Date: Sat, 23 May 1998 13:46:32 -0700
Sender: [email-masked]

Once upon a time in the vague recesses of my mind I remember this issue
coming up.  While I agree there are a number of good reasons for not having
the version field anyway (versioning could be done by just using a new OID
if necessary), I though that we had agreed that we were going to fix this by
turning the SET into a SEQUENCE and thus getting the version field first.
We have already made the break with the old encoding of security labels so
there should be no problem with this.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 22, 1998 1:11 PM
To: [email-masked]
Subject: ESSSecurityLabel Version Deletion

All,

In March, Darren Harter correctly pointed out a problem with the
ESSSecurityLabel syntax (see attached snip of Darren's msg).    The version
number was added to ESSSecurityLabel as an indicator that the syntax is
different than the X.411 securityLabel syntax (i.e. when privacyMark
UTF8String CHOICE is present).  Darren correctly pointed out that when the
ESSSecurityLabel SET is DER encoded, then the version number will appear
after the majority of the fields in the ESSSecurityLabel.  I propose that
the version component should be deleted from the ESSSecurityLabel syntax
because it does not serve a useful purpose because it is not the first field
to appear in the DER-encoded ESSSecurityLabel.  The id-aa-securityLabel OID
identifies the ESSSecurityLabel syntax when it is used in an authenticated
attribute.  If the ESSSecurityLabel syntax is changed after ESS becomes
stable, then a new OID can be assigned to indicate the changed syntax.   

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Darren Harter wrote:
>
>John,
>
>There is a further flaw in the scheme.  Because the ESSSecurityLabel is a
>SET, it will be sorted when DER is used.
>
>This means that the set elements will appear in the following order in the
DER
>encoding:
>
>When Printable String Used - v1
>
>     Classification - tag 0x02
>     PolicyId - tag 0x06
>     Privacy - tag 0x13
>     Categories - tag 0x30
>
>When UTF8 String Used - v2
>
>     Classification - tag 0x02
>     PolicyId - tag 0x06
>     Categories - tag 0x30
>     Version - 0x80
>     Privacy - tag 0x81
<snip>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Questions on Signed Receipts
Date: Sat, 23 May 1998 13:42:58 -0700
Sender: [email-masked]

I can agree with this wording.  It addresses the issue that I had about the
question of encrypting receipts quite well.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 21, 1998 5:35 AM
To: Ietf-Smime (E-mail)
Subject: RE: Questions on Signed Receipts

All,

Upon further reflection, I recommend that the following text be added to
ESS, Section 2.4, item 11: "All agents that support the generation of ESS
signed receipts MUST provide the ability to send encrypted signed receipts
(i.e. a signedData/Receipt encapsulated within an envelopedData).  The agent
MAY send an encrypted signed receipt in response to an
envelopedData-encapsulated signedData requesting a signed receipt.  It is a
matter of local policy regarding whether or not the signed receipt should be
encrypted.  The ESS signed receipt includes the message digest value
calculated for the original signedData object that requested the signed
receipt.  If the original signedData object was sent encrypted within an
envelopedData object and the ESS signed receipt is sent unencrypted, then
the message digest value calculated for the original encrypted signedData
object is sent unencrypted.  The responder should consider this when
deciding whether or not to encrypt the ESS signed receipt. "

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
===============================

Date: Fri, 22 May 1998 16:11:23 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESSSecurityLabel Version Deletion
Sender: [email-masked]

All,

In March, Darren Harter correctly pointed out a problem with the
ESSSecurityLabel syntax (see attached snip of Darren's msg).    The version
number was added to ESSSecurityLabel as an indicator that the syntax is
different than the X.411 securityLabel syntax (i.e. when privacyMark
UTF8String CHOICE is present).  Darren correctly pointed out that when the
ESSSecurityLabel SET is DER encoded, then the version number will appear
after the majority of the fields in the ESSSecurityLabel.  I propose that
the version component should be deleted from the ESSSecurityLabel syntax
because it does not serve a useful purpose because it is not the first field
to appear in the DER-encoded ESSSecurityLabel.  The id-aa-securityLabel OID
identifies the ESSSecurityLabel syntax when it is used in an authenticated
attribute.  If the ESSSecurityLabel syntax is changed after ESS becomes
stable, then a new OID can be assigned to indicate the changed syntax.   

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Darren Harter wrote:
>
>John,
>
>There is a further flaw in the scheme.  Because the ESSSecurityLabel is a
>SET, it will be sorted when DER is used.
>
>This means that the set elements will appear in the following order in the DER
>encoding:
>
>When Printable String Used - v1
>
>     Classification - tag 0x02
>     PolicyId - tag 0x06
>     Privacy - tag 0x13
>     Categories - tag 0x30
>
>When UTF8 String Used - v2
>
>     Classification - tag 0x02
>     PolicyId - tag 0x06
>     Categories - tag 0x30
>     Version - 0x80
>     Privacy - tag 0x81
<snip>

Date: Fri, 22 May 1998 15:36:17 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS EquivalentLabel Proposal
Sender: [email-masked]

All,

Recommend adding the following text as ESS Section 3.4:

"3.4.  Equivalent Security Labels 

Because organizations are allowed to define their own security policies,
many different security policies will exist. Some organizations may wish to
create equivalencies between their security policies with the security
policies of other organizations. For example, the Acme Company and the
Widget Corporation may reach a bilateral agreement that the "Acme private"
security-classification value is equivalent to the "Widget sensitive"
security-classification value.

The EquivalentLabel authenticated attribute is defined as:

EquivalentLabel ::= SEQUENCE OF ESSSecurityLabel

The id-equivalentLabel OID (TBD value) identifies the EquivalentLabel attribute.

As stated earlier, the ESSSecurityLabel contains the sensitivity values
selected by the original signer of the signedData. If an ESSSecurityLabel
is present in a signerInfo, all signerInfos in the signedData MUST contain
an ESSSecurityLabel and they MUST all be identical. In addition to an
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabel
authenticated attribute. If present, the equivalentLabel attribute MUST
include one or more security labels that are believed by the signer to be
semantically equivalent to the ESSSecurityLabel attribute included in the
same signerInfo. 

All security-policy object identifiers (OID) MUST be unique in the set of
ESSSecurityLabel and EquivalentLabel security labels.  Before using an
EquivalentLabel attribute, an agent MUST ensure that all security-policy
OIDs are unique in the security label(s) included in the EquivalentLabel.
Once the agent selects the security label (within the EquivalentLabel) to be
used for processing, then the security-policy OID of the selected
EquivalentLabel security label MUST be compared with the ESSSecurityLabel
security-policy OID to ensure that they are unique.

In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabel attribute may still be included.  For
example, in the Acme security policy, the absence of an ESSSecurityLabel
could be defined to equate to a security label composed of the Acme
security-policy OID and the "unmarked" security-classification.

Please note that equivalentLabel MUST NOT be used to convey security labels
that are semantically different from the ESSSecurityLabel included in the
signerInfo(s) in the signedData.  If an entity needs to apply a security
label that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the
ESSSecurityLabel.

If present, the equivalentLabel attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute.  A signerInfo MUST NOT
include multiple instances of the equivalentLabel attribute.  CMS defines
the ASN.1 syntax for the authenticated attributes to include attrValues SET
OF AttributeValue.  A equivalentLabel attribute MUST only include a single
instance of AttributeValue.  There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

From: Bruce Greenblatt <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-ldapext-sigops-00.txt
Date: Thu, 21 May 1998 17:15:27 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD8516.B92F5F8A
Content-Type: text/plain

here's an fyi about a draft using S/MIME in another WG.  Comments are always
welcome (as is praise)...

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, May 21, 1998 6:41 AM
> Cc:	[email-masked]
> Subject:	I-D ACTION:draft-ietf-ldapext-sigops-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the LDAP Extension Working Group of the IETF.
> 
> 	Title		: Signed Directory Operations Using S/MIME
> 	Author(s)	: B. Greenblatt, P. Richard
> 	Filename	: draft-ietf-ldapext-sigops-00.txt
> 	Pages		: 6
> 	Date		: 20-May-98
> 	
> This document defines an LDAP v3 based mechanism for signing direc-
> tory operations in order to create a secure journal of changes that have
> been made to each directory entry.  Both client and server based signa-
> tures are supported.  An object class for subsequent retrieval are
> 'journal entries' is also defined.  This document specifies LDAP v3 con-
> trols that enable this functionality.  It also defines an LDAP v3 schema
> that allows for subsequent browsing of the journal information.
> 
> Internet-Drafts are 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-ldapext-sigops-00.txt".
> A URL for the Internet-Draft is:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ldapext-sigops-00.txt
> 
> Internet-Drafts directories are located at:
> 
> 	Africa:	ftp.is.co.za
> 	
> 	Europe: ftp.nordu.net
> 		ftp.nis.garr.it
> 			
> 	Pacific Rim: munnari.oz.au
> 	
> 	US East Coast: ftp.ietf.org
> 	
> 	US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:	[email-masked].  In the body type:
> 	"FILE /internet-drafts/draft-ietf-ldapext-sigops-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft. <<Untitled Attachment>> 

------ =_NextPart_000_01BD8516.B92F5F8A
Content-Type: message/rfc822
Content-Description: Untitled Attachment

To: 
Subject: 
Date: Thu, 21 May 1998 17:15:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/mixed;
	boundary="---- =_NextPart_002_01BD8516.B92F5F8A"

------ =_NextPart_002_01BD8516.B92F5F8A
Content-Type: text/plain

------ =_NextPart_002_01BD8516.B92F5F8A
Content-Type: application/octet-stream;
	name="ATT02374.txt"
Content-Disposition: attachment;
	filename="ATT02374.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ldapext-sigops-00.txt

------ =_NextPart_002_01BD8516.B92F5F8A
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-ldapext-sigops-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------ =_NextPart_002_01BD8516.B92F5F8A--

------ =_NextPart_000_01BD8516.B92F5F8A--

Date: Thu, 21 May 1998 08:35:23 -0400
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Questions on Signed Receipts
Sender: [email-masked]

All,

Upon further reflection, I recommend that the following text be added to
ESS, Section 2.4, item 11: "All agents that support the generation of ESS
signed receipts MUST provide the ability to send encrypted signed receipts
(i.e. a signedData/Receipt encapsulated within an envelopedData).  The agent
MAY send an encrypted signed receipt in response to an
envelopedData-encapsulated signedData requesting a signed receipt.  It is a
matter of local policy regarding whether or not the signed receipt should be
encrypted.  The ESS signed receipt includes the message digest value
calculated for the original signedData object that requested the signed
receipt.  If the original signedData object was sent encrypted within an
envelopedData object and the ESS signed receipt is sent unencrypted, then
the message digest value calculated for the original encrypted signedData
object is sent unencrypted.  The responder should consider this when
deciding whether or not to encrypt the ESS signed receipt. "

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
===============================

Date: Tue, 19 May 1998 22:39:34 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Bob Jueneman wrote:
> 
> Steve,
> 
> Just to be sure we are on the same page, the issue revolves
> around the fact that if two certificates, potentially with different
> attributes and hence (perhaps) legal implications, both have the same
> public key, then it is cryptographically indeterminate which certificate
> should be used to validate the signature.
> 
> The fact that you have "A" signature chain of the sender does not
> necessarily mean that you have "THE" corrrect signature chain, unless
> you have cryptographically bound into the document itself, (or within the
> signature macro or signing process) an adequate identifier of the certificate
> itself.
> 

Yes same page so far :-)

> The identifier does not necessarily have to be the issuer and serial,
> although that would be adequate. A hash of the certificate would also
> suffice, and might even be better, if there is any chance that the CA might
> reuse or otherwise screw up serial numbers. Assuming there are any other differences, a hash of the certificate would also help to differentiate between
> two CAs that had the same name, but for example different issuers, etc., etc.
> 

Indeed, that was why I proposed it. If you have hash of certificate it
gets bound to the whole thing including the issuers signature and thus
indirectly their public key. 

If you just have issuer and serial number you are just duplicating
what's already there whereas IMHO this opportunity should be used to use
a more cryptograhically strong bind that covers more information.

It doesn't stop substitution of the other certificates e.g. the CA that
signed the issuers certificate nor does it protect against substitution
of the issuers certificate (or any other CA certificate) with an expired
version with the same public key. Though there have been other proposals
that can cover that (if it is deemed serious).

> I wasn't arguing pro or con OCSP.  That was Denis.  I do understand
> the argument that IF OCSP only has the CRLs and not the
> certificates, it cannot validate a hash of the ecetrtificate.  Whether
> that means the OCSP is braindead or the greatest thing since
> sliced bread is another topic.
> 

Well I wasn't commenting on OCSP as such. Just on OCSP in the context of
S/MIME: namely that even if OCSP can't verify the hash of the
certificate the S/MIME implementation can and can also compile whatever
information OCSP requires.

Since the information wont be present in SigningCertificate (and the
attribute wont be there) in a v2 or sub-v2 implementation anything that
relies on this for OCSP will be unable to handle such messages. I don't
think they will vanish overnight as soon as OCSP and S/MIME v3 are
finalised so anything using OCSP would be well advised to handle older
messages: as mentioned in the specs if I recall.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Tue, 19 May 1998 18:03:39 -0400
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Questions on Signed Receipts
Sender: [email-masked]

Larry (and friends),

Recommend that the following text be added to Section 2.4, item 11: "The ESS
signed receipt includes the message digest value calculated for the original
signedData object that requested the signed receipt.  If the original
signedData object was sent encrypted within an envelopedData object and the
ESS signed receipt is sent unencrypted, then the message digest value
calculated for the original encrypted signedData object is sent unencrypted.
The responder should consider this when deciding whether or not to encrypt
the ESS signed receipt."

I don't believe that any stronger wording is justified.  I disagree that ESS
should mandate that a signed receipt MUST always be encrypted when
responding to a encrypted signedData object.  I believe that this should be
an optional feature.  Organizations would not need to develop tailored
applications.  The COTS S/MIME v3 products should provide this as an
optional feature that is activated by a value in a configuration file.  If
this strategy were followed, then no custom SW development would be required.

- John Pawling 

At 08:35 AM 5/19/98 -0500, Larry Layten wrote:
>John,
>
>I disagree with you. Since what this standard is trying to do
>is to allow implementers to utilize any UA to achieve basically
>the same functionality -- not to make an organization develop
>tailored applications to meet their needs (even the paranoid
>ones). 
>
>I also believe that there are occasions and applications where
>in fact there would be too much information to assure a secure
>environment without encrypting the signed return receipt, 
>especially since the hash of the original message is contained
>in it.
>
>Larry
>
>-----Original Message-----
>From:	John Pawling [SMTP:[email-masked]]
>Sent:	Tuesday, May 19, 1998 7:13 AM
>To:	Jim Schaad (Exchange); Ietf-Smime (E-mail)
>Subject:	RE: Questions on Signed Receipts
>
>Jim,
>
>I believe that it is an extremely low probability that an attacker could
>gain any information of value from analyzing an unencrypted signed receipt.
>Therefore, I don't believe that ESS should encourage the encryption of
>signed receipts.  However, I don't believe that ESS should prohibit the
>encryption of signed receipts either.  IMHO, it should be a matter of local
>policy.  If an organization is paranoid enough to require that signed
>receipts must be encrypted, then they can pay the performance cost of
>encrypting the signed receipts.  I do not believe that encrypting signed
>receipts should be the deafult mode documented in ESS.  In summary, I
>believe that ESS should remain unchanged regarding this topic.
>
>- John Pawling
>
>
>At 04:33 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>>John,
>>
>>If you are suggesting that this is a matter of local policy, it is my belief
>>that most clients will never encrypt a secure receipt back.  I am not sure
>>that this is better than over encrypting.  Would adding a statement that it
>>should be done unless local policy says otherwise be ok?
>>
>>On point 2 I was really asking about expectation rather than about what is
>>permitted/prohibitted.  I agree that the current state of non-prohibition
>>should remain, I was just asking if people thought that SMimeCapabilities is
>>expected in a signed receipt message.
>>
>>jim
>>
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>Sent: Monday, May 18, 1998 2:41 PM
>>To: Ietf-Smime (E-mail)
>>Subject: Re: Questions on Signed Receipts
>>
>>
>>Jim,
>>
>>1. I respectfully disagree with your proposed text for Section 2.4, item 11.
>>I believe that the decision to encrypt a signed receipt should be a matter
>>of local policy.  The "SHOULD" requirement in your recommended text would
>>cause local organizations and implementors to decide to encrypt signed
>>receipts more often than not.  IMHO, it is wasteful to encrypt signed
>>receipts.
>>
>>2. I believe that any of the S/MIME attributes could be included in a signed
>>receipt (except for receiptRequest).  This is what ESS currently states.
>>For many of the attribute types (such as ESSSecurityLabel), it doesn't make
>>sense to include them in a signed receipt, but I don't see any reason why
>>ESS should specifcally prohibit their inclusion.
>>
>>================================
>>John Pawling, [email-masked]                             
>>J.G. Van Dyke & Associates, Inc.   
>>www.jgvandyke.com         
>>================================
>>
>>At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>>>In working through some of the implementation issues for signed receipts I
>>>ended up with two questions:
>>>
>>>1.  We say what to do if you need to encrypt a signed receipt, however we
>>>don't provide any guidance on when a signed receipt should be encrypted.
>>>While this can be said to be a user agent policy decision, I would like to
>>>make sure that is the correct answer.  I can see alot of arguments for
>>>attempting to encrypted the returned receipt if the message came in
>>>encrypted.  There is information which is shown in the receipt which was
>>not
>>>in the orginal encrypted message and is therefore a source of data leak.
>>>How significant this data is in the real world is a different question.  
>>>
>>>To start the discussion:  Recommend that Section 2.4 item 11 be modified by
>>>appending the following sentences.  "Signed receipts SHOULD be encrypted if
>>>possible if the receipt request was also encrypted.  The receipt SHOULD be
>>>sent without encryption if no key can be found for receipt receipients."
>>>
>>>2.  Do we think that the standard additional S/MIME signature attributes
>>>should be added to signed receipts?  My initial response to this is to say
>>>yes.  It provides an interesting way to collect certificates and S/MIME
>>>capibilities however.  Send a receipt request to lots of people and you may
>>>get back lots of certificates to be automatically updated in your address
>>>book.  The main reason for saying no is size of the receipt -- there is no
>>>need to include your encrypt certificates, S/MIME capabilities and any
>>other
>>>interesting information not immeadiately relevent to the signature on the
>>>receipt.
>>>
>>>jim
>>>
>>
>

Date: Tue, 19 May 1998 12:37:13 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Steve,=20

Just to be sure we are on the same page, the issue revolves=20
around the fact that if two certificates, potentially with different=20
attributes and hence (perhaps) legal implications, both have the same
public key, then it is cryptographically indeterminate which certificate=20=

should be used to validate the signature.

The fact that you have "A" signature chain of the sender does not=20
necessarily mean that you have "THE" corrrect signature chain, unless
you have cryptographically bound into the document itself, (or within the
signature macro or signing process) an adequate identifier of the =
certificate
itself.

The identifier does not necessarily have to be the issuer and serial,=20
although that would be adequate. A hash of the certificate would also=20
suffice, and might even be better, if there is any chance that the CA =
might
reuse or otherwise screw up serial numbers. Assuming there are any other =
differences, a hash of the certificate would also help to differentiate =
between
two CAs that had the same name, but for example different issuers, etc., =
etc.

>> >
>> > We discussed on the PKIX list the need to tie an e-mail message to =
a=20
>specifc certificate, in particular in the case where the same public key =
has been=20
>included in two certificates with different expriation dates, different =
attributes,=20
>etc. We agreed to move that discussion to the S/MIME group, since they =
were=20
>working in that area.
>
>If you want to "tie" an email message to a certificate (specific or
>otherwise) you need to be able to verify the messages signature. This
>usually necessitates the posession of the senders certificate chain.
>At this point what you put in SigningCertificate is there solely to
>verify the right certificate is being used.

The point of course is that "solely" is still very important.
>
>If you can assume posession of the senders certificate chain then OCSP
>should be happy: any information it wants is available.

>> The proposal of using simply the hash of the certificate does not work
>> ... because of the minimum assumption we are making in the PKIX WG: the
>> OCSP has only access to the newest CRL but no access to the individual
>> certificates themselves. Under such assumption the OCSP is thus UNABLE
>> to verify the hash of the certificate and therefore to make sure it is
>> pointing to the right certificate. For solving the case Ambarish
>> proposed to replace the hash of the certificate by the hash of the
>> public key of the CA, which is a technically adequate solution.

I wasn't arguing pro or con OCSP.  That was Denis.  I do understand=20
the argument that IF OCSP only has the CRLs and not the=20
certificates, it cannot validate a hash of the ecetrtificate.  Whether=20
that means the OCSP is braindead or the greatest thing since=20
sliced bread is another topic.

Bob

Date: Tue, 19 May 1998 09:32:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Compressed Content Type
Sender: [email-masked]

Jim, I don't think I follow you, or you me. One or the other!

I am suggesting that you compute the signature on the raw, uncompressed =
text, then compress it, then optionally encrypt it.

Upon receipt, you optionally decrypt it, then uncompress it, and then =
check the validity of the signature.  I see no reason at all why this =
makes a general purpose signature verification code possible.  Obviously =
you do NOT want to have to trust the compression or decompression code.

Being rather new to this list, and not having thought much about S/MIME =
since the old PEM/MOSS days, I really haven't thought about what layer or =
functional area it should go into. I was merely waving my hands and saying =
"let it be so."

I do understand your issue of changing the compression type to fit various =
documents. It would be difficult to have the encryptioon function =
determine the document type, I suppose.  Does that mean the function =
should go into CMS, or S/MIME?  I would think S/MIME.??

Regards,

bob

>I would be againist the ability to compute the signature on something =
which
>is not the actual bytes of the item being signed (i.e. sign the
>pre-compressed item).  This means that general purpose signature
>verification code is no longer possible.  You cannot verify the signature =
of
>something that is compressed unless you can uncompress it as part of =
doing
>the signature verification.  This is the reason that I restricted the
>compression to the body of an encrypted object. =20
>
>A second reason that I did not want this to be on signed objects is that =
my
>proposal allows for us to specify the compression in the S/MIME documents.=

>If you want to put in the general purpose compression you must change CMS
>rather than S/MIME.
>
>If you want to compress random pieces and match the type of compression =
to
>the piece, I strong suspect that you want to change the MIME to have the
>compression rather than putting it in the security layer.  From that =
point
>of view I don't know if you want to change MIME or change security.
>
>jim
>
>-----Original Message-----
>From: Bob Jueneman [mailto:[email-masked]]=20
>Sent: Monday, May 18, 1998 1:38 PM
>To: Jim Schaad (Exchange); [email-masked]=20
>Subject: Re: Compressed Content Type
>
>
>AMEN, Brother!
>
>My only suggestion would be to specifically state that=20
>is is allowed for the signature to be computed first, and=20
>then the object compressed, followed by encryption if=20
>desired.  Just because an object is signed shouldn't=20
>prevent it from being compressed.
>
>Now if we can just get rid of all of the in-band certificates!
>
>BTW, I suspect that a compression algorithm that is=20
>optimal for text might not be so good for spreadsheets,=20
>JPEG images, sound files, etc.  Let's not lose the MIME=20
>functionality while we're doing this. One and only one=20
>algorithm might be too constraining. On the other hand,=20
>I hate standards that grandfather in everybody who=20
>was on the committee, so lets make some intelligent choices.
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Products Group
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]=20
>
>"If you are trying to get to the moon, climbing a tree,=20
>although a step in the right direction, will not prove=20
>to be very helpful."
>
>"The most dangerous strategy is to cross a chasm in two jumps."
>
>
>>>> "Jim Schaad (Exchange)" <[email-masked]>=20
>05/18 1:59 PM
>>>>
>I was recently informed that it was criminal that we where not doing
>anything to provide for compression in our encrypted mail.  While I would
>not go that far, it is true that this is one of the few features that PGP
>currently has over S/MIME and if you encrypt mail compressing protocals
>(such as modems) cannot do any compression on the data themselfs.  This =
is a
>suggested way to address the problem.  Please note that thoughout this I
>will use the algorithm name MIS (message is shrunk) since I have not yet
>done the research to find what is the perfered IETF compression algorithm.=

>I recommend that we select one such compression algorithm and stick to =
it.
>
>Please note -- If we are going to do this I would much perfer to do it =
now
>and get it over with.
>
>Note:  Additional edits (such as for section 2.4.1) would be required if
>this is adopted.
>
>Insert New section:
>2.4.2 Compressed Content Type
>
>Sending agents MAY use the id-ct-smime-mis content type identifier to
>indication the message has had compression applied to it.  This content =
type
>is only used within EnvelopedData content types.  This content type =
MUST=20
>NOT
>be used in a SignedData content type.  This content type does not provide
>any security services.
>
>When this content type is used, the body is compressed using MIS and the
>result of the compression operation is encoded as the eContent in an
>EnvelopedData object.
>
>The reason that this object cannot be used in a SignedData object is that
>the signature needs to be applied to the original body, but if the body =
is
>compressed and then encoded in a SignedData object the signature would be
>applied to the compressed object.  Additionally, the requirement for
>applying compression to SignedData objects is not as high as they will =
tend
>to respond to externally applied compression since the source data is =
merely
>encoded and not scrambled.
>
>Compression would only be applied if the SMIMECapabilities of all =
receipents
>indicated that a compressed body is understood.
>
>---------------------
>
>I would assume that a new OID would be added to the SMIMECapibilities =
input
>list.  This would be either the content type oid or a different oid.  I
>don't really care which.
>
>jim

From: Larry Layten <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Questions on Signed Receipts
Date: Tue, 19 May 1998 08:35:06 -0500
Sender: [email-masked]

John,

I disagree with you. Since what this standard is trying to do
is to allow implementers to utilize any UA to achieve basically
the same functionality -- not to make an organization develop
tailored applications to meet their needs (even the paranoid
ones). 

I also believe that there are occasions and applications where
in fact there would be too much information to assure a secure
environment without encrypting the signed return receipt, 
especially since the hash of the original message is contained
in it.

Larry

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Tuesday, May 19, 1998 7:13 AM
To:	Jim Schaad (Exchange); Ietf-Smime (E-mail)
Subject:	RE: Questions on Signed Receipts

Jim,

I believe that it is an extremely low probability that an attacker could
gain any information of value from analyzing an unencrypted signed receipt.
Therefore, I don't believe that ESS should encourage the encryption of
signed receipts.  However, I don't believe that ESS should prohibit the
encryption of signed receipts either.  IMHO, it should be a matter of local
policy.  If an organization is paranoid enough to require that signed
receipts must be encrypted, then they can pay the performance cost of
encrypting the signed receipts.  I do not believe that encrypting signed
receipts should be the deafult mode documented in ESS.  In summary, I
believe that ESS should remain unchanged regarding this topic.

- John Pawling

At 04:33 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>John,
>
>If you are suggesting that this is a matter of local policy, it is my belief
>that most clients will never encrypt a secure receipt back.  I am not sure
>that this is better than over encrypting.  Would adding a statement that it
>should be done unless local policy says otherwise be ok?
>
>On point 2 I was really asking about expectation rather than about what is
>permitted/prohibitted.  I agree that the current state of non-prohibition
>should remain, I was just asking if people thought that SMimeCapabilities is
>expected in a signed receipt message.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, May 18, 1998 2:41 PM
>To: Ietf-Smime (E-mail)
>Subject: Re: Questions on Signed Receipts
>
>
>Jim,
>
>1. I respectfully disagree with your proposed text for Section 2.4, item 11.
>I believe that the decision to encrypt a signed receipt should be a matter
>of local policy.  The "SHOULD" requirement in your recommended text would
>cause local organizations and implementors to decide to encrypt signed
>receipts more often than not.  IMHO, it is wasteful to encrypt signed
>receipts.
>
>2. I believe that any of the S/MIME attributes could be included in a signed
>receipt (except for receiptRequest).  This is what ESS currently states.
>For many of the attribute types (such as ESSSecurityLabel), it doesn't make
>sense to include them in a signed receipt, but I don't see any reason why
>ESS should specifcally prohibit their inclusion.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>
>At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>>In working through some of the implementation issues for signed receipts I
>>ended up with two questions:
>>
>>1.  We say what to do if you need to encrypt a signed receipt, however we
>>don't provide any guidance on when a signed receipt should be encrypted.
>>While this can be said to be a user agent policy decision, I would like to
>>make sure that is the correct answer.  I can see alot of arguments for
>>attempting to encrypted the returned receipt if the message came in
>>encrypted.  There is information which is shown in the receipt which was
>not
>>in the orginal encrypted message and is therefore a source of data leak.
>>How significant this data is in the real world is a different question.  
>>
>>To start the discussion:  Recommend that Section 2.4 item 11 be modified by
>>appending the following sentences.  "Signed receipts SHOULD be encrypted if
>>possible if the receipt request was also encrypted.  The receipt SHOULD be
>>sent without encryption if no key can be found for receipt receipients."
>>
>>2.  Do we think that the standard additional S/MIME signature attributes
>>should be added to signed receipts?  My initial response to this is to say
>>yes.  It provides an interesting way to collect certificates and S/MIME
>>capibilities however.  Send a receipt request to lots of people and you may
>>get back lots of certificates to be automatically updated in your address
>>book.  The main reason for saying no is size of the receipt -- there is no
>>need to include your encrypt certificates, S/MIME capabilities and any
>other
>>interesting information not immeadiately relevent to the signature on the
>>receipt.
>>
>>jim
>>
>

Date: Tue, 19 May 1998 08:19:42 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Questions on Signed Receipts
Sender: [email-masked]

All,

I don't oppose Paul's recommended text (except that I would change both
occurrences of "receipt" to "signed receipt"):

>I am in
>favor of adding a sentence or two that says something along the line of "An
>unencrypted receipt of an encrypted message may expose information from the
>original message. The responder should consider this when deciding whether
>or not to encrypt the receipt."
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

- John Pawling

Date: Tue, 19 May 1998 08:13:25 -0400
To: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Questions on Signed Receipts
Sender: [email-masked]

Jim,

I believe that it is an extremely low probability that an attacker could
gain any information of value from analyzing an unencrypted signed receipt.
Therefore, I don't believe that ESS should encourage the encryption of
signed receipts.  However, I don't believe that ESS should prohibit the
encryption of signed receipts either.  IMHO, it should be a matter of local
policy.  If an organization is paranoid enough to require that signed
receipts must be encrypted, then they can pay the performance cost of
encrypting the signed receipts.  I do not believe that encrypting signed
receipts should be the deafult mode documented in ESS.  In summary, I
believe that ESS should remain unchanged regarding this topic.

- John Pawling

At 04:33 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>John,
>
>If you are suggesting that this is a matter of local policy, it is my belief
>that most clients will never encrypt a secure receipt back.  I am not sure
>that this is better than over encrypting.  Would adding a statement that it
>should be done unless local policy says otherwise be ok?
>
>On point 2 I was really asking about expectation rather than about what is
>permitted/prohibitted.  I agree that the current state of non-prohibition
>should remain, I was just asking if people thought that SMimeCapabilities is
>expected in a signed receipt message.
>
>jim
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, May 18, 1998 2:41 PM
>To: Ietf-Smime (E-mail)
>Subject: Re: Questions on Signed Receipts
>
>
>Jim,
>
>1. I respectfully disagree with your proposed text for Section 2.4, item 11.
>I believe that the decision to encrypt a signed receipt should be a matter
>of local policy.  The "SHOULD" requirement in your recommended text would
>cause local organizations and implementors to decide to encrypt signed
>receipts more often than not.  IMHO, it is wasteful to encrypt signed
>receipts.
>
>2. I believe that any of the S/MIME attributes could be included in a signed
>receipt (except for receiptRequest).  This is what ESS currently states.
>For many of the attribute types (such as ESSSecurityLabel), it doesn't make
>sense to include them in a signed receipt, but I don't see any reason why
>ESS should specifcally prohibit their inclusion.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>
>At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>>In working through some of the implementation issues for signed receipts I
>>ended up with two questions:
>>
>>1.  We say what to do if you need to encrypt a signed receipt, however we
>>don't provide any guidance on when a signed receipt should be encrypted.
>>While this can be said to be a user agent policy decision, I would like to
>>make sure that is the correct answer.  I can see alot of arguments for
>>attempting to encrypted the returned receipt if the message came in
>>encrypted.  There is information which is shown in the receipt which was
>not
>>in the orginal encrypted message and is therefore a source of data leak.
>>How significant this data is in the real world is a different question.  
>>
>>To start the discussion:  Recommend that Section 2.4 item 11 be modified by
>>appending the following sentences.  "Signed receipts SHOULD be encrypted if
>>possible if the receipt request was also encrypted.  The receipt SHOULD be
>>sent without encryption if no key can be found for receipt receipients."
>>
>>2.  Do we think that the standard additional S/MIME signature attributes
>>should be added to signed receipts?  My initial response to this is to say
>>yes.  It provides an interesting way to collect certificates and S/MIME
>>capibilities however.  Send a receipt request to lots of people and you may
>>get back lots of certificates to be automatically updated in your address
>>book.  The main reason for saying no is size of the receipt -- there is no
>>need to include your encrypt certificates, S/MIME capabilities and any
>other
>>interesting information not immeadiately relevent to the signature on the
>>receipt.
>>
>>jim
>>
>

Date: Mon, 18 May 1998 18:53:34 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Compressed Content Type
Sender: [email-masked]

I agree with Jim that this should not be done on the thing being signed. I
go further and say I think it should only be done at the MIME level since
compression is being suggested here not for security purposes but general
space-saving.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 18 May 1998 18:50:35 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Questions on Signed Receipts
Sender: [email-masked]

At 04:33 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>If you are suggesting that this is a matter of local policy, it is my belief
>that most clients will never encrypt a secure receipt back.  I am not sure
>that this is better than over encrypting.

Jim, this is a great arguments against making a SHOULD. A SHOULD should
only be included if there is a strong reason why an implementation should
do it one way. I agree with you, that it is unclear; thus, there should be
a mention, and not a SHOULD.

>Would adding a statement that it
>should be done unless local policy says otherwise be ok?

That's a tautology: the latter clause is exactly what SHOULD means. I am in
favor of adding a sentence or two that says something along the line of "An
unencrypted receipt of an encrypted message may expose information from the
original message. The responder should consider this when deciding whether
or not to encrypt the receipt."

>On point 2 I was really asking about expectation rather than about what is
>permitted/prohibitted.  I agree that the current state of non-prohibition
>should remain, I was just asking if people thought that SMimeCapabilities is
>expected in a signed receipt message.

It is definitely permitted. I do not think it should be expected, due
exactly to the concern in your original message: unneeded bloat. Is user A
expected to remember to whom she sent her SMIMECapabilities? Adding it to
every receipt is a waste of bandwidth for every instance after the first
(until they are changed).

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Compressed Content Type
Date: Mon, 18 May 1998 16:40:33 -0700
Sender: [email-masked]

Steve,

I agree that this is a valid way of approaching the problem.  I don't have
any issues with doing it this way instead.  Doing it in the MIME has the
ability to compress lots of different types of data in different ways and
leading to growth as the compression algorithms of choice are altered.  If
we think that the best place to put this is in MIME, then I think that MIME
needs to solve the problems of how to communicate the compressions
understood.

jim

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]]
Sent: Monday, May 18, 1998 3:45 PM
To: Ietf-Smime (E-mail)
Subject: Re: Compressed Content Type

I would suggest that this might be better handled at a MIME level and
would thus not be restricted to S/MIME but MIME in general and would be
outside the scope of this list.

E.g. a MIME type application/super-compression means "decompress using
the super-compression algorithm and treat the result as a MIME entity".
There is no guarantee that the recipient supports this but then again
the recipient can't specify what MIME types they can view either. Maybe
we should have a "supported MIME types" authenticated attribute, or then
again maybe not.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Subject: RE: Compressed Content Type
Date: Mon, 18 May 1998 16:38:12 -0700
Sender: [email-masked]

I would be againist the ability to compute the signature on something which
is not the actual bytes of the item being signed (i.e. sign the
pre-compressed item).  This means that general purpose signature
verification code is no longer possible.  You cannot verify the signature of
something that is compressed unless you can uncompress it as part of doing
the signature verification.  This is the reason that I restricted the
compression to the body of an encrypted object.  

A second reason that I did not want this to be on signed objects is that my
proposal allows for us to specify the compression in the S/MIME documents.
If you want to put in the general purpose compression you must change CMS
rather than S/MIME.

If you want to compress random pieces and match the type of compression to
the piece, I strong suspect that you want to change the MIME to have the
compression rather than putting it in the security layer.  From that point
of view I don't know if you want to change MIME or change security.

jim

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, May 18, 1998 1:38 PM
To: Jim Schaad (Exchange); [email-masked]
Subject: Re: Compressed Content Type

AMEN, Brother!

My only suggestion would be to specifically state that 
is is allowed for the signature to be computed first, and 
then the object compressed, followed by encryption if 
desired.  Just because an object is signed shouldn't 
prevent it from being compressed.

Now if we can just get rid of all of the in-band certificates!

BTW, I suspect that a compression algorithm that is 
optimal for text might not be so good for spreadsheets, 
JPEG images, sound files, etc.  Let's not lose the MIME 
functionality while we're doing this. One and only one 
algorithm might be too constraining. On the other hand, 
I hate standards that grandfather in everybody who 
was on the committee, so lets make some intelligent choices.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> "Jim Schaad (Exchange)" <[email-masked]> 05/18 1:59 PM
>>>
I was recently informed that it was criminal that we where not doing
anything to provide for compression in our encrypted mail.  While I would
not go that far, it is true that this is one of the few features that PGP
currently has over S/MIME and if you encrypt mail compressing protocals
(such as modems) cannot do any compression on the data themselfs.  This is a
suggested way to address the problem.  Please note that thoughout this I
will use the algorithm name MIS (message is shrunk) since I have not yet
done the research to find what is the perfered IETF compression algorithm.
I recommend that we select one such compression algorithm and stick to it.

Please note -- If we are going to do this I would much perfer to do it now
and get it over with.

Note:  Additional edits (such as for section 2.4.1) would be required if
this is adopted.

Insert New section:
2.4.2 Compressed Content Type

Sending agents MAY use the id-ct-smime-mis content type identifier to
indication the message has had compression applied to it.  This content type
is only used within EnvelopedData content types.  This content type MUST NOT
be used in a SignedData content type.  This content type does not provide
any security services.

When this content type is used, the body is compressed using MIS and the
result of the compression operation is encoded as the eContent in an
EnvelopedData object.

The reason that this object cannot be used in a SignedData object is that
the signature needs to be applied to the original body, but if the body is
compressed and then encoded in a SignedData object the signature would be
applied to the compressed object.  Additionally, the requirement for
applying compression to SignedData objects is not as high as they will tend
to respond to externally applied compression since the source data is merely
encoded and not scrambled.

Compression would only be applied if the SMIMECapabilities of all receipents
indicated that a compressed body is understood.

---------------------

I would assume that a new OID would be added to the SMIMECapibilities input
list.  This would be either the content type oid or a different oid.  I
don't really care which.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Questions on Signed Receipts
Date: Mon, 18 May 1998 16:33:22 -0700
Sender: [email-masked]

John,

If you are suggesting that this is a matter of local policy, it is my belief
that most clients will never encrypt a secure receipt back.  I am not sure
that this is better than over encrypting.  Would adding a statement that it
should be done unless local policy says otherwise be ok?

On point 2 I was really asking about expectation rather than about what is
permitted/prohibitted.  I agree that the current state of non-prohibition
should remain, I was just asking if people thought that SMimeCapabilities is
expected in a signed receipt message.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 18, 1998 2:41 PM
To: Ietf-Smime (E-mail)
Subject: Re: Questions on Signed Receipts

Jim,

1. I respectfully disagree with your proposed text for Section 2.4, item 11.
I believe that the decision to encrypt a signed receipt should be a matter
of local policy.  The "SHOULD" requirement in your recommended text would
cause local organizations and implementors to decide to encrypt signed
receipts more often than not.  IMHO, it is wasteful to encrypt signed
receipts.

2. I believe that any of the S/MIME attributes could be included in a signed
receipt (except for receiptRequest).  This is what ESS currently states.
For many of the attribute types (such as ESSSecurityLabel), it doesn't make
sense to include them in a signed receipt, but I don't see any reason why
ESS should specifcally prohibit their inclusion.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>In working through some of the implementation issues for signed receipts I
>ended up with two questions:
>
>1.  We say what to do if you need to encrypt a signed receipt, however we
>don't provide any guidance on when a signed receipt should be encrypted.
>While this can be said to be a user agent policy decision, I would like to
>make sure that is the correct answer.  I can see alot of arguments for
>attempting to encrypted the returned receipt if the message came in
>encrypted.  There is information which is shown in the receipt which was
not
>in the orginal encrypted message and is therefore a source of data leak.
>How significant this data is in the real world is a different question.  
>
>To start the discussion:  Recommend that Section 2.4 item 11 be modified by
>appending the following sentences.  "Signed receipts SHOULD be encrypted if
>possible if the receipt request was also encrypted.  The receipt SHOULD be
>sent without encryption if no key can be found for receipt receipients."
>
>2.  Do we think that the standard additional S/MIME signature attributes
>should be added to signed receipts?  My initial response to this is to say
>yes.  It provides an interesting way to collect certificates and S/MIME
>capibilities however.  Send a receipt request to lots of people and you may
>get back lots of certificates to be automatically updated in your address
>book.  The main reason for saying no is size of the receipt -- there is no
>need to include your encrypt certificates, S/MIME capabilities and any
other
>interesting information not immeadiately relevent to the signature on the
>receipt.
>
>jim
>

Date: Tue, 19 May 1998 00:31:37 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Compressed Content Type
Sender: [email-masked]

Bob Jueneman wrote:
> 
> Now if we can just get rid of all of the in-band certificates!
> 

You can assuming the CA complies and includes extensions in their end
user certificates. Check out the authorityInfoAccess attribute in the
PKIX certificate and CRL spec.

Maybe it should be at least mentioned in CMS with the addition that it
MUST be an authenticated attribute.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Compressed Content Type
Date: Mon, 18 May 1998 15:57:56 -0700
Sender: [email-masked]

> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Monday, May 18, 1998 3:45 PM
> To: Ietf-Smime (E-mail)
> Subject: Re: Compressed Content Type
> 
> 
> I would suggest that this might be better handled at a MIME level and
> would thus not be restricted to S/MIME but MIME in general 
> and would be
> outside the scope of this list.

I suspect that the MIME folks have already come to some kind of
understanding about this issue in the MIME community.  Dave?  Paul?
Jamie?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Mon, 18 May 1998 23:44:37 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Compressed Content Type
Sender: [email-masked]

I would suggest that this might be better handled at a MIME level and
would thus not be restricted to S/MIME but MIME in general and would be
outside the scope of this list.

E.g. a MIME type application/super-compression means "decompress using
the super-compression algorithm and treat the result as a MIME entity".
There is no guarantee that the recipient supports this but then again
the recipient can't specify what MIME types they can view either. Maybe
we should have a "supported MIME types" authenticated attribute, or then
again maybe not.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 18 May 1998 23:42:18 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Denis Pinkas wrote:
> 
> Bob,
> 
> >
> > Denis,
> >
> > I had expected to agree with you, but I am not sure I do.
> >
> > We discussed on the PKIX list the need to tie an e-mail message to a specifc certificate, in particular in the case where the same public key has been included in two certificates with different expriation dates, different attributes, etc. We agreed to move that discussion to the S/MIME group, since they were working in that area.

If you want to "tie" an email message to a certificate (specific or
otherwise) you need to be able to verify the messages signature. This
usually necessitates the posession of the senders certificate chain.
At this point what you put in SigningCertificate is there solely to
verify the right certificate is being used.

If you can assume posession of the senders certificate chain then OCSP
should be happy: any information it wants is available.

> If this is done in the context of S/MIME then we would extract that
> reference and then send it to the OCSP. Ideally a COPY and PASTE
> operation would be nice: the same data structure should be used for both
> the SMIME WG and the PKIX WG.
> 

The term "in the context of S/MIME" needs clarification. If this means
in the context of an S/MIME implementation then there is no problem.

> The proposal of using simply the hash of the certificate does not work
> ... because of the minimum assumption we are making in the PKIX WG: the
> OCSP has only access to the newest CRL but no access to the individual
> certificates themselves. Under such assumption the OCSP is thus UNABLE
> to verify the hash of the certificate and therefore to make sure it is
> pointing to the right certificate. For solving the case Ambarish
> proposed to replace the hash of the certificate by the hash of the
> public key of the CA, which is a technically adequate solution.
> 

OCSP doesn't have to verify the hash of the certificate or make sure it
is pointing to the right certificate in an S/MIME implementation. The
S/MIME implementation would do that as part of the verification process
and feed the information to OCSP (assuming the signatures were OK).

> 
> The conclusion is then simple: what is need is a triple consisting of :
> 
>    a) the issuer name,
>    b) the certificate serial number, and
>    c) a hash of the public key of the CA.
> 
> All that information needs to be part of the authenticated attributes."
> 

If you did do that and just copy and paste the relevant information in a
relevant S/MIME implementation it would be unable to use OCSP for any
S/MIME messages not complying to the standard, for example v2 or the
majority of S/MIME messages currently in use. A bad idea IMHO.

If on the other hand the OCSP request is formed as part of the normal
S/MIME signature verification process you can use OCSP for v3, v2 and
all those highly popular sub-v2 implementations (you know who you are!)
that are in use.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 18 May 1998 17:40:46 -0400
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Questions on Signed Receipts
Sender: [email-masked]

Jim,

1. I respectfully disagree with your proposed text for Section 2.4, item 11.
I believe that the decision to encrypt a signed receipt should be a matter
of local policy.  The "SHOULD" requirement in your recommended text would
cause local organizations and implementors to decide to encrypt signed
receipts more often than not.  IMHO, it is wasteful to encrypt signed receipts.

2. I believe that any of the S/MIME attributes could be included in a signed
receipt (except for receiptRequest).  This is what ESS currently states.
For many of the attribute types (such as ESSSecurityLabel), it doesn't make
sense to include them in a signed receipt, but I don't see any reason why
ESS should specifcally prohibit their inclusion.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
>In working through some of the implementation issues for signed receipts I
>ended up with two questions:
>
>1.  We say what to do if you need to encrypt a signed receipt, however we
>don't provide any guidance on when a signed receipt should be encrypted.
>While this can be said to be a user agent policy decision, I would like to
>make sure that is the correct answer.  I can see alot of arguments for
>attempting to encrypted the returned receipt if the message came in
>encrypted.  There is information which is shown in the receipt which was not
>in the orginal encrypted message and is therefore a source of data leak.
>How significant this data is in the real world is a different question.  
>
>To start the discussion:  Recommend that Section 2.4 item 11 be modified by
>appending the following sentences.  "Signed receipts SHOULD be encrypted if
>possible if the receipt request was also encrypted.  The receipt SHOULD be
>sent without encryption if no key can be found for receipt receipients."
>
>2.  Do we think that the standard additional S/MIME signature attributes
>should be added to signed receipts?  My initial response to this is to say
>yes.  It provides an interesting way to collect certificates and S/MIME
>capibilities however.  Send a receipt request to lots of people and you may
>get back lots of certificates to be automatically updated in your address
>book.  The main reason for saying no is size of the receipt -- there is no
>need to include your encrypt certificates, S/MIME capabilities and any other
>interesting information not immeadiately relevent to the signature on the
>receipt.
>
>jim
>

Date: Mon, 18 May 1998 14:37:56 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Compressed Content Type
Sender: [email-masked]

AMEN, Brother!

My only suggestion would be to specifically state that=20
is is allowed for the signature to be computed first, and=20
then the object compressed, followed by encryption if=20
desired.  Just because an object is signed shouldn't=20
prevent it from being compressed.

Now if we can just get rid of all of the in-band certificates!

BTW, I suspect that a compression algorithm that is=20
optimal for text might not be so good for spreadsheets,=20
JPEG images, sound files, etc.  Let's not lose the MIME=20
functionality while we're doing this. One and only one=20
algorithm might be too constraining. On the other hand,=20
I hate standards that grandfather in everybody who=20
was on the committee, so lets make some intelligent choices.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> "Jim Schaad (Exchange)" <[email-masked]> 05/18 1:59 PM =
>>>
I was recently informed that it was criminal that we where not doing
anything to provide for compression in our encrypted mail.  While I would
not go that far, it is true that this is one of the few features that PGP
currently has over S/MIME and if you encrypt mail compressing protocals
(such as modems) cannot do any compression on the data themselfs.  This is =
a
suggested way to address the problem.  Please note that thoughout this I
will use the algorithm name MIS (message is shrunk) since I have not yet
done the research to find what is the perfered IETF compression algorithm.
I recommend that we select one such compression algorithm and stick to it.

Please note -- If we are going to do this I would much perfer to do it now
and get it over with.

Note:  Additional edits (such as for section 2.4.1) would be required if
this is adopted.

Insert New section:
2.4.2 Compressed Content Type

Sending agents MAY use the id-ct-smime-mis content type identifier to
indication the message has had compression applied to it.  This content =
type
is only used within EnvelopedData content types.  This content type MUST =
NOT
be used in a SignedData content type.  This content type does not provide
any security services.

When this content type is used, the body is compressed using MIS and the
result of the compression operation is encoded as the eContent in an
EnvelopedData object.

The reason that this object cannot be used in a SignedData object is that
the signature needs to be applied to the original body, but if the body is
compressed and then encoded in a SignedData object the signature would be
applied to the compressed object.  Additionally, the requirement for
applying compression to SignedData objects is not as high as they will =
tend
to respond to externally applied compression since the source data is =
merely
encoded and not scrambled.

Compression would only be applied if the SMIMECapabilities of all =
receipents
indicated that a compressed body is understood.

---------------------

I would assume that a new OID would be added to the SMIMECapibilities =
input
list.  This would be either the content type oid or a different oid.  I
don't really care which.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Questions on Signed Receipts
Date: Mon, 18 May 1998 12:59:57 -0700
Sender: [email-masked]

In working through some of the implementation issues for signed receipts I
ended up with two questions:

1.  We say what to do if you need to encrypt a signed receipt, however we
don't provide any guidance on when a signed receipt should be encrypted.
While this can be said to be a user agent policy decision, I would like to
make sure that is the correct answer.  I can see alot of arguments for
attempting to encrypted the returned receipt if the message came in
encrypted.  There is information which is shown in the receipt which was not
in the orginal encrypted message and is therefore a source of data leak.
How significant this data is in the real world is a different question.  

To start the discussion:  Recommend that Section 2.4 item 11 be modified by
appending the following sentences.  "Signed receipts SHOULD be encrypted if
possible if the receipt request was also encrypted.  The receipt SHOULD be
sent without encryption if no key can be found for receipt receipients."

2.  Do we think that the standard additional S/MIME signature attributes
should be added to signed receipts?  My initial response to this is to say
yes.  It provides an interesting way to collect certificates and S/MIME
capibilities however.  Send a receipt request to lots of people and you may
get back lots of certificates to be automatically updated in your address
book.  The main reason for saying no is size of the receipt -- there is no
need to include your encrypt certificates, S/MIME capabilities and any other
interesting information not immeadiately relevent to the signature on the
receipt.

jim

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Compressed Content Type
Date: Mon, 18 May 1998 12:59:58 -0700
Sender: [email-masked]

I was recently informed that it was criminal that we where not doing
anything to provide for compression in our encrypted mail.  While I would
not go that far, it is true that this is one of the few features that PGP
currently has over S/MIME and if you encrypt mail compressing protocals
(such as modems) cannot do any compression on the data themselfs.  This is a
suggested way to address the problem.  Please note that thoughout this I
will use the algorithm name MIS (message is shrunk) since I have not yet
done the research to find what is the perfered IETF compression algorithm.
I recommend that we select one such compression algorithm and stick to it.

Please note -- If we are going to do this I would much perfer to do it now
and get it over with.

Note:  Additional edits (such as for section 2.4.1) would be required if
this is adopted.

Insert New section:
2.4.2 Compressed Content Type

Sending agents MAY use the id-ct-smime-mis content type identifier to
indication the message has had compression applied to it.  This content type
is only used within EnvelopedData content types.  This content type MUST NOT
be used in a SignedData content type.  This content type does not provide
any security services.

When this content type is used, the body is compressed using MIS and the
result of the compression operation is encoded as the eContent in an
EnvelopedData object.

The reason that this object cannot be used in a SignedData object is that
the signature needs to be applied to the original body, but if the body is
compressed and then encoded in a SignedData object the signature would be
applied to the compressed object.  Additionally, the requirement for
applying compression to SignedData objects is not as high as they will tend
to respond to externally applied compression since the source data is merely
encoded and not scrambled.

Compression would only be applied if the SMIMECapabilities of all receipents
indicated that a compressed body is understood.

---------------------

I would assume that a new OID would be added to the SMIMECapibilities input
list.  This would be either the content type oid or a different oid.  I
don't really care which.

jim

Date: Mon, 18 May 1998 13:15:27 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Denis,

My apologies for not following the discussion as closely as=20
I should have.

I failed to realize that the real question was how to determine the=20
certificate status via OCSP, not merely how to determine which=20
certificate was used.

I'm happy enough with the triple you proposed, although from my=20
perspective just the issuer plus serial would have been enough, so=20
long as it is is cryptographically bound to the message itself, and=20
not merely attached to the message without authentication.

Now if the  PKIX group could just decide how many angels can=20
dance on the head of an unbounded combination of subject=20
and issuer DNs, in unspecified permutations with globally=20
unambiguous and/or only locally defined, unconstrained=20
alternate names, and what the processing algorithm is for that,=20
we will be home free! :-(

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Denis Pinkas <[email-masked]> 05/18 6:53 PM >>>
Bob,

>=20
> Denis,
>=20
> I had expected to agree with you, but I am not sure I do.
>=20
> We discussed on the PKIX list the need to tie an e-mail message to a =
specifc certificate, in particular in the case where the same public key =
has been included in two certificates with different expriation dates, =
different attributes, etc. We agreed to move that discussion to the S/MIME =
group, since they were working in that area.
>=20
> (I would be happy to recapitulate the argument on the PKIX list for =
those on the list that might have missed the discussion.)
>=20
> Assuming that the hash covers the entire certificate, _including_ the =
public key, this would seem to satisfy that requirement.
>=20
> I don't understand what purpose a hash of the key, as opposed to a hash =
of the entire certificate, would serve.  I'm not saying there isn't such a =
need, only that I don't understand. Could you explain?

This has been discussed just before and after the SMIME session at LA
with Ambarish. I do remember that you could not attend the last meeting.
However ... all the information you need is in a very recent E-mail from
May the 15 th. Please take a close look at it. It contains all the
explanations you need. Here it is again:

" In the pkix WG we are discussing the OCSP protocol, where basically
giving the reference of a certificate it should be possible to know
*on-line* from an OCSP whether this certificate is or is not revoked.

If this is done in the context of S/MIME then we would extract that
reference and then send it to the OCSP. Ideally a COPY and PASTE
operation would be nice: the same data structure should be used for both
the SMIME WG and the PKIX WG.

The proposal of using simply the hash of the certificate does not work
.. because of the minimum assumption we are making in the PKIX WG: the
OCSP has only access to the newest CRL but no access to the individual
certificates themselves. Under such assumption the OCSP is thus UNABLE
to verify the hash of the certificate and therefore to make sure it is
pointing to the right certificate. For solving the case Ambarish
proposed to replace the hash of the certificate by the hash of the
public key of the CA, which is a technically adequate solution.

In that case the minimum assumption we are making works fine, since the
OCSP server must anyway know the value of the public key of the CA to
verify the CRL. So it can compute its hash.

The conclusion is then simple: what is need is a triple consisting of :

   a) the issuer name,=20
   b) the certificate serial number, and=20
   c) a hash of the public key of the CA.

All that information needs to be part of the authenticated attributes."

Denis

> Bob

> >>>> Denis Pinkas <[email-masked]> 05/18 4:00 PM >>>
> >Jim,
> >
> >I would guess that working on Sundays is no good. :-)
> >
> >You did not look at my E-mail sufficiently.
> >
> >> >From the messages to date, it would appear that we have the =
following
> >> questions to be answered:
> >>
> >> 1.  Should a hash of the certificate be part of the new attribute?  =
>From the
> >> mail to-date (admittally very few people) the answer appears to be =
yes.
> >
> >My E-mail is advocating *against* the use of the hash of the
> >certificate. Instead it is advocating for the use of the same structure
> >in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
> >hash of the certificate, but the hash of the issuer public key.
> >
> >This would allow to make the difference between two CAs having the same
> >name.
>=20
> This doesn't appear to make sense. Obviously a hash of the entire =
certificate, including the public key, would staisfy the same goal. But =
more importantly, it would allow discrimination between two certificates =
issued by the same CA with differnt attrigbutes but the same key.
>=20
> Bob
>=20
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]=20
>=20
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>=20
> "The most dangerous strategy is to cross a chasm in two jumps."

--=20
      Denis Pinkas     Bull S.A.          mailto:[email-masked]=20
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 18 May 1998 09:20:51 -0700
To: [email-masked], "Jim Schaad (Exchange)" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Cc: [email-masked]
Sender: [email-masked]

Denis,

A hash of the certificate covers the signature.

Mike

At 03:00 PM 5/18/98 -0700, Denis Pinkas wrote:
>
>My E-mail is advocating *against* the use of the hash of the
>certificate. Instead it is advocating for the use of the same structure
>in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
>hash of the certificate, but the hash of the issuer public key.
>
>This would allow to make the difference between two CAs having the same
>name.

Date: Mon, 18 May 1998 17:53:18 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Bob,

> 
> Denis,
> 
> I had expected to agree with you, but I am not sure I do.
> 
> We discussed on the PKIX list the need to tie an e-mail message to a specifc certificate, in particular in the case where the same public key has been included in two certificates with different expriation dates, different attributes, etc. We agreed to move that discussion to the S/MIME group, since they were working in that area.
> 
> (I would be happy to recapitulate the argument on the PKIX list for those on the list that might have missed the discussion.)
> 
> Assuming that the hash covers the entire certificate, _including_ the public key, this would seem to satisfy that requirement.
> 
> I don't understand what purpose a hash of the key, as opposed to a hash of the entire certificate, would serve.  I'm not saying there isn't such a need, only that I don't understand. Could you explain?

This has been discussed just before and after the SMIME session at LA
with Ambarish. I do remember that you could not attend the last meeting.
However ... all the information you need is in a very recent E-mail from
May the 15 th. Please take a close look at it. It contains all the
explanations you need. Here it is again:

" In the pkix WG we are discussing the OCSP protocol, where basically
giving the reference of a certificate it should be possible to know
*on-line* from an OCSP whether this certificate is or is not revoked.

If this is done in the context of S/MIME then we would extract that
reference and then send it to the OCSP. Ideally a COPY and PASTE
operation would be nice: the same data structure should be used for both
the SMIME WG and the PKIX WG.

The proposal of using simply the hash of the certificate does not work
... because of the minimum assumption we are making in the PKIX WG: the
OCSP has only access to the newest CRL but no access to the individual
certificates themselves. Under such assumption the OCSP is thus UNABLE
to verify the hash of the certificate and therefore to make sure it is
pointing to the right certificate. For solving the case Ambarish
proposed to replace the hash of the certificate by the hash of the
public key of the CA, which is a technically adequate solution.

In that case the minimum assumption we are making works fine, since the
OCSP server must anyway know the value of the public key of the CA to
verify the CRL. So it can compute its hash.

The conclusion is then simple: what is need is a triple consisting of :

   a) the issuer name, 
   b) the certificate serial number, and 
   c) a hash of the public key of the CA.

All that information needs to be part of the authenticated attributes."

Denis

> Bob

> >>>> Denis Pinkas <[email-masked]> 05/18 4:00 PM >>>
> >Jim,
> >
> >I would guess that working on Sundays is no good. :-)
> >
> >You did not look at my E-mail sufficiently.
> >
> >> >From the messages to date, it would appear that we have the following
> >> questions to be answered:
> >>
> >> 1.  Should a hash of the certificate be part of the new attribute?  >From the
> >> mail to-date (admittally very few people) the answer appears to be yes.
> >
> >My E-mail is advocating *against* the use of the hash of the
> >certificate. Instead it is advocating for the use of the same structure
> >in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
> >hash of the certificate, but the hash of the issuer public key.
> >
> >This would allow to make the difference between two CAs having the same
> >name.
> 
> This doesn't appear to make sense. Obviously a hash of the entire certificate, including the public key, would staisfy the same goal. But more importantly, it would allow discrimination between two certificates issued by the same CA with differnt attrigbutes but the same key.
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
> 
> "The most dangerous strategy is to cross a chasm in two jumps."

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 18 May 1998 09:06:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Denis,

I had expected to agree with you, but I am not sure I do.

We discussed on the PKIX list the need to tie an e-mail message to a =
specifc certificate, in particular in the case where the same public key =
has been included in two certificates with different expriation dates, =
different attributes, etc. We agreed to move that discussion to the S/MIME =
group, since they were working in that area.

(I would be happy to recapitulate the argument on the PKIX list for those =
on thei list that might have missed the discussion.)

Assuming that the hash covers the entire certificate, _including_ the =
public key, this would seem to satisfy that requirement.

I don't understand what purpose a hash of the key, as opposed to a hash of =
the entire certificate, would serve.  I'm not saying there isn't such a =
need, only that I don't understand. Could you explain?

Bob

>
>>>> Denis Pinkas <[email-masked]> 05/18 4:00 PM >>>
>Jim,
>
>I would guess that working on Sundays is no good. :-)
>
>You did not look at my E-mail sufficiently.
>
>> >From the messages to date, it would appear that we have the following
>> questions to be answered:
>>=20
>> 1.  Should a hash of the certificate be part of the new attribute?  =
>From the
>> mail to-date (admittally very few people) the answer appears to be yes.
>
>My E-mail is advocating *against* the use of the hash of the
>certificate. Instead it is advocating for the use of the same structure
>in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
>hash of the certificate, but the hash of the issuer public key.
>
>This would allow to make the difference between two CAs having the same
>name.

This doesn't appear to make sense. Obviously a hash of the entire =
certificate, including the public key, would staisfy the same goal. But =
more importantly, it would allow discrimination between two certificates =
issued by the same CA with differnt attrigbutes but the same key.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date: Mon, 18 May 1998 15:00:25 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Jim,

I would guess that working on Sundays is no good. :-)

You did not look at my E-mail sufficiently.

> >From the messages to date, it would appear that we have the following
> questions to be answered:
> 
> 1.  Should a hash of the certificate be part of the new attribute?  From the
> mail to-date (admittally very few people) the answer appears to be yes.

My E-mail is advocating *against* the use of the hash of the
certificate. Instead it is advocating for the use of the same structure
in the PKIX WG and the SMIME WG. A hash is needed, but it is NOT the
hash of the certificate, but the hash of the issuer public key.

This would allow to make the difference between two CAs having the same
name.

> 2.  Should we try and use the same ASN object as is being used in OCSP?

The answer is yes.
 
> A yes answer to this question has several different ramifications.

> -  First, this would give us yet another tie to the PKIX group in terms of
> dependencies.  We might well be able to finish before the OCSP group if we
> don't have this dependency.  On the other hand it means there is one less
> ASN structure to write encode/decode functions for.

You may finsih before as long as we can reach an agreement on that
structure. Anyway there will be a dependency on PKIX Part 1.

> -  Second, the OCSP group needs to have much more information in their
> structure than we do.  

If the PKIX WG needs it, this means that the SMIME WG must be able to
supply it and therefore it has to be extractable from an SMIME message.

> As Steve pointed out all we really need is the hash
> of the certificate in the attribute as we have both the issuer and serial
> number (required in our certificates) and the certificate or we don't even
> get pass the initial part of the verification.  The current OCSP structures
> that I have seen include the issuerName, issuerAltName, serialNumber and
> hash of certificate.  

hash of the issuer public key.

> (IssuerAltName is required for looking at CA
> certificates, a problem we don't have.)  

It depends whether or not DNs only can be used, or AltNames can be used
as well. This is currently a rather hot topic within the PKIX WG.

> I have a strong desire for reduction of size and therefore 
> do like the ability to have just the serial number.

This would not work, unless we can get the other elements.

> My answer to number 2 most likely be, gee it would be nice but.... 
> and probably falls into the no category.
 
> 3.  If the answer is NO to question 2.  Should the structure consist of the
> issuer/serial number or the hash.  I personally like the hash as it is short
> and provides additional information than the issuer/serial number option.

See above.

Denis
 
> jim
 
> > -----Original Message-----
> > From: Dr Stephen Henson [mailto:[email-masked]]
> > Sent: Friday, May 15, 1998 6:30 AM
> > To: [email-masked]
> > Subject: Re: SigningCertificate and IssuerAndSerialNumber.

> > Denis Pinkas wrote:

> > > I do have a strong preference. :-)

> > > In the pkix WG we are discussing the OCSP protocol, where basically
> > > giving the reference of a certificate it should be possible to know
> > > *on-line* from an OCSP whether this certificate is or is
> > > not revoked.
> > >
> > > If this is done in the context of S/MIME then we would extract that
> > > reference and then send it to the OCSP. Ideally a COPY and PASTE
> > > operation would be nice: the same data structure should be
> > > used for both the SMIME WG and the PKIX WG.
> > >
> > > The proposal of using simply the hash of the certificate
> > > does not work
> > > ... because of the minimum assumption we are making in the
> > > PKIX WG: the OCSP has only access to the newest CRL but no 
> > > access to the individual certificates themselves. Under such 
> > > assumption the OCSP is thus UNABLE to verify the hash of the 
> > > certificate and therefore to make sure it is pointing to the 
> > > right certificate. For solving the case Ambarish proposed 
> > > to replace the hash of the certificate by the hash of the
> > > public key of the CA, which is a technically adequate solution.

> > I may be missing something here but why can't the standard "outer"
> > issuerAndSerialNumber be used? Under the proposal (at least
> > how I meant it) it would still be there.
> >
> > The extra binding caused by the SigningCertificate attribute crucially
> > relies on the fact that the authenticated attributes are
> > signed. If the signature on the authenticated attributes cannot 
> > be checked (e.g. if the senders certificate is not available) then 
> > checking the IssuerAndSerialNumber of the SigningCertificate 
> > (assuming it is present) is no better than checking the outer 
> > unsigned issuerAndSerialNumber.
> >
> > If there is a situation where an agent would have access to enough
> > information to verify the signature on the authenticated attributes
> > (which would as a bare minimum require the senders public key) but not
> > have access to the senders certificate then yes I agree this
> > would be a  problem.
> >
> > Steve.
> > --
> > Dr Stephen N. Henson.
> > UK based freelance Cryptographic Consultant. For info see homepage.
> > Homepage: http://www.drh-consultancy.demon.co.uk/
> > Email: [email-masked]
> > PGP key: via homepage.
> >

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 18 May 1998 14:25:06 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Jim,

Thank you for your detailed response. Unfortunately there are several
points I do not agree with.  :-(

> I am addressing the non-certificate identification issues in this message.
> These issues will be addressed separately to keep the threads separate
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> >
> > A. In section 2. Re-issue of Certificate.
> >
> > Either I do not see this as a problem or I do not understand your
> > problem.
> > Cross certificates can be revoked. So if the CA wishes to re-issue a
> > certificate it simply revokes it before and may use different policies
> > in the new issued certificate. Where is the problem ?
> >
> 
> I did not make myself clear here.  The attack that I was looking at on this
> point had to do with a CA re-issuing its own root certificate.  

There is an important issue here. This question was raised in a recent
E-mail from Francois Rousseau. Unless the security policy to be applied
for verification is itself signed, you are open to many attacks, as the
one you mention. So a security policy identifier (e.g. an OID) should be
part of the signature. If you have a single trust point (which is a very
specific case) then you could replace the OID by a self-signed
certificate. Under that case there will be no ambiguity about what to
use for verification. Note the IDUP, which is an API covering
non-repudiation already incorportates this major concept.

> The change I
> would expect would be in the CPS however I will give and example of name
> constraints here.  If a CA re-issues its CA certificate and specifically
> constrains my certificate out of the set of legal DNs, I may sign my message
> with a valid chain (I have the original root certificate) and you may fail
> the validation because you have the new root certificate.

The threat you mention can be countered by the inclusion of the security
policy as an "authenticated attribute"; I would prefer to call it a
"signed attribute" :-)

> What I was trying to point out in the second paragraph is that a similar
> problem already exists with cross-certificates.  When CA2 issues the cross
> certificate for CA1, it may add or remove extensions from the CA1
> certificate.  Thus it could put in the same name constraints extension that
> I postulated above on the CA root certificate re-issue.  This means that my
> signature was valid when I sent it, as I trusted the CA1 root directly, but
> you will fail the signature validation as the name constrained imposed by
> CA2 on CA1 causes my certificate to be invalid.

For the case of CAs which are "below" this is not a problem as I
mentionned it in my previous E-mail.

> > B. The discussion and explanations about the need for the hash
> > mentioned in the discussion above should be added.
> 
> I am waiting for a consensus to develop on this issue before making this
> change.

Well, since your paper is supposed to be a discussion paper, I do not
see why we should not address the problem there. There is not yet a
consensus on the other issues.  :-)

> > C. In the Open Issues section. The inclusion for a complete chain of
> > certificates would have some advantages (I do not claim it is
> > necessary
> > in all the cases). It allows the signer to specify its own belief for
> > the verification process. If the verifier wants to use a different
> > chain, this is fine for him, but then under his own risk.
> >
> > The "rollover" argument is not a problem since anyway it is
> > important to
> > capture all the certificates that were valid at the time the signature
> > was created, but this is a minor detail.
> 
> I agree that this might be a useful extension to have, but I would argue
> that this is not the correct attribute to place that information in.  This
> attribute will change the validity of the signature based on the match or
> non-match of the specified certificate to the certificate used in the
> signature validation process.

It only changes the validity of the signature based on which security
policy you are using.

> > Finally I could not understand the issue expressed in the
> > last paragraph
> > of "B. Open Issues". A different wording might be necessary.
> 
> I will attempt to express the issue again in new wording and hope that I do
> better this time.
> 
> From a pure cryptographic (i.e. mathematical sense) a signature is created
> by using a private key and verified by using a public key.  In this world
> there is no such thing as a certificate and one does not worry about how the
> public key is obtained.

Correct.

> In the next level of abstraction up, a certificate comes into being.  

More generally I would say a way to relate the public key to the
identity of the signer. For this a certificate may or mot not be used.

> All a
> certificate provides from a mathematical sense is a way of providing a
> public key in a cryptographically secure manner.  In this sense it does not
> matter what certificate one uses to find the public key to verify a
> signature as long as one finds some certificate with the correct public key.

I respectfully disagree with you on this issue. I would take again my
favorite example with a CA from the Barracuda Banana Republic. This CA
for 1.000 $ may be willing to issue me a certificate with the same
public key value like yours (without performing POP, ie. Proof op
Private key possession). If that CA appears to be in your trust tree,
then you may be fooled. So it does matter that the signer indicates
which certificate sahll be used for verification. It is not *any*.

> This means that if I have two certificates, both containing the same public
> key, it does not matter which of these certificates you use in validating
> the signature as both are equally viable from a mathematical sense.

No. it does matter instead. As I do not agree on your second level, I
also respectfully disagree with the next level.

> The final level of abstraction that I add is the level of protocol of
> signing.  At this level I care about which of the different certificates I
> use in the validation process as certificates carry different information
> about the signer and the ways in which signing may occur.  This information
> is carried as extension on the certificate and these need to be validated as
> part of the process of validating the original signature.
> 
> Those people who don't go all the way to the final protocol level we are
> providing don't like what this draft does, so far I have found two sets of
> people who tend to stop at level 2 and not go to level 3.  The PGP community
> and those people who come out of that community live at level two.  I
> believe that this is because they don't have the authoritative CA to do the
> binding and add additional protocol information.  They tend to be
> individuals who make statements only about identity and it does not matter
> what identity you use as they mean the same person (as the private key must
> be the same).  The second set is represented by Dave Solo who state that
> everything which needs to be an important part of the signature ought to be
> in the document being signed and the extra information provided by the
> certificate extensions is of less importance that what is in the document.

> Jim

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 18 May 1998 13:16:52 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Michael Myers <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

> Denis,
> 
> Please bear in mind that your opinion of the state of the OCSP consensus
> may not be uniformly held.  In particular, you note that
> 
> >... because of the minimum assumption we are making in the PKIX WG: the
> >OCSP has only access to the newest CRL but no access to the individual
> >certificates themselves.
> 
> It is a matter of record that the minutes of the PKIX L.A. meeting note that:
> 
> ". . . CRLs not be required to implement OCSP . . ."

CRLs *may* also be used to implemented OCSP. This is not in
contradiction.

> >In that case the minimum assumption we are making works fine, since the
> >OCSP server must anyway know the value of the public key of the CA to
> >verify the CRL.
> 
> However, CRLs may not exist in some OCSP deployment contexts.  This
> observation leads to the need for CHOICE in certificate identification.

Really ? A CHOICE of what ?
  
> I trust we can resolve this issue soon to everyone's satisfaction.

I do hope so as well. :-)

Denis
 
> Mike

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Sun, 17 May 1998 18:25:40 -0700
Sender: [email-masked]

>From the messages to date, it would appear that we have the following
questions to be answered:

1.  Should a hash of the certificate be part of the new attribute?  From the
mail to-date (admittally very few people) the answer appears to be yes.

2.  Should we try and use the same ASN object as is being used in OCSP?  

A yes answer to this question has several different ramifications.
-  First, this would give us yet another tie to the PKIX group in terms of
dependencies.  We might well be able to finish before the OCSP group if we
don't have this dependency.  On the other hand it means there is one less
ASN structure to write encode/decode functions for.

-  Second, the OCSP group needs to have much more information in their
structure than we do.  As Steve pointed out all we really need is the hash
of the certificate in the attribute as we have both the issuer and serial
number (required in our certificates) and the certificate or we don't even
get pass the initial part of the verification.  The current OCSP structures
that I have seen include the issuerName, issuerAltName, serialNumber and
hash of certificate.  (IssuerAltName is required for looking at CA
certificates, a problem we don't have.)  I have a strong desire for
reduction of size and therefore do like the ability to have just the serial
number.

My answer to number 2 most likely be, gee it would be nice but.... and
probably falls into the no category.

3.  If the answer is NO to question 2.  Should the structure consist of the
issuer/serial number or the hash.  I personally like the hash as it is short
and provides additional information than the issuer/serial number option.

jim

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Friday, May 15, 1998 6:30 AM
> To: [email-masked]
> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> 
> 
> Denis Pinkas wrote:
> > 
> > I do have a strong preference. :-)
> > 
> > In the pkix WG we are discussing the OCSP protocol, where basically
> > giving the reference of a certificate it should be possible to know
> > *on-line* from an OCSP whether this certificate is or is 
> not revoked.
> > 
> > If this is done in the context of S/MIME then we would extract that
> > reference and then send it to the OCSP. Ideally a COPY and PASTE
> > operation would be nice: the same data structure should be 
> used for both
> > the SMIME WG and the PKIX WG.
> > 
> > The proposal of using simply the hash of the certificate 
> does not work
> > ... because of the minimum assumption we are making in the 
> PKIX WG: the
> > OCSP has only access to the newest CRL but no access to the 
> individual
> > certificates themselves. Under such assumption the OCSP is 
> thus UNABLE
> > to verify the hash of the certificate and therefore to make 
> sure it is
> > pointing to the right certificate. For solving the case Ambarish
> > proposed to replace the hash of the certificate by the hash of the
> > public key of the CA, which is a technically adequate solution.
> > 
> 
> I may be missing something here but why can't the standard "outer"
> issuerAndSerialNumber be used? Under the proposal (at least 
> how I meant
> it) it would still be there.
> 
> The extra binding caused by the SigningCertificate attribute crucially
> relies on the fact that the authenticated attributes are 
> signed. If the
> signature on the authenticated attributes cannot be checked 
> (e.g. if the
> senders certificate is not available) then checking the
> IssuerAndSerialNumber of the SigningCertificate (assuming it 
> is present)
> is no better than checking the outer unsigned issuerAndSerialNumber.
> 
> If there is a situation where an agent would have access to enough
> information to verify the signature on the authenticated attributes
> (which would as a bare minimum require the senders public key) but not
> have access to the senders certificate then yes I agree this 
> would be a
> problem.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.
> UK based freelance Cryptographic Consultant. For info see homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk/
> Email: [email-masked]
> PGP key: via homepage.
> 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Sun, 17 May 1998 17:58:07 -0700
Sender: [email-masked]

I am addressing the non-certificate identification issues in this message.
These issues will be addressed separately to keep the threads separate

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> 
> A. In section 2. Re-issue of Certificate.
> 
> Either I do not see this as a problem or I do not understand your
> problem.
> Cross certificates can be revoked. So if the CA wishes to re-issue a
> certificate it simply revokes it before and may use different policies
> in the new issued certificate. Where is the problem ?
> 

I did not make myself clear here.  The attack that I was looking at on this
point had to do with a CA re-issuing its own root certificate.  The change I
would expect would be in the CPS however I will give and example of name
constraints here.  If a CA re-issues its CA certificate and specifically
constrains my certificate out of the set of legal DNs, I may sign my message
with a valid chain (I have the original root certificate) and you may fail
the validation because you have the new root certificate.

What I was trying to point out in the second paragraph is that a similar
problem already exists with cross-certificates.  When CA2 issues the cross
certificate for CA1, it may add or remove extensions from the CA1
certificate.  Thus it could put in the same name constraints extension that
I postulated above on the CA root certificate re-issue.  This means that my
signature was valid when I sent it, as I trusted the CA1 root directly, but
you will fail the signature validation as the name constrained imposed by
CA2 on CA1 causes my certificate to be invalid.

> 
> B. The discussion and explanations about the need for the hash
> mentioned in the discussion above should be added.

I am waiting for a consensus to develop on this issue before making this
change.

> 
> 
> C. In the Open Issues section. The inclusion for a complete chain of
> certificates would have some advantages (I do not claim it is 
> necessary
> in all the cases). It allows the signer to specify its own belief for
> the verification process. If the verifier wants to use a different
> chain, this is fine for him, but then under his own risk.
> 
> The "rollover" argument is not a problem since anyway it is 
> important to
> capture all the certificates that were valid at the time the signature
> was created, but this is a minor detail.

I agree that this might be a useful extension to have, but I would argue
that this is not the correct attribute to place that information in.  This
attribute will change the validity of the signature based on the match or
non-match of the specified certificate to the certificate used in the
signature validation process.

> 
> Finally I could not understand the issue expressed in the 
> last paragraph
> of "B. Open Issues". A different wording might be necessary.

I will attempt to express the issue again in new wording and hope that I do
better this time.

>From a pure cryptographic (i.e. mathematical sense) a signature is created
by using a private key and verified by using a public key.  In this world
there is no such thing as a certificate and one does not worry about how the
public key is obtained.

In the next level of abstraction up, a certificate comes into being.  All a
certificate provides from a mathematical sense is a way of providing a
public key in a cryptographically secure manner.  In this sense it does not
matter what certificate one uses to find the public key to verify a
signature as long as one finds some certificate with the correct public key.
This means that if I have two certificates, both containing the same public
key, it does not matter which of these certificates you use in validating
the signature as both are equally viable from a mathematical sense.

The final level of abstraction that I add is the level of protocol of
signing.  At this level I care about which of the different certificates I
use in the validation process as certificates carry different information
about the signer and the ways in which signing may occur.  This information
is carried as extension on the certificate and these need to be validated as
part of the process of validating the original signature.

Those people who don't go all the way to the final protocol level we are
providing don't like what this draft does, so far I have found two sets of
people who tend to stop at level 2 and not go to level 3.  The PGP community
and those people who come out of that community live at level two.  I
believe that this is because they don't have the authoritative CA to do the
binding and add additional protocol information.  They tend to be
individuals who make statements only about identity and it does not matter
what identity you use as they mean the same person (as the private key must
be the same).  The second set is represented by Dave Solo who state that
everything which needs to be an important part of the signature ought to be
in the document being signed and the extra information provided by the
certificate extensions is of less importance that what is in the document.

> 
> Denis
> 
> 
Jim

Date: Fri, 15 May 1998 15:03:27 -0700
To: [email-masked], "Jim Schaad (Exchange)" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Cc: Ambarish Malpani <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Denis,

Please bear in mind that your opinion of the state of the OCSP consensus
may not be uniformly held.  In particular, you note that

>... because of the minimum assumption we are making in the PKIX WG: the
>OCSP has only access to the newest CRL but no access to the individual
>certificates themselves.

It is a matter of record that the minutes of the PKIX L.A. meeting note that:

". . . CRLs not be required to implement OCSP . . ."

>In that case the minimum assumption we are making works fine, since the
>OCSP server must anyway know the value of the public key of the CA to
>verify the CRL.

However, CRLs may not exist in some OCSP deployment contexts.  This
observation leads to the need for CHOICE in certificate identification.  I
trust we can resolve this issue soon to everyone's satisfaction.

Mike

Date: Fri, 15 May 1998 21:02:34 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

IMHO another issue is how (if?) the various SigningCertificate options
would cope with substitution of expired certificates for valid ones.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Fri, 15 May 1998 14:29:32 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Denis Pinkas wrote:
> 
> I do have a strong preference. :-)
> 
> In the pkix WG we are discussing the OCSP protocol, where basically
> giving the reference of a certificate it should be possible to know
> *on-line* from an OCSP whether this certificate is or is not revoked.
> 
> If this is done in the context of S/MIME then we would extract that
> reference and then send it to the OCSP. Ideally a COPY and PASTE
> operation would be nice: the same data structure should be used for both
> the SMIME WG and the PKIX WG.
> 
> The proposal of using simply the hash of the certificate does not work
> ... because of the minimum assumption we are making in the PKIX WG: the
> OCSP has only access to the newest CRL but no access to the individual
> certificates themselves. Under such assumption the OCSP is thus UNABLE
> to verify the hash of the certificate and therefore to make sure it is
> pointing to the right certificate. For solving the case Ambarish
> proposed to replace the hash of the certificate by the hash of the
> public key of the CA, which is a technically adequate solution.
> 

I may be missing something here but why can't the standard "outer"
issuerAndSerialNumber be used? Under the proposal (at least how I meant
it) it would still be there.

The extra binding caused by the SigningCertificate attribute crucially
relies on the fact that the authenticated attributes are signed. If the
signature on the authenticated attributes cannot be checked (e.g. if the
senders certificate is not available) then checking the
IssuerAndSerialNumber of the SigningCertificate (assuming it is present)
is no better than checking the outer unsigned issuerAndSerialNumber.

If there is a situation where an agent would have access to enough
information to verify the signature on the authenticated attributes
(which would as a bare minimum require the senders public key) but not
have access to the senders certificate then yes I agree this would be a
problem.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Fri, 15 May 1998 14:59:01 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Jim,

I am joining the thread since your document directly relates to the
presentation I made at the Los Angeles meeting.

I will also attempt to bridge the gap between the smime WG and the pkix
WG.

I will first comment on this E-mail and then address some other issues
related to your document. 

> I have to admit that I like this proposal for a couple of reasons.  First it
> makes the message shorter as the hash is almost certianally smaller than the
> issuer/serial number.  Secondly it removes duplicated information from the
> certificate.
> 
> I originally proposed the issuer/serial number for two reasons.  First this
> is the currently accepted method of identifying a certificate.  Second, it
> makes the process of validating the correctness easier.  A binary compare of
> the issuer DNs and the serial numbers can be binary compared to validate the
> certifiate.  Using the hash requires that the certificate be present (so it
> can be pre-validated by a gateway) and potentially adds a more complicated
> computation (hashing the certificate) to validate the attribute.
> 
> I don't really have a strong preference about which way this should be done.

I do have a strong preference. :-)

In the pkix WG we are discussing the OCSP protocol, where basically
giving the reference of a certificate it should be possible to know
*on-line* from an OCSP whether this certificate is or is not revoked.

If this is done in the context of S/MIME then we would extract that
reference and then send it to the OCSP. Ideally a COPY and PASTE
operation would be nice: the same data structure should be used for both
the SMIME WG and the PKIX WG.

The proposal of using simply the hash of the certificate does not work
... because of the minimum assumption we are making in the PKIX WG: the
OCSP has only access to the newest CRL but no access to the individual
certificates themselves. Under such assumption the OCSP is thus UNABLE
to verify the hash of the certificate and therefore to make sure it is
pointing to the right certificate. For solving the case Ambarish
proposed to replace the hash of the certificate by the hash of the
public key of the CA, which is a technically adequate solution.

In that case the minimum assumption we are making works fine, since the
OCSP server must anyway know the value of the public key of the CA to
verify the CRL. So it can compute its hash.

The conclusion is then simple: what is need is a triple consisting of :

   a) the issuer name, 
   b) the certificate serial number, and 
   c) a hash of the public key of the CA.

All that information needs to be part of the authenticated attributes.

At this time, in the PKIX WG we are discussing the details of such an
ASN.1 data structure.

Please join the PKIX mailing list if you wish to participate.
 
Now a few more comments on the document:

A. In section 2. Re-issue of Certificate.

Either I do not see this as a problem or I do not understand your
problem.
Cross certificates can be revoked. So if the CA wishes to re-issue a
certificate it simply revokes it before and may use different policies
in the new issued certificate. Where is the problem ?

B. The discussion and explanations about the need for the hash
mentionned in the discussion above should be added.

C. In the Open Issues section. The inclusion for a complete chain of
certificates would have some advantages (I do not claim it is necessary
in all the cases). It allows the signer to specify its own belief for
the verification process. If the verifier wants to use a different
chain, this is fine for him, but then under his own risk.

The "rollover" argument is not a problem since anyway it is important to
capture all the certificates that were valid at the time the signature
was created, but this is a minor detail.

Finally I could not understand the issue expressed in the last paragraph
of "B. Open Issues". A different wording might be necessary.

Denis

> jim
 
> -----Original Message-----
> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Wednesday, May 13, 1998 7:30 PM
> To: [email-masked]
> Subject: SigningCertificate and IssuerAndSerialNumber.
> 
> While I feel that the principle of the specification is good I have to
> admit that I have been swayed by the argument in favour of using
> something other than IssuerAndSerialNumber to bind the signers
> certificate.
> 
> One reason is that as things stand use of the signing certificate
> attribute makes the "outer" issuerAndSerialNumber redundant. I feel that
> something that complemented the outer issuerAndSerialNumber rather than
> duplicated it would be preferable.
> 
> > B. Open Issues
> >
> >  Some people have expressed a desire to solve the "Reissue
> >  of Certificate" attack. I see no pressing need to address
> >  this attack. Any certificate authority that allowed for
> >  this attack is operating in an improper fashion and should
> >  not be used. In the event that the attack is deemed to be
> >  of importance, it could be solved by the addition of a
> >  hash to the SigningCertificate ASN structure. This would
> >  allow the relying entity to verify that the certificate
> >  was exactly the same as the signing entity claimed to have
> >  used.
> >
> 
> I would respectfully suggest that if the SigningCertificate structure
> contained a hash of the signers certificate (or some equivalent) the
> IssuerAndSerialNumber structure would be redundant.
> 
> This prompts the question: why not make the SigningCertificate structure
> consist wholly of the hash?
> 
> In addition the hash is likely to be more compact than the
> issuerAndSerial number structure.
> 
> I agree that there is no pressing need to address the other attacks (a
> rogue CA could do much nastier things invisibly) but if they can be
> addressed (in addition to the original "Substitution Attack") this is no
> bad thing IMHO.
> 
> Steve.
> --
> Dr Stephen N. Henson.
> UK based freelance Cryptographic Consultant. For info see homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk/
> Email: [email-masked]
> PGP key: via homepage.

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: James M Hayes <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Fri, 15 May 1998 09:49:16 -0400
Sender: [email-masked]

Jim wrote:

>I have to admit that I like this proposal for a couple of reasons.  =
First it
>makes the message shorter as the hash is almost certianally smaller =
than the
>issuer/serial number.  Secondly it removes duplicated information from =
the
>certificate.

>I originally proposed the issuer/serial number for two reasons.  First =
this
>is the currently accepted method of identifying a certificate.  Second, =
it
>makes the process of validating the correctness easier.  A binary =
compare of
>the issuer DNs and the serial numbers can be binary compared to =
validate the
>certifiate.  Using the hash requires that the certificate be present =
(so it
>can be pre-validated by a gateway) and potentially adds a more =
complicated
>computation (hashing the certificate) to validate the attribute.

>I don't really have a strong preference about which way this should be =
done.

In an earlier thread dealing with ACs Dave Kemp wrote:

"A single attribute containing a list of (issuerName, serialNumber, =
hash(issuerPublicKey)) could serve the dual purpose of binding a normal =
certificate into the transaction (to prevent spoofing) and to bind =
selected attribute certs into the transaction (to prevent third parties =
from inserting unwanted-but-valid attribute certs)."

Thinking along the line of Steve and using Dave's method for binding =
X.509 v3 to ACs, the signingCertificate attribute binding could be =
hash(issuerName, serialNumber, issuerPublicKey). =20

>jim

>-----Original Message-----
>From: Dr Stephen Henson [mailto:[email-masked]]
>Sent: Wednesday, May 13, 1998 7:30 PM
>To: [email-masked]
>Subject: SigningCertificate and IssuerAndSerialNumber.

>While I feel that the principle of the specification is good I have to
>admit that I have been swayed by the argument in favour of using
>something other than IssuerAndSerialNumber to bind the signers
>certificate.

>One reason is that as things stand use of the signing certificate
>attribute makes the "outer" issuerAndSerialNumber redundant. I feel =

Date: Fri, 15 May 1998 03:14:38 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Russ Housley wrote:
> 
> If IssuerAndSerialNumber is sufficient for specifying a cerrtificate in a
> CRL, then what makes it insufficient here?
> 
> Russ
> 

I would say that one difference is that a CRL has IssuerAndSerialNumber
and an issuer signature. I would also (not too seriously) argue that
there is not much use in substituting one revoked certificate for
another :-)

All I'm really saying is why have a weaker, duplicating bind when you
can have a stronger, smaller one with minimal extra effort?

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Thu, 14 May 1998 18:51:59 -0700
Sender: [email-masked]

I have to admit that I like this proposal for a couple of reasons.  First it
makes the message shorter as the hash is almost certianally smaller than the
issuer/serial number.  Secondly it removes duplicated information from the
certificate.

I originally proposed the issuer/serial number for two reasons.  First this
is the currently accepted method of identifying a certificate.  Second, it
makes the process of validating the correctness easier.  A binary compare of
the issuer DNs and the serial numbers can be binary compared to validate the
certifiate.  Using the hash requires that the certificate be present (so it
can be pre-validated by a gateway) and potentially adds a more complicated
computation (hashing the certificate) to validate the attribute.

I don't really have a strong preference about which way this should be done.

jim

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]]
Sent: Wednesday, May 13, 1998 7:30 PM
To: [email-masked]
Subject: SigningCertificate and IssuerAndSerialNumber.

While I feel that the principle of the specification is good I have to
admit that I have been swayed by the argument in favour of using
something other than IssuerAndSerialNumber to bind the signers
certificate.

One reason is that as things stand use of the signing certificate
attribute makes the "outer" issuerAndSerialNumber redundant. I feel that
something that complemented the outer issuerAndSerialNumber rather than
duplicated it would be preferable.

> B. Open Issues
> 
>  Some people have expressed a desire to solve the "Reissue
>  of Certificate" attack. I see no pressing need to address
>  this attack. Any certificate authority that allowed for
>  this attack is operating in an improper fashion and should
>  not be used. In the event that the attack is deemed to be
>  of importance, it could be solved by the addition of a
>  hash to the SigningCertificate ASN structure. This would
>  allow the relying entity to verify that the certificate
>  was exactly the same as the signing entity claimed to have
>  used.
> 

I would respectfully suggest that if the SigningCertificate structure
contained a hash of the signers certificate (or some equivalent) the
IssuerAndSerialNumber structure would be redundant.

This prompts the question: why not make the SigningCertificate structure
consist wholly of the hash?

In addition the hash is likely to be more compact than the
issuerAndSerial number structure.

I agree that there is no pressing need to address the other attacks (a
rogue CA could do much nastier things invisibly) but if they can be
addressed (in addition to the original "Substitution Attack") this is no
bad thing IMHO.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Thu, 14 May 1998 18:46:50 -0700
Sender: [email-masked]

Russ,

The issuer and serial number in a CRL is making a negitive statement ("Any
certificate which you find with this issuer and serial number is not good.")
while this is trying to make a positive statement ("This is the one true
certificate.")  The quality of the statements differ as one is making the
general statement about all certificates with a given issuer/serial number
and the other is trying to identify from a possible set of certificates with
the same issuer/serial number the correct certificate.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, May 14, 1998 9:10 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.

If IssuerAndSerialNumber is sufficient for specifying a cerrtificate in a
CRL, then what makes it insufficient here?

Russ

At 03:30 AM 5/14/98 +0100, Dr Stephen Henson wrote:
>While I feel that the principle of the specification is good I have to
>admit that I have been swayed by the argument in favour of using
>something other than IssuerAndSerialNumber to bind the signers
>certificate.
>
>One reason is that as things stand use of the signing certificate
>attribute makes the "outer" issuerAndSerialNumber redundant. I feel that
>something that complemented the outer issuerAndSerialNumber rather than
>duplicated it would be preferable.
>
>> B. Open Issues
>> 
>>  Some people have expressed a desire to solve the "Reissue
>>  of Certificate" attack. I see no pressing need to address
>>  this attack. Any certificate authority that allowed for
>>  this attack is operating in an improper fashion and should
>>  not be used. In the event that the attack is deemed to be
>>  of importance, it could be solved by the addition of a
>>  hash to the SigningCertificate ASN structure. This would
>>  allow the relying entity to verify that the certificate
>>  was exactly the same as the signing entity claimed to have
>>  used.
>> 
>
>I would respectfully suggest that if the SigningCertificate structure
>contained a hash of the signers certificate (or some equivalent) the
>IssuerAndSerialNumber structure would be redundant.
>
>This prompts the question: why not make the SigningCertificate structure
>consist wholly of the hash?
>
>In addition the hash is likely to be more compact than the
>issuerAndSerial number structure.
>
>I agree that there is no pressing need to address the other attacks (a
>rogue CA could do much nastier things invisibly) but if they can be
>addressed (in addition to the original "Substitution Attack") this is no
>bad thing IMHO.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

Date: Thu, 14 May 1998 12:09:38 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

If IssuerAndSerialNumber is sufficient for specifying a cerrtificate in a
CRL, then what makes it insufficient here?

Russ

At 03:30 AM 5/14/98 +0100, Dr Stephen Henson wrote:
>While I feel that the principle of the specification is good I have to
>admit that I have been swayed by the argument in favour of using
>something other than IssuerAndSerialNumber to bind the signers
>certificate.
>
>One reason is that as things stand use of the signing certificate
>attribute makes the "outer" issuerAndSerialNumber redundant. I feel that
>something that complemented the outer issuerAndSerialNumber rather than
>duplicated it would be preferable.
>
>> B. Open Issues
>> 
>>  Some people have expressed a desire to solve the "Reissue
>>  of Certificate" attack. I see no pressing need to address
>>  this attack. Any certificate authority that allowed for
>>  this attack is operating in an improper fashion and should
>>  not be used. In the event that the attack is deemed to be
>>  of importance, it could be solved by the addition of a
>>  hash to the SigningCertificate ASN structure. This would
>>  allow the relying entity to verify that the certificate
>>  was exactly the same as the signing entity claimed to have
>>  used.
>> 
>
>I would respectfully suggest that if the SigningCertificate structure
>contained a hash of the signers certificate (or some equivalent) the
>IssuerAndSerialNumber structure would be redundant.
>
>This prompts the question: why not make the SigningCertificate structure
>consist wholly of the hash?
>
>In addition the hash is likely to be more compact than the
>issuerAndSerial number structure.
>
>I agree that there is no pressing need to address the other attacks (a
>rogue CA could do much nastier things invisibly) but if they can be
>addressed (in addition to the original "Substitution Attack") this is no
>bad thing IMHO.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

Date: Thu, 14 May 1998 03:30:21 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

While I feel that the principle of the specification is good I have to
admit that I have been swayed by the argument in favour of using
something other than IssuerAndSerialNumber to bind the signers
certificate.

One reason is that as things stand use of the signing certificate
attribute makes the "outer" issuerAndSerialNumber redundant. I feel that
something that complemented the outer issuerAndSerialNumber rather than
duplicated it would be preferable.

> B. Open Issues
> 
>  Some people have expressed a desire to solve the "Reissue
>  of Certificate" attack. I see no pressing need to address
>  this attack. Any certificate authority that allowed for
>  this attack is operating in an improper fashion and should
>  not be used. In the event that the attack is deemed to be
>  of importance, it could be solved by the addition of a
>  hash to the SigningCertificate ASN structure. This would
>  allow the relying entity to verify that the certificate
>  was exactly the same as the signing entity claimed to have
>  used.
> 

I would respectfully suggest that if the SigningCertificate structure
contained a hash of the signers certificate (or some equivalent) the
IssuerAndSerialNumber structure would be redundant.

This prompts the question: why not make the SigningCertificate structure
consist wholly of the hash?

In addition the hash is likely to be more compact than the
issuerAndSerial number structure.

I agree that there is no pressing need to address the other attacks (a
rogue CA could do much nastier things invisibly) but if they can be
addressed (in addition to the original "Substitution Attack") this is no
bad thing IMHO.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 13 May 1998 18:52:33 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Signing Cert Attribute Spec
Sender: [email-masked]

All,

IMHO, Jim Schaad has done an excellent job of writing the 9 May 98 Signing
Certificate Attribute Specification.  I agree with Jim's proposals.  I
believe that the signingCertificate attribute should be supported by S/MIME
v3-compliant applications.

I have one comment to the spec.  Pleas add the following text to Sec 4:

"If present, the signingCertificate attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute.  A signerInfo MUST NOT
include multiple instances of the signingCertificate attribute.  CMS defines
the ASN.1 syntax for the authenticated attributes to include attrValues SET
OF AttributeValue.  A signingCertificate attribute MUST only include a
single instance of AttributeValue.  There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF AttributeValue."

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Wed, 13 May 1998 12:18:45 -0400
To: Graham Klyne <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: DSS signatures and keys
Cc: <[email-masked]>
Sender: [email-masked]

Yes.Please take a look at draft-ietf-pkix-ipki-part1-*.txt.

Russ

At 02:26 PM 5/13/98 +0100, Graham Klyne wrote:
>Folks,
>
>Is there a document which describes exactly how DSS signature and
>certificate data should be formatted (i.e. the organization of data within
>a "SignatureValue", etc.)?
>
>Specifically, in handling signed messages, we have:
>
>>To verify the contents of a DSA signed message on the other end you need 
>>three values P, Q, G and the Public Key. The values of P, Q and G must be 
>>the same as those used to sign the message.  (where the Public Key is 
>>derived from the P,Q, and G values and the private key).
>
>How are the P, Q and G values communicated?  Are they part of the
>signature, the public key or something else?
>
>#g
>
>------------
>Graham Klyne
>  

Date: Wed, 13 May 1998 10:17:51 -0400
To: Graham Klyne <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: DSS signatures and keys
Sender: [email-masked]

Graham,

The PKIX X.509 Certificate and CRL Profile (aka PKIX Part I) contains this
info (ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-07.txt).

The ietf host is down right now, so here are the applicable excerpts from
PKIX Pt 1:

7.2.2  DSA Signature Algorithm

   A patent statement regarding the DSA can be found at the end of this
   profile.

   The Digital Signature Algorithm (DSA) is also called the Digital Sig-
   nature Standard (DSS).  DSA was developed by the U.S. Government, and
   DSA is used in conjunction with the the SHA-1 one-way hash function.
   DSA is fully described in FIPS 186 [FIPS 186].  The ASN.1 object
   identifiers used to identify this signature algorithm are:

           id-dsa-with-sha1 ID  ::=  {
                   iso(1) member-body(2) us(840) x9-57 (10040)
                   x9cm(4) 3 }

   The id-dsa-with-sha1 algorithm syntax has NULL parameters. The DSA
   parameters in the subjectPublicKeyInfo field of the certificate of
   the issuer shall apply to the verification of the signature.

   If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL param-
   eters and the CA signed the subject certificate using DSA, then the
   certificate issuer's parameters apply to the subject's DSA key. If
   the subjectPublicKeyInfo AlgorithmIdentifier field has NULL parame-
   ters and the CA signed the subject with a signature algorithm other
   than DSA, then clients shall not validate the certificate.

   When signing, the DSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they shall be ASN.1 encoded using the fol-
   lowing ASN.1 structure:

           Dss-Sig-Value  ::=  SEQUENCE  {
                   r       INTEGER,
                   s       INTEGER  }

7.3  Subject Public Key Algorithms

   Certificates described by this standard may convey a public key for
   any public key algorithm. The certificate indicates the algorithm
   through an algorithmidentifier.  This algorithm identfieier is an OID
   and optionally associated parameters.

   This section identifies preferred OIDs and parameters for the RSA,
   DSA, and Diffie-Hellman algorithms.  Conforming CAs shall use the
   identified OIDs when issuing certificates containing public keys for
   these algorithms. Conforming applications supporting any of these
   algorithms shall, at a minimum, recognize the OID identified in this
   section.

7.3.3 DSA Signature Keys

   The object identifier supported by this standard is

        id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
                  x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional parameters.  These
   parameters are commonly referred to as p, q, and g.  When omitted,
   the parameters component shall be present and have the value NULL.

   If the DSA algorithm parameters are absent from the subjectPublicKey-
   Info AlgorithmIdentifier and the CA signed the subject certificate
   using DSA, then the certificate issuer's DSA parameters apply to the
   subject's DSA key.  If the DSA algorithm parameters are absent from
   the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using a signature algorithm other than DSA, then
   the subject's DSA parameters are distributed by other means.  The
   parameters are included using the following ASN.1 structure:

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }

   If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL param-
   eters and the CA signed the subject certificate using DSA, then the
   certificate issuer's parameters apply to the subject's DSA key. If
   the subjectPublicKeyInfo AlgorithmIdentifier field has NULL parame-
   ters and the CA signed the subject with a signature algorithm other
   than DSA, then clients shall not validate the certificate.

   When signing, DSA algorithm generates two values.  These values are
   commonly referred to as r and s.  To easily transfer these two values
   as one signature, they are ASN.1 encoded using the following ASN.1
   structure:

        Dss-Sig-Value  ::=  SEQUENCE  {
            r             INTEGER,
            s             INTEGER  }

   The encoded signature is conveyed as the value of the BIT STRING sig-
   nature in a Certificate or CertificateList.

   The DSA public key shall be ASN.1 encoded as an INTEGER; this encod-
   ing shall be used as the contents (i.e., the value) of the sub-
   jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

        DSAPublicKey ::= INTEGER -- public key Y

   If the keyUsage extension is present in an end entity certificate
   which conveys a DSA public key, any combination of the following
   values may be present:

      digitalSignature; and
      nonRepudiation.

   If the keyUsage extension is present in an CA certificate which con-
   veys a DSA public key, any combination of the following values may be
   present:

      digitalSignature;
      nonRepudiation;
      keyCertSign; and
      cRLSign.

- John Pawling

At 02:26 PM 5/13/98 +0100, Graham Klyne wrote:
>Folks,
>
>Is there a document which describes exactly how DSS signature and
>certificate data should be formatted (i.e. the organization of data within
>a "SignatureValue", etc.)?
>
>Specifically, in handling signed messages, we have:
>
>>To verify the contents of a DSA signed message on the other end you need 
>>three values P, Q, G and the Public Key. The values of P, Q and G must be 
>>the same as those used to sign the message.  (where the Public Key is 
>>derived from the P,Q, and G values and the private key).
>
>How are the P, Q and G values communicated?  Are they part of the
>signature, the public key or something else?
>
>#g
>
>------------
>Graham Klyne
>
>

Date: Wed, 13 May 1998 14:26:57 +0100
To: <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: DSS signatures and keys
Sender: [email-masked]

Folks,

Is there a document which describes exactly how DSS signature and
certificate data should be formatted (i.e. the organization of data within
a "SignatureValue", etc.)?

Specifically, in handling signed messages, we have:

>To verify the contents of a DSA signed message on the other end you need 
>three values P, Q, G and the Public Key. The values of P, Q and G must be 
>the same as those used to sign the message.  (where the Public Key is 
>derived from the P,Q, and G values and the private key).

How are the P, Q and G values communicated?  Are they part of the
signature, the public key or something else?

#g

------------
Graham Klyne

Date: Wed, 13 May 1998 10:24:09 +0900
From: tyone <[email-masked]>
To: [email-masked]
Subject: The OID and Parameter Definition of MISTY1
Sender: [email-masked]

Dear All

Recently I am often asked  the OID and parameter definition of MISTY1
(http://www.ietf.org/internet-drafts/draft-ohta-misty1desc-00.txt)
.So please have me the opportunity for announcing them.

(1) MISTY1-CBC OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) jisc(392)
      mitsubishi-electric-corporation(200011) isl(61) security(1)
      algorithm(1) symmetric-encryption-algorithm(1) misty1-cbc(1) }

   *The Encryption Block Padding is the same as that defined
in PKCS#5 6.2
   *The number of rounds of MISTY1 is 8.

(2) Parameter
MISTY1-CBC parameter ::= IV
Where IV ::= OCTET STRING --8 octets.

-------------------------------
This information will be described in the next update
 internet-draft or RFC of MISTY1.

Please refer to this information in the case of using MISTY1-CBC
in PKCS#7 EnvelopedData (S/MIME)

Mitsubishi Electric Corp.
Takeshi Yoneda
Email: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sigattr-00.txt
Date: Tue, 12 May 1998 10:24:17 -0400
Sender: [email-masked]

--NextPart

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		: Signing Certificate Attribute Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-sigattr-00.txt
	Pages		: 4
	Date		: 11-May-98
	
 A set of attacks on SignedData objects have been
 identified relating to the fact that the certificate to be
 used when verifying the signature in a SignerInfo is not
 cryptographically bound into the signature. This leads to
 a set of attacks where the certificate used to verify the
 signature is altered leading to possible incorrect
 results. This document describes these attacks and
 provides ways to deal with some of the attacks.
 
 This draft is being discussed on the 'ietf-smime' mailing
 list. To join the list, send a message to <ietf-smime-
 [email-masked] <mailto:[email-masked]> > with the single word
 'subscribe' in the body of the message. Also, there is a Web site      
 for the mailing list at <http://www.imc.org/ietf-smime>.

Internet-Drafts are 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-sigattr-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-sigattr-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-sigattr-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-sigattr-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-sigattr-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 11 May 1998 19:27:46 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Cc: Francois Rousseau <[email-masked]>, [email-masked]
Sender: [email-masked]

I do not see a need.

Russ

At 06:32 PM 5/11/98 -0700, Denis Pinkas wrote:
>Russ,
>
>> Denis:
>> 
>> I can look at it another way.  The recipient may require the presence of a
>> particular AC.  And, in a store-and-forward application, the originator
>> may not know what AC was required by the recipient.  I do agree that in
>> most cases both the originator and recipient will know what ACs are needed
>> from context.
>> 
>> Russ
>
>So what is your conclusion ? :-)
>
>Do you agree to have AC (or AC references) signed ?
>
>Up to now, everyone is refering a definition of AC. Can some one post or
>give a URL where the (single) definition of an AC can be found. If it is
>short enough, posting the whole ASN 1 definition directly to the list
>would be fine. I would like to check how the pointer to the user
>certificate is defined.
>
>Denis
>
>-- 
>      Denis Pinkas     Bull S.A.          mailto:[email-masked]
>      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 

Date: Mon, 11 May 1998 18:36:40 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CERT-04 Comments
Sender: [email-masked]

All,

IMHO, Blake has done a wonderful job of incorporating the comments into
CERT-04 (4 May 98) upon which the group has reached concurrence.  I have a
few comments related to the open issues listed in App C:

Key usage for signing / encrypting certificate explanation
[JSP: Don't need it, just refer to PKIX.  Please delete this issue.]

Attribute certificates -- keep 'em or pitch 'em?
[JSP: Keep the X.509 syntax and the CERT-04 text as is.  Please delete this
issue.]

Delete DN jabber from 3.1?
[JSP: This was deleted in CERT-04.  Please delete this issue.]

Extensions -- do we make this list the "maximum allowable" instead of
the "minimum required"?
[JSP: NO.  PKIX allows extensions other than those listed in CERT-04.
Please delete this issue.]

What is the criticality for the "minimum required" extensions?
[JSP: CERT-04 should just refer to PKIX on this.  Please delete this issue.]

Shouldn't 4.4.2.1 be in PKIX I?
[JSP:  Yes.  Recommend that Blake propose that the text be added to PKIX Pt I.]

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Mon, 11 May 1998 18:26:26 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: MSG-04 Comments
Sender: [email-masked]

All,

IMHO, Blake has done a great job of incorporating the comments into MSG-04
(4 May 98) upon which the group has reached concurrence.  I have a few comments:

1) Sec 2.5.2: Please add the following text as the second paragraph:

"If present, the SMIMECapabilities attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute.  A signerInfo MUST NOT
include multiple instances of the SMIMECapabilities attribute.  CMS defines
the ASN.1 syntax for the authenticated attributes to include attrValues SET
OF AttributeValue.  A SMIMECapabilities attribute MUST only include a single
instance of AttributeValue.  There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue."

2) Sec 2.5.3: Please add the following text as the second paragraph:

"If present, the SMIMEEncryptionKeyPreference attribute MUST be an
authenticated attribute; it MUST NOT be an unauthenticated attribute. CMS
defines authenticatedAttributes as a SET OF AuthAttribute.  A signerInfo
MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference
attribute.  CMS defines the ASN.1 syntax for the authenticated attributes to
include attrValues SET OF AttributeValue.  A SMIMEEncryptionKeyPreference
attribute MUST only include a single instance of AttributeValue.  There MUST
NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue."

3) App E: See in-line comments:

4.1 keylengths for RSA need to move to CMS
[JSP: Agree.]

2.5.3.1 to determine the "same subject name" should this be a check
against the subject DN, or both the DN and the subjectAltName
extension?
[JSP: Both.]

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Mon, 11 May 1998 12:58:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

> From: Denis Pinkas <[email-masked]>
> 
> Up to now, everyone is refering a definition of AC. Can some one post or
> give a URL where the (single) definition of an AC can be found. If it is
> short enough, posting the whole ASN 1 definition directly to the list
> would be fine. I would like to check how the pointer to the user
> certificate is defined.

Quite close to home for you :-):

  ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

which contains:

AttributeCertificate ::= SIGNED {AttributeCertificateInfo}

AttributeCertificateInfo ::= SEQUENCE {
    version             Version DEFAULT v1,
    subject CHOICE {
        baseCertificateID [0] IssuerSerial, -- associated with a Public Key Cert
        subjectName       [1] GeneralNames },  -- associated with a name 
    issuer              GeneralNames,    -- CA issuing the attribute cert
    signature           AlgorithmIdentifier,
    serialNumber        CertificateSerialNumber,
    attrCertValidityPeriod  AttCertValidityPeriod,
    attributes          SEQUENCE OF Attribute,
    issuerUniqueID      UniqueIdentifier OPTIONAL,
    extensions          Extensions OPTIONAL }

IssuerSerial ::= SEQUENCE {
    issuer          GeneralNames,
    serial          CertificateSerialNumber,
    issuerUID       UniqueIdentifier OPTIONAL}

AttCertValidityPeriod ::= SEQUENCE {
    notBeforeTime   GeneralizedTime,
    notAfterTime    Generalized Time }

Date: Mon, 11 May 1998 18:32:00 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Russ Housley <[email-masked]>
CC: Francois Rousseau <[email-masked]>, [email-masked]
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

Russ,

> Denis:
> 
> I can look at it another way.  The recipient may require the presence of a
> particular AC.  And, in a store-and-forward application, the originator
> may not know what AC was required by the recipient.  I do agree that in
> most cases both the originator and recipient will know what ACs are needed
> from context.
> 
> Russ

So what is your conclusion ? :-)

Do you agree to have AC (or AC references) signed ?

Up to now, everyone is refering a definition of AC. Can some one post or
give a URL where the (single) definition of an AC can be found. If it is
short enough, posting the whole ASN 1 definition directly to the list
would be fine. I would like to check how the pointer to the user
certificate is defined.

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 08 May 1998 11:12:50 -0400
To: [email-masked] (John Pawling), [email-masked]
From: "Capt Y. Theriault" <[email-masked]>
Subject: Re: ESS-05 comments - MLA withdrawal of a signed receipt   request.
Sender: [email-masked]

All,

a signed receipt from the MLA seemed to be the simpler way to inform the
originator from the withdrawal of his/her request for receipts without
creating a new content type.  I agree that the originator is not expecting
a receipt from the MLA, but it is expecting receipts from other recipients.
 These receipts will never be submitted.  An unauthenticated message from
the MLA without any reference to the message that has been denied receipts
does not help the originator/originator user agent.

That being said.  There appear to be no other expressed requirements for
that feature.  Consequently, it is probably best to stick with Mr.
Pawling's proposal. =20

Yves Th=E9riault. =20

At 09:12 AM 5/8/98 -0400, John Pawling wrote:
>All,
>
>I respectfully disagree with Capt Theriault's proposed additions.  It will
>not always be appropriate for the MLA to send a signed receipt to the
>originator.  For example, if the originator requested that only certain
>recipients return a signed receipt (via the receiptRequest attribute
>receiptsFrom receiptList field) and the ML is not listed as one of those
>recipients, then the MLA should not send a signed receipt to the originator
>because the originator is not expecting a signed receipt from the ML.
>
>If the original signer of the signedData requested a signed receipt from=
 the
>ML itself (ex: receiptRequest ReceiptsFrom allOrFirstTier set to
>allReceipts), then it would be appropriate for the MLA to send a signed
>receipt to the originator.
>
>Please note that the ML's mlReceiptPolicy only applies to the ML members,
>not to the ML itself.  For example, if the originator requested a signed
>receipt from all recipients and the ML's mlReceiptPolicy is none, then the
>MLA would send a signed receipt to the originator, but the ML members would
>not send a signed receipt to the originator.
>
>I strongly disagree with the Captain's other proposal:
>>"It is up to the originator to interpret this receipt as an indication=
 that
>>no other receipts will be received."
>
>There is nothing special about the signed receipt received from the MLA, so
>there will not be any special action taken by the originator's software=
 when
>it receives the MLA's signed receipt.
>
>In summary, I believe that my proposal should be accepted without the
>proposed modifications.
>
>- John Pawling
>
>
>At 08:20 AM 5/8/98 -0400, Capt Y. Theriault wrote:
>>All, =20
>>
>>I would add at the end of John's proposal: "... the MLA MAY inform the
>>originator of that fact by sending a signed receipt."
>>
>>I would also add the following:
>>
>>"It is up to the originator to interpret this receipt as an indication=
 that
>>no other receipts will be received."
>>
>>Yves Theriault.
>>
>>At 11:54 AM 5/6/98 -0400, John Pawling wrote:
>>>All,
>>>
>>>I don't object to adding the following text to ESS:  "In the event that a
>>>ML's signed receipt policy supersedes the originator's request for signed
>>>receipts such that the originator will not receive any signed receipts,
then
>>>the MLA MAY inform the originator of that fact."
>>>
>>>I would object to this being a SHOULD or MUST requirement.
>>>
>>>- John Pawling
>>>
>>>
>
>
>
Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

Date: Fri, 8 May 1998 09:12:46 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-05 comments - MLA withdrawal of a signed receipt   request.
Sender: [email-masked]

All,

I respectfully disagree with Capt Theriault's proposed additions.  It will
not always be appropriate for the MLA to send a signed receipt to the
originator.  For example, if the originator requested that only certain
recipients return a signed receipt (via the receiptRequest attribute
receiptsFrom receiptList field) and the ML is not listed as one of those
recipients, then the MLA should not send a signed receipt to the originator
because the originator is not expecting a signed receipt from the ML.

If the original signer of the signedData requested a signed receipt from the
ML itself (ex: receiptRequest ReceiptsFrom allOrFirstTier set to
allReceipts), then it would be appropriate for the MLA to send a signed
receipt to the originator.

Please note that the ML's mlReceiptPolicy only applies to the ML members,
not to the ML itself.  For example, if the originator requested a signed
receipt from all recipients and the ML's mlReceiptPolicy is none, then the
MLA would send a signed receipt to the originator, but the ML members would
not send a signed receipt to the originator.

I strongly disagree with the Captain's other proposal:
>"It is up to the originator to interpret this receipt as an indication that
>no other receipts will be received."

There is nothing special about the signed receipt received from the MLA, so
there will not be any special action taken by the originator's software when
it receives the MLA's signed receipt.

In summary, I believe that my proposal should be accepted without the
proposed modifications.

- John Pawling

At 08:20 AM 5/8/98 -0400, Capt Y. Theriault wrote:
>All,  
>
>I would add at the end of John's proposal: "... the MLA MAY inform the
>originator of that fact by sending a signed receipt."
>
>I would also add the following:
>
>"It is up to the originator to interpret this receipt as an indication that
>no other receipts will be received."
>
>Yves Theriault.
>
>At 11:54 AM 5/6/98 -0400, John Pawling wrote:
>>All,
>>
>>I don't object to adding the following text to ESS:  "In the event that a
>>ML's signed receipt policy supersedes the originator's request for signed
>>receipts such that the originator will not receive any signed receipts, then
>>the MLA MAY inform the originator of that fact."
>>
>>I would object to this being a SHOULD or MUST requirement.
>>
>>- John Pawling
>>
>>

Date: Fri, 08 May 1998 08:20:15 -0400
To: [email-masked] (John Pawling), [email-masked]
From: "Capt Y. Theriault" <[email-masked]>
Subject: Re: ESS-05 comments - MLA withdrawal of a signed receipt  request.
Sender: [email-masked]

All, =20

I would add at the end of John's proposal: "... the MLA MAY inform the
originator of that fact by sending a signed receipt."

I would also add the following:

"It is up to the originator to interpret this receipt as an indication that
no other receipts will be received."

Yves Theriault.

At 11:54 AM 5/6/98 -0400, John Pawling wrote:
>All,
>
>I don't object to adding the following text to ESS:  "In the event that a
>ML's signed receipt policy supersedes the originator's request for signed
>receipts such that the originator will not receive any signed receipts,=
 then
>the MLA MAY inform the originator of that fact."
>
>I would object to this being a SHOULD or MUST requirement.
>
>- John Pawling
>
>
>
>At 09:49 AM 5/6/98 -0400, Capt Y. Theriault wrote:
>>I do not see why the originator should not be informed of his/her denied
>>request to receive signed receipts.  Assuming that there were good reasons
>>to deny the user of such an information, there are other occasions where
>>these reasons would not apply.   It would be nice for the originator to be
>>informed of the denial so that no receipts are expected.
>>
>>Yves Th=E9riault.
>>
>
>
>
Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

From: James M Hayes <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Subject: RE: Re(2): Finding and retrieving applicable AttributeCertificate(s)
Date: Thu, 7 May 1998 15:21:41 -0400
Sender: [email-masked]

Dave Kemp wrote:

>A single attribute containing a list of (issuerName, serialNumber,
>hash(issuerPublicKey)) could serve the dual purpose of binding a normal
>certificate into the transaction (to prevent spoofing) and to bind
>selected attribute certs into the transaction (to prevent third parties
>from inserting unwanted-but-valid attribute certs).  I support the
>definition of such an attribute, as discussed a while back in the
>context of shared public keys.

It never occured to me to use the issuer's key.=20

The advantage of using Dave's method (issuer's key hash
along with issuer name and serial number) is that an Attribute Authority =
that performs intensive issuing operations can cache this information if =
all base certicates are issued by the same CA, where as the solution =
that I proposed requires more CPU time since there is a calculation for =
each subject's public key.

Now all we have to do is worry about dealing with multiple attribute =
authorities.  That can wait for another list :)

Capt Hayes

Date: Thu, 07 May 1998 14:16:03 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re(2): Attribute Certificate(s) in S/MIME
Cc: [email-masked] (David P. Kemp)
Sender: [email-masked]

I am again sorry if I have confused anyone while trying to express my
client's requirements related to ACs.

Of the two requirements I have been trying to get addressed, the first one
is on the binding of a particular originator's AC to a signed S/MIME
business transaction (requirement 1 from David Kemp below) and the second
about the implication on ACs if the CertificateSet in the SignedData
certificates field INTENTIONALLY does NOT include ACs.

For the former, as a business transaction is signed with the originator's
private signing key, to verify the authenticity and integrity of the
transaction, the recipient's application software uses the originator's
public key certificate, which is identified through SignerInfo
issuerAndSerialNumber field of the signed transaction.

However, there are currently no EXPLICIT means to bind a particular AC, of
the many ACs an originator may have, with a signed business transaction to
convey the privilege of this originator. An example of a privilege conveyed
through an AC is: Bob is authorized to approved contract under $1 Million
US for Firm X. The only IMPLICIT means in CMS to bind an AC with a signed
business transaction is to include the particular originator's AC in the
SignedData certificates field. Because of the different version number
allowed by CMS for the SignedData version field, the recipient's
application software would know that ACs were included with this signed
business transaction. However, the originator would have no explicit
guarantee that the recipient's application software would process the
included AC properly. Would the recipient's application software only
verify the signature on the transaction versus the particular originator's
privilege to approved this signed business transaction conveyed through the
bound AC?

Note that I have not suggested to include ACs in the SignerInfo
authenticatedAttributes field of CMS since their current inclusion in the
SignedData certificates field is most appropriate (option 3 from David Kemp
below).

For the latter, if ACs are intentionally NOT included in the SignedData
certificates field, there will than be no means for the recipient to ever
know that a particular AC had been bound to this signed business
transaction, by the originator, to convey the proof of his/her
authorization. Since the SignerInfo issuerAndSerialNumber field is already
being used to identify each originator's valid public key certificate, it
can not also be used for the purpose of identifying the particular
originator's AC. How can the recipient's application software than find and
retrieve the applicable originator's AC?

This is why I have suggested in a previous message that a new CRITICAL
authenticated attribute should be supported by CMS in the SignerInfo
authenticatedAttributes field. This new authenticated attribute would just
be a pointer that UNIQUELY identifies the applicable originator's AC and
would not include the applicable AC. ACs could still optionally be included
in the SignedData certificates field. By being signed by the originator,
this new authenticated attribute would preclude spoofing. This new
attribute would EXPLICITLY identify which particular AC, of the many ACs an
originator may have, MUST be used by the recipient's application software
to verify the authorization service conveyed through the particular
originator's AC bound to this signed business transaction.

This new authenticated attribute addresses all of my client's requirements
related to ACs:

- First, since I have suggested that this attribute should be CRITICAL, the
originator would have an EXPLICIT guarantee that the recipient's
application software would know how to process the bound AC properly,
otherwise the application software would not processed further the signed
business transaction.

- Second, it would allow the recipient's application software to find the
applicable originator's AC if many ACs have been included with the
SignedData certificates field.

- Third, it would allow the recipient's application software to find and
retrieve the applicable originator's AC from the repository where ACs are
published or to find it in the ones the application software may have
cached, if ACs have NOT been included with the SignedData certificates field.

Francois Rousseau

You wrote:
>
>Stephen,
>
>Although putting requirements first and protocol second is a good idea,
>paralysis by analysis is a potential bad outcome of that method.  It
>seems to me that requirements may be stated more abstractly, perhaps
>illustrated by specific examples, but that compiling an exhaustive list
>of scenarios is not necessary.
>
>The abstract requirements are:
>
>1. Is it necessary to bind an AC to a specific content or signature (y/n)?
>2. Is it necessary to add or remove ACs from a message without invalidating
>   signatures (y/n)?
>
>Note that the two requirements are mutually exclusive - no mechanism can
>simultaneously satisfy both.
>
>Although Mr. Rousseau originally proposed that ACs be carried in
>signed attributes, his Electronic Commerce scenario implies no
>requirement for the user to sign the AC:
>
>  > Although public key certificates can provide
>  > such an authorization service directly if privileges are associated with
>  > this user through the practices of the issuing Certificate Authority, it
>  > can be more appropriate to dissociate privilege from identity. In such
>  > cases, the AC can be the means by which the user's privileges are
>  > expressed. Based on this, ACs are than required to convey, with
>  > authenticity, integrity and currency, the privileges associated with a
>  > user, in order that Verifiers can enforce the appropriate Control
Policy on
>  > signed S/MIME transactions.
>
>
>And your (Stephen's) mail list scenario has a requirement that users
>*not* compute signatures over the ACs:
>
>  > firstly, it may be appropriate
>  > for the mail list to remove the originator's AC (it could be
>  > usable for lots of things which we don't want the entire list
>  > to know about) and, secondly, multiple expansions could occur
>  > meaning that different ACs may be needed at different stages.
>
>
>Thus we have a negative answer for requirement 1, and a positive answer
>for requirement 2.  The only reason to collect any more scenarios would
>be to find one which not only implies a "yes" for requirement 1, but
>which is so compelling that it trumps the requirement 2 scenarios and
>leads to a syntax which does not address them.
>
>Note also that any scenario which required the user to sign the AC
>violates the fundamental principle that the security properties of
>certificates derive from validating the Authority's (CA or AA)
>signature, and do not depend on any protection provided by the
>repository or the transmission path between the Authority and the
>Verifier.
>
>So we have three syntax options for ACs:
>                                          Satisfies
>     Option                               Reqt  1  2
>--------------------------------------    ----------
>1. signed attribute in each SignerInfo          Y  N
>2. unsigned attribute in each SignerInfo        N  Y
>3. (unsigned) field in SignedData               N  Y
>
>
>As previously mentioned, including all the ACs in SignedData is more
>space efficient than including potentially duplicate copies in
>each SignerInfo, so I still prefer Option 3, which is the method
>CMS currently uses to carry ACs.
>
>
>  Dave Kemp
>
>

Date: Thu, 07 May 1998 14:15:05 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Cc: Francois Rousseau <[email-masked]>, [email-masked]
Sender: [email-masked]

Denis:

I can look at it another way.  The recipient may require the presence of a
particualar AC.  And, in a store-and-forward application, the originator
may not know waht AC was required by the recipeint.  I do agrre that in
most cases both the originator and recipient will know what ACs are needed
from context.

Russ

At 03:45 PM 5/7/98 -0700, Denis Pinkas wrote:
>Russ Housley wrote:
>
>> At 12:06 PM 5/5/98 -0400, Francois Rousseau wrote:
>> >Yes storing Attribute Certificates in the signedData certificates field
>> >will avoid the redundancy of having them repeated in each signer
>> >signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
>> >meant to help find the correct AC as suggested. It is meant to specify
>> >which signer's public key to use to verify the digital signature on the
>> >signedData eContent field.
>> 
>> Agree, issuerAndSerialNumber is meant to identify the signature certificate
>> containing the signer's public key.  The attribute certificate (AC)
>> contains the same issuer and serial number field (or subject distinguished
>> name) linking it to the signature certificate.
>> 
>> >So when AC's are included in the signedData
>> >certificates CertificateSet, the receiving software can NOT still be sure
>> >to find the correct AC.
>> 
>> Zero or more ACs may be needed.  Zero is the easy case, but multiple AC
>> (potentially issued by different authorities) may bee needed in some
context.
>> 
>> >It is even worst when AC's are NOT included in the
>> >signedData certificates CertificateSet to minimize the size of
>> >transactions, although AC's have been used with the signing process to
>> >provide an authorization service. The receiving software than has no means
>> >to know that AC's were used, and to find and retrieve the applicable AC
>> >during the later verification.
>> 
>> The recipient will determine which ACs are needed from the context.  The
>> recipient can readiy determine which ACs are linked to the signer's
>> signature certificate (as discussed above).
>> 
>> >It is recommended that a new CMSAttribute be added in the signerInfo
>> >authenticatedAttributes field to let the receiving software know that AC's
>> >were used along the signing process, and to help it find and retrieve the
>> >applicable AC for the later verification.
>> 
>> Given the linkage that is already present, why is this needed?
>
>I believe the reason is simple: The signer may have multiple ACs. It is
>up to the signer to indicate which ones he is wishing the recipient to
>use. The recipient should only be allowed to use what is possible within
>the choice of the signer.
>
>Denis
>
>> Russ
>
>-- 
>      Denis Pinkas     Bull S.A.          mailto:[email-masked]
>      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 

Date: Thu, 07 May 1998 12:36:36 -0400
To: Nada Kapidzic Cicovic <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

You interpret by position correctly.  Diffie-Hellman keys and ElGamal keys
shoudl have different AlgorithmIdentifiers.

Russ

At 01:38 PM 5/7/98 +0200, Nada Kapidzic Cicovic wrote:
>Peter and Russ,
>
>It seems that you both have the same opinion on ElGamal encryption with
>Diffie-Hellman keys. What you are suggesting is to use separate usage and
>object identifier for ElGamal keys.
>
>To me it seems to be an overkill for users who would like to use ElGamal
>for encryption. They would then need to have three different types of keys:
>
>- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
>- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
>PKIX and S/MIME),
>- a pair of DH keys (or ElGamal keys, but essentially they are the same)
>for ElGamal encryption,
>
>in spite the fact that the two latter keys are syntactically the same (I am
>not suggesting the usage of ElGamal signature, so the strength of the
>generators is not questionable).
>
>
>
>Regards,
>Nada
>
>
>At 16:20 5/6/98, Peter Gutmann wrote:
>>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys
may
>>>only be used in the way suggested by Russ Housley, i.e. for each
>recipient to
>>>take recipient's Diffie-Hellman certificate (key agreement certificate),
get
>>>the public key from there, generate a shared key (Russ suggested 3DES)
>and use
>>>it to encrypt the content-encryption key.
>>>
>>>However, another possibility is to use El-Gamal algorithm with
>Diffie-Hellman
>>>keys and encrypt the content-encryption key directly with recipients
>>>Diffie-Hellman public key. This would be a very similar operation as if the
>>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
>are
>>>used for keys encryption (unless I have missed some point here).
>> 
>>If you use the key this way then it's no longer DH but Elgamal, with its
own 
>>algorithm/object identifiers and usage requirements.  For example some 
>>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
>for 
>>example) you can't just use it as if it were Elgamal.  If you want to use a 
>>key for Elgamal encryption/signatures, you should really call it Elgamal,
>and 
>>not take a DH key and use it for something it was never designed for.
>> 
>>(If you want to get really nitpicky, there are actually three different 
>> algorithms which use keys which look more or less the same: DH (key 
>> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
>> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
>> rather than overload DH further and further)
>> 
>>Peter.
>> 
>>
>>
> 

Date: Thu, 7 May 1998 12:58:35 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Re(2): Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

>  
> However, as indicated by both Rich Ankney and Denis Pinkas, the originator
> may have multiple ACs. It should be up to the originator to indicate which
> ones he/she is wishing the recipient to use. The recipient should only be
> allowed to use what is possible within the choice of the originator.

I agree with you and Rich and Denis that if the requirement is for the
originator to select at origination time a subset of the attibutes he may
use, then a list of attribute certs is required somewhere in the
message.  The question is must this list be signed?

A single attribute containing a list of (issuerName, serialNumber,
hash(issuerPublicKey)) could serve the dual purpose of binding a normal
certificate into the transaction (to prevent spoofing) and to bind
selected attribute certs into the transaction (to prevent third parties
from inserting unwanted-but-valid attribute certs).  I support the
definition of such an attribute, as discussed a while back in the
context of shared public keys.

But the operational question remains whether it is desirable (in the
case of a gateway) or undesirable (in the case of an attacker) for a
third party to be able to insert/delete the sender's legitimate
attribute certs from a message.  That question doesn't have to be
answered now - if the certlist S/MIME attribute is defined, it can be
used or not as appropriate.

As long as ACs may be carried in CertificateSet, I'm happy.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cert-04.txt
Date: Thu, 07 May 1998 12:36:09 -0400
Sender: [email-masked]

--NextPart

A Revised 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		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-04.txt
	Pages		: 9
	Date		: 06-May-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use X.509 certificates to validate public keys as described in
the ITU-T Recommendation X.509 (1997) [X.509] and the Internet Public
Key Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM].
S/MIME agents MUST meet the S/MIME-specific requirements documented in
this I-D in addition to those stated in [X.509] and [KEYM].

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cert-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-04.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cert-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cert-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 07 May 1998 11:14:36 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re(2): Finding and retrieving applicable Attribute Certificate(s)
Cc: [email-masked]
Sender: [email-masked]

I am sorry if I may have confused anyone, but I would like to clarify some
of your comments.

At 03:05 PM 06/05/98 -0400, you wrote:
>> From: Francois Rousseau <[email-masked]>
>> 
>> This
>> implies that the signedInfo issuerAndSerialNumber field can NOT uniquely
>> identify both the public key certificate and the AC for each originator.
>
>
>Either I am completely confused about the point you are trying to make,
>or you are confused about the difference between an attribute authority
>and the subject of an attribute certificate.
>
>To clarify:
>
> * a public key certificate is issued and signed by a CA.

* in a public key certificate, the CA is identified through the issuer
field represented by "Name" AND/OR the issuerAltName extension represented
by "GeneralNames". 

> * one or more attribute certificates are issued and signed by one or
>   more AAs, which in general are different from the CA.

* in an AC, the AA is identified only through the issuer field represented
by "GeneralNames".

> * each AC refers to one or more base public key certificates
>   (the "subject") which, as you point out, can be referred to using
>   either a baseCertificateID or a subjectName.

Instead it should have read:

* each AC refers to a subject, which can be identified by using either a
baseCertificateID or a subjectName.

* if the subject of a particular AC is identified by a baseCertificateID,
it is represented by a SEQUENCE of the GeneralNames of the issuer (i.e. the
CA) and the CertificateSerialNumber of the subject's public key
certificate, and an OPTIONAL issuer unique identifier. As the subject's
public key certificate is revoked and reissued, ACs using this approach
also needs to be revoked and reissued in order to remain valid.

* if instead the subject of a particular AC is identified by a subjectName,
it is currently only represented by the GeneralNames of the subject. As the
subject's public key certificate is revoked and reissued, ACs using this
approach will not be impacted.

Note that when the latter approach is used and to address the masquerade
issue raised by Capt Hayes, it has been suggested that the subject should
also be identified by the name of the issuer (i.e. the CA) of its public
key certificate in addition to the subject's GeneralNames.

> * the CMS SignerInfo issuerAndSerialNumber field refers to one public
>   key certificate.
>
>Therefore, since the issuerAndSerialNumber field refers to one public key
>certificate, and all ACs have a subject (public key certificate),
>then the issuerAndSerialNumber field uniquely determines both the
>signer and all ACs which apply to the signer. 

Yes the issuerAndSerialNumber field identifies, which signer's public key
certificate MUST be used by the recipient to verify the integrity and
authenticity of the signed message.

However, as indicated by both Rich Ankney and Denis Pinkas, the originator
may have multiple ACs. It should be up to the originator to indicate which
ones he/she is wishing the recipient to use. The recipient should only be
allowed to use what is possible within the choice of the originator.

Because of this, the issuerAndSerialNumber field can NOT at the SAME TIME
uniquely identify, which signer's public key certificate and which
particular AC, of the many ACs an originator may have, MUST be used by the
recipient to verify an authorization service conveyed through this
particular AC, which is bound to this signed message.

Francois Rousseau

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-04.txt
Date: Thu, 07 May 1998 10:58:05 -0400
Sender: [email-masked]

--NextPart

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		: S/MIME Version 3 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-msg-04.txt
	Pages		: 24
	Date		: 06-May-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).

Internet-Drafts are 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-msg-04.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-msg-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-msg-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-msg-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: James M Hayes <[email-masked]>
To: James M Hayes <[email-masked]>, "'Dr Stephen Henson'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: FW: Charter Change Request
Date: Thu, 7 May 1998 11:42:06 -0400
Sender: [email-masked]

Dr. Stephen Henson wrote:=20

>Item 2 refers to the autenticated attributes (see S/MIME CMS) not
>attribute certificates as such. I believe its purpose is to prevent an
>attack mentioned previously.=20

I did misunderstand what the difference is between authenticated =
attributes and attribute certificates.  Someone in my office has shown =
me the light; however, I believe the attack is different, but the end =
result is the same.  The end user believes he/she has received a message =
from an authenticated source.  See below.

>I'll briefly describe it: suppose a user has two certificates signed by
>different CAs (A and B) but with the same public key. Under the current
>CMS the issuer and serial number field is not authenticated. Thus an
>attacker can take a message signed by a certificate of CA A and
>transform it into an equally valid message signed by the same user but
>for CA B.

>Adding an authenticated attribute with issuer and serial number =
prevents
>this attack because the issuer and serial number is now signed by the
>message originator.

This still does not prevent a masquerade for authenticated attributes.  =
Let's say you have the following:

Root:      CA A                  CA B
Sub CA:     -                     CA A
Cert        Duke, 822          Duke, 822

Both Dukes have issuers of CA A and serial number 822.  Root CA B's Duke =
can't change Root CA A's Duke's messages, but he can pull CA A's Duke's =
message's and replace them with his.  The recipient will see that the =
message was signed by Duke, 822 whose issuer is CA A and is therefore =
linked to the authenticated attribute.  The key to CA B's Duke messages =
completing their task is the countersignature.  If the process =
performing this function trusts CA B, it will perform chain validation =
as well and therefore accept CA B's Duke.  Based on section 11 of the =
CMS and the type of attributes being certified this may not be critical =
(their not privilege attributes).  What is critical is the content of =
Duke's message. =20

>[interesting rogue CA discussion deleted]

>I think this is a bit off topic for this list but I think the line has
>to be drawn somewhere: if one assumes rogue CAs can exist then all
>manner of undesirable consequences can result. It doesn't even need a
>rogue CA: CA private key compromise or just issuing certificates with
>improper extensions can have the same result.

I'm sorry you feel this way.  The scenario I described, IMHO, is no less =
important than the one you describe.  I would think the goal is to =
account for all vulnerabilities and try and develop solutions for them.

>If a CA is not a root CA then some problems of this nature can be
>avoided by use of the basicConstraints pathLenConstraint by preventing
>CAs from producing subordinate CAs. In the case of root CAs this is not
>possible: but that's likely to be the least of your worries if such a
>rogue CA decides to e.g. issue object signing certificates for e.g.
>ActiveX controls and a subjectName of whoever they wish to blame.

I agree.  Unfortunately, the CA in question probably won't put Name and =
Path constraints on itself.  I as a user or a peer CA have no say on =
what constraints a CA will impose on itself. IMO, one way that a =
targeted CA can protect itself is for the CA to employ attributes and =
techniques of its own to prevent such attacks.  The SHA-1 binding =
between a base certificate and attribute certificate in my previous =
example would prevent CA B's CA A clients from being able to claim ACs =
of CA A's clients. =20

I, as the user, have the right to trust or not trust a CA. You and I =
understand the intricacies of trust and CA's, but I seriously doubt that =
the general public does.  The goal should be to "teach" applications how =
to detect such attacks under these conditions.  When a user runs an =
application to e-mail or browse the Web, they are relying on the =
application to notify them when something is going wrong.=20

>In the example given if CA B decided to forge its own subordinate =
pseudo
>CA A then the only real option of the server would be to no longer =
trust
>CA B. This is the only sensible option for the server IMHO.

I agree, but CA B would probably be removed after an attack took place =
and only if the attack was discovered.  Thanks for informing me about =
the other attack.

>Steve.
>--=20
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.

JAMES M. HAYES, Capt, USAF
NSA

Date: Thu, 07 May 1998 15:45:06 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Russ Housley <[email-masked]>
CC: Francois Rousseau <[email-masked]>, [email-masked]
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

Russ Housley wrote:

> At 12:06 PM 5/5/98 -0400, Francois Rousseau wrote:
> >Yes storing Attribute Certificates in the signedData certificates field
> >will avoid the redundancy of having them repeated in each signer
> >signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
> >meant to help find the correct AC as suggested. It is meant to specify
> >which signer's public key to use to verify the digital signature on the
> >signedData eContent field.
> 
> Agree, issuerAndSerialNumber is meant to identify the signature certificate
> containing the signer's public key.  The attribute certificate (AC)
> contains the same issuer and serial number field (or subject distinguished
> name) linking it to the signature certificate.
> 
> >So when AC's are included in the signedData
> >certificates CertificateSet, the receiving software can NOT still be sure
> >to find the correct AC.
> 
> Zero or more ACs may be needed.  Zero is the easy case, but multiple AC
> (potentially issued by different authorities) may bee needed in some context.
> 
> >It is even worst when AC's are NOT included in the
> >signedData certificates CertificateSet to minimize the size of
> >transactions, although AC's have been used with the signing process to
> >provide an authorization service. The receiving software than has no means
> >to know that AC's were used, and to find and retrieve the applicable AC
> >during the later verification.
> 
> The recipient will determine which ACs are needed from the context.  The
> recipient can readiy determine which ACs are linked to the signer's
> signature certificate (as discussed above).
> 
> >It is recommended that a new CMSAttribute be added in the signerInfo
> >authenticatedAttributes field to let the receiving software know that AC's
> >were used along the signing process, and to help it find and retrieve the
> >applicable AC for the later verification.
> 
> Given the linkage that is already present, why is this needed?

I believe the reason is simple: The signer may have multiple ACs. It is
up to the signer to indicate which ones he is wishing the recipient to
use. The recipient should only be allowed to use what is possible within
the choice of the signer.

Denis

> Russ

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

To: [email-masked] (David P. Kemp)
Cc: [email-masked], [email-masked]
Subject: Re: Attribute Certificate(s) in S/MIME 
Date: Thu, 07 May 1998 13:38:28 +0100
From: Stephen Farrell <[email-masked]>
Sender: [email-masked]

Dave,

I'll answer both your mails in one...

> The abstract requirements are:
> 
> 1. Is it necessary to bind an AC to a specific content or signature (y/n)?
> 2. Is it necessary to add or remove ACs from a message without invalidating
>    signatures (y/n)?

I basically agree with your analysis, however, there is a third
possible requirement to be considered:

3. Is it necessary to support controlled delegation of ACs (y/n)?

If the answer is yes, then we need to allow more than just
the AC in the SignedData (or wherever).

And the reason for this is...

> One cannot "steal" a public key certificate - certificates are (in
> principle) public knowledge, and possession of a certificate does
> not by itself convey any privilege whatsoever.

That's right, and if no delegation support is needed then
just sending the AC with an authenticated message is fine.
However, stealing an AC becomes a threat once delegation 
is allowed.

Take the following TLS based example, client (C) establishes a TLS
session with intermediate server (IS), which establishes
a TLS session with a final target (T) on behalf of the client. 
Now assume that IS and T base their access decisions on ACs
(doesn't matter here how IS and T get the ACs).

Many environments require that the access decision to be made at
T is based on C's AC and not on IS's AC (or maybe both).

For this to happen IS has to pass (a reference to) C's AC to T. 
This is where theft of ACs becomes possible - you need to prevent 
a bad IS pretending to be acting on behalf of C. There are different 
ways to do this, but all depend one way or another on the C giving IS 
the right to delegate, e.g. by signing a structure containing C's name,
IS's name, AC issuer/serial, time etc.

Now, I've no idea if such a scenario is relevant to S/MIME, but
I suspect that some CMS consumers may need to support delegation.
If such controlled delegation is required then it isn't enough
just to pass the AC from C to IS, C also needs to (be able to) 
give IS the right to delegate and some additional syntax 
is required (though come to think of it, it needn't go
right beside the AC - maybe we could define a delegtion control 
authenticated attribute which affects how recipients treat
the ACs?).

Regards,
Stephen.

BTW: Just for information, DCE PACs are somewhat like ECMA PACs which 
are very like X.509 ACs (see ftp://ftp.ecma.ch/ecma-st/e219-pdf.pdf,
around page 80, the definition of GeneralisedCertificate). 

Date: Thu, 07 May 1998 13:38:42 +0200
To: [email-masked], [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter and Russ,

It seems that you both have the same opinion on ElGamal encryption with
Diffie-Hellman keys. What you are suggesting is to use separate usage and
object identifier for ElGamal keys.

To me it seems to be an overkill for users who would like to use ElGamal
for encryption. They would then need to have three different types of keys:

- a pair of DSA keys for signing (being mandatory in PKIX and S/MIME),
- a pair of DH keys for Diffie-Hellman key exchange (being mandatory in
PKIX and S/MIME),
- a pair of DH keys (or ElGamal keys, but essentially they are the same)
for ElGamal encryption,

in spite the fact that the two latter keys are syntactically the same (I am
not suggesting the usage of ElGamal signature, so the strength of the
generators is not questionable).

Regards,
Nada

At 16:20 5/6/98, Peter Gutmann wrote:
>>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>>only be used in the way suggested by Russ Housley, i.e. for each
recipient to
>>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>>the public key from there, generate a shared key (Russ suggested 3DES)
and use
>>it to encrypt the content-encryption key.
>>
>>However, another possibility is to use El-Gamal algorithm with
Diffie-Hellman
>>keys and encrypt the content-encryption key directly with recipients
>>Diffie-Hellman public key. This would be a very similar operation as if the
>>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>>much better way of using Diffie-Hellman keys, similar to the way RSA keys
are
>>used for keys encryption (unless I have missed some point here).
> 
>If you use the key this way then it's no longer DH but Elgamal, with its own 
>algorithm/object identifiers and usage requirements.  For example some 
>generators which are OK for Elgamal encryption aren't secure for Elgamal 
>signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does,
for 
>example) you can't just use it as if it were Elgamal.  If you want to use a 
>key for Elgamal encryption/signatures, you should really call it Elgamal,
and 
>not take a DH key and use it for something it was never designed for.
> 
>(If you want to get really nitpicky, there are actually three different 
> algorithms which use keys which look more or less the same: DH (key 
> exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
> Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
> rather than overload DH further and further)
> 
>Peter.
> 
>
>

Date: Thu, 07 May 1998 02:28:25 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: Sean Turner <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Charter Change Request
Sender: [email-masked]

Sean Turner wrote:
> 
> There is an attribute (supportAlgorithms) defined in the ASN.1 module, but it's not referenced in the specification in anyway.  The attribute was include, I believe, so that it could be put in a directory not carried in a certificate (somebody tell me if I'm wrong), presumably in the subjectDirectoryAttributes extension.
> 

I think that's part of the problem here. If such a thing is well
defined, authenticated (i.e. signed by the user) and can be updated
unambiguously (possibly in the face of conflicting SMIMECapabilities)
then yes it would be OK.

It is tempting though to just adopt something identical (or nearly so)
to the concept of retrieving S/MIME supported algorithms via
SMIMECapabilities in a signed message (which is well defined). This
could be fairly painlessly supported: as opposed to essentially
representing the same thing in two different ways.

> Maybe I'm not on the same wavelength, but I thought the user would >need to know in advance of sending a message what algorithms the >recipient supports for signature verification and encryption purposes. 

Yes: other than the "must" algorithms but since v2 and v3 are mutually
exclusive in some senses even this is no guarantee.

>Or is the query directed at the directory?  If the query is aimed at >the directory, I think it's already supported, the only thing left to >determine is what information should be in the directory to retrieve >the right certificate.

Can someone give some info on where this is defined? I can see mention
of certificates but no mention of supported algorithms or specifically
S/MIME supported algorithms (which may well differ from supported
algorithms for other purposes).

As mentioned in my previous message "directory" should ideally not just
mean LDAP but also a method of including S/MIME certificates and
algorithms via ftp or http. The "dummy message" painlessly supports
this, only requiring a MIME type or extension (or minor additions to an
existing type).

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Thu, 07 May 1998 01:04:48 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: James M Hayes <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: FW: Charter Change Request
Sender: [email-masked]

James M Hayes wrote:
> 
> Hello All,
> 
> This email was sent to me concerning item 2 of the Charter Change.  I am new to the list so I'm not familiar with all of the on going issues.  I have been looking at attribute certificates and how to bind them to base certificates (signing certificates?).
> 
> From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
> Sent:  Friday, May 01, 1998 7:48 PM
> To:  Ietf-Smime (E-mail)
> Subject:  Charter Change Request
> 
> >2.  A draft proposing a new authenticated attribute which carries the issuer
> >and serial number fields to more tightly bind the signing certificate into
> >the signature itself.
> 
> The binding between an attribute certificate and a X.509 v3 certificate in a multiroot environment may not be unique.  The current X.509 standard calls for a binding based on either the subjectName or issuer name and serial number.  The proposed Charter Change Request would use the latter.  A proposed binding of issuer name and serial number may not be unique in the context of a certificate masquerade.  Let me use an example before I get into defining a proposed "relatively" unique binding.
> 

Item 2 refers to the autenticated attributes (see S/MIME CMS) not
attribute certificates as such. I believe its purpose is to prevent an
attack mentioned previously. 

I'll briefly describe it: suppose a user has two certificates signed by
different CAs (A and B) but with the same public key. Under the current
CMS the issuer and serial number field is not authenticated. Thus an
attacker can take a message signed by a certificate of CA A and
transform it into an equally valid message signed by the same user but
for CA B.

Adding an authenticated attribute with issuer and serial number prevents
this attack because the issuer and serial number is now signed by the
message originator.

[interesting rogue CA discussion deleted]

I think this is a bit off topic for this list but I think the line has
to be drawn somewhere: if one assumes rogue CAs can exist then all
manner of undesirable consequences can result. It doesn't even need a
rogue CA: CA private key compromise or just issuing certificates with
improper extensions can have the same result.

If a CA is not a root CA then some problems of this nature can be
avoided by use of the basicConstraints pathLenConstraint by preventing
CAs from producing subordinate CAs. In the case of root CAs this is not
possible: but that's likely to be the least of your worries if such a
rogue CA decides to e.g. issue object signing certificates for e.g.
ActiveX controls and a subjectName of whoever they wish to blame.

In the example given if CA B decided to forge its own subordinate pseudo
CA A then the only real option of the server would be to no longer trust
CA B. This is the only sensible option for the server IMHO.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 6 May 1998 17:20:20 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

All,

I agree with everything that Dave Kemp has stated regarding Attribute
Certificates.

- John Pawling

From: "Rich Ankney" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Date: Wed, 6 May 1998 16:36:10 -0400
Sender: [email-masked]

It occurs to me that I may want to just assert(use) one of my
attribute certificates in a transaction, rather than all of them.
So I think we need to identify which ACs to use, and whether
the attribute to do this is authenticated or not.

Regards,
Rich

----------
> From: David P. Kemp <[email-masked]>
> To: [email-masked]
> Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
> Date: Wednesday, May 06, 1998 3:05 PM
> 
> > From: Francois Rousseau <[email-masked]>
> > 
> > This
> > implies that the signedInfo issuerAndSerialNumber field can NOT
uniquely
> > identify both the public key certificate and the AC for each
originator.
> 
> 
> Either I am completely confused about the point you are trying to make,
> or you are confused about the difference between an attribute authority
> and the subject of an attribute certificate.
> 
> To clarify:
> 
>  * a public key certificate is issued and signed by a CA.
> 
>  * one or more attribute certificates are issued and signed by one or
>    more AAs, which in general are different from the CA.
> 
>  * each AC refers to one or more base public key certificates
>    (the "subject") which, as you point out, can be referred to using
>    either a baseCertificateID or a subjectName.
> 
>  * the CMS SignerInfo issuerAndSerialNumber field refers to one public
>    key certificate.
> 
> 
> Therefore, since the issuerAndSerialNumber field refers to one public key
> certificate, and all ACs have a subject (public key certificate),
> then the issuerAndSerialNumber field uniquely determines both the
> signer and all ACs which apply to the signer. 

From: James M Hayes <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'David P. Kemp'" <[email-masked]>
Subject: RE: Finding and retrieving applicable Attribute Certificate(s)
Date: Wed, 6 May 1998 17:09:40 -0400
Sender: [email-masked]

Dave Wrote:

>> From: Francois Rousseau <[email-masked]>
>>=20
>> This
>> implies that the signedInfo issuerAndSerialNumber field can NOT =
uniquely
>> identify both the public key certificate and the AC for each =
originator.

>Either I am completely confused about the point you are trying to make,
>or you are confused about the difference between an attribute authority
>and the subject of an attribute certificate.

>To clarify:

 >* a public key certificate is issued and signed by a CA.

 >* one or more attribute certificates are issued and signed by one or
   >more AAs, which in general are different from the CA.

 >* each AC refers to one or more base public key certificates
   >(the "subject") which, as you point out, can be referred to using
   >either a baseCertificateID or a subjectName.

 >* the CMS SignerInfo issuerAndSerialNumber field refers to one public
   >key certificate.

>Therefore, since the issuerAndSerialNumber field refers to one public =
key
>certificate, and all ACs have a subject (public key certificate),
>then the issuerAndSerialNumber field uniquely determines both the
>signer and all ACs which apply to the signer.=20

I was confused too until I had someone else look at Mr. Rousseau =
message.  I believe what he's saying is that he doesn't want all ACs =
coming back from a directory, just the one(s) used for the message.  I =
believe this may be a concern if you didn't want someone to see every =
privilege that you had, in which case, the AA probably wouldn't want to =
put it in the directory,  I would send it along with the message.  The =
other case could be that you wouldn't want the end user or end =
application have to pick the correct AC.  He believes the directory =
should handle it.  Anyway, that's my guess.

I would like to comment on the following:

>Because ACs offer a choice, the baseCertificateID associated with a =
public
>key certificate is not the only approach to refer to its owner. =
Instead, an
>AC can refer to its owner through its GeneralNames.

In the context of my last message discussing masquerading, GeneralNames =
won't protect you in a masquerade if the attacker knows the subject DNs =
of clients for a CA.

Capt Hayes

Date: Wed, 6 May 1998 15:33:01 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Attribute Certificate(s) in S/MIME
Sender: [email-masked]

> From: Stephen Farrell <[email-masked]>
> 
> One example supporting this is to do with providing AC based 
> delegation control whilst at the same time preventing AC "stealing". 
> If such delegation is required, (perhaps only as part of ESS, or 
> for some mailing list cases, or maybe outside of S/MIME), then its 
> pretty much for sure that simply sending the ACs of the originator 
> isn't sufficient.

I assume from this example that you are referring to something
like DCE "Privilege Attribute Certificates", which, despite the
similarity in name, have nothing to do with public-key-based
"Attribute Certificates" as defined by X.509 and ANSI X9.

One cannot "steal" a public key certificate - certificates are (in
principle) public knowledge, and possession of a certificate does
not by itself convey any privilege whatsoever. 

Date: Wed, 6 May 1998 15:05:27 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

> From: Francois Rousseau <[email-masked]>
> 
> This
> implies that the signedInfo issuerAndSerialNumber field can NOT uniquely
> identify both the public key certificate and the AC for each originator.

Either I am completely confused about the point you are trying to make,
or you are confused about the difference between an attribute authority
and the subject of an attribute certificate.

To clarify:

 * a public key certificate is issued and signed by a CA.

 * one or more attribute certificates are issued and signed by one or
   more AAs, which in general are different from the CA.

 * each AC refers to one or more base public key certificates
   (the "subject") which, as you point out, can be referred to using
   either a baseCertificateID or a subjectName.

 * the CMS SignerInfo issuerAndSerialNumber field refers to one public
   key certificate.

Therefore, since the issuerAndSerialNumber field refers to one public key
certificate, and all ACs have a subject (public key certificate),
then the issuerAndSerialNumber field uniquely determines both the
signer and all ACs which apply to the signer. 

Date: Wed, 6 May 1998 14:40:23 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Attribute Certificate(s) in S/MIME
Sender: [email-masked]

> From: Stephen Farrell <[email-masked]>
>
> The recent draft on "role" names might also be calling for
> functionality which can be implemented using ACs.
> 
> I guess people will identify other potential uses of
> ACs (even limiting ourselves to mail). The step after that
> would presumably be to accept or reject the different
> scenarios and then consider how best to pack the
> ACs with the messages.

Stephen,

Although putting requirements first and protocol second is a good idea,
paralysis by analysis is a potential bad outcome of that method.  It
seems to me that requirements may be stated more abstractly, perhaps
illustrated by specific examples, but that compiling an exhaustive list
of scenarios is not necessary.

The abstract requirements are:

1. Is it necessary to bind an AC to a specific content or signature (y/n)?
2. Is it necessary to add or remove ACs from a message without invalidating
   signatures (y/n)?

Note that the two requirements are mutually exclusive - no mechanism can
simultaneously satisfy both.

Although Mr. Rousseau originally proposed that ACs be carried in
signed attributes, his Electronic Commerce scenario implies no
requirement for the user to sign the AC:

  > Although public key certificates can provide
  > such an authorization service directly if privileges are associated with
  > this user through the practices of the issuing Certificate Authority, it
  > can be more appropriate to dissociate privilege from identity. In such
  > cases, the AC can be the means by which the user's privileges are
  > expressed. Based on this, ACs are than required to convey, with
  > authenticity, integrity and currency, the privileges associated with a
  > user, in order that Verifiers can enforce the appropriate Control Policy on
  > signed S/MIME transactions.

And your (Stephen's) mail list scenario has a requirement that users
*not* compute signatures over the ACs:

  > firstly, it may be appropriate
  > for the mail list to remove the originator's AC (it could be
  > usable for lots of things which we don't want the entire list
  > to know about) and, secondly, multiple expansions could occur
  > meaning that different ACs may be needed at different stages.

Thus we have a negative answer for requirement 1, and a positive answer
for requirement 2.  The only reason to collect any more scenarios would
be to find one which not only implies a "yes" for requirement 1, but
which is so compelling that it trumps the requirement 2 scenarios and
leads to a syntax which does not address them.

Note also that any scenario which required the user to sign the AC
violates the fundamental principle that the security properties of
certificates derive from validating the Authority's (CA or AA)
signature, and do not depend on any protection provided by the
repository or the transmission path between the Authority and the
Verifier.

So we have three syntax options for ACs:
                                          Satisfies
     Option                               Reqt  1  2
--------------------------------------    ----------
1. signed attribute in each SignerInfo          Y  N
2. unsigned attribute in each SignerInfo        N  Y
3. (unsigned) field in SignedData               N  Y

As previously mentioned, including all the ACs in SignedData is more
space efficient than including potentially duplicate copies in
each SignerInfo, so I still prefer Option 3, which is the method
CMS currently uses to carry ACs.

  Dave Kemp

Date: Wed, 06 May 1998 13:22:04 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

Mr. Kemp wrote:
>
>However, the same issuer and serial number fields are used in the
>AttributeCertificate's baseCertificateID to identify the same signer's
>certificate.  So issuerAndSerialNumber uniquely identifies both the
>signature certificate and the attribute certificate(s) which reference
>it.

Attribute Certificates will most probably be signed by Attribute
Authorities (AA) that have their own private keys, which will be different
from the private key used by a Certificate Authority (CA) to signed public
key certificates. The only exception is if a CA is also acting as an AA and
it is using the same private key to signed both types of certificates. This
implies that the signedInfo issuerAndSerialNumber field can NOT uniquely
identify both the public key certificate and the AC for each originator.
Also the issuer field in AC is not referred through "Name" as in public key
certificates, instead it is referred through "GeneralNames" (same
GeneralNames as in subjectAltName and issuerAltName extensions from PKIX
Part 1). Because of this, the issuerSerial in Attribute Certificate's
baseCertificateID does NOT have the same syntax as the signedInfo
issuerAndSerialNumber field.

Because ACs offer a choice, the baseCertificateID associated with a public
key certificate is not the only approach to refer to its owner. Instead, an
AC can refer to its owner through its GeneralNames.
>
>> It is even worst when AC's are NOT included in the
>> signedData certificates CertificateSet to minimize the size of
>> transactions, although AC's have been used with the signing process to
>> provide an authorization service. The receiving software than has no means
>> to know that AC's were used, and to find and retrieve the applicable AC
>> during the later verification.
>
>I agree that the receiver has no way of knowing that an AC was used if
>it is not included in the CertificateSet.  That is an argument for
>requiring that any applicable AC be included in CertificateSet.  To
>enable the use of repositories so that the full AC doesn't need to
>be carried in the message, I would support the addition of a reference to
>CertificateChoices, which could contain a pointer to either a cert
>or an attribute cert:
>
Because of what is mentioned above, I would again suggest that a new
CMSAttribute be added in the signerInfo authenticatedAttributes field to
let the receiving software know for each signer that AC's were used along
the signing process, and to help the receiving software find and retrieve
from the repository the applicable AC for each signer that used them.
Instead of using the syntax of the signedInfo issuerAndSerialNumber field,
I suggest it should have the following syntax:

IssuerSerial ::= SEQUENCE {
        issuer	GeneralNames,
        serialNumber	CertificateSerialNumber
        issuerUID	UniqueIdentifier OPTIONAL }

Where the fields of IssuerSerial have the following meanings:

The issuer is the name of the Attribute Authority which signed the
attribute certificate.

The serialNumber is the serial number that uniquely identifies the
attribute certificate.

The issuerUID may be used to identify the issuer of the attribute
certificate in instances where the issuer name is not sufficient. This may
be required because of the use of GeneralNames to identify the issuer.

Note that all these fields already exist in ACs.

Francois Rousseau

From: James M Hayes <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Charter Change Request
Date: Wed, 6 May 1998 13:40:37 -0400
Sender: [email-masked]

I neglected to say that the hash would be SHA-1!

----------
From:  James M Hayes[SMTP:[email-masked]]
Sent:  Wednesday, May 06, 1998 1:33 PM
To:  [email-masked]
Subject:  FW: Charter Change Request

Hello All,

This email was sent to me concerning item 2 of the Charter Change.  I am =
new to the list so I'm not familiar with all of the on going issues.  I =
have been looking at attribute certificates and how to bind them to base =
certificates (signing certificates?). =20

James,

Please see item 2 below...

Jean

----------
From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
Sent:  Friday, May 01, 1998 7:48 PM
To:  Ietf-Smime (E-mail)
Subject:  Charter Change Request

>I am proposing a pair of charter changes to deal with the two new =
drafts
>which the working group decided it wanted to look at during the March =
IETF
>meeting. These drafts are:
>1.  A draft to address methods of publishing certificates with =
authenticated
>attributes in directories.
>2.  A draft proposing a new authenticated attribute which carries the =
issuer
>and serial number fields to more tightly bind the signing certificate =
into
>the signature itself.

The binding between an attribute certificate and a X.509 v3 certificate =
in a multiroot environment may not be unique.  The current X.509 =
standard calls for a binding based on either the subjectName or issuer =
name and serial number.  The proposed Charter Change Request would use =
the latter.  A proposed binding of issuer name and serial number may not =
be unique in the context of a certificate masquerade.  Let me use an =
example before I get into defining a proposed "relatively" unique =
binding.

Let's say you have CA A and CA B.  In addition let's say CA B is =
initially a good CA but turns bad and it doesn't use name constraints.  =
CA A has the ability to issue attribute certificates to both CA A and CA =
B clients and CA B does not.  Now, let's say that there's a server out =
on the Internet that will allow access to users who have X.509 v3 =
certificates signed by CA A and CA B and attribute certificates signed =
by CA A.

CA B creates a subordinate "CA A" or cross certifies with a its own root =
"CA A".  CA B's CA A has the exact same DN and serial number as the real =
CA A.  CA B can now issue "CA A" certificates that correspond to the =
correct serial numbers as the real CA A certificates.  They don't even =
have to be the same subject names.  CA B goes through all this trouble =
so that its clients can have the same kinds of privileges as the real CA =
A's clients.  Each of CA B's CA A client certificates can be said to be =
bound to the same attribute certificates as the real CA A clients.  In =
order to compensate for this vulnerability, the server would have to =
implement rules of its own to stop the X.509 v3 certificates from CA B's =
CA A from being bound to the attribute certificates issued by the real =
CA A.  Not a very nice programming task.

Ideally, we would like the certificate framework to define a relatively =
"unique" binding between the X.509 v3 base certificate and the attribute =
certificate.  The Charter IMHO should use the optional issuerUID  to =
bind the base certificate with the attribute certificate.  It could be =
defined as follows:
{issuerUID Uniqueidentifier}
where Uniqueidentifier ::=3DSEQUENCE{publicKeyThumbprint =
DD{SubjectPublicKeyInfo{SupportedAlgorithms}}}

This solution too is implementation dependent.  What would be nice would =
be to modify X.509 to include a BaseCertKeyID and define subject CHOICE =
as follows:

subject CHOICE{
         baseCertificateID [0] IssuerSerial,                     =
--associated with a PK certificate
         subjectName       [1] GeneralNames,                --associated =
with a name
         BaseCertKeyID   [2] HashedPublicKeySyntax, --associated with a =
PK}

HashedPublicKeySyntax ::=3DSEQUENCE{publicKeyThumbprint DD =
{SubjectPublicKeyInfo{SupportedAlgorithms}}}

What's nice about the new binding is that it requires no modifications =
to implementations if the environment goes from a single root to a =
multiple root environment.

Hope this clarifies the case for establishing a different way to bind AC =
and base certificates.  Please excuse any ASN.1 notation errors.  I do =
not know it and used cut and paste to illustrate my point.

=20
>The charter changes are a new paragraph (paragraph #3) and a new =
sentence at
>the end of paragraph #2
=20
>The S/MIME Working Group will define MIME encapsulation of digitally =
signed
>and encrypted objects whose format is based on PKCS #7. [1] X.509
>Certificates and CRLs as profiled by the existing PKIX Working Group =
will be
>used to support authentication and key management. The Working Group =
will
>base its work on the S/MIME version 2 specification (available from RSA =
Data
>Security), but the Working Group will be free to change any part of =
that
>specification. In particular, the Working Group will prepare a new =
document
>that allows algorithm independence, based on PKCS #7 1.5.=20

>The message syntax specification, based on PKCS #7 version 1.5, will be
>expanded to allow additional key signature and key exchange algorithms. =
The
>message and certificate specifications will be revised to allow them to
>become standards. The optional security extensions document will =
specify
>protocols that allow for additional security features, such as signed
>message receipts.  An optional specification will provide an =
authenticated
>attribute to provide for tight binding of the signing certificate to a
>signature.=20

>The S/MIME Working Group will define methods of publishing certificates =
in
>public repositories with the aim of  maximizing the ability to send
>encrypted and signed mail between two parties without prior direct
>negotiation between the parties.=20

>The S/MIME Working Group will attempt to coordinate its efforts with =
the
>OpenPGP Working Group in areas where the work of the two groups =
overlap,
>particularly in specification of cryptographic algorithms and MIME
>structure.=20

>[1] RSA Data Security publishes the PKCS Series of documents. RSA Data
>Security has permitted the IETF to publish them as Informational RFCs =
as
>well as to extend and enhance them.=20

JAMES M HAYES, Capt, USAF
Information Warfare Research Manager
National Security Agency

From: James M Hayes <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: FW: Charter Change Request
Date: Wed, 6 May 1998 13:33:28 -0400
Sender: [email-masked]

Hello All,

This email was sent to me concerning item 2 of the Charter Change.  I am =
new to the list so I'm not familiar with all of the on going issues.  I =
have been looking at attribute certificates and how to bind them to base =
certificates (signing certificates?). =20

James,

Please see item 2 below...

Jean

----------
From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
Sent:  Friday, May 01, 1998 7:48 PM
To:  Ietf-Smime (E-mail)
Subject:  Charter Change Request

>I am proposing a pair of charter changes to deal with the two new =
drafts
>which the working group decided it wanted to look at during the March =
IETF
>meeting. These drafts are:
>1.  A draft to address methods of publishing certificates with =
authenticated
>attributes in directories.
>2.  A draft proposing a new authenticated attribute which carries the =
issuer
>and serial number fields to more tightly bind the signing certificate =
into
>the signature itself.

The binding between an attribute certificate and a X.509 v3 certificate =
in a multiroot environment may not be unique.  The current X.509 =
standard calls for a binding based on either the subjectName or issuer =
name and serial number.  The proposed Charter Change Request would use =
the latter.  A proposed binding of issuer name and serial number may not =
be unique in the context of a certificate masquerade.  Let me use an =
example before I get into defining a proposed "relatively" unique =
binding.

Let's say you have CA A and CA B.  In addition let's say CA B is =
initially a good CA but turns bad and it doesn't use name constraints.  =
CA A has the ability to issue attribute certificates to both CA A and CA =
B clients and CA B does not.  Now, let's say that there's a server out =
on the Internet that will allow access to users who have X.509 v3 =
certificates signed by CA A and CA B and attribute certificates signed =
by CA A.

CA B creates a subordinate "CA A" or cross certifies with a its own root =
"CA A".  CA B's CA A has the exact same DN and serial number as the real =
CA A.  CA B can now issue "CA A" certificates that correspond to the =
correct serial numbers as the real CA A certificates.  They don't even =
have to be the same subject names.  CA B goes through all this trouble =
so that its clients can have the same kinds of privileges as the real CA =
A's clients.  Each of CA B's CA A client certificates can be said to be =
bound to the same attribute certificates as the real CA A clients.  In =
order to compensate for this vulnerability, the server would have to =
implement rules of its own to stop the X.509 v3 certificates from CA B's =
CA A from being bound to the attribute certificates issued by the real =
CA A.  Not a very nice programming task.

Ideally, we would like the certificate framework to define a relatively =
"unique" binding between the X.509 v3 base certificate and the attribute =
certificate.  The Charter IMHO should use the optional issuerUID  to =
bind the base certificate with the attribute certificate.  It could be =
defined as follows:
{issuerUID Uniqueidentifier}
where Uniqueidentifier ::=3DSEQUENCE{publicKeyThumbprint =
DD{SubjectPublicKeyInfo{SupportedAlgorithms}}}

This solution too is implementation dependent.  What would be nice would =
be to modify X.509 to include a BaseCertKeyID and define subject CHOICE =
as follows:

subject CHOICE{
         baseCertificateID [0] IssuerSerial,                     =
--associated with a PK certificate
         subjectName       [1] GeneralNames,                --associated =
with a name
         BaseCertKeyID   [2] HashedPublicKeySyntax, --associated with a =
PK}

HashedPublicKeySyntax ::=3DSEQUENCE{publicKeyThumbprint DD =
{SubjectPublicKeyInfo{SupportedAlgorithms}}}

What's nice about the new binding is that it requires no modifications =
to implementations if the environment goes from a single root to a =
multiple root environment.

Hope this clarifies the case for establishing a different way to bind AC =
and base certificates.  Please excuse any ASN.1 notation errors.  I do =
not know it and used cut and paste to illustrate my point.

=20
>The charter changes are a new paragraph (paragraph #3) and a new =
sentence at
>the end of paragraph #2
=20
>The S/MIME Working Group will define MIME encapsulation of digitally =
signed
>and encrypted objects whose format is based on PKCS #7. [1] X.509
>Certificates and CRLs as profiled by the existing PKIX Working Group =
will be
>used to support authentication and key management. The Working Group =
will
>base its work on the S/MIME version 2 specification (available from RSA =
Data
>Security), but the Working Group will be free to change any part of =
that
>specification. In particular, the Working Group will prepare a new =
document
>that allows algorithm independence, based on PKCS #7 1.5.=20

>The message syntax specification, based on PKCS #7 version 1.5, will be
>expanded to allow additional key signature and key exchange algorithms. =
The
>message and certificate specifications will be revised to allow them to
>become standards. The optional security extensions document will =
specify
>protocols that allow for additional security features, such as signed
>message receipts.  An optional specification will provide an =
authenticated
>attribute to provide for tight binding of the signing certificate to a
>signature.=20

>The S/MIME Working Group will define methods of publishing certificates =
in
>public repositories with the aim of  maximizing the ability to send
>encrypted and signed mail between two parties without prior direct
>negotiation between the parties.=20

>The S/MIME Working Group will attempt to coordinate its efforts with =
the
>OpenPGP Working Group in areas where the work of the two groups =
overlap,
>particularly in specification of cryptographic algorithms and MIME
>structure.=20

>[1] RSA Data Security publishes the PKCS Series of documents. RSA Data
>Security has permitted the IETF to publish them as Informational RFCs =
as
>well as to extend and enhance them.=20

JAMES M HAYES, Capt, USAF
Information Warfare Research Manager
National Security Agency

Date: Wed, 6 May 1998 11:54:59 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-05 comments - MLA withdrawal of a signed receipt  request.
Sender: [email-masked]

All,

I don't object to adding the following text to ESS:  "In the event that a
ML's signed receipt policy supersedes the originator's request for signed
receipts such that the originator will not receive any signed receipts, then
the MLA MAY inform the originator of that fact."

I would object to this being a SHOULD or MUST requirement.

- John Pawling

At 09:49 AM 5/6/98 -0400, Capt Y. Theriault wrote:
>I do not see why the originator should not be informed of his/her denied
>request to receive signed receipts.  Assuming that there were good reasons
>to deny the user of such an information, there are other occasions where
>these reasons would not apply.   It would be nice for the originator to be
>informed of the denial so that no receipts are expected.
>
>Yves Th=E9riault.
>

Date: Wed, 6 May 1998 11:49:48 -0400
To: Elliott Ginsburg <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-05 comments 
Cc: [email-masked]
Sender: [email-masked]

Elliott,

The MLA can decrypt the message and locate the fields in the message or
header to support the exempted address just as it can with a non-encrypted
message. 

- John Pawling

At 09:42 AM 5/6/98 -0400, Elliott Ginsburg wrote:
>There is no disagreement that exempted addresses are not in general a
>security feature. However, the security protocol needs to serve the needs
>of those agents which process secured messages. In the case of a mail list
>expander, in the absence of a secured message, it can expand a message and
>support the use of exempted addresses which are embedded somewhere in the
>message or header and it can change headers to indicate removal of
>addressees, etc. However, for an encrypted message, the expander needs
>protocol elements to carry exempted addresses if it is to be able to supply
>this service to secured messages. 
>
>After all, why else do we have an extension for mlExpansionHistory if not
>to support the expansion service for secured messages?
>
>elliott
>
>
>
>
>At 08:00 AM 5/6/98 , John Pawling wrote:
>>All,
>>
>>I still disagree with adding the ML exempted address feature to CMS or ESS.
>>This service does not belong in any security protocol.  If a user
>>organization needs this service then they can implement it without adding
>>unneeded complexity to the security protocol.
>>
>>================================
>>John Pawling, [email-masked]                             
>>J.G. Van Dyke & Associates, Inc.   
>>www.jgvandyke.com         
>>================================
>> 
>
>

Date: Wed, 06 May 1998 09:49:58 -0400
To: [email-masked] (John Pawling), [email-masked]
From: "Capt Y. Theriault" <[email-masked]>
Subject: Re: ESS-05 comments - MLA withdrawal of a signed receipt request.
Sender: [email-masked]

I do not see why the originator should not be informed of his/her denied
request to receive signed receipts.  Assuming that there were good reasons
to deny the user of such an information, there are other occasions where
these reasons would not apply.   It would be nice for the originator to be
informed of the denial so that no receipts are expected.

Yves Th=E9riault.

At 11:37 AM 5/5/98 -0400, John Pawling wrote:
>Capt. Theriault:
>
>I have a few comments regarding your questions/proposals:
>
>1) It is not always the case that the originator should be advised of the
>MLA withdrawing her request for signed receipts; therefore, I believe that
>the ESS text is fine the way that it is.
>

>At 03:20 PM 5/1/98 -0400, Capt Y. Theriault wrote:
>>1)Sect 4.4 states that the "The receipt policy of the ML can withdraw the
>>originator's request for the return of a signed receipt."
>>
>>Shouldn't the originator be advised of this withdrawal?  The User Agent
>>might try to keep status information on messages requiring a signed=
 receipt
>>without knowing that a receipt will never arrive.  The MLA could send the
>>originator some kind of signed receipt to warn the User Agent and the
>>originator.
>>
>>2)Some organizations require that some mailing list members be exempted to
>>receive a message distributed by a mailing list agent.  I suggest to=
 modify
>>the MLData type as follows:
>>
>>MLData ::=3D SEQUENCE {
>>	mailListIdentifier EntityIdentifier,
>>		--EntityIdentifier is imported from [CMS]
>>	expansionTime GeneralizedTime,
>>	mlReceiptPolicy MLReceiptPolicy OPTIONAL,
>>	exemptedAddress	SEQUENCE OF GeneralNames OPTIONAL}
>>
>>If exemptedAddress exists the MLA should remove the recipients identified
>>by GeneralNames.
>>Capt Y. Theriault
>>National Defence Headquarters
>>PMO Defence Message Handling System Hardware Engineer
>>MGen R. Pearkes Building, Ottawa K1A 0K2
>>office:  (613) 995-6476
>>email:	 [email-masked]
>>
>
>
>
Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

Date: Wed, 06 May 1998 09:48:55 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
CC: "[email-masked]" <[email-masked]>
Subject: Re: Charter Change Request
Sender: [email-masked]

Dr Stephen Henson wrote:
> 
> I respectfully disagree with the idea that S/MIME supported algorithms
> should be handled by PKIX for the reasons below.
> 
> According to my understanding the PKIX solutions involve a certificate
> extension that is signed by an issuing authority.

A certificate does not list the algorithms supported by the recipient, only the algorithm which that particular certificate can be used for.

There is an attribute (supportAlgorithms) defined in the ASN.1 module, but it's not referenced in the specification in anyway.  The attribute was include, I believe, so that it could be put in a directory not carried in a certificate (somebody tell me if I'm wrong), presumably in the subjectDirectoryAttributes extension.

Maybe I'm not on the same wavelength, but I thought the user would need to know in advance of sending a message what algorithms the recipient supports for signature verification and encryption purposes.  Do you want to define a message that could be used by the originator to query the recipient about the algorithms she supports?  Or is the query directed at the directory?  If the query is aimed at the directory, I think it's already supported, the only thing left to determine is what information should be in the directory to retrieve the right certificate.  This is being performed in the PKIX group see "Internet X.509 Public Key Infrastructure LDAPv2 Schema", draft-ietf-pkix-ldapv2-schema-00.txt.

..snip...

Cheers

-- 
Sean Turner - IECA, Inc.

Date: Wed, 06 May 1998 09:47:32 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: Attribute Certificate(s) in S/MIME
Sender: [email-masked]

Hi All,

I will not try to identify the purpose for the use of Attribute
Certificates in S/MIME, however I can see ACs being used to provide an
authorization service for Electronic Commerce using S/MIME as its transport
mechanism. Signing a S/MIME transaction only provides the identity of a
user, it does NOT prove necessarily that this user had the privilege to
authorized this transaction. Although public key certificates can provide
such an authorization service directly if privileges are associated with
this user through the practices of the issuing Certificate Authority, it
can be more appropriate to dissociate privilege from identity. In such
cases, the AC can be the means by which the user's privileges are
expressed. Based on this, ACs are than required to convey, with
authenticity, integrity and currency, the privileges associated with a
user, in order that Verifiers can enforce the appropriate Control Policy on
signed S/MIME transactions.

Here is where the old working document on ACs from the ISO/ITU Directory
Working Group can be found, which provides a generic model for ACs use and
another model for the delegation of privileges through new extensions
specifically meant for ACs.

ftp://ftp.bull.com/pub/OSIdirectory/Helsinki97Output/21DIR4.DOC

Note that an updated version of this working document should be available
on that same site within the next few weeks.

Francois Rousseau

Date: Wed, 06 May 1998 09:42:55 -0400
To: [email-masked] (John Pawling)
From: Elliott Ginsburg <[email-masked]>
Subject: Re: ESS-05 comments 
Cc: [email-masked]
Sender: [email-masked]

There is no disagreement that exempted addresses are not in general a
security feature. However, the security protocol needs to serve the needs
of those agents which process secured messages. In the case of a mail list
expander, in the absence of a secured message, it can expand a message and
support the use of exempted addresses which are embedded somewhere in the
message or header and it can change headers to indicate removal of
addressees, etc. However, for an encrypted message, the expander needs
protocol elements to carry exempted addresses if it is to be able to supply
this service to secured messages. 

After all, why else do we have an extension for mlExpansionHistory if not
to support the expansion service for secured messages?

elliott

At 08:00 AM 5/6/98 , John Pawling wrote:
>All,
>
>I still disagree with adding the ML exempted address feature to CMS or ESS.
>This service does not belong in any security protocol.  If a user
>organization needs this service then they can implement it without adding
>unneeded complexity to the security protocol.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
> 

Date: Wed, 06 May 1998 09:39:00 -0400
From: "Bonatti, Chris" <[email-masked]>
Organization: IECA, Inc.
To: John Pawling <[email-masked]>
CC: [email-masked], Elliott Ginsburg <[email-masked]>
Subject: Re: ESS-05 comments
Sender: [email-masked]

    Sorry, John.  I have to side with Elliot's statment here.  If the "security protocol" need only look at "security features" then why look at list expansion at all?  The answer is that obviously the security protocol has a direct effect on non-security features.  Ergo, you have to accept some level of non-security baggage in the interest of functionality.

    Exempted addresses are a mail feature that makes good functional sense.  I think it is finding it's way into most definitions of "business grade messaging".  It would be wise for us to support it, I think.

Chris

__________________

John Pawling wrote:

> All,
>
> I still disagree with adding the ML exempted address feature to CMS or ESS.
> This service does not belong in any security protocol.  If a user
> organization needs this service then they can implement it without adding
> unneeded complexity to the security protocol.
>
> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================

Elliott Ginsburg wrote:

> I don't see why it is 'bad protocol practice'. If a remote service (in this
> case an ML expander) offers a certain service, it is the job of the
> protocol to
> allow the service to be requested.
>
> In an environment where there are a large number of MLs, ML management becomes
> a problem; having to create and maintain variants for each is untenable and
> would in effect guarantee that they were not maintained well (as, for
> instance,
> when someone should be removed). It is perfectly reasonable for a 'third party
> ( the ML expander) to offer a service which is an alternative to having to
> maintain variants.
>
> elliott ginsburg
>

Date: Wed, 06 May 1998 09:32:14 -0400
To: Sean Turner <[email-masked]>
From: "Capt Y. Theriault" <[email-masked]>
Subject: Re: ESS-05 comments - exempted addresses
Cc: [email-masked]
Sender: [email-masked]

At 08:35 AM 5/6/98 -0400, Sean Turner wrote:
>Paul Hoffman / IMC wrote:
>>=20
>> At 11:37 AM 5/5/98 -0400, John Pawling wrote:
>> >I believe that if the originator does
>> >not want to send the message to the entire ML, then it is the=
 originator's
>> >responsibility to construct a separate ML including the desired=
 recipients
>> >or to compose a list of the individual recipients (i.e. not use an ML at
>> all).
>>=20
>> John's right here. It is bad protocol practice to say to a remote=
 processor
>> "here's what I want you to do" when you can cause the same actions
yourself.
>>=20
>> --Paul Hoffman, Director
>> --Internet Mail Consortium
>
>Paul,
>
>The problem is that if the list is quite large the burden placed on the
user could be too much for them to handle.  Besides the originator may not
know all the recipients - they might know that it's a community of people
but not all the people in the community.  With that said ...
>
>I'm not thinking about this in terms of a "security function" because if
you don't want a recipient to get the message then some form of access
control should be employed.  I'm a thinking of it in a sense of I've got to
send a message to a community of people to arrange Sara's birthday party,
but since it's Sara's birthday party I don't want Sara to know about it so
I exempt her address.  Since it's not a security feature, in my mind, then
I agree with John P's that it should not be added in ESS or CMS.  I think
the idea is more applicable as a general heading field.=20
>
>I'm not sure Capt Y. Theriault and I were thinking of using it in the same
way so if we're not on the same wavelength let me know (I don't want to
misrepresent the Captain's motivations for exempted addresses).
>
>Cheers
>
>--=20
>Sean Turner - IECA, Inc.
>
>
All,

Mr. Turner's birthday party example reflects the requirement I had in mind.
 Some times it is useful to leave some organization/people out of a
discussion ( I am not saying that it is a nice thing to do, but this is a
service that is desired by a large community - the military community being
one).  I see the exempted address feature as a discretionary access control
security service since I am specifying who can see a message.
Consequently, the exempted address feature would logically belong to the=
 ESS.

Creating a new mailing list for an occasional situation is a big
administrative burden because you have to involve system
administration/security administration personnel.  The alternative of
listing every recipient is also very annoying if the mailing list is large.
 This is also the maintability issue as expressed Mr. Ginsburg.

Yves Th=E9riault.

Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

To: [email-masked] (John Pawling)
Cc: [email-masked], [email-masked]
Subject: Re: Attribute Certificate(s) in S/MIME 
Date: Wed, 06 May 1998 14:22:06 +0100
From: Stephen Farrell <[email-masked]>
Sender: [email-masked]

John,

> There is a requirement to bind a user's clearance (i.e.
> security-classification and security-categories) authorizations to her
> identity and public key.

Good - that's one use. (Mind you - it does seem to assume the
recipient's AC is long-lived, which not all authorization
policies would allow).

I guess another potential use of labels within ACs would be for a 
gateway to control message routing based on the originator AC and
other info.

A different scenario that may be relevant is a "permission to
publish" attribute, perhaps with a mail list name as its value. 
The intent would be that the mail list would only accept incoming 
messages where the originator has the required attribute(s). Now this
one may lead to some trickiness - firstly, it may be appropriate
for the mail list to remove the originator's AC (it could be
usable for lots of things which we don't want the entire list
to know about) and, secondly, multiple expansions could occur
meaning that different ACs may be needed at different stages.

The recent draft on "role" names might also be calling for
functionality which can be implemented using ACs.

I guess people will identify other potential uses of
ACs (even limiting ourselves to mail). The step after that
would presumably be to accept or reject the different
scenarios and then consider how best to pack the
ACs with the messages.

Regards,
Stephen.

Date: Wed, 06 May 1998 13:48:38 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Charter Change Request
Sender: [email-masked]

I respectfully disagree with the idea that S/MIME supported algorithms
should be handled by PKIX for the reasons below.

According to my understanding the PKIX solutions involve a certificate
extension that is signed by an issuing authority. 

The supported algorithms may change according to software, export laws,
or just plain user preference. There is indeed no reason why the S/MIME
supported algorithms should be the same as those for other purposes. If
the PKIX solution requires a new certificate (and possible expense)
whenever the supported algorithms change this is not very flexible.

I would presume the S/MIME proposal would involve very minor (if any)
changes to the current method of sending supported S/MIME algorithms in
the SMIMECapabilities authenticated attribute. One natural (to me
anyway) method is to use an empty message, (maybe with no certificates)
and dummy (or no) content and including a signing time in
SMIMECapabilities. The dummy content case involves no changes to CMS.

The S/MIME method has the advantage that it is under control of the
software and does not rely on an issuing authority. It is very similar
to the current method: all that would really be required would be to
feed in the "dummy message" from whatever source it came from into the
sofware as an ordinary S/MIME message with minor alterations.

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 06 May 1998 08:35:08 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked], "Capt Y. Theriault" <[email-masked]>
Subject: Re: ESS-05 comments
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 11:37 AM 5/5/98 -0400, John Pawling wrote:
> >I believe that if the originator does
> >not want to send the message to the entire ML, then it is the originator's
> >responsibility to construct a separate ML including the desired recipients
> >or to compose a list of the individual recipients (i.e. not use an ML at
> all).
> 
> John's right here. It is bad protocol practice to say to a remote processor
> "here's what I want you to do" when you can cause the same actions yourself.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Paul,

The problem is that if the list is quite large the burden placed on the user could be too much for them to handle.  Besides the originator may not know all the recipients - they might know that it's a community of people but not all the people in the community.  With that said ...

I'm not thinking about this in terms of a "security function" because if you don't want a recipient to get the message then some form of access control should be employed.  I'm a thinking of it in a sense of I've got to send a message to a community of people to arrange Sara's birthday party, but since it's Sara's birthday party I don't want Sara to know about it so I exempt her address.  Since it's not a security feature, in my mind, then I agree with John P's that it should not be added in ESS or CMS.  I think the idea is more applicable as a general heading field. 

I'm not sure Capt Y. Theriault and I were thinking of using it in the same way so if we're not on the same wavelength let me know (I don't want to misrepresent the Captain's motivations for exempted addresses).

Cheers

-- 
Sean Turner - IECA, Inc.

Date: Wed, 6 May 1998 08:19:46 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Attribute Certificate(s) in S/MIME
Sender: [email-masked]

Stephen,

There is a requirement to bind a user's clearance (i.e.
security-classification and security-categories) authorizations to her
identity and public key.  One method to do this is to include the user's
clearance authorizations in an AC that is bound to the user's X.509
certificate which binds the user's identity with her digital signature
public key.  When an originator wants to send a sensitive message to a
recipient, then the originator would obtain and validate the recipient's
X.509 cert and AC.  The originator selects the ESSSecurityLabel
security-classification and security-category values required to label the
content.  The originator ensures that the recipient's AC contains the
appropriate clearance authorizations indicating that the recipient is
authorized to access data labeled with the originator-selected
ESSSecurityLabel security-classification and security-category values.  One
strategy is that the originator could send her X.509 cert and AC in the
signedData object.  The recipient can then use the originator's X.509 cert
and AC to verify the originator's signature and to ensure that the
originator's AC contains the appropriate clearance authorizations indicating
that the originator was authorized to send the data as labeled with the
ESSSecurityLabel security-classification and security-category values. 

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Wed, 6 May 1998 08:00:11 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-05 comments 
Sender: [email-masked]

All,

I still disagree with adding the ML exempted address feature to CMS or ESS.
This service does not belong in any security protocol.  If a user
organization needs this service then they can implement it without adding
unneeded complexity to the security protocol.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Wed, 06 May 1998 07:28:45 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Elliott Ginsburg <[email-masked]>
Subject: Re: ESS-05 comments 
Cc: [email-masked]
Sender: [email-masked]

I don't see why it is 'bad protocol practice'. If a remote service (in this
case an ML expander) offers a certain service, it is the job of the
protocol to
allow the service to be requested. 

In an environment where there are a large number of MLs, ML management becomes
a problem; having to create and maintain variants for each is untenable and
would in effect guarantee that they were not maintained well (as, for
instance,
when someone should be removed). It is perfectly reasonable for a 'third party
( the ML expander) to offer a service which is an alternative to having to
maintain variants.

elliott ginsburg

At 12:01 PM 5/5/98 , Paul Hoffman / IMC wrote: 
>
> At 11:37 AM 5/5/98 -0400, John Pawling wrote:
> >I believe that if the originator does
> >not want to send the message to the entire ML, then it is the originator's
> >responsibility to construct a separate ML including the desired recipients
> >or to compose a list of the individual recipients (i.e. not use an ML at
> all).
>
> John's right here. It is bad protocol practice to say to a remote processor
> "here's what I want you to do" when you can cause the same actions yourself.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Attribute Certificate(s) in S/MIME
Date: Wed, 06 May 1998 10:35:44 +0100
From: Stephen Farrell <[email-masked]>
Sender: [email-masked]

Hi All,

I'd like to ask two quick questions before this discussion gets 
too detailed.

What is (are) the purpose(s) for the use of ACs in S/MIME? What
assumptions exist about other CMS consumers?

Until this is clear, I don't believe that a particular syntax
for the bucket of stuff which includes ACs should be chosen.

One example supporting this is to do with providing AC based 
delegation control whilst at the same time preventing AC "stealing". 
If such delegation is required, (perhaps only as part of ESS, or 
for some mailing list cases, or maybe outside of S/MIME), then its 
pretty much for sure that simply sending the ACs of the originator 
isn't sufficient.

So, can we establish requirements before syntax?

Regards,
Stephen.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Usage of Diffe-Hellman keys
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 May 1998 16:20:37 (NZST)
Sender: [email-masked]

>Trying to put this into S/MIME context it seems that Diffie-Hellman keys may
>only be used in the way suggested by Russ Housley, i.e. for each recipient to
>take recipient's Diffie-Hellman certificate (key agreement certificate), get
>the public key from there, generate a shared key (Russ suggested 3DES) and use
>it to encrypt the content-encryption key.
>
>However, another possibility is to use El-Gamal algorithm with Diffie-Hellman
>keys and encrypt the content-encryption key directly with recipients
>Diffie-Hellman public key. This would be a very similar operation as if the
>recipient had RSA keys and keyEnchipherment certificate. This seems to be a
>much better way of using Diffie-Hellman keys, similar to the way RSA keys are
>used for keys encryption (unless I have missed some point here).
 
If you use the key this way then it's no longer DH but Elgamal, with its own 
algorithm/object identifiers and usage requirements.  For example some 
generators which are OK for Elgamal encryption aren't secure for Elgamal 
signatures, so if you've got DH-pretending-to-be-Elgamal (which PGP does, for 
example) you can't just use it as if it were Elgamal.  If you want to use a 
key for Elgamal encryption/signatures, you should really call it Elgamal, and 
not take a DH key and use it for something it was never designed for.
 
(If you want to get really nitpicky, there are actually three different 
 algorithms which use keys which look more or less the same: DH (key 
 exchange), Elgamal encryption == DH-Vernam encryption (encryption), and 
 Elgamal signatures (signature).  It'd be nicer to actually call it Elgamal
 rather than overload DH further and further)
 
Peter.

Date: Tue, 05 May 1998 14:51:05 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Cc: [email-masked]
Sender: [email-masked]

At 12:06 PM 5/5/98 -0400, Francois Rousseau wrote:
>Yes storing Attribute Certificates in the signedData certificates field
>will avoid the redundancy of having them repeated in each signer
>signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
>meant to help find the correct AC as suggested. It is meant to specify
>which signer's public key to use to verify the digital signature on the
>signedData eContent field. 

Agree, issuerAndSerialNumber is meant to identify the signature certificate
containing the signer's public key.  The attribute certificate (AC)
contains the same issuer and serial number field (or subject distinguished
name) linking it to the sigbature certificate.

>So when AC's are included in the signedData
>certificates CertificateSet, the receiving software can NOT still be sure
>to find the correct AC.

Zero or more ACs may be needed.  Zero is the easy case, but multiple AC
(potentially issued by different authorities) may bee needed in some context.

>It is even worst when AC's are NOT included in the
>signedData certificates CertificateSet to minimize the size of
>transactions, although AC's have been used with the signing process to
>provide an authorization service. The receiving software than has no means
>to know that AC's were used, and to find and retrieve the applicable AC
>during the later verification.

The recipient will determine which ACs are needed from the context.  The
recipient can readiy determine which ACs are linked to the signer's
signature certificate (as discussed above).

>It is recommended that a new CMSAttribute be added in the signerInfo
>authenticatedAttributes field to let the receiving software know that AC's
>were used along the signing process, and to help it find and retrieve the
>applicable AC for the later verification.

Given the linkage that is already present, why is this needed?

Russ

Date: Tue, 5 May 1998 13:07:03 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

> From: Francois Rousseau <[email-masked]>
> 
> Yes storing Attribute Certificates in the signedData certificates field
> will avoid the redundancy of having them repeated in each signer
> signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
> meant to help find the correct AC as suggested. It is meant to specify
> which signer's public key to use to verify the digital signature on the
> signedData eContent field.

As you say, issuerAndSerialNumber is meant to identify the signature
certificate containing the signer's public key.

However, the same issuer and serial number fields are used in the
AttributeCertificate's baseCertificateID to identify the same signer's
certificate.  So issuerAndSerialNumber uniquely identifies both the
signature certificate and the attribute certificate(s) which reference
it.

> So when AC's are included in the signedData
> certificates CertificateSet, the receiving software can NOT still be sure
> to find the correct AC.

I strongly disagree with the idea that there can be "correct" and
"incorrect" ACs.  Every valid AC which has been issued against a
particular base certificate is correct, i.e. the subject possesses
every attribute which has been issued to him, regardless of whether the
attributes are contained in the base certificate, one large attribute
cert, or a bunch of smaller attribute certs.

If an authorization service requires the presence of a particular
attribute, then it is sufficient that the subject possesses that
attribute.  The fact that the subject may also possess a number of
other attributes is not a factor in the authorization decision, i.e.
the other attributes are not "incorrect", they are merely ignored.

> It is even worst when AC's are NOT included in the
> signedData certificates CertificateSet to minimize the size of
> transactions, although AC's have been used with the signing process to
> provide an authorization service. The receiving software than has no means
> to know that AC's were used, and to find and retrieve the applicable AC
> during the later verification.

I agree that the receiver has no way of knowing that an AC was used if
it is not included in the CertificateSet.  That is an argument for
requiring that any applicable AC be included in CertificateSet.  To
enable the use of repositories so that the full AC doesn't need to
be carried in the message, I would support the addition of a reference to
CertificateChoices, which could contain a pointer to either a cert
or an attribute cert:

  CertificateChoices ::= CHOICE {
    certificate         Certificate,
    extendedCertificate [0] IMPLICIT ExtendedCertificate, -- obsolete
    attrCert            [1] IMPLICIT AttributeCertificate,
    certReference       [2] IMPLICIT IssuerAndSerialNumber }

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Reference to Applicable Attribute Certificate(s) within the CMS
Date: Tue, 5 May 1998 12:56:44 -0400
Sender: [email-masked]

> From: John Pawling <[email-masked]>
> To: [email-masked]
> Subject: Re: Reference to Applicable Attribute Certificate(s) within the
CMS
> Date: Tuesday, May 05, 1998 7:55 AM
> 
> All,
> 
> I believe that Attribute Certificates should be stored in the signedData
> certificates field.  The receiving software can find the correct AC in
the
> signedData certificates CertificateSet by matching the
issuerAndSerialNumber
> info in the signerInfo being verified with the issuerSerial field in the
AC.

But the issuerAndSerialNumber field points to the correct public key
certificate
(needed to verify the signature).  Do we need a new authenticated attribute
to convey the issuer/serial # (s) of any relevant attribute certificate(s)?

> I believe that it is more efficient to store the ACs in the signedData
> certificates field because the same signer's AC may be needed as part of
the
> process to verify multiple signerInfos in a signedData.  In that case,
the
> signer's AC is only stored once in the signedData certificates field
rather
> than redundantly in each signerInfo field.
> 
> ================================
> John Pawling, [email-masked]                             
> J.G. Van Dyke & Associates, Inc.   
> www.jgvandyke.com         
> ================================

Regards,
Rich

Date: Tue, 05 May 1998 12:06:27 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Finding and retrieving applicable Attribute Certificate(s)
Sender: [email-masked]

Yes storing Attribute Certificates in the signedData certificates field
will avoid the redundancy of having them repeated in each signer
signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
meant to help find the correct AC as suggested. It is meant to specify
which signer's public key to use to verify the digital signature on the
signedData eContent field. So when AC's are included in the signedData
certificates CertificateSet, the receiving software can NOT still be sure
to find the correct AC. It is even worst when AC's are NOT included in the
signedData certificates CertificateSet to minimize the size of
transactions, although AC's have been used with the signing process to
provide an authorization service. The receiving software than has no means
to know that AC's were used, and to find and retrieve the applicable AC
during the later verification.

It is recommended that a new CMSAttribute be added in the signerInfo
authenticatedAttributes field to let the receiving software know that AC's
were used along the signing process, and to help it find and retrieve the
applicable AC for the later verification.

Francois Rousseau
[email-masked]

>
>I believe that Attribute Certificates should be stored in the signedData
>certificates field.  The receiving software can find the correct AC in the
>signedData certificates CertificateSet by matching the issuerAndSerialNumber
>info in the signerInfo being verified with the issuerSerial field in the AC.
>I believe that it is more efficient to store the ACs in the signedData
>certificates field because the same signer's AC may be needed as part of the
>process to verify multiple signerInfos in a signedData.  In that case, the
>signer's AC is only stored once in the signedData certificates field rather
>than redundantly in each signerInfo field.
>
>================================
>John Pawling, [email-masked]                             
>J.G. Van Dyke & Associates, Inc.   
>www.jgvandyke.com         
>================================
>

Date: Tue, 05 May 1998 09:01:20 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: ESS-05 comments
Sender: [email-masked]

At 11:37 AM 5/5/98 -0400, John Pawling wrote:
>I believe that if the originator does
>not want to send the message to the entire ML, then it is the originator's
>responsibility to construct a separate ML including the desired recipients
>or to compose a list of the individual recipients (i.e. not use an ML at
all).

John's right here. It is bad protocol practice to say to a remote processor
"here's what I want you to do" when you can cause the same actions yourself.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 5 May 1998 11:37:57 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: ESS-05 comments
Sender: [email-masked]

Capt. Theriault:

I have a few comments regarding your questions/proposals:

1) It is not always the case that the originator should be advised of the
MLA withdrawing her request for signed receipts; therefore, I believe that
the ESS text is fine the way that it is.

2) I respecfully disagree with your proposal to add the exemptedAddress
field to MLData.  The MLData sequence is created by the MLA to include info
about the distribution of a message to an ML.  The field that you are
proposing would need to be filled in by the originating user and
communicated to the MLA before it decides to whom to send the message.  I do
not believe that the exemptedAddress requirement should be met by a field in
the CMS signedData security heading.  I believe that if the originator does
not want to send the message to the entire ML, then it is the originator's
responsibility to construct a separate ML including the desired recipients
or to compose a list of the individual recipients (i.e. not use an ML at all).

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 03:20 PM 5/1/98 -0400, Capt Y. Theriault wrote:
>1)Sect 4.4 states that the "The receipt policy of the ML can withdraw the
>originator's request for the return of a signed receipt."
>
>Shouldn't the originator be advised of this withdrawal?  The User Agent
>might try to keep status information on messages requiring a signed receipt
>without knowing that a receipt will never arrive.  The MLA could send the
>originator some kind of signed receipt to warn the User Agent and the
>originator.
>
>2)Some organizations require that some mailing list members be exempted to
>receive a message distributed by a mailing list agent.  I suggest to modify
>the MLData type as follows:
>
>MLData ::= SEQUENCE {
>	mailListIdentifier EntityIdentifier,
>		--EntityIdentifier is imported from [CMS]
>	expansionTime GeneralizedTime,
>	mlReceiptPolicy MLReceiptPolicy OPTIONAL,
>	exemptedAddress	SEQUENCE OF GeneralNames OPTIONAL}
>
>If exemptedAddress exists the MLA should remove the recipients identified
>by GeneralNames.
>Capt Y. Theriault
>National Defence Headquarters
>PMO Defence Message Handling System Hardware Engineer
>MGen R. Pearkes Building, Ottawa K1A 0K2
>office:  (613) 995-6476
>email:	 [email-masked]
>

Date: Tue, 05 May 1998 11:22:13 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Charter Change Request
Sender: [email-masked]

All,

There is an attribute called supportedAlgorithms in X.509 (section 12.2.2.7).  If it meets our needs, we should propose that it be added to the PKIX schema to support SMIME.

Cheers,

-- 
Sean Turner - IECA, Inc.

Bob Jueneman wrote:
> 
> The issue of providing a list of supported algorithms is quite
> reasonable, and should be an request from this group to the PKIX
> group, just as they agreed to defer to this group for a solution
> to the problem of uniquely identifying of which particular
> certificate should be used to validate a certificate.
> 
> Likewise, if it isn't there yet, we need an ability to upwards reference
> a certificate chain (issuer cert) beginning with the digital signature
> itself, and chaining back through all of the certs.  It hink that the
> revised format for authority KeyId is join to solve that problem within
> the certificates, but I haven't followed this thread closely
> enough to know that it is solved within the signature itself.
> 
> Bob
> 
> >Marc Branchaud wrote:
> >>
> >>
> >> Isn't PKIX doing this already?  Does the stated goal ("maximizing...")
> >> require more than what PKIX is doing?
> >>
> >>                 Marc
> >>
> >
> >The last time I looked at the PKIX stuff it didn't include a way to
> >state supported ciphers (someone please correct me if I'm wrong) e.g.
> >via some SMIMECapabilities variant.
> >
> >If you just have the certificate via (e.g.) LDAP then you can't be sure
> >what ciphers are supported by the recipient: considering the SMIME v3/v2
> >differences in mandatory ciphers (3DES and RC2-40) this is important
> >IMHO.
> >
> >Currently I think the only way to be sure is to send plaintext to the
> >recipient and get something signed in return including the capabilities.
> >This makes the directory certificate of little use: you could've done
> >that with just the email address.
> >
> >--
> >Dr Stephen N. Henson.
> >UK based freelance Cryptographic Consultant. For info see homepage.
> >Homepage: http://www.drh-consultancy.demon.co.uk/
> >Email: [email-masked]
> >PGP key: via homepage.
> >
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
> 
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
> 
> "The most dangerous strategy is to cross a chasm in two jumps."

Date: Tue, 5 May 1998 07:55:25 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Reference to Applicable Attribute Certificate(s) within the CMS
Sender: [email-masked]

All,

I believe that Attribute Certificates should be stored in the signedData
certificates field.  The receiving software can find the correct AC in the
signedData certificates CertificateSet by matching the issuerAndSerialNumber
info in the signerInfo being verified with the issuerSerial field in the AC.
I believe that it is more efficient to store the ACs in the signedData
certificates field because the same signer's AC may be needed as part of the
process to verify multiple signerInfos in a signedData.  In that case, the
signer's AC is only stored once in the signedData certificates field rather
than redundantly in each signerInfo field.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Tue, 05 May 1998 12:33:51 +0200
To: "Jim Schaad (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: RE: Charter Change Request
Sender: [email-masked]

At 13:02 5/4/98 -0700, Jim Schaad (Exchange) wrote:
>It certianly could include other access methods than LDAP, and that is why I
>wrote the statment the way that I did.  I currently am only planning to
>address LDAP (and maybe X500 style directories) but the document could
>easily be expanded if necessary.

PKIX has already published a draft 
"Internet X.509 Public Key Infrastructure LDAPv2 Schema" 
available on 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt
so I do not see a need for something like that in S/MIME.

Regards,

Nada

>
>-----Original Message-----
>From: Dr Stephen Henson [mailto:[email-masked]]
>Sent: Saturday, May 02, 1998 3:09 PM
>To: Ietf-Smime (E-mail)
>Subject: Re: Charter Change Request
>
>
>Jim Schaad (Exchange) wrote:
>> 
>> The S/MIME Working Group will define methods of publishing certificates in
>> public repositories with the aim of  maximizing the ability to send
>> encrypted and signed mail between two parties without prior direct
>> negotiation between the parties.
>> 
>
>Does "public repositories" include http (and ftp maybe too)? I feel it
>would be a good idea to handle (for example) the ability to incorporate
>certificates and attributes into a web page (with appropriate MIME type)
>at the same time. 
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
>

Date: Mon, 04 May 1998 20:03:03 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Charter Change Request
Sender: [email-masked]

The issue of providing a list of supported algorithms is quite=20
reasonable, and should be an request from this group to the PKIX=20
group, just as they agreed to defer to this group for a solution=20
to the problem of uniquely identifying of which particular=20
certificate should be used to validate a certificate.

Likewise, if it isn't there yet, we need an ability to upwards reference
a certificate chain (issuer cert) beginning with the digital signature=20
itself, and chaining back through all of the certs.  It hink that the=20
revised format for authority KeyId is join to solve that problem within=20
the certificates, but I haven't followed this thread closely
enough to know that it is solved within the signature itself.

Bob

>Marc Branchaud wrote:
>>=20
>>=20
>> Isn't PKIX doing this already?  Does the stated goal ("maximizing...")
>> require more than what PKIX is doing?
>>=20
>>                 Marc
>>=20
>
>The last time I looked at the PKIX stuff it didn't include a way to
>state supported ciphers (someone please correct me if I'm wrong) e.g.
>via some SMIMECapabilities variant.=20
>
>If you just have the certificate via (e.g.) LDAP then you can't be sure
>what ciphers are supported by the recipient: considering the SMIME v3/v2
>differences in mandatory ciphers (3DES and RC2-40) this is important
>IMHO.
>
>Currently I think the only way to be sure is to send plaintext to the
>recipient and get something signed in return including the capabilities.=
=20
>This makes the directory certificate of little use: you could've done
>that with just the email address.
>
>--=20
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/=20
>Email: [email-masked]=20
>PGP key: via homepage.
>

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,=20
although a step in the right direction, will not prove=20
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date: Mon, 04 May 1998 23:40:56 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Charter Change Request
Sender: [email-masked]

Marc Branchaud wrote:
> 
> 
> Isn't PKIX doing this already?  Does the stated goal ("maximizing...")
> require more than what PKIX is doing?
> 
>                 Marc
> 

The last time I looked at the PKIX stuff it didn't include a way to
state supported ciphers (someone please correct me if I'm wrong) e.g.
via some SMIMECapabilities variant. 

If you just have the certificate via (e.g.) LDAP then you can't be sure
what ciphers are supported by the recipient: considering the SMIME v3/v2
differences in mandatory ciphers (3DES and RC2-40) this is important
IMHO.

Currently I think the only way to be sure is to send plaintext to the
recipient and get something signed in return including the capabilities. 
This makes the directory certificate of little use: you could've done
that with just the email address.

-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

To: "Jim Schaad (Exchange)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Charter Change Request 
Date: Mon, 04 May 1998 14:43:42 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

"Jim Schaad (Exchange)" <[email-masked]> scrawled:
> 
> The S/MIME Working Group will define methods of publishing certificates in
> public repositories with the aim of  maximizing the ability to send
> encrypted and signed mail between two parties without prior direct
> negotiation between the parties.
> 

Isn't PKIX doing this already?  Does the stated goal ("maximizing...") 
require more than what PKIX is doing?

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Charter Change Request
Date: Mon, 4 May 1998 13:02:54 -0700 
Sender: [email-masked]

It certianly could include other access methods than LDAP, and that is why I
wrote the statment the way that I did.  I currently am only planning to
address LDAP (and maybe X500 style directories) but the document could
easily be expanded if necessary.

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]]
Sent: Saturday, May 02, 1998 3:09 PM
To: Ietf-Smime (E-mail)
Subject: Re: Charter Change Request

Jim Schaad (Exchange) wrote:
> 
> The S/MIME Working Group will define methods of publishing certificates in
> public repositories with the aim of  maximizing the ability to send
> encrypted and signed mail between two parties without prior direct
> negotiation between the parties.
> 

Does "public repositories" include http (and ftp maybe too)? I feel it
would be a good idea to handle (for example) the ability to incorporate
certificates and attributes into a web page (with appropriate MIME type)
at the same time. 

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 4 May 1998 12:30:48 -0400
To: "Ietf-Smime (E-mail)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Charter Change Request
Sender: [email-masked]

All,

I concur with Jim's proposal.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

Date: Sat, 02 May 1998 23:08:59 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Re: Charter Change Request
Sender: [email-masked]

Jim Schaad (Exchange) wrote:
> 
> The S/MIME Working Group will define methods of publishing certificates in
> public repositories with the aim of  maximizing the ability to send
> encrypted and signed mail between two parties without prior direct
> negotiation between the parties.
> 

Does "public repositories" include http (and ftp maybe too)? I feel it
would be a good idea to handle (for example) the ability to incorporate
certificates and attributes into a web page (with appropriate MIME type)
at the same time. 

Steve.
-- 
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Charter Change Request
Date: Fri, 1 May 1998 16:48:07 -0700 
Sender: [email-masked]

I am proposing a pair of charter changes to deal with the two new =
drafts
which the working group decided it wanted to look at during the March =
IETF
meeting. These drafts are:
1.=A0 A draft to address methods of publishing certificates with =
authenticated
attributes in directories.
2.=A0 A draft proposing a new authenticated attribute which carries the =
issuer
and serial number fields to more tightly bind the signing certificate =
into
the signature itself.
=A0
The charter changes are a new paragraph (paragraph #3) and a new =
sentence at
the end of paragraph #2
=A0
The S/MIME Working Group will define MIME encapsulation of digitally =
signed
and encrypted objects whose format is based on PKCS #7. [1] X.509
Certificates and CRLs as profiled by the existing PKIX Working Group =
will be
used to support authentication and key management. The Working Group =
will
base its work on the S/MIME version 2 specification (available from RSA =
Data
Security), but the Working Group will be free to change any part of =
that
specification. In particular, the Working Group will prepare a new =
document
that allows algorithm independence, based on PKCS #7 1.5.=20

The message syntax specification, based on PKCS #7 version 1.5, will be
expanded to allow additional key signature and key exchange algorithms. =
The
message and certificate specifications will be revised to allow them to
become standards. The optional security extensions document will =
specify
protocols that allow for additional security features, such as signed
message receipts.=A0 An optional specification will provide an =
authenticated
attribute to provide for tight binding of the signing certificate to a
signature.=20

The S/MIME Working Group will define methods of publishing certificates =
in
public repositories with the aim of=A0 maximizing the ability to send
encrypted and signed mail between two parties without prior direct
negotiation between the parties.=20

The S/MIME Working Group will attempt to coordinate its efforts with =
the
OpenPGP Working Group in areas where the work of the two groups =
overlap,
particularly in specification of cryptographic algorithms and MIME
structure.=20

[1] RSA Data Security publishes the PKCS Series of documents. RSA Data
Security has permitted the IETF to publish them as Informational RFCs =
as
well as to extend and enhance them.=20

Date: Fri, 01 May 1998 15:20:55 -0400
To: [email-masked]
From: "Capt Y. Theriault" <[email-masked]>
Subject: ESS-05 comments
Sender: [email-masked]

1)Sect 4.4 states that the "The receipt policy of the ML can withdraw the
originator's request for the return of a signed receipt."

Shouldn't the originator be advised of this withdrawal?  The User Agent
might try to keep status information on messages requiring a signed receipt
without knowing that a receipt will never arrive.  The MLA could send the
originator some kind of signed receipt to warn the User Agent and the
originator.

2)Some organizations require that some mailing list members be exempted to
receive a message distributed by a mailing list agent.  I suggest to modify
the MLData type as follows:

MLData ::= SEQUENCE {
	mailListIdentifier EntityIdentifier,
		--EntityIdentifier is imported from [CMS]
	expansionTime GeneralizedTime,
	mlReceiptPolicy MLReceiptPolicy OPTIONAL,
	exemptedAddress	SEQUENCE OF GeneralNames OPTIONAL}

If exemptedAddress exists the MLA should remove the recipients identified
by GeneralNames.
Capt Y. Theriault
National Defence Headquarters
PMO Defence Message Handling System Hardware Engineer
MGen R. Pearkes Building, Ottawa K1A 0K2
office:  (613) 995-6476
email:	 [email-masked]

Date: Fri, 01 May 1998 13:57:44 +0100
To: Francois Rousseau <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Reference to Applicable Attribute Certificate(s) within the CMS
Cc: [email-masked]
Sender: [email-masked]

At 16:17 30/04/98 -0400, Francois Rousseau wrote:
>Refs: A. ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8: 1997,
>Information Technology-Open Systems Interconnections - The Directory:
>Authentication Framework

I purchased X.509 from the ITU site just a couple of days ago, and the
version I received was (1993).  Where does this (1997) version fit in the
scheme of things?

#g

------------
Graham Klyne

Organization: ESAT, K.U.Leuven, Belgium
From: "Mark Vandenwauver" <[email-masked]>
To: <[email-masked]>, "Francois Rousseau" <[email-masked]>
Subject: Re: Reference to Applicable Attribute Certificate(s) within the CMS
Date: Fri, 1 May 1998 11:28:09 +0200
Sender: [email-masked]

How about the Privilege Attribute Certificate defined in ECMA 219
and implemented in the SESAME (http://www.esat.kuleuven.ac.be/cosic/sesame)
architecture ?

@MISC{ECMA21996,
  author = "{ECMA 219}",
  title = "{ECMA}-219 {S}ecurity in {O}pen {S}ystems -
              {A}uthentication and {P}rivilege {A}ttribute {S}ecurity
              {A}pplication with {R}elated {K}ey {D}istribution
{F}unctionality, 2nd {E}dition",
  note = "European Computer Manufacturers Association",
  month = "March",
  year = 1996
}

Mark

-----Original Message-----
From: Francois Rousseau <[email-masked]>
To: [email-masked] <[email-masked]>
Date: donderdag 30 april 1998 22:57
Subject: Reference to Applicable Attribute Certificate(s) within the CMS

>Refs: A. ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8: 1997,
>Information Technology-Open Systems Interconnections - The Directory:
>Authentication Framework
>B. ANSI X.9.45, Enhance Management Controls Using Digital Signatures and
>Attribute Certificates, November 1996 (Draft)
>C. ISO/WD-15782-2, Banking - Certificate Management, Part 2: Attribute
>Certificates, October 1997 (Draft)
>D. PKCS #7: Cryptographic Message Syntax Standard, Version 1.5, Revised
>November 1, 1993
>E. "Cryptographic Message Syntax", draft-ietf-smime-cms-04.txt, Work in
>Progress, March 1998
>
>As part of a study for the Government of Canada (GoC) on its long term
>requirements for an Electronic Authorization and Authentication (EAA)
>framework, which would be based on Attribute Certificates as defined in
>reference A, we also had to review the structure of digitally signed
>business transactions.
>
>References B and C, which are both based on reference D, were a good basis
>for such a structure and seemed to provide a mean to convey Attribute
>Certificates. However, both references B and C took the approach of
>OPTIONALLY conveying Attribute Certificates in the
>unauthenticatedAttributes field of each per-signer SignerInfo. CMS (ref E)
>is taking instead a more elegant approach of collecting Attribute
>Certificates and OPTIONALLY including them in the certificates field of the
>SignedData along with public key certificates.
>
>In the future GoC EAA framework, Attribute Certificates will form part of
>the solution for controlling access to sensitive services, such as
>disbursement of funds. If you assume the following model with these four
>components: the Claimant, the Verifier, the Service and the Control policy.
>To validate a service request (e.g. S/MIME message), the Verifier MUST
>obtain some information including the Claimant's public key, the Claimant's
>privilege, encoded in its Attribute Certificate, and the applicable Control
>policy. However, as indicated above, public key certificates and Attribute
>Certificates do NOT have to be included in the certificates field of the
>SignedData. Because the issuerAndSerialNumber field of each per-signer
>SignerInfo only specifies the signer's certificate (and thereby the
>signer's public key) by issuer distinguished name and issuer-specific
>serial number, when certificates are NOT included in the certificates field
>of the SignedData, the issuerAndSerialNumber field only allows the
>recipient of the SignedData to identify for each claimant the signer's
>public key to use to validate the message. This implies there are currently
>no mean within CMS to convey to the Verifier which Attribute Certificate
>MUST be used for each Claimant.
>
>Should not considerations be given within CMS to use the
>authenticatedAttributes field under each per-signer SignerInfo to specify
>through new CRITICAL attributes, the applicable claimant's Attribute
>Certificate and the applicable Control policy that the Verifier MUST use to
>validate the message?
>
>Francois Rousseau
>[email-masked]
>