Subject: Re: Certificates Field in Signed Data
From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 27 Jan 97 12:07:34

At 11:06 PM 1/23/97 +0000, David Chadwick wrote: 
>
>> It also seems
>> likely that people are going to want to push other certificates than the 
>> ones that are required to validate the signature or signing certificate 
>> trust (in the case of a dual key model where the signing and enveloping 
>> certificates are separate, you may want to push both the signing and
>> enveloping certificates and their respective chains). 
>> 
>
>This is an arguement for a SET OF SEQUENCES in my opinion

Presently, PKCS #7 provides a heap of certificates that might be useful to 
the recipient.  PKCS #7 does not constrain the originator in the contets of 
the heap.  The originator can include any certificates that might be useful 
to the recipient, including certificates for key management.  I do not see 
any reason why the originator cannot piggy back key management certificates 
on a signed only message in the current syntax.

>> I think that the current wording of the use of
>> ExtendedCertificatesAndCertificates in the S/MIME implementation guide is 
>> appropriate -- the sender should put in the signing certificate and
>> certificate chain, and the receiver should be prepared to accept anything 
>> in any order, but other stuff can go in there also if it's useful.
>> 
>> Being too restrictive in this case will probably hurt, especially in the 
>> dual key model that I mentioned before.
>
>But being too loose creates work for the receiver, does it not?

The additional authorization information needs to be transfered somewhere.  
These certificates containing authorization information do not make the 
recipient's job overly onerous.

>>In our case, we maintain a
>> local cache database that has certificates indexed by issuerAndSerialNumber 
>> and also by subject, and root keys that are indexed by subject.  Finding
>> the chain is a matter of doing lookups by issuerAndSerialNumber and by
>> subject (by issuerAndSerialNumber for the signing cert, and then looking up 
>> root keys or certificates by subject, keeping in mind that multiple
>> certificates can have the same subject). 
>
>Yes, but if you have a local database, you dont really need any 
>certificates to be passed to you do you? Except to add more to your 
>database. I think that the certificates in the message are for 
>receivers who dont have a general certificate database, but who only 
>have a very small set of trusted root keys. And to help them, one or 
>more chains of certificates seems to be the best.

The certificates must be passed in the message or obtained from some server 
(perhaps a Directory or Web Server).  They do not appear in the local cache 
without being sent or fetched.  Also, most implementations of local 
certificate stores limit their size, so certificate key flushed 
periodically.

Russ

From: [email-masked]
Date: Fri, 24 Jan 1997 06:10:42 -0500 (EST)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG Charter
Sender: [email-masked]

In a message dated 97-01-23 19:10:28 EST, [email-masked]
(David Chadwick) writes:

<< This is odd. The X.509 spec uses SEQUENCE for its forward and reverse 
 certification paths, so why are we using SET ? This places 
 unnecessary burden on the receiver to sort out the jumble.
 
 If we are going to go for a SEQUENCE (or SET OF SEQUENCES which 
 solves the multiple key problem), two alternative schemes are 
 possible. Start with the trusted root (or roots), and if the receiver 
 does not know any of them, he can pack up there and then. 
 Alternatively, start with the senders certificate, and work down the 
 chain from there till you come to a certificate you trust (which 
 might be before a trusted root, so it can be more efficient)
 But if it is a bag of certificates, as proposed, then the receiver 
 has to sort them before he can start.
 
 David 
  >>

 I agree with you. Actually, the same thing is true for 

   1. SET OF Recipients
   2. SET OF Signers
   3. SET OF CRLs

 in SignedData , EnvelopedData and SignedAndEnveloped Data cases.

I fail to see any reason why they can not be SEQUENCE OF instead?
If someone has any valid reason I would request him to present that.

Regards,

  --Arup 

Date: Thu, 23 Jan 1997 23:22:42 -0800
To: [email-masked], Arup Biswas <[email-masked]>, [email-masked]
From: "Blake Ramsdell" <[email-masked]>
Subject: Re: Certificates Field in Signed Data
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:06 PM 1/23/97 +0000, David Chadwick wrote:
>
>> It also seems
>> likely that people are going to want to push other certificates than the
>> ones that are required to validate the signature or signing certificate
>> trust (in the case of a dual key model where the signing and enveloping
>> certificates are separate, you may want to push both the signing and
>> enveloping certificates and their respective chains).
>> 
>
>This is an arguement for a SET OF SEQUENCES in my opinion

Yup -- that is a way to address this issue.  I think my concern is that I
don't want to get stuck in a corner where all we can use is a hierarchical
trust model, and that any structure we impose on the transmission of certs
could railroad us into a single way of thinking about trusting
certificates.  The SET OF SEQUENCES seems like a good compromise in the
event that this all boils over and we absolutely have to change something.

I don't think it's difficult to rearrange a list of certificates, or to
traverse a certificate path according to a local trust convention.  Take
your pile of certificates (the ones in the message, and the ones you may
have lying around), shuffle them around, and see if you get something that
makes your trust code happy.  The alternative that you're proposing takes a
static snapshot of the certificates needed to form a chain according to the
hierarchical model, and some of those certificates will expire, for
instance, which makes the chain invalid without the renewed certificates
(which could be present in a local cache, since they could be transmitted
in messages received after the original message that you are trying to
re-verify).  The only benefit I see to the SET OF SEQUENCE is that in the
event that you are using a hierarchical model, you don't have to go through
the trouble of arranging the certificates yourself, and it separates the
different "leaf" certificates (enveloping and signing) and their associated
chains from each other.  Each of these chains may have redundant
intermediate certificates I might add, which wastes a bit of space in
transmission.

>> I think that the current wording of the use of
>> ExtendedCertificatesAndCertificates in the S/MIME implementation guide is
>> appropriate -- the sender should put in the signing certificate and
>> certificate chain, and the receiver should be prepared to accept anything
>> in any order, but other stuff can go in there also if it's useful.
>> 
>> Being too restrictive in this case will probably hurt, especially in the
>> dual key model that I mentioned before.
>
>But being too loose creates work for the receiver, does it not?

Yup -- that's what I'm paid for :).  I think that creating work for the
receiver is a small price to pay when the alternative is a structure that
might break a future trust model.  Extra work is Just More Code.  An overly
restrictive specification can become unworkable, since it may not
accommodate all the possibilities.

>>In our case, we maintain a
>> local cache database that has certificates indexed by issuerAndSerialNumber
>> and also by subject, and root keys that are indexed by subject.  Finding
>> the chain is a matter of doing lookups by issuerAndSerialNumber and by
>> subject (by issuerAndSerialNumber for the signing cert, and then looking up
>> root keys or certificates by subject, keeping in mind that multiple
>> certificates can have the same subject).
>
>Yes, but if you have a local database, you dont really need any 
>certificates to be passed to you do you? Except to add more to your 
>database. I think that the certificates in the message are for 
>receivers who dont have a general certificate database, but who only 
>have a very small set of trusted root keys. And to help them, one or 
>more chains of certificates seems to be the best.

You certainly do need certs passed to you.  How do you get certificates
initially?  Through the extensive public key infrastructure that we enjoy
now?  Sending certificates along with a message is a convenient (and
essential, in today's S/MIME world) way to do key distribution, even if you
have the local cert store.

Blake

Comments: Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
To: Arup Biswas <[email-masked]>, [email-masked], Blake Ramsdell <[email-masked]>
Date: Thu, 23 Jan 1997 23:06:21 +0000
Subject: Re: Certificates Field in Signed Data
Reply-to: [email-masked]
CC: [email-masked], [email-masked]
Sender: [email-masked]

> It seems reasonable that for size or other reasons someone might not want
> to send anything in the bag o' certs and put the responsibility on the
> receiving entity to find the signing certificate and any other certificates
> required to satisfy the trust requirements of the receiver. 

Ok, fine, that is the senders choice. But this has no effect on the 
SET or SEQUENCE issue, since an empty sequence or empty set are the 
same thing :-)

> It also seems
> likely that people are going to want to push other certificates than the
> ones that are required to validate the signature or signing certificate
> trust (in the case of a dual key model where the signing and enveloping
> certificates are separate, you may want to push both the signing and
> enveloping certificates and their respective chains).
> 

This is an arguement for a SET OF SEQUENCES in my opinion

> I think that the current wording of the use of
> ExtendedCertificatesAndCertificates in the S/MIME implementation guide is
> appropriate -- the sender should put in the signing certificate and
> certificate chain, and the receiver should be prepared to accept anything
> in any order, but other stuff can go in there also if it's useful.
> 
> Being too restrictive in this case will probably hurt, especially in the
> dual key model that I mentioned before.

But being too loose creates work for the receiver, does it not?

> 
> >The issue is the following: I get a signed Data message, I decode it,
> >get a bunch of certificates (provided it has been attached). Now,
> >what would be the simplest way to select the certificate of the signer
> >and verify the whole chain?
> 
> Each of the SignerInfo types in the signerInfos has an
> issuerAndSerialNumber member that can be compared against the received
> certificates.  After that point, you need to enforce your own rules as to
> your validation of that certificate (in the case of the hierarchy model,
> you look up the issuer of the parent certificate, and continue on up the
> chain until the trusted root).  I'm guessing that you are looking for an
> easier way, but I'm not sure that there is one. 

That seems to be the easiest way to me, following a chain.

>In our case, we maintain a
> local cache database that has certificates indexed by issuerAndSerialNumber
> and also by subject, and root keys that are indexed by subject.  Finding
> the chain is a matter of doing lookups by issuerAndSerialNumber and by
> subject (by issuerAndSerialNumber for the signing cert, and then looking up
> root keys or certificates by subject, keeping in mind that multiple
> certificates can have the same subject).

Yes, but if you have a local database, you dont really need any 
certificates to be passed to you do you? Except to add more to your 
database. I think that the certificates in the message are for 
receivers who dont have a general certificate database, but who only 
have a very small set of trusted root keys. And to help them, one or 
more chains of certificates seems to be the best.

> 
> In any case, I think the PKCS #7 syntax is fine.  We may want to clarify
> the philosophy a little better in the S/MIME implementation guide, however,
> especially with regard to the transmission of self-signed root keys.
> 
> Blake
> 
> 
***************************************************
David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
***************************************************

Comments: Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
To: Arup Biswas <[email-masked]>, ietf-smime <[email-masked]>, smime-dev <[email-masked]>, Jeff Thompson <[email-masked]>
Date: Thu, 23 Jan 1997 23:06:21 +0000
Subject: Re: WG Charter
Reply-to: [email-masked]
Sender: [email-masked]

> From:          Jeff Thompson <[email-masked]>
> To:            Arup Biswas <[email-masked]>, ietf-smime <[email-masked]>,
>                smime-dev <[email-masked]>
> Subject:       Re: WG Charter
> Date:          Thu, 3 Jan 1980 10:47:11 -0500

> > From: Arup Biswas <[email-masked]>
> 
> > One small detail for the WG to resolve, we need to establish a protocol
> > about the certificates field  in the Signed Data message. Do we keep a
> > single certificate or the chain? Trusted Root Certificate first or last?
> > Similarly for the CRLs. 
> 
> I think you should push as many certificates when sending a message
> that you think will help the recipient validate your public key.
> 

Agreed in principle, but you will normally know the order in which to 
push them, it is not just any old random set of certificates, is it?

> As for the certificates field, it is a SET OF, not a SEQUENCE OF.  

This is odd. The X.509 spec uses SEQUENCE for its forward and reverse 
certification paths, so why are we using SET ? This places 
unnecessary burden on the receiver to sort out the jumble.

If we are going to go for a SEQUENCE (or SET OF SEQUENCES which 
solves the multiple key problem), two alternative schemes are 
possible. Start with the trusted root (or roots), and if the receiver 
does not know any of them, he can pack up there and then. 
Alternatively, start with the senders certificate, and work down the 
chain from there till you come to a certificate you trust (which 
might be before a trusted root, so it can be more efficient)
But if it is a bag of certificates, as proposed, then the receiver 
has to sort them before he can start.

David 
***************************************************
David W Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 745 5351  Fax +44 161 745 8169
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
***************************************************

Date: Thu, 23 Jan 97 11:42:41 
From: "Housley, Russ" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: WG Charter
Sender: [email-masked]

At 11:48 PM 1/21/97 +0100, Dave Crocker wrote: 
>At 8:24 PM +0100 1/20/97, Housley, Russ wrote:
>>The use of "SEQUENCE OF" is necessary when order is important, but it can 
>>also be used when order is not important.  And, it has much less overhead 
>
> Just to see whether my interpretation of your statement is accurate: 
>
>Your view is that it is ok to impose a required order in all cases?

No.  Just because the use of "SEQUENCE OF" will preserve the order chosen 
by the sender does not mean that there is any semantic meaning to the 
ordering.

I object to the use of "SET OF" with the Distinguished Encoding Rules (DER) 
because it imposes an order.  The "SET OF" encoding must place the 
membership in sorted order.

When one of these constructs is digitally signed, the validator must 
compute the hash (a.k.a. digest) over the same sequence of bits.  In either 
case, the cheapest processing to achieve this is to use the order presented 
by the originator.  In the "SEQUENCE OF" case, there is no laternative.  In 
the "SET OF" case, the recipient could re-sort the members, but there is no 
need to do this if the order used bu the originator is preserved by the 
ASN.1 software .

Russ

Date: Wed, 22 Jan 1997 15:35:24 -0800
To: Dave Crocker <[email-masked]>, "Housley, Russ" <[email-masked]>
From: "Blake Ramsdell" <[email-masked]>
Subject: Re: WG Charter
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:48 PM 1/21/97 +0100, Dave Crocker wrote:
>At 8:24 PM +0100 1/20/97, Housley, Russ wrote:
>>The use of "SEQUENCE OF" is necessary when order is important, but it can
>>also be used when order is not important.  And, it has much less overhead
>
>	Just to see whether my interpretation of your statement is accurate:
>
>Your view is that it is ok to impose a required order in all cases?

I think this is more along the lines of "the sender put these in a specific
order, and the receiver will get them in that same order, in the event that
anyone ever wants to associate semantics with the order", not necessarily
that there is an imposed, required order (even though one could be specified).

Then again, I'm not Russ, so he could have something else in mind entirely.

Blake

Date: Tue, 21 Jan 1997 23:48:46 +0100
To: "Housley, Russ" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: WG Charter
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 8:24 PM +0100 1/20/97, Housley, Russ wrote:
>The use of "SEQUENCE OF" is necessary when order is important, but it can
>also be used when order is not important.  And, it has much less overhead

	Just to see whether my interpretation of your statement is accurate:

Your view is that it is ok to impose a required order in all cases?

d/

--------------------
Dave Crocker                                             +1 408 246 8253
Brandenburg Consulting                              fax: +1 408 249 6205
675 Spruce Dr.                                  [email-masked]
Sunnyvale CA 94086 USA                        http://www.brandenburg.com

Internet Mail Consortium                http://www.imc.org, [email-masked]

Date: Tue, 21 Jan 1997 09:50:11 -0800
From: Arup Biswas <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Certificates Field in Signed Data -Reply
Sender: [email-masked]

>>> "Blake Ramsdell" <[email-masked]> 01/20/97 03:44pm >>>
>>You mean unordered, right?

Yes, thanks for the correction.

>>It seems reasonable that for size or other reasons someone might not
>>want
>>to send anything in the bag o' certs and put the responsibility on the
>>receiving entity to find the signing certificate and any other certificates
>>required to satisfy the trust requirements of the receiver.  It also
>>seems
>>likely that people are going to want to push other certificates than the
>>ones that are required to validate the signature or signing certificate
>>trust (in the case of a dual key model where the signing and
>>enveloping
>>certificates are separate, you may want to push both the signing and
>>enveloping certificates and their respective chains).

>>I think that the current wording of the use of
>>ExtendedCertificatesAndCertificates in the S/MIME implementation
>>guide is
>>appropriate -- the sender should put in the signing certificate and
>>certificate chain, and the receiver should be prepared to accept
>>anything
>>in any order, but other stuff can go in there also if it's useful.

>>Being too restrictive in this case will probably hurt, especially in the
>>dual key model that I mentioned before.

>>Each of the SignerInfo types in the signerInfos has an
>>issuerAndSerialNumber member that can be compared against the
>>received
>>certificates.  After that point, you need to enforce your own rules as
>>to
>>your validation of that certificate (in the case of the hierarchy model,
>>you look up the issuer of the parent certificate, and continue on up the
>>chain until the trusted root).  I'm guessing that you are looking for an
>>easier way, but I'm not sure that there is one.  In our case, we
>>maintain a
>>local cache database that has certificates indexed by
>>issuerAndSerialNumber
>>and also by subject, and root keys that are indexed by subject. 
>>Finding
>>the chain is a matter of doing lookups by issuerAndSerialNumber and
>>by
>>subject (by issuerAndSerialNumber for the signing cert, and then
>>looking up
>>root keys or certificates by subject, keeping in mind that multiple
>>certificates can have the same subject).

>>In any case, I think the PKCS #7 syntax is fine.  We may want to clarify
>>the philosophy a little better in the S/MIME implementation guide,
>>however,
>>especially with regard to the transmission of self-signed root keys.

>>Blake

Blake,

I think you have convinced me why an order can not *always* be 
imposed on the certificates field . But, I think you have overlooked the
cases when an order can be imposed between the negotiating parties.
For example, PKCS #7 used in the degenerated cases for Certificate/CRL
Retrieval.

My point is in such cases if the negotiating parties want to impose an 
order the syntax should not be a hindrance; currently, the SET OF DER
encoding destroys such orders (tell me if I'm wrong). 

On the other hand an ordered collection such as SEQUENCE OF does not
necessarily mean you have to impose an order, 
it merely assures that if any such order was imposed at the time of 
creation it will not be disturbed afterwards. So you have the flexibility
to go either way. The optional inclusion of certificate that you have
mentioned is also satisfied by SEQUENCE OF.

Cheers,

  --Arup

Date: Mon, 20 Jan 97 20:24:42 
From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked], "Jeff Thompson" <[email-masked]>
Subject: Re: WG Charter
Sender: [email-masked]

Jeff:

> As for the certificates field, it is a SET OF, not a SEQUENCE OF.
> Therefore, there is no meaning to the order of certificates found in
> there. In fact, if someone's software is automatically encoding as DER
> (as opposed to BER) then the ordering will be strictly according to the
> encoded bytes of each certificate - that is, irrelevant of the meaning of
> each certificate.  The certificates field is therefore an unordered
> "bag o' certificates".  The same goes for CRLs.

The use of "SEQUENCE OF" is necessary when order is important, but it can 
also be used when order is not important.  And, it has much less overhead 
that "SET OF" when DER is used since a sort is not required.  Either 
"SEQUENCE OF" or "SET OF" can be used to carry a "bag o' certificates".

I see no benefit to "SET OF."

Russ

Date: Mon, 20 Jan 1997 15:44:50 -0800
To: Arup Biswas <[email-masked]>, [email-masked]
From: "Blake Ramsdell" <[email-masked]>
Subject: Re: Certificates Field in Signed Data
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:02 PM 1/20/97 -0800, Arup Biswas wrote:
>
>I think you are right. In the current version of PKCS7 Signed Data format
>certificates field is indeed a SET OF which means an ordered collection
>of Certificates.

You mean unordered, right?

>But My question is more fundamental. Do we fit our requirement
>according to the syntax or do we modify the syntax according to our
>requirements?
>
>In other words, could we make the certificates fields as a SEQUENCE
>OF instead of a SET OF in the next version of PKCS7 Signed Data?
>This is only a suggestion. Why don't we brainstorm this issue?

It seems reasonable that for size or other reasons someone might not want
to send anything in the bag o' certs and put the responsibility on the
receiving entity to find the signing certificate and any other certificates
required to satisfy the trust requirements of the receiver.  It also seems
likely that people are going to want to push other certificates than the
ones that are required to validate the signature or signing certificate
trust (in the case of a dual key model where the signing and enveloping
certificates are separate, you may want to push both the signing and
enveloping certificates and their respective chains).

I think that the current wording of the use of
ExtendedCertificatesAndCertificates in the S/MIME implementation guide is
appropriate -- the sender should put in the signing certificate and
certificate chain, and the receiver should be prepared to accept anything
in any order, but other stuff can go in there also if it's useful.

Being too restrictive in this case will probably hurt, especially in the
dual key model that I mentioned before.

>The issue is the following: I get a signed Data message, I decode it,
>get a bunch of certificates (provided it has been attached). Now,
>what would be the simplest way to select the certificate of the signer
>and verify the whole chain?

Each of the SignerInfo types in the signerInfos has an
issuerAndSerialNumber member that can be compared against the received
certificates.  After that point, you need to enforce your own rules as to
your validation of that certificate (in the case of the hierarchy model,
you look up the issuer of the parent certificate, and continue on up the
chain until the trusted root).  I'm guessing that you are looking for an
easier way, but I'm not sure that there is one.  In our case, we maintain a
local cache database that has certificates indexed by issuerAndSerialNumber
and also by subject, and root keys that are indexed by subject.  Finding
the chain is a matter of doing lookups by issuerAndSerialNumber and by
subject (by issuerAndSerialNumber for the signing cert, and then looking up
root keys or certificates by subject, keeping in mind that multiple
certificates can have the same subject).

In any case, I think the PKCS #7 syntax is fine.  We may want to clarify
the philosophy a little better in the S/MIME implementation guide, however,
especially with regard to the transmission of self-signed root keys.

Blake

Date: Mon, 20 Jan 1997 14:02:24 -0800
From: Arup Biswas <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Certificates Field in Signed Data
Sender: [email-masked]

>>> "Jeff Thompson" <[email-masked]> 01/03/80 07:47am >>>

>I think you should push as many certificates when sending a message
>that you think will help the recipient validate your public key.

>As for the certificates field, it is a SET OF, not a SEQUENCE OF.  
>Therefore, there is no meaning to the order of certificates found in
>there.
>n fact, if someone's software is automatically encoding as DER
>(as opposed to BER) then the ordering will be strictly according to the
>encoded bytes of each certificate - that is, irrelevant of the meaning of
>each certificate.  The certificates field is therefore an unordered 
>"bag o' certificates".  The same goes for CRLs.

>I don't want to get into the argument about the Trusted Root Certificate:
>whether it is a self-signed certificate, how it is in fact "trusted".  Some
>applications also send self-signed certificates for the signer of the
>message
>(not the root) to support non-hierarchical certification schemes so the
>sender can
>send a certificate for him/herself which is not created by a third party.
>But again, the "Trusted Root Certificate" would not come first or last
>in the SET OF certificates.

Jeff,

I think you are right. In the current version of PKCS7 Signed Data format
certificates field is indeed a SET OF which means an ordered collection
of Certificates.

But My question is more fundamental. Do we fit our requirement
according to the syntax or do we modify the syntax according to our
requirements?

In other words, could we make the certificates fields as a SEQUENCE
OF instead of a SET OF in the next version of PKCS7 Signed Data?
This is only a suggestion. Why don't we brainstorm this issue?

The issue is the following: I get a signed Data message, I decode it,
get a bunch of certificates (provided it has been attached). Now,
what would be the simplest way to select the certificate of the signer
and verify the whole chain?

 I am proposing let the syntax indicate a mechanism to select the signer's
certificate and the Root Certificate. I would like to hear other's opinion
too.

Regards,

  --Arup Biswas
    Software Engineer,
    Novell

> From: Arup Biswas <[email-masked]>

> One small detail for the WG to resolve, we need to establish a protocol
> about the certificates field  in the Signed Data message. Do we keep a
> single certificate or the chain? Trusted Root Certificate first or last?
> Similarly for the CRLs. 

From: "Jeff Thompson" <[email-masked]>
To: "Arup Biswas" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: WG Charter
Date: Thu, 3 Jan 1980 10:47:11 -0500
Sender: [email-masked]

> From: Arup Biswas <[email-masked]>

> One small detail for the WG to resolve, we need to establish a protocol
> about the certificates field  in the Signed Data message. Do we keep a
> single certificate or the chain? Trusted Root Certificate first or last?
> Similarly for the CRLs. 

I think you should push as many certificates when sending a message
that you think will help the recipient validate your public key.

As for the certificates field, it is a SET OF, not a SEQUENCE OF.  
Therefore, there is no meaning to the order of certificates found in there.
In fact, if someone's software is automatically encoding as DER
(as opposed to BER) then the ordering will be strictly according to the
encoded bytes of each certificate - that is, irrelevant of the meaning of
each certificate.  The certificates field is therefore an unordered 
"bag o' certificates".  The same goes for CRLs.

I don't want to get into the argument about the Trusted Root Certificate:
whether it is a self-signed certificate, how it is in fact "trusted".  Some
applications also send self-signed certificates for the signer of the message
(not the root) to support non-hierarchical certification schemes so the sender can
send a certificate for him/herself which is not created by a third party.
But again, the "Trusted Root Certificate" would not come first or last
in the SET OF certificates.

Date: Thu, 16 Jan 1997 12:38:05 -0800
From: Arup Biswas <[email-masked]>
To: [email-masked], [email-masked]
Subject: WG Charter
Sender: [email-masked]

Hi All,

One small detail for the WG to resolve, we need to establish a protocol
about the certificates field  in the Signed Data message. Do we keep a
single certificate or the chain? Trusted Root Certificate first or last?
Similarly for the CRLs. 

Thanks,

  --Arup Biswas
    Software Engineer,
    Novell Inc.

Greetings again.  In the interest of generating a bit more (as in, some)
action here, I'd like to start the discussion off with a proposed working
group charter and milestones for the S/MIME WG.  Please feel free to
bash
away.

Description of the Working Group:

S/MIME is a method for encrypting and/or authenticating MIME data.  The
definition of S/MIME falls into three areas:

*    Description of the overall message format
*    Description of the security portions of the message
*    Defaults, options, and extensions of the security portions

The first area, the message format, has already been submitted to
the IETF ("draft-dusse-mime-msg-spec").  The second area, the security
portions, are defined by RSA's PKCS #7 and PKCS #10 specifications. 
These
may be published as Informational RFCs, eventually.  The third area,
security profile, is the main task of this current effort, in order to insure
interoperability of S/MIME-compliant programs.

In order to create a complete (and more perfect) specification, the
Working
Group must fully specify the message format, as well as the minimum
security profile needed in order for two mail clients to communicate.  The
profile must also include other optional security mechanisms, such as
additional hashing algorithms, as well as a method for syncrhonize two
S/MIME agents that have never communicated to determine which of the
optional mechanisms can be used in future messages.  Further, the
profile
must specify an extension registration mechanism (probably through
IANA) so
that future security protocols can be included in S/MIME.

A modestly aggressive schedule is specified, due to the amount of
existing
work on S/MIME.

Goals and Milestones:

February 1997: Revised draft of the message format document

March 1997: Submit PKCS #7 and PKCS #10 as Informational RFCs

March 1997: Draft of security profile document

April 1997: Submit message format document for standards track

May 1997: Revised draft of the security profile document

June 1997: Submit security profile document, submit for standards track

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Thu, 16 Jan 1997 09:45:40 -0800
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Are we interesting in becoming a Working Group?
Sender: [email-masked]

Greetings again. I'm pretty surprised at the lack of discussion on this
list, even after I proposed the first cut of a WG charter. About 125 people
have signed up to be on this mailing list, and there were certainly lots of
people in the room for the SMIME BOF in San Jose last month.

Without a Working Group, it will be harder to move SMIME into full IETF
specification, which is the stated intention of RSA. There are still some
tough issues to resolve, such as default choices for encryption algorithm
and the extension mechanism. At the BOF, there were many comments about
changes people wanted to see in the current SMIME spec, and there should be
a forum for that kind of discussion.

Further, only one of the four documents needed to turn this into a full
spec has been submitted to the IETF. Having a Working Group with a document
editor and chairman could help change this and get the process moving.

Of course, if no one is interested in doing the work in the Working Group,
it shouldn't form. However, given the great interest in San Jose and the
general industry desire to not have more than one email security protocol
(PGP/MIME is already an Experimental RFC), I think things should get moving.

Again, please take a look at the rough proposed charter I suggested, and
please feel free to make comments and criticisms here on the mailing list.
You can find my proposed charter in the mailing list archive at
<http://www.imc.org/ietf-smime/mail-archive/0003.html>.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Tue, 14 Jan 1997 09:45:01 -0800
From: Arup Biswas <[email-masked]>
To: [email-masked], [email-masked]
Subject: Want Enveloped Message
Sender: [email-masked]

Hi All,

Thanks to all those who responded to my previous call for Signed Data 
Message testing. I have been able to read majority of them successfully. 
I am still in the process of testing and would appreciate more Signed
Data Messages.

However, this time I would like to start testing Enveloped Messages.
So, please send me enveloped messages as many as you can. I would
appreciate any pointer to any archive of Enveloped Messages too.

Note: I am attaching my certificate for secret key encryption.

Thanks for your cooperation,

 Arup Biswas,
 Software Engineer,
 Novell Inc.

Date: Wed, 8 Jan 1997 09:31:26 -0800
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: First cut of a WG charter
Sender: [email-masked]

Greetings again.  In the interest of generating a bit more (as in, some)
action here, I'd like to start the discussion off with a proposed working
group charter and milestones for the S/MIME WG.  Please feel free to bash
away.

Description of the Working Group:

S/MIME is a method for encrypting and/or authenticating MIME data.  The
definition of S/MIME falls into three areas:

*    Description of the overall message format
*    Description of the security portions of the message
*    Defaults, options, and extensions of the security portions

The first area, the message format, has already been submitted to
the IETF ("draft-dusse-mime-msg-spec").  The second area, the security
portions, are defined by RSA's PKCS #7 and PKCS #10 specifications.  These
may be published as Informational RFCs, eventually.  The third area,
security profile, is the main task of this current effort, in order to insure
interoperability of S/MIME-compliant programs.

In order to create a complete (and more perfect) specification, the Working
Group must fully specify the message format, as well as the minimum
security profile needed in order for two mail clients to communicate.  The
profile must also include other optional security mechanisms, such as
additional hashing algorithms, as well as a method for syncrhonize two
S/MIME agents that have never communicated to determine which of the
optional mechanisms can be used in future messages.  Further, the profile
must specify an extension registration mechanism (probably through IANA) so
that future security protocols can be included in S/MIME.

A modestly aggressive schedule is specified, due to the amount of existing
work on S/MIME.

Goals and Milestones:

February 1997: Revised draft of the message format document

March 1997: Submit PKCS #7 and PKCS #10 as Informational RFCs

March 1997: Draft of security profile document

April 1997: Submit message format document for standards track

May 1997: Revised draft of the security profile document

June 1997: Submit security profile document, submit for standards track

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Thu, 02 Jan 1997 10:20:28 -0800
From: Arup Biswas <[email-masked]>
To: [email-masked], [email-masked]
Subject: List of algorithms - need your feedback
Sender: [email-masked]

Hi All,

 I was wondering if there has been a consensus about the
 cryptographic algorithms to be used for various cryptographic
 operations in S/MIME. I have compiled a list of such algorithms from
 some RSA guideline documents. Please, feel free to Add/Delete/Modify/
 Comment on this list. If necessarry, I will post a summary 
 at the end of the discussion.

Content Encryption:

	RC2 in CBC mode 
	DES EDE3 CBC
	DES CBC
	RC5 CBC

Digest Algorithm:

	sha -1
	MD2
	MD5

Digest Encryption Algorithm:

	rsaEncryption

Key Encryption Algorithm:

	rsaEncryption

Cheers,

  --Arup