Subject: Re: Weakening the rigid heirarchical trust model
From: EKR <[email-masked]>
To: Ed Gerck <[email-masked]>
Cc: David Sternlight <[email-masked]>, [email-masked]
Date: 31 Dec 1997 19:19:04 -0800

Ed Gerck <[email-masked]> writes:
> The bottom line is that S/MIME aims at a security level which is not
> critical, while it can be perfectly operational for the bulk use of the
> Internet today. A honest and correct appraisal of this fact must be more
> useful than snake-oil, here too. 
I absolutely agree. I was simply observing that it's quite possible
to create a profile of S/MIME that is usable in a high security
environment.

> -> 
> -> > ->S/MIME the protocol is perfectly usable in 
> -> > -> high security situations. As always, the implementation has to
> -> > -> be secure. (Incidentally, all the security holes you mention with
> -> > -> the exception of self-signed certs are easily solved by using a 
> -> > -> secure hardware token for one's own private keying material.)
> -> > 
> -> > I must again disagree. It is a common misconception that a third-party
> -> > manufactured hardware token would magically infuse trust into the final
> -> > result of a cryptographic calculation. As we know, trapdoors can be easily
> -> > inserted into the calculation of keys or signatures, arguably more
> -> > stealthly in a hardware token with concealed and secret source code.
> ->
> -> This misses the point entirely. I'm not suggesting that a hardware
> -> is a magic bullet. I'm merely observing that suitably designed
> -> hardware tokens (of which several are available) can solve the
> -> implementation problems you were complaining about. In fact, 
> -> hardware is quite a common requirement in certain environments
> -> for precisely that reason.
> ->
> 
> My point was that a protocol weakness cannot be solved by hardware, no
> matter how controlled.
Yes, but a lot of the things you were complaining about (e.g.
bad randomness for key generation,  programs which are willing
to give up the key, etc.) are (1) not protocol bugs but
implementation bugs and (2) can be fixed by trusted hardware.

That was my only point.

> -> That said, the issue of trapdoors is a red herring. Ultimately
> -> you have to trust your vendor not to intentionally compromise your
> -> security--or do it all yourself. Read "Reflections On Trusting Trust"
> -> for an example that makes this point quite clearly.
> 
> First, "not intentionally compromised" is difficult to disprove,
> especially when you bear the burden of proof in a tamper-proof device, no?
> (Further, as you may remember from the case of Stac vs Microsoft, Stac
> proved by reverse assembly of MS's code that DoubleSpace used substantial
> code from Stac, but Stac was also found guilty of "invading" MS's code.)
>
> Second, as above, no vendors or third-parties can be trusted in today's
> competitive environment-- not even Volkswagen vis-a-vis General Motors. 
> What the international Internet community needs is not some immaterial
> trust on a foreign government or company or, even, on a domestic
> government or company -- but open knowledge and fail-safe procedures. 
> After all, if trust would be such a safe "blank check" then the whole
> issue of key-escrow, TTP legislation and CAs would be moot. 
I think you're missing the point here. The vast majority of users
of security critical software are using software supplied by
others, even if those others are in-house. If those suppliers can't
be trusted not to intentionally compromise your security, there
are very few measures that you can take to really protect yourself.

> BTW, "Trusting Trust" reflects the wrong assumption that trust is
> transitive -- which it is not.
>From this, I infer that you haven't actually read "Reflections on
Trusting Trust", but are just guessing what it's about based
on the title. Am I right?

Certainly your comments don't speak at all to the point that the
paper is trying to make. (Hint: It's not about cryptography at
all.)

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 31 Dec 1997 22:22:49 -0200 (EDT)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: EKR <[email-masked]>
cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

On 31 Dec 1997, EKR wrote:

-> [snip, already requoted]
-> That doesn't mean that S/MIME can't be used for high security
-> purposes. It merely means that it can be used in situations where
-> those requirements aren't met as well. On the other hand, if you
-> want to meet requirements like that, you can do so using S/MIME.

While it is true that the laissez-faire philosophy can be very disastrous
when applied to security protocols and indeed S/MIME is managing to steer
away from open statements, we must also not interpolate lines when we read
the protocol specs -- especially when I understand by the above that you
intend to say to non-cryptographers (ie, the public at large) that the
protocol can be used for high security purposes (such as for banking or
company-critical messages). I prefer Paul's assesment, when he wrote about
S/MIME: "This is a mail spec, not a banking spec.", in this thread.
 
By allowing low-security procedures to be 100% S/MIME compliant, you must
agree that an application that is 100% S/MIME compliant does not say more
than guaranteeing that low-security level -- which defines its security
level for the public. A member of a class must be defined by the class's
properties, no?

On the other hand, if you still want to imagine a situation where two
applications are equally 100% S/MIME compliant while one offers a higher
security level, then you must also agree that these two applications are
incompatible in that high-security level -- though both are S/MIME
compliant, which would be a contradiction by itself *if* S/MIME would be a
high-security protocol. After all, the primary purpose of a standard is to
guarantee interoperability -- which would be utterly destroyed in your
example. This is not the case and S/MIME must guarantee interoperation at
its intended security level -- which is whatever the standard mandates by
its MUST and MUST NOT clauses. 

The bottom line is that S/MIME aims at a security level which is not
critical, while it can be perfectly operational for the bulk use of the
Internet today. A honest and correct appraisal of this fact must be more
useful than snake-oil, here too. 

-> 
-> > ->S/MIME the protocol is perfectly usable in 
-> > -> high security situations. As always, the implementation has to
-> > -> be secure. (Incidentally, all the security holes you mention with
-> > -> the exception of self-signed certs are easily solved by using a 
-> > -> secure hardware token for one's own private keying material.)
-> > 
-> > I must again disagree. It is a common misconception that a third-party
-> > manufactured hardware token would magically infuse trust into the final
-> > result of a cryptographic calculation. As we know, trapdoors can be easily
-> > inserted into the calculation of keys or signatures, arguably more
-> > stealthly in a hardware token with concealed and secret source code.
->
-> This misses the point entirely. I'm not suggesting that a hardware
-> is a magic bullet. I'm merely observing that suitably designed
-> hardware tokens (of which several are available) can solve the
-> implementation problems you were complaining about. In fact, 
-> hardware is quite a common requirement in certain environments
-> for precisely that reason.
->

My point was that a protocol weakness cannot be solved by hardware, no
matter how controlled. The points I complained about (a few, from a larger
list) cannot be solved for the average international user (non-US) by a
hardware token either, mainly because: (i) cost, (ii) export controls,
(iii) the current servers do NOT let you do that for S/MIME, (iv) the
current export-version browsers do NOT let you do that for S/MIME, (v) 
the CAs do NOT let you do that for S/MIME, (vi) there are serious
questions on possible cryptographic proofs that you actually signed the
message and which message was signed if you lose or destroy your hardware
token, (vii) the datestamp and clock synchronization questions, (viii) 
fairness of the hardware token, etc.

Of course, going further in this Gedankenexperiment, if (instead of
keeping to its turf) an Internet protocol requires the use of a special
and expensive hardware token in order to cope with added security
promises, then ... we may count several additional benefits, such as: (i) 
adding a secondary market, (ii) restricting access to export-controlled
technology (read, restricting access to higher security) in a much better
way, (iv) adding buzzword "smart"  devices, etc. 

Here, if we pursue it even further, we see that the 40-bit limitation of
S/MIME may be even dwarfed by this issue, were S/MIME to make the claim it
is a high-security protocol when used with hardware tokens.

<clarification>
As we can see around us, the Internet is not any longer a parochial
network. Competing businesses, competing countries and competing economic
blocks are present in the Internet. Recently, a world renowned and
respected car manufacturer was found guilty and fined US$ 1.1 billion
because of industrial espionage on another world renowned and respected
car manufacturer. The companies: GM and VW (guilty). The surprise: VW
publicly declared (previously) that the information had already saved it
US$ 500 million in a few months (so, the fine was not excessive after all
and may have been less than the benefit). The conclusion: we live in a
"hostile" environment where the Internet is no exception, even when
household and "trusted" names are involved, because it pays off.

The information leverage is such today that one person (from GM to VW)
could cause a damage of more than one billion dollars in less than one
year.          

Thus, information gathered from e-mail can mean a large leveraged bounty
to an eavesdroper on the Internet -- even among well-known and otherwise
respected companies. So, in the same way that S/MIME does not aim to allow
a security level suitable to a bank, it is also not suitable for critical
messages such as highly-competitive corporate e-mail information
(finances, engineering, patents, liabilities, employee records, sales,
marketing, etc.)  because even small bits of information may be
detrimentaly used nowadays for a large effect in a leveraged competitive
context. 
</clarification>

-> That said, the issue of trapdoors is a red herring. Ultimately
-> you have to trust your vendor not to intentionally compromise your
-> security--or do it all yourself. Read "Reflections On Trusting Trust"
-> for an example that makes this point quite clearly.

First, "not intentionally compromised" is difficult to disprove,
especially when you bear the burden of proof in a tamper-proof device, no?
(Further, as you may remember from the case of Stac vs Microsoft, Stac
proved by reverse assembly of MS's code that DoubleSpace used substantial
code from Stac, but Stac was also found guilty of "invading" MS's code.)

Second, as above, no vendors or third-parties can be trusted in today's
competitive environment-- not even Volkswagen vis-a-vis General Motors. 
What the international Internet community needs is not some immaterial
trust on a foreign government or company or, even, on a domestic
government or company -- but open knowledge and fail-safe procedures. 
After all, if trust would be such a safe "blank check" then the whole
issue of key-escrow, TTP legislation and CAs would be moot. 

BTW, "Trusting Trust" reflects the wrong assumption that trust is
transitive -- which it is not. You can only really trust in first order --
if you trust your brother this does not mean that you must trust your
brother's friends (e.g., trusting his trust). This is a common
misconception when understanding PGP, because PGP does not allow trust to
be transitive (thus, the maximum depth of a Web of Trust is one when
signing certs and could never be seven as postulated recently here in an
anti-PGP example by Phillip, which also invalidates his example). 

<reference> 
Trust can be modelled as given in http://mcg.org.br/trustprop.txt which
allows one to view trust as a transformation. With this model, it is
possible to consider trust as it may depend on each of its attributes
(transitive, distributive, symmetric), domains, agents and, time (yes,
trust is not a time-invariant property either). Thus, direct or "hard" 
trust would be modeled as (t=0,d=0,s=0) for totally nontransitive,
nondistributive, and nonsymmetric, whereas "soft" trust would allow
nonzero values for (t,d,s) -- albeit with a corresponding decrease in
trust transfer when correlating between different agents, events, etc. 
</reference>

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br
    --- Visit the Meta-Certificate Group at http://mcg.org.br ---

Date: Wed, 31 Dec 1997 15:20:46 -0800
To: ietf-smime <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: CMS Critical flag for signed attributes?
Sender: [email-masked]

At 03:25 PM 12/31/97 -0500, Phillip Hallam-Baker wrote:
>It seems to me we may just need a critical flag just like there is in
>the X.509v3 certificate. If the critical bit is set and the client does
>not understand the semantics of the attribute a client is required to
>inform the user of the fact.

This sounds alright to me, but not the differences in action between PKIX
and S/MIME. In PKIX, you MUST not process a cert that has a critical
attribute you don't understand. In S/MIME, you propose that we "inform the
user", which is the handwaving we're forced to do when a signature check
fails.

If we go with this idea, the handwaving wording for what happens for failed
criticality should be identical as the handwaving wording we use for failed
signature validation. In fact, I'd like to see that wording appear only
once as the same outcome to two different bad events.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 31 Dec 1997 14:43:34 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid hierarchical trust model
Sender: [email-masked]

NoSpam wrote:
<ideology excised> 

> Accordingly, I advocate a technical specification that fully permits
> self-signed certificates, that promotes their ease of transfer with the
> message content, that provides for their review by the recipient, and for
> his informed choice to accept or reject the certificate for various usages.
> To treat (at the standards level) some certificates as first-class and
> convenient, and others second-class and less convenient, based upon the
> IETF working group's assessment of who has signed them, is paternalism,
> reaching into the political and ideological mire of parochial and
> provincial interests.

1. One may insure that a choice is pro-active rather than accomodating,
without being paternalistic. Thus making it necessary for a user to obtain
self-signed certificates  of unknown bona fides via seeking behavior, rather
than by easy acceptance of a choice screen (how often have users selected the
"wrong" option either inadvertently or through error), is simple prudence
appropriate to inclusion in an internet-wide standard expected to be affect
many novices. The principle of positive action networks has been well
understood for years, particularly in the security field.

2. The notion that levels of security somehow make lower levels "second class"
(with overtones of social injustice) is simply incorrect. The discussion is
about whether to distinguish those CAs meeting agreed standards (as indicated
by certification by some higher-level authority, possibly ultimately through
the IPRA) from CAs about which one knows nothing a priori from the
certificates in that they are self-signed. Since the distinction can be of
major security significance, it is reasonable for users to have to seek out
and obtain such self-signed certificates through positive action pull rather
than through simple acceptance of a push. 

The notion of being able to push malign certificates (since self-signing CAs
opens the door wide to that) on trusting users seems to me to be a pernicious
one not unrelated to that of free junk mail. While it is true that one can
always refuse to read such junk mail, distinguishing is a difficult task,
users are often harried with much mail, and issuers often go out of their way
to disguise such mail to take advantage of ambiguity and uncertainty. Far
better to use a pull system where users request such material if they want it.

David

To: Ed Gerck <[email-masked]>
Cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
From: EKR <[email-masked]>
Date: 31 Dec 1997 13:45:05 -0800
Lines: 57
Sender: [email-masked]

Ed Gerck <[email-masked]> writes:

> On 30 Dec 1997, EKR wrote:
> 
> -> Ed Gerck <[email-masked]> writes:
> -> > 1. It is clear that S/MIME does not intend to be a high-security standard
> -> > (such as could be used for banking purposes, for company-critical
> -> > information exchange, etc.), when you see for example the various
> -> > documented security holes that already exist and are simply discarded (to
> -> > name a few, the potential "trojan horse"  situation of S/MIME private-key
> -> > generation in MSIE, the "on-line" S/MIME private-key generation with the
> -> > CA in the same session as used in NS Communicator, the question of no user
> -> > choice in the random seed generation for S/MIME private-key generation in
> -> > either case, the S/MIME use of self-signed certs, the possibility of
> -> > traceless S/MIME private-key snatching with an ActiveX control, etc.).
> ->
> -> AAAAH. These aren't security holes in S/MIME. They're security holes in
> -> S/MIME implementations. 
> 
> I disagree, because the security holes mentioned are perfectly allowed by
> the S/MIME standard.  So, such implementations are 100% S/MIME-compliant
> -- which they should never be if the standard would aim at a higher
> security level. 
That doesn't mean that S/MIME can't be used for high security
purposes. It merely means that it can be used in situations where
those requirements aren't met as well. On the other hand, if you
want to meet requirements like that, you can do so using S/MIME.

> ->S/MIME the protocol is perfectly usable in 
> -> high security situations. As always, the implementation has to
> -> be secure. (Incidentally, all the security holes you mention with
> -> the exception of self-signed certs are easily solved by using a 
> -> secure hardware token for one's own private keying material.)
> 
> I must again disagree. It is a common misconception that a third-party
> manufactured hardware token would magically infuse trust into the final
> result of a cryptographic calculation. As we know, trapdoors can be easily
> inserted into the calculation of keys or signatures, arguably more
> stealthly in a hardware token with concealed and secret source code.
This misses the point entirely. I'm not suggesting that a hardware
is a magic bullet. I'm merely observing that suitably designed
hardware tokens (of which several are available) can solve the
implementation problems you were complaining about. In fact, 
hardware is quite a common requirement in certain environments
for precisely that reason.

That said, the issue of trapdoors is a red herring. Ultimately
you have to trust your vendor not to intentionally compromise your
security--or do it all yourself. Read "Reflections On Trusting Trust"
for an example that makes this point quite clearly.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 31 Dec 1997 15:25:24 -0500
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
To: ietf-smime <[email-masked]>
Subject: CMS Critical flag for signed attributes?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms0CCABF89030CB7C01C4BD0E1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Should there be a criticallity flag for signed attributes?

The application I am thiniking of is limiting an employees signing
authority inside a company. An obvious way to do this would be to have
an OID for the signed attribute 'this message does not constitute an
offer or acceptance of a contract'.

The problem is forcing the client to bring this (or a like) OID to the
attention of the reader.

It seems to me we may just need a critical flag just like there is in
the X.509v3 certificate. If the critical bit is set and the client does
not understand the semantics of the attribute a client is required to
inform the user of the fact.

Alternatively one could suggest making all extensions critical in which
case I am sure I can think up an example of a need to flag something
non-critical!

		Phill
--------------ms0CCABF89030CB7C01C4BD0E1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms0CCABF89030CB7C01C4BD0E1--

Date: Wed, 31 Dec 1997 14:27:36 -0500
To: [email-masked]
From: NoSpam <[email-masked]>
Subject: Re: Weakening the rigid hierarchical trust model
Sender: [email-masked]

The caution expressed here about delving into ideology incident to
self-certifying CAs is wise. That does not remove, however, the inescapable
fact that ideology may underlie a technology or standard. For example, the
ideologies of private property and monetizing value underlie payment systems.

IETF working groups unavoidably develop proposals based on such ideological
underlayments, but must remain free of tweaking for parochial and
provincial interests, the arguing of which can endlessly bog down technical
implementation, and make global standards problematic, if not impossible.

Thus, a payment system standard may be developed, while encoding a payment
system standard that prevents the purchase of liquor on Sunday, or in Saudi
Arabia, or by minors, enters the arena of troublesome tweaking to parochial
and provincial interests.

To deal with the generally-accepted facts that purchasing liquor may be
religiously offensive to some when done on Sunday, illegal in Saudi Arabia,
or harmful to unsupervised minors, is clearly beyond both the scope and
ability of a technical standards body like an IETF working group.

The problem arises in determining where ideological underlayments end, and
parochial and provincial interests begin. That question is not of the same
class as "how long is this piece of string". Judgments must be made. If
error is to be made, placing most issues into the "parochial and
provincial" category, and excluding them from standards-body tweaking,
facilitates the pace and globalness of standard development and extends
applicability, and expands the choices left to the user. I submit that
those results are beneficial. Erring in the other direction retards the
pace of standards development and diminishes applicability, and reduces the
choices left to the user.

If one wishes to enter the arena of protecting the unsophisticated user
from the possibility that he may make bad choices (e.g., a minor seeks to
purchase liquor), then one has entered the thickest mire of ideology, that
of paternal judgments made by one to ostensibly benefit another. In that
mire, one must decide what is good for others, and limit their opportunity
to choose that which you believe is not good. Some, including myself,
believe (ideologically) that the quality of such paternal judgments
decreases as the distance between paternal judger and the ostensibly
protected party increases. I submit that the standards body is sufficiently
distant from a widely-diverse array of potential beneficiaries of
gratuitous paternalism, such that a low quality, generalized result might
be obtained, even from the most-enlightened and best-intended efforts.

There is a protocol, the use of which mitigates the foregoing concern. That
protocol is to provide notice to the user of the reasonable consequences of
the various choices he may make. Rather than prohibiting hot things,
Underwriters Laboratories has tags placed on transformers that say, "Hot.
To avoid burning, do not touch." The verbiage of such notice moves into
political consideration. A standard can implement notice protocols,
although notice-message-content itself may be better left to implementors.
For example "algorithm/notice".

I submit for consideration that the two primary ideological underlayments
of cryptographic communications are 1) the  secrecy and authenticity of
communications between communicants, and 2) the communicants' selection of
methods to accomplish and authenticate such communications, i.e., what do
the *communicants trust and prefer* for the content at hand.

If one accepts the foregoing, then one adopts the necessary strategy of
providing choices to the user, with notice, rather than hard-wiring out the
possibilities of choice at the technical standards level.

Accordingly, I advocate a technical specification that fully permits
self-signed certificates, that promotes their ease of transfer with the
message content, that provides for their review by the recipient, and for
his informed choice to accept or reject the certificate for various usages.
To treat (at the standards level) some certificates as first-class and
convenient, and others second-class and less convenient, based upon the
IETF working group's assessment of who has signed them, is paternalism,
reaching into the political and ideological mire of parochial and
provincial interests.

In my view, a specification that steers clear of that bog facilitates both
the pace and globalness of standard development, the broad applicability of
the result, and the informed choices left to the user.

----------------------------
Ed Stone
[email-masked]
delete "-birdname" spam avoider
----------------------------

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: Re: Signing HTTP Transactions
Date: Wed, 31 Dec 1997 10:38:50 -0500
Sender: [email-masked]

>Phill,
>You might like to read
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-wts-shttp-05.txt

Thank you, I commented on the first draft back in early 1994.

I think that the basic premise for S-HTTP has to be entirely
re-evaluated in the light of ubiquitous S/MIME support in the
basic Internet support code for the clients. I see transaction
level signatures as being much more important than 
transport level encryption which offers little more than a 
small caching  advantage over transport layer security 

Given the fact that the browser vendors seem to have little
interest in transaction level security I am simply proposing 
that we consider a very minor change to the HTTP spec
that would obtain 80% of the value of security at the 
transaction layer with a tiny fraction of the cost of implenting
S-HTTP.

One scenario for using this protocol would be: user is 
presented with a contract offer, user fills in some details
and sends a signed response back.

Netscape has already provided a feature of this sort with
its 'form signing technology' in Navigator 4.04. What I am
proposing is essentially similar but covering more than
just form signing and using headers alone, not cookies or
anything else.
http://developer.netscape.com/one/security/formsign/formsign.html

<digression relevance="some">
As a separate matter I would like to define a number of OIDs
to express some HTTP/HTML specific signing scenarios. 
For example a user obtains a signed form with an anchor
with a cryptopts="signed" attribute. There are obvious security
problems in having the user sign responses automatically and
informed consent is hard to achieve for anything beyond 
plaintext. One means of addressing these security problems
would be to incorporate a hash of the signed 'offer' document
into the signature.
</digression>

I think these scenarios are already implicit in S/MIME since 
HTTP and SMTP are both layered on MIME. We already have 
a rack of compromises to cope with SMTP junk I am simply
suggesting we make an additional one to cope with HTTP
installed base "junk".

Also note that it might well be sensible to state that a browser
recieving a header signature that supports offline storage 
'should' assemble an S/MIME wrapper out of the parts to allow
the signature to be saved.

What this buys us is the ability to do most of the high value
transaction layer security tricks without folks slaving over 
reams of code and without having to make sure that a
particular browser can cope with the extension. Unfortunately
the only mechanism we have for this in HTTP is the 
user-agent field which was not my choice but is what we
are stuck with.

            Phill

Date: Wed, 31 Dec 1997 09:22:28 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, "'Rich Ankney'" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Sender: [email-masked]

All,

I am not a MAC expert, but I have a few comments anyway.  It seems that the
security processing requirements for MAC objects are significantly different
than the processing requirements for non-MAC signedData objects.  If this is
true, then I believe that it makes more sense to define a separate object
(i.e. Rich's AuthenticatedData proposal) than to add complexity to
signedData (Jim's proposals to add ukm and RecipientIdentifier to
signerInfo).  I assume that Rich's proposal is to use signedData to provide
signature services other than MAC and to use AuthenticatedData to provide
MAC services.  This definition of two distinct objects allows an OID to be
assigned for each which can be used to identify each object.  When a CMS
object is received, the receiving agent can examine the contentInfo
contentType to quickly identify which type of processing is required to
validate the object.  

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

At 02:46 PM 12/30/97 -0800, Jim Schaad (Exchange) wrote:
>I made these changes to the SignedData and Enveloped data fields for two
>reasons:
>
>1.  S/MIME is primarly concerned with the transport of these two
>encoding formats and has not yet defined how to transport other encoding
>types, and
>2.  I wanted to keep the total number of "things" that I had to deal
>with to a minimum.
>
>We could easily add transport of other types if needed.  The second goal
>is just a desire on my part and could easily be overridden by others.
>It may be that the added complexity that I have added to the SignedData
>and EnvelopedData out weight the benifits of having just the two types.
>
>jim
>
>-----Original Message-----
>From: Rich Ankney [mailto:[email-masked]]
>Sent: Tuesday, December 30, 1997 1:13 PM
>To: [email-masked]; John Pawling
>Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
>
>
>> From: John Pawling <[email-masked]>
>> All,
>> 
>> IMHO, CMS should be algorithm independent.  If changes are required to
>> support HMAC (as stated by Jim), then those changes should be
>considered
>for
>> incorporation into CMS.  We should also consider Jim's proposed
>changes
>> related to supporting key agreement algorithms such as the derived
>password
>> keys in PKCS#12.
>>
>The AuthenticatedData structure I proposed several weeks ago (and which
>will
>be in draft 3) was designed explicitly to support HMAC (and DES-MAC).  I
>believe it will support the password derived MAC (at least as defined in
>PKIX-3)
>as well.
> 
>AuthenticatedData uses the key management stuff from EnvelopedData, and
>a SET OF MAC (one MAC per algorithm, allowing different recipients to
>use
>different algorithms:
>
>AuthenticatedData ::= SEQUENCE {
>  version Version,
>  originatorInfo [0] OriginatorInfo OPTIONAL,
>  recipientInfos RecipientInfos,
>  contentInfo contentInfo,
>  macs MACS }
>
>RecipientInfo ::= SEQUENCE {
>  version Version,
>  rid RecipientIdentifier,
>  macAlgorithm AlgorithmIdentifier
>  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>  encryptedKey EncryptedKey }
>
>MACS ::= SET OF MAC
>
>MAC ::= SEQUENCE {
>  algorithm AlgorithmIdentifier,
>  authenticator OCTET STRING }
>
>Notes:
>
>1.   This construct supports provision of an authenticator (MAC) by a
>single
>originator.
>2.  The originator may compute multiple MACs in order to accommodate
>multiple recipients who use different algorithms.  For a given
>algorithm,
>the originator will provide a single MAC, and transport the key to all
>recipients which use that algorithm.
>3.  Key management is based on that in EnvelopedData; the
>macAlgorithm field is added to the RecipientInfo field to assist the
>recipient in locating the appropriate MAC in the MACS field.
>4.  There is no support for multiple originators, or for authenticated
>or 
>unauthenticated attributes.
>5.   Some discussion on deriving both content-encryption and MAC keys
>from
>the same keying material (DH shared secret, or RSA-encrypted "blob" a
>la SSL) might be in order.
>
>Regards,
>Rich
>

Date: Wed, 31 Dec 1997 08:43:54 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Sender: [email-masked]

All,

I now agree with Jim's recommended addition of otherKeyId to
ReceipientIdentifier.  I also agree with Paul that the S/MIME v3 Msg and
Cert specs already specify that X.509 Certs MUST be used in conjunction with
S/MIME msgs.  In summary, I believe that it is appropriate for the CMS spec
to accommmodate non-X.509 certs, but S/MIME msgs MUST use X.509 certs.

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

Date: Tue, 30 Dec 1997 23:38:05 -0200 (EDT)
From: Ed Gerck <[email-masked]>
To: EKR <[email-masked]>
cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

On 30 Dec 1997, EKR wrote:

-> Ed Gerck <[email-masked]> writes:
-> > 1. It is clear that S/MIME does not intend to be a high-security standard
-> > (such as could be used for banking purposes, for company-critical
-> > information exchange, etc.), when you see for example the various
-> > documented security holes that already exist and are simply discarded (to
-> > name a few, the potential "trojan horse"  situation of S/MIME private-key
-> > generation in MSIE, the "on-line" S/MIME private-key generation with the
-> > CA in the same session as used in NS Communicator, the question of no user
-> > choice in the random seed generation for S/MIME private-key generation in
-> > either case, the S/MIME use of self-signed certs, the possibility of
-> > traceless S/MIME private-key snatching with an ActiveX control, etc.).
->
-> AAAAH. These aren't security holes in S/MIME. They're security holes in
-> S/MIME implementations. 

I disagree, because the security holes mentioned are perfectly allowed by
the S/MIME standard.  So, such implementations are 100% S/MIME-compliant
-- which they should never be if the standard would aim at a higher
security level. 

->S/MIME the protocol is perfectly usable in 
-> high security situations. As always, the implementation has to
-> be secure. (Incidentally, all the security holes you mention with
-> the exception of self-signed certs are easily solved by using a 
-> secure hardware token for one's own private keying material.)

I must again disagree. It is a common misconception that a third-party
manufactured hardware token would magically infuse trust into the final
result of a cryptographic calculation. As we know, trapdoors can be easily
inserted into the calculation of keys or signatures, arguably more
stealthly in a hardware token with concealed and secret source code.

-> 
-> > 3. *All* certificate chains eventually end in a self-signed cert.
-> I don't agree with this. A self-signed cert is just one (of many) ways
-> of carrying a root key.
-> 

The issue here is not syntax but semantics. Clearly, a root key does not
exist by itself -- it is issued by someone, which is where the bucket
stops.

It is immaterial if this someone cryptographically signs the public
root-key (to provide for origin and data authentication in an open
environment) or seals it unsigned in a tamper-proof secure token that
provides for origin and data authentication by itself, or "seals" it using
any other method (such as encryption), or etc. In any case, the issuer is
"signing" the root-key (signing as with a seal)  -- either in software, in
hardware, etc. The main point here is that the issuer is adding the same
semantics in any such cases: "This public-key was issued by myself
according to my policy A and its private counterpart is further kept
according to my policy B" -- which you cannot prove or otherwise test for
A or B but must trust if you desire to accept it.

There is no way a root key can exist by itself as an absolute reference --
which makes self-signed (signed in the semantic sense) certs unavoidable
when using extrinsic certificates, which is another you can read my phrase
above.

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

From: Trevor Freeman <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Signing HTTP Transactions
Date: Tue, 30 Dec 1997 18:49:29 -0800
Sender: [email-masked]

Phill,
You might like to read
ftp://ftp.ietf.org/internet-drafts/draft-ietf-wts-shttp-05.txt

Date: Tue, 30 Dec 1997 19:39:23 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
CC: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

David Sternlight wrote:
> 
> David P. Kemp wrote:
> >
> > > From: David Sternlight <[email-masked]>
> > >
> > > > any means except S/MIME.
> > >
> > > Not bad! If a user has to exercise positive seeking behavior to get a
> > > self-signed CA cert ...
> >
> > Get a clue, please.
> 
> This is the first personal attack in this discussion. It has no place here. It
> brings into question the rest of your contribution.
> 
> >  The "any means except S/MIME" suggestion was intended
> > to demonstrate absurdity, not be taken seriously.
> 
> Nevertheless it is a good idea and I give you full credit. It wouldn't be the
> first time someone thinking they were offering a straw man inadvertently
> stumbled onto an insight. Since self-signed CA certs not meeting agreed trust
> standards are an inherent opening for weakness, we should make that "opening"
> in the system fail-safe via the standard. Positive seeking behavior is a way
> to insure that the user can't accidentally foul up either through carelessness
> or under the pressure of time. It must be the user's thoughtful act that
> permits that, not a "push" followed by a possibly naive user simply going along.
> 
> Judging by your e-mail address, don't you work for an organization that spends
> a lot of time on the concept of fail-safe crypto and authentication systems?
> Why not bring some of that flavor (appropriately tailored) to benefit this
> group's work?
> 
> Do you have some local agenda involving self-signed CAs? If so, perhaps it is
> worth discussing openly as part of the evolution of understanding of this issue.
> 
> >
> > "Positive seeking behavior" is a property of applications, not of
> > protocols.
> 
> It is a property of users, if they have no alternative. The standard can be so
> written as to preclude push CA certificates of unknown trustworthiness, and
> thus require the user to obtain them exogenously.
> 
> >
> > Please discuss application design and security ergonomics somewhere
> > else - it is off-topic for the IETF S/MIME protocol working group.
> 
> Nice lateral arabesque. By redefining my suggestion away from inclusion in the
> standard (where it CAN be included), you convert it to "application design and
> security ergonomics", which in turn permits you to say "off topic." But as the
> first response to my post, from the head of the IMC said, it is both apt and timely.
> 
> David

I think that if we take this "positive seeking behavior" idea
as a standards requirement to wall, it's wisdom becomes numbingly
clear. To really, really test the level-headedness and worthiness
of the user in his quest for the one true self-signed Certificate, 
I suggest that the user be required to solve a riddle, or he gets 
no Cert.

How about one like the following?

  "How old are your family of three?" asked the census taker.

  "Well, the product of their ages is 2450" said his friend the banker.

  The census taker looked wary; "Anything else?" he asked.

  "Altogether their ages total yours" said the banker.

  The census taker looked a lot more cheerful. "Ah!" he said, 
  scribbling a few notes, but then he paused, looked puzzled,
  then he entered into the spirit and asked: "Are they all 
  younger than you?"

  "Yes" said the banker.

  "Thank you very much" said the census taker, writing down 
  the ages of the family.

What were the ages of all FIVE (the census taker,
the banker, and his three family) people.

Happy New Year! :-)

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, [email-masked], John Pawling <[email-masked]>
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Date: Tue, 30 Dec 1997 14:46:57 -0800
Sender: [email-masked]

I made these changes to the SignedData and Enveloped data fields for two
reasons:

1.  S/MIME is primarly concerned with the transport of these two
encoding formats and has not yet defined how to transport other encoding
types, and
2.  I wanted to keep the total number of "things" that I had to deal
with to a minimum.

We could easily add transport of other types if needed.  The second goal
is just a desire on my part and could easily be overridden by others.
It may be that the added complexity that I have added to the SignedData
and EnvelopedData out weight the benifits of having just the two types.

jim

-----Original Message-----
From: Rich Ankney [mailto:[email-masked]]
Sent: Tuesday, December 30, 1997 1:13 PM
To: [email-masked]; John Pawling
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS

> From: John Pawling <[email-masked]>
> All,
> 
> IMHO, CMS should be algorithm independent.  If changes are required to
> support HMAC (as stated by Jim), then those changes should be
considered
for
> incorporation into CMS.  We should also consider Jim's proposed
changes
> related to supporting key agreement algorithms such as the derived
password
> keys in PKCS#12.
>
The AuthenticatedData structure I proposed several weeks ago (and which
will
be in draft 3) was designed explicitly to support HMAC (and DES-MAC).  I
believe it will support the password derived MAC (at least as defined in
PKIX-3)
as well.
 
AuthenticatedData uses the key management stuff from EnvelopedData, and
a SET OF MAC (one MAC per algorithm, allowing different recipients to
use
different algorithms:

AuthenticatedData ::= SEQUENCE {
  version Version,
  originatorInfo [0] OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  contentInfo contentInfo,
  macs MACS }

RecipientInfo ::= SEQUENCE {
  version Version,
  rid RecipientIdentifier,
  macAlgorithm AlgorithmIdentifier
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

MACS ::= SET OF MAC

MAC ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  authenticator OCTET STRING }

Notes:

1.   This construct supports provision of an authenticator (MAC) by a
single
originator.
2.  The originator may compute multiple MACs in order to accommodate
multiple recipients who use different algorithms.  For a given
algorithm,
the originator will provide a single MAC, and transport the key to all
recipients which use that algorithm.
3.  Key management is based on that in EnvelopedData; the
macAlgorithm field is added to the RecipientInfo field to assist the
recipient in locating the appropriate MAC in the MACS field.
4.  There is no support for multiple originators, or for authenticated
or 
unauthenticated attributes.
5.   Some discussion on deriving both content-encryption and MAC keys
from
the same keying material (DH shared secret, or RSA-encrypted "blob" a
la SSL) might be in order.

Regards,
Rich

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Date: Tue, 30 Dec 1997 14:42:59 -0800
Sender: [email-masked]

I don't believe that even if we disallowed other certificate types I
would want to change the proposal.  The reason for this is so that we
can get other means of identification into the system.  As an example:
If I am sending an enrollment message to a RA which has previously
issued me a name and token.  I need to put my name someplace so that it
can look up my token and do the correct things to get a common
encryption key.  The correct place to put this identification
information would be in the recipientId structure.  This requires the
ability to put in a non X509 identification field.  Thus I think my
proposal stands as is.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 30, 1997 12:21 PM
To: [email-masked]
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS

All,

IMHO, CMS should be algorithm independent.  If changes are required to
support HMAC (as stated by Jim), then those changes should be considered
for
incorporation into CMS.  We should also consider Jim's proposed changes
related to supporting key agreement algorithms such as the derived
password
keys in PKCS#12.

However, I don't believe that we should change CMS to accommodate
non-X.509
certificates. I believe that the S/MIME community has agreed that the
X.509
Certificate syntax will be the standard format for binding an entity's
public key with its identity.  Allowing other forms of certificates to
be
used will adversely impact interoperability.  I believe that Jim should
re-submit his proposal such that it does not include any changes solely
aimed at accommodating non-X.509 certificates.

One could make the argument that CMS is intended for use by application
environments other than S/MIME some of which may choose to use a format
other than the X.509 Certificate syntax.  In that case, it may be
appropriate to make Jim's recommended changes to the CMS format, but to
include text in the S/MIME v3 Message and Cert specs stating that only
X.509
Certificates can be used in S/MIME messages.

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

Date: Tue, 30 Dec 1997 14:29:59 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: David Sternlight <[email-masked]>
> >
> > > any means except S/MIME.
> >
> > Not bad! If a user has to exercise positive seeking behavior to get a
> > self-signed CA cert ...
> 
> Get a clue, please.

This is the first personal attack in this discussion. It has no place here. It
brings into question the rest of your contribution.

>  The "any means except S/MIME" suggestion was intended
> to demonstrate absurdity, not be taken seriously.

Nevertheless it is a good idea and I give you full credit. It wouldn't be the
first time someone thinking they were offering a straw man inadvertently
stumbled onto an insight. Since self-signed CA certs not meeting agreed trust
standards are an inherent opening for weakness, we should make that "opening"
in the system fail-safe via the standard. Positive seeking behavior is a way
to insure that the user can't accidentally foul up either through carelessness
or under the pressure of time. It must be the user's thoughtful act that
permits that, not a "push" followed by a possibly naive user simply going along.

Judging by your e-mail address, don't you work for an organization that spends
a lot of time on the concept of fail-safe crypto and authentication systems?
Why not bring some of that flavor (appropriately tailored) to benefit this
group's work?

Do you have some local agenda involving self-signed CAs? If so, perhaps it is
worth discussing openly as part of the evolution of understanding of this issue.

> 
> "Positive seeking behavior" is a property of applications, not of
> protocols.

It is a property of users, if they have no alternative. The standard can be so
written as to preclude push CA certificates of unknown trustworthiness, and
thus require the user to obtain them exogenously. 

> 
> Please discuss application design and security ergonomics somewhere
> else - it is off-topic for the IETF S/MIME protocol working group.

Nice lateral arabesque. By redefining my suggestion away from inclusion in the
standard (where it CAN be included), you convert it to "application design and
security ergonomics", which in turn permits you to say "off topic." But as the
first response to my post, from the head of the IMC said, it is both apt and timely.

David

Date: Tue, 30 Dec 1997 14:02:43 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
Sender: [email-masked]

>One could make the argument that CMS is intended for use by application
>environments other than S/MIME some of which may choose to use a format
>other than the X.509 Certificate syntax.  In that case, it may be
>appropriate to make Jim's recommended changes to the CMS format, but to
>include text in the S/MIME v3 Message and Cert specs stating that only X.509
>Certificates can be used in S/MIME messages.

I believe that this is correct. If we can do it without torture, we should
allow other cert types without specifying them. We already say "MUST use
PKIX-style certs" in  the S/MIME certs draft, so there won't be any
questions what you have to use in order to interoperate, but we should make
it easy (if we can) to allow expansion for non-S/MIME use of CMS.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
Date: Tue, 30 Dec 1997 16:12:38 -0500
Sender: [email-masked]

> From: John Pawling <[email-masked]>
> All,
> 
> IMHO, CMS should be algorithm independent.  If changes are required to
> support HMAC (as stated by Jim), then those changes should be considered
for
> incorporation into CMS.  We should also consider Jim's proposed changes
> related to supporting key agreement algorithms such as the derived
password
> keys in PKCS#12.
>
The AuthenticatedData structure I proposed several weeks ago (and which
will
be in draft 3) was designed explicitly to support HMAC (and DES-MAC).  I
believe it will support the password derived MAC (at least as defined in
PKIX-3)
as well.
 
AuthenticatedData uses the key management stuff from EnvelopedData, and
a SET OF MAC (one MAC per algorithm, allowing different recipients to use
different algorithms:

AuthenticatedData ::= SEQUENCE {
  version Version,
  originatorInfo [0] OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  contentInfo contentInfo,
  macs MACS }

RecipientInfo ::= SEQUENCE {
  version Version,
  rid RecipientIdentifier,
  macAlgorithm AlgorithmIdentifier
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

MACS ::= SET OF MAC

MAC ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  authenticator OCTET STRING }

Notes:

1.   This construct supports provision of an authenticator (MAC) by a
single
originator.
2.  The originator may compute multiple MACs in order to accommodate
multiple recipients who use different algorithms.  For a given algorithm,
the originator will provide a single MAC, and transport the key to all
recipients which use that algorithm.
3.  Key management is based on that in EnvelopedData; the
macAlgorithm field is added to the RecipientInfo field to assist the
recipient in locating the appropriate MAC in the MACS field.
4.  There is no support for multiple originators, or for authenticated or 
unauthenticated attributes.
5.   Some discussion on deriving both content-encryption and MAC keys from
the same keying material (DH shared secret, or RSA-encrypted "blob" a
la SSL) might be in order.

Regards,
Rich

Date: Tue, 30 Dec 1997 15:20:58 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS
Sender: [email-masked]

All,

IMHO, CMS should be algorithm independent.  If changes are required to
support HMAC (as stated by Jim), then those changes should be considered for
incorporation into CMS.  We should also consider Jim's proposed changes
related to supporting key agreement algorithms such as the derived password
keys in PKCS#12.

However, I don't believe that we should change CMS to accommodate non-X.509
certificates. I believe that the S/MIME community has agreed that the X.509
Certificate syntax will be the standard format for binding an entity's
public key with its identity.  Allowing other forms of certificates to be
used will adversely impact interoperability.  I believe that Jim should
re-submit his proposal such that it does not include any changes solely
aimed at accommodating non-X.509 certificates.

One could make the argument that CMS is intended for use by application
environments other than S/MIME some of which may choose to use a format
other than the X.509 Certificate syntax.  In that case, it may be
appropriate to make Jim's recommended changes to the CMS format, but to
include text in the S/MIME v3 Message and Cert specs stating that only X.509
Certificates can be used in S/MIME messages.

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

Date: Tue, 30 Dec 1997 15:02:43 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

> From: David Sternlight <[email-masked]>
>
> > any means except S/MIME.
> 
> Not bad! If a user has to exercise positive seeking behavior to get a
> self-signed CA cert ...

Get a clue, please.  The "any means except S/MIME" suggestion was intended
to demonstrate absurdity, not be taken seriously.

"Positive seeking behavior" is a property of applications, not of
protocols.  If an MUA is designed to fetch and install root certs
automatically, without user intervention, then the specific protocol
(LDAP, http, ftp ...) used to transport the cert is immaterial.

Please discuss application design and security ergonomics somewhere
else - it is off-topic for the IETF S/MIME protocol working group.

Date: Tue, 30 Dec 1997 11:29:48 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: David Sternlight <[email-masked]>
> >
> > This isn't about openness or freedom. It is about arms-length trust when the
> > parties are pretty much all at the ends of wires and there are massive
> > economies of scale/effort in having trusted, audited,
> > certification-operation-standards-meeting CAs and only those CAs in at least
> > this ietf standard.
> 
> David,
> 
> I agree with your ends, but do not believe that your means (putting
> restrictions in the S/MIME protocol spec) can be effective in achieving
> them.
> 
> We agree that there must be some mechanism whereby a "domain
> administrator" (individual user, IT staff person, security officer,
> software manufacturer, the Federal Reserve, etc) is able to control
> which CAs are to be trusted within a particular domain.  A "domain" as
> used here could be a single machine at home, a corporation or division
> or branch, a political/regulatory environment such as the banking system,
> etc.
> 
> If I understand your argument, you are claiming that software
> manufacturers (or the IETF?) should be the only entities capable of
> specifying the list of acceptable root CAs, and that the consumer's
> control should be limited to disabling entries on the list, not adding
> CAs to it.  It should be obvious that that solution would never fly -
> the MUA vendor could not possibly be expected to be the trust
> administrator for all possible domains in which the product might be
> used.
> 
> So perhaps you are arguing for a more limited form of technical control -
> users should be able to specify the list of trusted CAs, but an entry
> on that list could not be received in an S/MIME message, it would have
> to be retrieved by LDAP, floppy disk, non-secure email, ftp, http, or
> any means except S/MIME.

Not bad! If a user has to exercise positive seeking behavior to get a
self-signed CA cert which didn't meet generally accepted and audited trust
requirements, and there were no possibility of an inadvertence (as there could
be if it were passed via an S/MIME message and the user given an
"accept/reject" choice), that would meet many of my objectives. I would add
only one thing--a mechanism that prevented such accepted CA certs from being
transitive--that is: EACH user who wished to accept such a cert would have to
engage in similar positive seeking behavior with respect to getting the CA's
cert. I recognize that this makes it more difficult to propagate such
self-signed CA certs, and makes it harder to authenticate/decrypt traffic
received for the first time that is certified BY such CAs, but that's the
point of protection.

> 
> No, that's not what you meant?
> 
> Perhaps you want S/MIME to mandate the form of user interface to be
> used to administer the trusted CA list - it would be unacceptable to
> present a dialog box saying:
> 
>   Root cert received via S/MIME - click on:
>     a) accept for this message,
>     b) accept for all messages,
>     c) don't accept.
> 
> But it would be acceptable to, for example, present a box that said:
> 
>  "Root cert received via S/MIME.  To enable use of this cert as
>   a trusted CA, save it to a file, then enter it into the certificate
>   registry using the TrustEdit utility."

I'm not quite comfortable with this, since again the user is presented with
the CA cert and has to go through a (more difficult) accept/reject process. It
is not positive SEEKING behavior since the user doesn't have the additional
responsibility of going himself to a site he trusts to get the CA's cert via
pull. Instead, he gets it via push, albeit with decision points.

> 
> No, I didn't think you were advocating micromanagement of the user
> interface either.  Besides, the IETF does not do UIs, it does protocols.

How the thing is implemented could be left to the software designers. But the
rule--"no self-signed push CA certs" is easy enough to put in the standard.

> 
> 
> > I think it very important that this sub-topic not be clouded with ideological
> > issues. I think, instead, it's about (as much as feasible) reliable,
> > dependable, count-on-able systems for global trust.
> >
> > David
> 
> To the extent that "global trust" is not oxymoronic, it must be
> accomplished by social means (legislation/regulation, advertising /
> brand loyalty, consumer reporting, insurance, etc), not by technical
> controls.  Attempting to establish a foundation for "global trust" by
> manipulating the S/MIME protocol specification is doomed to failure.

I think that while in principle you're correct, in practice proper systems
design can either enhance confidence or make its achievement more difficult.

Best;
David

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Weakening the rigid heirarchical trust model
Date: Tue, 30 Dec 1997 14:33:35 -0500
Sender: [email-masked]

>My point is the same one that has lead to all sorts of
>assurance systems and exclusions from membership of those who don't meet
>specified standards in credit card systems, banking systems, etc. Secure
>e-mail should be no different.

This is an IETF working group. The idea is to arrive at a technical
specification for a protocol. The idea is not to tell other folk how
to run their life.

IETF process is like herding cats. The only sure way I know to 
get people to do something is to absolutely forbid them to do it.

I don't see how any statement of the sort you propose would be
anything other than be damaging and counter-productive.

In any case both S/MIME and PGP have been ordered by the 
IESG to standardize message formats. PKI is the realm of PKIX
and SPKI. I suggest you take this discussion to one of those 
groups David, preferably SPKI.

            Phill

Date: Tue, 30 Dec 1997 11:05:30 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

Phillip M Hallam-Baker wrote:
> 
> >In the end the user MUST be the one resonsible for make the judgement
> >call about what is and is not a good CA for their purposes.
> 
> I agree with this point as well and would use it to utterly refute
> David and Ed's arguments against self signed certs and such.

Since you fail to distinguish between ethical (or legal)  responsibility and
practical behavior, I do not see how this is refutatory. That is: while if I
accept a "generally accepted" CA without checking their balance sheet,
auditing procedures, personnel, etc., I am ultimately responsible (leaving
aside litigation or offered indemnities) for the consequences, that does not
mean that most Internet users are capable or willing to take on such an
onerous burden. Thus the system should offer the greatest confidence possible,
recognizing pragmatically how users will behave and how to facilitate useful
systems at scale. My point is the same one that has lead to all sorts of
assurance systems and exclusions from membership of those who don't meet
specified standards in credit card systems, banking systems, etc. Secure
e-mail should be no different.

Creating an opening for self-signed CAs meeting no standards at all is not the
way to increase such confidence.

> 
> There are no 'high security' protocols, the class simply cannot
> exist. There are only high security _systems_, that is systems
> comprising protocols and operating proceedures which
> together provide a given level of assurance that certain
> specified risks have been guarded against.

This is not about perfection. There can be no perfection. This is about
"better" for the group in the large (in this case at the expense of a
relatively few who would find being able to be a self-signed CA convenient or
who just don't like a system that has rules, for aesthetic or ideological reasons).

> 
> The only valid reason for restricting a protocol in the manner
> suggested would be if the forbiden mode of operation was
> inherently insecure. It is not.

That some CAs could be fiat CAs meeting no trust standards IS inherently insecure.

> 
> I think we should let this argument rest. Open PGP has at this
> point only one supporter of consequence, Qualcomm. With
> everyone else in the S/MIME camp and PGP just rescued
> from bankrupcy the outcome is not hard to guess. We should
> be looking to see how we can salvage what is best from the
> PGP experiment rahter than continue to fight a war that
> has been won as far as the desktop goes.

I do not see this as having anything to do with ideological wars or winning or
losing. I see it as creating a secure/authenticated e-mail system in which
people in the large at global internet scale, who do not know each other, can
have enough confidence they are will use it transparently.

> 
> The problem we have is that many of the people who are the
> natural early adopter constituency for S/MIME have not
> realised that PGP is dead. In other words we have won the
> standards battle but not the mind share battle.

I suggest this kind of argument polarizes the discussion in this group on this
point. It is best avoided.

> 
> I see no reason to alienate a significant user base simply to
> trample on the remains of a PKI model that isn't viable in
> any case. I don't think that most PGP users want to be a
> CA, they just want to have that option.

Arguing that a weakness should be included because it will make some whom you
feel have lost some battle feel better isn't the way to develop confidence in
a security standard. And arguing that a security hole is ok because it
probably won't be used much seems equally unpersuasive.

This isn't about "trampling" on anything. It is about creating confidence in a standard.

Best;
David

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>
Subject: Signing HTTP Transactions
Date: Tue, 30 Dec 1997 13:51:57 -0500
Sender: [email-masked]

Hello all.

    Since S/MIME is based on top of MIME and HTTP is meant to be MIME based
these days S/MIME is clearly one vehicle for signing an HTTP page. This even
works today if one uses Navigator (well sortof).

    Should we be explicitly considering HTTP as a transport for S/MIME? In
particular the ability to sign documents in a manner compatible with
existing browsers would be handy.

    A particular application in mind being the VeriSign repository. I would
like folk downloading the CPS to always get a signature. This would
facilitate remote checking of the service to check that the server had not
been hacked.

    Note that this is a completely different requirement to SSL which is
basically oriented towards session confidentiality. If Kevin Mitnick
captures your server it will serve up the new pages regardless...

    Essentially I am arguing that a webmaster in charge of a sensitive site
is likely to want to have the signing key for content stored offline (e.g.
its on a smartcard she carries arround her neck). Gosh - they would need a
second certificate!

    A really paranoid Webmaster would probably want the server to check the
signature of pages internally before publishing them. Folk can work out the
obvious means of caching the publishing authorization themselves...

    The simplest mechanism for achieving this objective consistent with the
PKIX, S/MIME base already present in the browser is a new header to carry a
pkcs #7 detached signature. ie:

GET /fribble.html HTTP/1.1
Hostname: fool.com
Date: 1-Apr-1997

HTTP/1.1 201 O.K. (sort of)
Content-Type: text/html
Content-Signature: a+slekruaseoituaaweyqwpoetoqsweytluqwetgyqwerty
    qwliue/qwetluyqwietyqwieytoiqweytoiqwyetoiuqwyetoiuqyw
    etouyqweoty
Content-Length: 1034

<HTML>
... etc

    The advantages of this approach are that the signature causes no problem
if it is recieved by IE 3.0 or Navigator 3.0. There is a risk that a proxy
might fish out the content signature header but this should just be a matter
of configuring the firewall.

    Questions

1) is there an interest in this application?

2) are there other considerations.

3) How/where should it be described? In the S/MIMEv3 description? As a
separate draft?

Altertnatively we can wait to see if whatever comes out of the W3C
PICS/DigSig proposal is acceptable. At this point however I think the
existing investment in PKCS#7 infrastructure makes its use as an envelope
format here (albeit in detached form) a slam dunk.

What I would like to do with the DigSig work is to take the assertion model,
issue it an OID and wrap it up in PKCS#7 and X.509v3. The SPKI/SDSI stuff
looked a good idea two years ago when that project was kicked off but I
don't think its viable at this point. With the CDA dead the momentum behind
PICS is flagging and it appears many see it as a future liability, possibly
allowing a censorship bill to be passed more justices would find
constitutional (cf the Lessig argument picked up by O'Connor). Hence the
DigSig links to the PICS censorship scheme is also a liability.

            Phill

Date: Tue, 30 Dec 1997 10:35:23 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

Ed Gerck wrote:
> 
> On Mon, 29 Dec 1997, David Sternlight wrote:
> 
> 1. It is clear that S/MIME does not intend to be a high-security standard
> (such as could be used for banking purposes, for company-critical
> information exchange, etc.), when you see for example the various
> documented security holes that already exist and are simply discarded (to
> name a few, the potential "trojan horse"  situation of S/MIME private-key
> generation in MSIE, the "on-line" S/MIME private-key generation with the
> CA in the same session as used in NS Communicator, the question of no user
> choice in the random seed generation for S/MIME private-key generation in
> either case, the S/MIME use of self-signed certs, the possibility of
> traceless S/MIME private-key snatching with 
>an ActiveX control, etc.)

E-mail is often used for purposes requiring high security/high assurance. An
open hole in a system (such as permitting anyone to self-sign a CA
certificate) is, I have argued, simply a Bad Idea. That other open holes may
exist through implementation or other problems doesn't justify it--the others
ought to be addressed as well.

As to the specifics above, if MSIE has problems they ought to be addressed by
MS, not used as a reason to weaken the standard in other areas; same for NS;
not clear how serious the random seed issue is; S/MIME's use doesn't mean this
standard can't be more robust; Active X's problems should not be a
justification for weakening this standard, "etc.".

To: Ed Gerck <[email-masked]>
Cc: David Sternlight <[email-masked]>, [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
From: EKR <[email-masked]>
Date: 30 Dec 1997 08:12:32 -0800
Lines: 27
Sender: [email-masked]

Ed Gerck <[email-masked]> writes:
> 1. It is clear that S/MIME does not intend to be a high-security standard
> (such as could be used for banking purposes, for company-critical
> information exchange, etc.), when you see for example the various
> documented security holes that already exist and are simply discarded (to
> name a few, the potential "trojan horse"  situation of S/MIME private-key
> generation in MSIE, the "on-line" S/MIME private-key generation with the
> CA in the same session as used in NS Communicator, the question of no user
> choice in the random seed generation for S/MIME private-key generation in
> either case, the S/MIME use of self-signed certs, the possibility of
> traceless S/MIME private-key snatching with an ActiveX control, etc.).
AAAAH. These aren't security holes in S/MIME. They're security holes in
S/MIME implementations. S/MIME the protocol is perfectly usable in
high security situations. As always, the implementation has to
be secure. (Incidentally, all the security holes you mention with
the exception of self-signed certs are easily solved by using a 
secure hardware token for one's own private keying material.)

> 3. *All* certificate chains eventually end in a self-signed cert.
I don't agree with this. A self-signed cert is just one (of many) ways
of carrying a root key.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Tue, 30 Dec 1997 10:08:47 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

> From: David Sternlight <[email-masked]>
> 
> This isn't about openness or freedom. It is about arms-length trust when the
> parties are pretty much all at the ends of wires and there are massive
> economies of scale/effort in having trusted, audited,
> certification-operation-standards-meeting CAs and only those CAs in at least
> this ietf standard.

David,

I agree with your ends, but do not believe that your means (putting
restrictions in the S/MIME protocol spec) can be effective in achieving
them.

We agree that there must be some mechanism whereby a "domain
administrator" (individual user, IT staff person, security officer,
software manufacturer, the Federal Reserve, etc) is able to control
which CAs are to be trusted within a particular domain.  A "domain" as
used here could be a single machine at home, a corporation or division
or branch, a political/regulatory environment such as the banking system,
etc.

If I understand your argument, you are claiming that software
manufacturers (or the IETF?) should be the only entities capable of
specifying the list of acceptable root CAs, and that the consumer's
control should be limited to disabling entries on the list, not adding
CAs to it.  It should be obvious that that solution would never fly -
the MUA vendor could not possibly be expected to be the trust
administrator for all possible domains in which the product might be
used.

So perhaps you are arguing for a more limited form of technical control -
users should be able to specify the list of trusted CAs, but an entry
on that list could not be received in an S/MIME message, it would have
to be retrieved by LDAP, floppy disk, non-secure email, ftp, http, or
any means except S/MIME.

No, that's not what you meant?

Perhaps you want S/MIME to mandate the form of user interface to be
used to administer the trusted CA list - it would be unacceptable to
present a dialog box saying:

  Root cert received via S/MIME - click on:
    a) accept for this message,
    b) accept for all messages,
    c) don't accept.

But it would be acceptable to, for example, present a box that said:

 "Root cert received via S/MIME.  To enable use of this cert as
  a trusted CA, save it to a file, then enter it into the certificate
  registry using the TrustEdit utility."

No, I didn't think you were advocating micromanagement of the user
interface either.  Besides, the IETF does not do UIs, it does protocols.

 
> I think it very important that this sub-topic not be clouded with ideological
> issues. I think, instead, it's about (as much as feasible) reliable,
> dependable, count-on-able systems for global trust.
> 
> David

To the extent that "global trust" is not oxymoronic, it must be
accomplished by social means (legislation/regulation, advertising /
brand loyalty, consumer reporting, insurance, etc), not by technical
controls.  Attempting to establish a foundation for "global trust" by
manipulating the S/MIME protocol specification is doomed to failure.

David K.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Jim Schaad (Exchange)" <[email-masked]>, <[email-masked]>
Subject: Re: Weakening the rigid heirarchical trust model
Date: Tue, 30 Dec 1997 09:45:32 -0500
Sender: [email-masked]

>My feeling on this, and one that is backed up by management at
>Microsoft, is that Microsoft does not want to even think about the
>responsability of deciding on what basis a Certificate Authority should
>be judged and then try and do the necessary follow up work in order to
>make sure that the standards are being held to.  

While I would agree to this point, it does not mean that the user
is necessarily going to have no guidance on what standards and
precautions a CA takes. There are auditing standards for security
such as SAS 70, there are even companies who make a business
essentially out of accrediting CAs (gosh guess who they might be!)

>In the end the user MUST be the one resonsible for make the judgement
>call about what is and is not a good CA for their purposes.  

I agree with this point as well and would use it to utterly refute
David and Ed's arguments against self signed certs and such.

There are no 'high security' protocols, the class simply cannot
exist. There are only high security _systems_, that is systems
comprising protocols and operating proceedures which
together provide a given level of assurance that certain
specified risks have been guarded against.

The only valid reason for restricting a protocol in the manner 
suggested would be if the forbiden mode of operation was
inherently insecure. It is not. The problem with Web of Trust
is that the folk who can use it competently is probably less
than one percent of the population and the largest feasible 
community of trust is about ten thousand folk. I accept the
fact that Jeff Schiller has the ability to issue ten thousand 
odd PGP certs to MIT's Athena users, but guess what? he is
acting as a CA. There is no essential difference between the
MIT PGP cert server and their X.509 cert server except that
an S/MIME client makes it easy to note that there is something
rather special about the X.509 root certificate.

I think we should let this argument rest. Open PGP has at this
point only one supporter of consequence, Qualcomm. With
everyone else in the S/MIME camp and PGP just rescued
from bankrupcy the outcome is not hard to guess. We should
be looking to see how we can salvage what is best from the 
PGP experiment rahter than continue to fight a war that
has been won as far as the desktop goes.

The problem we have is that many of the people who are the 
natural early adopter constituency for S/MIME have not
realised that PGP is dead. In other words we have won the
standards battle but not the mind share battle.

I see no reason to alienate a significant user base simply to
trample on the remains of a PKI model that isn't viable in
any case. I don't think that most PGP users want to be a
CA, they just want to have that option.

            Phill

Date: Tue, 30 Dec 1997 04:48:24 -0200 (EDT)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: David Sternlight <[email-masked]>
cc: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

On Mon, 29 Dec 1997, David Sternlight wrote:

David:

I have enjoyed the postings and the replies on the thread you initiated on
the subject above. The fact that you cited my paper (Overview of
Certification Systems) may have helped ;-) 

However, I have five comments.

1. It is clear that S/MIME does not intend to be a high-security standard
(such as could be used for banking purposes, for company-critical
information exchange, etc.), when you see for example the various
documented security holes that already exist and are simply discarded (to
name a few, the potential "trojan horse"  situation of S/MIME private-key
generation in MSIE, the "on-line" S/MIME private-key generation with the
CA in the same session as used in NS Communicator, the question of no user
choice in the random seed generation for S/MIME private-key generation in
either case, the S/MIME use of self-signed certs, the possibility of
traceless S/MIME private-key snatching with an ActiveX control, etc.).

2. What is the goal of S/MIME? S/MIME wants to be a simple no-liability
(i.e., to the companies involved, as has been clearly spelled out in this
thread) system that can provide for "secure" e-mail messages as the
average user may need them, where "secure" means whatever you care to
understand by that word. How good is a S/MIME signature in an e-mail
message if your private-key may have already been compromised when it was
generated, or snatched at a later time? As has been often said, you get as
much as you paid for it (browsers and its S/MIME MUAs are essentially
free, as we all know) and different vendors may offer more bells and
whistles.

3. *All* certificate chains eventually end in a self-signed cert. So,
self-signed certs MUST be acceptable by S/MIME and the text you quoted
MUST NOT be dropped otherwise you would just need to introduce yet another
way to accept a self-signed root certificate -- which would defeat the
purpose of prohibiting it. It's the CA paradox -- "trust me because you
have no other choice". So, by further induction, there is no sense in
S/MIME for banning other self-signed certs just because they did not come
from a CA.

{The true and (provable) only solution to this Catch 22 situation is to
use intrinsic certificates (that can be used by themselves or to bootstrap
conventional extrinsic certificates such as a CA's). This is referenced in
http://mcg.org.br/intrinsic.htm}

4. With the current model, then, S/MIME may indeed coherently accept
self-signed certs because the deployed trust model is already local --
i.e., either the CA is trusted by you or it can be trusted if it is
trusted by a CA you trust, you know who self-signed the cert, etc. In
other words, this builds up a local trust domain, which is perfectly valid
for users in its domain (whereas being a leap of faith on a global level,
but that is besides the point) 

5. Within such a parochial model, a further increase in the security level
can only be achieved with insurance -- such as already being sold by
VeriSign for S/MIME certs, which has the added benefit of providing for a
secondary market (and a tertiary market for lawyers specialized in
international liability, consulting and litigation) without decreasing the
first.

Cheers,

Ed

-> One reader sent me an e-mail indicating that he didn't see what my original
-> post had to do with the deliberations of this group. Here is a copy of the
-> clarifying response I sent him:
-> 
-> My objection is based on the current quote from draft-ietf-smime-cert:
-> 
-> "Clients MAY send CA certificates, that is, certificates that are self-
-> signed and can be considered the "root" of other chains. Note that
-> receiving agents SHOULD NOT simply trust any self-signed certificates
-> as valid CAs, but SHOULD use some other mechanism to determine if this
-> is a CA that should be trusted."
-> 
-> The provision of self-signed CA certificates corrupts the rigid heirarchical
-> model, and I think the hand-waving "should use some other mechanism" casts the
-> huge body of arms-length users unable or unwilling to check such a CA's bona
-> fides adrift. It can ruin the "bank check/credit card" model of S/MIME as
-> practiced in Netscape and Explorer via Verisign and the many other certifiers,
-> where CAs are required to conform to specified standards, and are audited to
-> that, just as banks are supervised by the Controller of the Currency, and
-> credit card issuers by VISA, MASTER CARD, etc. While I have no objection to
-> web of trust as a separate model in some other standard, to weaken S/MIME in
-> this way can destroy its usefulness as a routinely trusted medium (just
-> as are VISA and MASTER CARDS and checks after perhaps checking only the
-> individual account's validity--corresponding to a user's public key).
-> 
-> I speak as a professional economist. For details, read any good introductory
-> economics text on money and banking. The conceptual issues are exactly the
-> same for trust here (whether for e-mail or transactions) as they were in the
-> abolition of specie money and the rise of national banking systems, and
-> subsequently national and international credit card systems.
-> 
-> My recommendation is that the subject paragraph, and any other opening for
-> self-signed CA certificates be dropped from the standard.
-> 
-> David
-> 

______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

Date: Mon, 29 Dec 1997 20:59:31 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

Phillip H. Griffin wrote:
> 
> >From nothing more than a personal freedom perspective, I really
> warm to the idea of everyone, everywhere, whether they're just
> plain humans, or licensed, audited and certified entities, being
> allowed to create and distribute their own certs, to anyone,
> anywhere, that's willing to trust them. It just seems to me like
> a more open posture for a standard to take.

As a political position it is certainly as legitimate for you as the
anarchist, or libertarian, or socialist, or democratic, or republican
positions are for them. But as the basis for a global internet trust system
viable for trusted e-mail and related interactions including commercial
interaction via e-mail among arms-length parties, consider the analogous
consequences if everyone could print their own money or their own checks, or
other trust documents. 

This isn't about openness or freedom. It is about arms-length trust when the
parties are pretty much all at the ends of wires and there are massive
economies of scale/effort in having trusted, audited,
certification-operation-standards-meeting CAs and only those CAs in at least
this ietf standard. It's a technical, not a values issue. Not to put too fine
a point on it, I think it can make the difference between a successful system,
and one that will die slowly of its own internal contradictions.

I think it very important that this sub-topic not be clouded with ideological
issues. I think, instead, it's about (as much as feasible) reliable,
dependable, count-on-able systems for global trust.

David

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: Weakening the rigid heirarchical trust model
Date: Mon, 29 Dec 1997 20:57:27 -0800
Sender: [email-masked]

Paul Wrote:

> In fact, I think you are overestimating when you suggest that today's
> deployed S/MIME v2 applications don't allow them. At the S/MIME
testing at
> MailConnect 3, I heard that some vendors accepted self-signed certs,
and
> others didn't. Deming, Microsoft, Netscape, and other developers are
> encouraged to jump in here and say what their shipping receiving MUAs
do
> when mailed a self-signed cert.

My feeling on this, and one that is backed up by management at
Microsoft, is that Microsoft does not want to even think about the
responsability of deciding on what basis a Certificate Authority should
be judged and then try and do the necessary follow up work in order to
make sure that the standards are being held to.  Not only is this a
problem from the standpoint of manpower, but it is also a legal
liability in the event that it messed up by somebody and money changes
hands.

In the end the user MUST be the one resonsible for make the judgement
call about what is and is not a good CA for their purposes.  This
judgement call will be a much different basis for a bank or store where
money and liability are going to change hands, than in the case where my
mother is deciding as to wheither the message was really sent by my
sister where information about the certificate (self-signed perhaps)
could be send on the side.  (It may also be that she doesn't really care
in most cases about wheither it really is my sister as long as it can
reasonibly be assumed to be my sister.)

On this bases we (the S/MIME working group) cannot make a statment as to
how the root of all trust should be decided.  I think that Paul may not
be far off base with the comment that it makes sense to put something in
the security considerations, but it does not belong in the base of the
specification.

jim schaad
Microsoft Outlook

Date: Mon, 29 Dec 1997 18:48:24 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 04:33 PM 12/29/97 -0800, David Sternlight wrote:
> >The provision of self-signed CA certificates corrupts the rigid heirarchical
> >model, and I think the hand-waving "should use some other mechanism" casts
> the
> >huge body of arms-length users unable or unwilling to check such a CA's bona
> >fides adrift.
> 
> A valid concern, but one that I do not agree with.

I understand that you disagree. Without in any way delegitimizing your
opinion, some comments:

> This is a mail spec, not
> a banking spec.

Mail is used for many things, including placing orders and passing legal or
other documents which require strong validity. In citing the evolution of
banking and credit card systems I did not mean to suggest that we're
discussing that here, but rather that the trust issues, and the "bad money
driving out good" issues (as for example when anyone could issue scrip money
and the burden was on the user to check out the issuer), apply as well to any
standard intended to provide a fecund base for internet-wide trusted mail at
scale among arms-length participants.

> We have exactly two choices: allow self-signed certs or
> disallow them. I think the current wording, which tells MUAs that they
> might want to allow them but the must think about how, is sufficient to
> keep most MUA makers in the camp of "not on my software".

I think that for the standard itself to carry trust, it is not enough to rely
on the good sense of MUA makers and the ability of recipients alone to ignore
possibly untrustworthy self-signed CAs. Just as it is the rules of the
Comptroller of Currency that inspire some of the trust required by users of
the banking system, and just as it is VISA and MASTER CHARGE rules that
inspire some of the trust required for international credit card systems to be
workable, so for trusted e-mail we need a "gilt-edged" standard and not one
with a lot of loopholes in it, in my view. This is in no way to denigrate web
of trust for purposes it is suited for. But just as the discount coupons any
advertiser may print in the newspaper aren't legal-tender-trust-grade but are
managed separately, and just as state and even individual institutions'
"money" had to be outlawed just after the Civil War to make a national
monetary system work, just so for the trust purposes I'm citing it is
important for the current spec to exclude "roll your own" CAs in creating at
least one global Internet trusted e-mail standard. Other standards can
certainly compete in the marketplace, but they should be separate.

> 
> However, if we disallow them, then the people who have a very good reason
> for using them in their application circle are prohibited because of the
> spec, not because of the technology.

This is a valid concern. But there are three alternative choices for such people:

1. Use the ietf-s/mime structure but violate the spec by using self-signed
CAs. This will clearly encapsulate such sub-networks (since standard
ietf-S/MIME compliant applications won't accept such certificates), while
allowing them (at their option) to use the technology. It will thus separate
them from the trusted e-mail analogue of the "check clearing system"--the
rigid hierarchical CA structure.  It's the analogue of a supermarket coupon
clearing system handled outside the money and banking system and with far
fewer forced safeguards, while using the same cash register scanners (in this
case the same computers and modems but different software)--think of it as a
"tunneling" system.

2. Use Open PGP. I like this best since PGP from the start was based on a
"roll your own", web of trust model and in effect that's what's being proposed
in the case you're discussing.

3. Use something else--there is no reason the IETF can't, for example, develop
a separate standard for self-signed CAs which borrows heavily from the
presently developing one without weakening it.

Other solutions not requiring loosening of the ietf-smime standard will
doubtlessly occur to readers.

>For example, there are many non-mail
> or quasi-mail Internet applications that might want to use S/MIME as an
> end-to-end security mechanism, but they have very good reasons for wanting
> (or even requiring) self-signed certs in their own protocol.

There were many reasons states or institutions wanted to continue issuing
their own money. But the narrow good was the enemy of the general good in such
a case.

> We specify
> S/MIME and its application to Internet mail only here.

See my opening comments.

> 
> Said another way, I don't see why we should prohibit self-signed certs in
> the spec if they work on-the-wire. We should explain why they might be a
> Bad Idea (and maybe do so more forcefully than we do now), but from a
> protocol and security perspective, I don't see a good reason to prohibit
> them. As the wording stands now, MUA makers are not required or even
> suggested to support them.

I understand your view, but for a trust standard whose main purposes are what
I think most want--arms-length trust at Internet scale with a minimum auditing
burden on the users of certified keys, I think that greater good sufficient to
move self-signed CAs to a separate standards domain. This was the basis of my
earlier "all things to all men" remark. Just as you can't be a "little bit
pregnant", and "Kosher-style" means "tref", I think it a bad idea to weaken
the model in this particular standard.

> 
> >My recommendation is that the subject paragraph, and any other opening for
> >self-signed CA certificates be dropped from the standard.
> 
> As you can tell, I disagree. I would, however, be happy to see someone
> (maybe you, David?) write a couple of paragraphs describing the current
> model and explaining why it is good, and why willy-nilly self-signed certs
> would be bad. This would be quite appropriate for this document, both at
> the point of discussion and in the Security section.

I'm not smart enough about the fine structure, nor have I studied trust models
in as much depth as some here who have thought and labored long and deeply
over the above issue. I would thus rather a real expert (that's not me folks,
when it comes to this topic, though I can speak as a competent economist with
respect to what seem to me to be apt historical parallels) take this on
formally, since the group is making a historical decision whose consequences
will echo for some time to come if it's done well. I'd be glad to comment
privately to such an author on any pre-circulated drafts. 

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

David Sternlight
Los Angeles

Date: Mon, 29 Dec 1997 22:51:15 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 04:33 PM 12/29/97 -0800, David Sternlight wrote:
> >The provision of self-signed CA certificates corrupts the rigid heirarchical
> >model, and I think the hand-waving "should use some other mechanism" casts
> the
> >huge body of arms-length users unable or unwilling to check such a CA's bona
> >fides adrift.
> 
> A valid concern, but one that I do not agree with. This is a mail spec, not
> a banking spec. We have exactly two choices: allow self-signed certs or
> disallow them. I think the current wording, which tells MUAs that they
> might want to allow them but the must think about how, is sufficient to
> keep most MUA makers in the camp of "not on my software".
> 
> However, if we disallow them, then the people who have a very good reason
> for using them in their application circle are prohibited because of the
> spec, not because of the technology. For example, there are many non-mail
> or quasi-mail Internet applications that might want to use S/MIME as an
> end-to-end security mechanism, but they have very good reasons for wanting
> (or even requiring) self-signed certs in their own protocol. We specify
> S/MIME and its application to Internet mail only here.
> 
> Said another way, I don't see why we should prohibit self-signed certs in
> the spec if they work on-the-wire. We should explain why they might be a
> Bad Idea (and maybe do so more forcefully than we do now), but from a
> protocol and security perspective, I don't see a good reason to prohibit
> them. As the wording stands now, MUA makers are not required or even
> suggested to support them.
> 
> >My recommendation is that the subject paragraph, and any other opening for
> >self-signed CA certificates be dropped from the standard.
> 
> As you can tell, I disagree. I would, however, be happy to see someone
> (maybe you, David?) write a couple of paragraphs describing the current
> model and explaining why it is good, and why willy-nilly self-signed certs
> would be bad. This would be quite appropriate for this document, both at
> the point of discussion and in the Security section.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

Paul,

>From nothing more than a personal freedom perspective, I really 
warm to the idea of everyone, everywhere, whether they're just 
plain humans, or licensed, audited and certified entities, being 
allowed to create and distribute their own certs, to anyone, 
anywhere, that's willing to trust them. It just seems to me like 
a more open posture for a standard to take.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Mon, 29 Dec 1997 19:37:25 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

At 06:48 PM 12/29/97 -0800, David Sternlight wrote:
>I think that for the standard itself to carry trust, it is not enough to rely
>on the good sense of MUA makers and the ability of recipients alone to ignore
>possibly untrustworthy self-signed CAs.

This, then, is the basis of our disagreement. I don't see anything that we
can do to fully cover the trust issue for all users, other than, as you
have, outlaw anything other than rejecting all self-signed certs mailed to
a receiving agent.

>I think it a bad idea to weaken
>the model in this particular standard.

The current standard explicitly allows self-signed certs. The last draft
for S/MIME v2 reads:

    Clients MAY send CA certificates, that is, certificates that are
    self-signed and can be considered the "root" of other chains. Note
    that receiving agents SHOULD NOT simply trust any self-signed
    certificates as valid CAs, but SHOULD use some other mechanism
    to determine if this is a CA that should be trusted.

 In fact, I think you are overestimating when you suggest that today's
deployed S/MIME v2 applications don't allow them. At the S/MIME testing at
MailConnect 3, I heard that some vendors accepted self-signed certs, and
others didn't. Deming, Microsoft, Netscape, and other developers are
encouraged to jump in here and say what their shipping receiving MUAs do
when mailed a self-signed cert.

But either way, what you're asking for is a change from the S/MIME v2 spec.
That might be fine with the WG, it might not. What do others say?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 29 Dec 1997 16:54:49 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Weakening the rigid heirarchical trust model
Sender: [email-masked]

At 04:33 PM 12/29/97 -0800, David Sternlight wrote:
>The provision of self-signed CA certificates corrupts the rigid heirarchical
>model, and I think the hand-waving "should use some other mechanism" casts
the
>huge body of arms-length users unable or unwilling to check such a CA's bona
>fides adrift.

A valid concern, but one that I do not agree with. This is a mail spec, not
a banking spec. We have exactly two choices: allow self-signed certs or
disallow them. I think the current wording, which tells MUAs that they
might want to allow them but the must think about how, is sufficient to
keep most MUA makers in the camp of "not on my software".

However, if we disallow them, then the people who have a very good reason
for using them in their application circle are prohibited because of the
spec, not because of the technology. For example, there are many non-mail
or quasi-mail Internet applications that might want to use S/MIME as an
end-to-end security mechanism, but they have very good reasons for wanting
(or even requiring) self-signed certs in their own protocol. We specify
S/MIME and its application to Internet mail only here.

Said another way, I don't see why we should prohibit self-signed certs in
the spec if they work on-the-wire. We should explain why they might be a
Bad Idea (and maybe do so more forcefully than we do now), but from a
protocol and security perspective, I don't see a good reason to prohibit
them. As the wording stands now, MUA makers are not required or even
suggested to support them.

>My recommendation is that the subject paragraph, and any other opening for
>self-signed CA certificates be dropped from the standard.

As you can tell, I disagree. I would, however, be happy to see someone
(maybe you, David?) write a couple of paragraphs describing the current
model and explaining why it is good, and why willy-nilly self-signed certs
would be bad. This would be quite appropriate for this document, both at
the point of discussion and in the Security section.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 29 Dec 1997 16:33:52 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Weakening the rigid heirarchical trust model
Sender: [email-masked]

One reader sent me an e-mail indicating that he didn't see what my original
post had to do with the deliberations of this group. Here is a copy of the
clarifying response I sent him:

My objection is based on the current quote from draft-ietf-smime-cert:

"Clients MAY send CA certificates, that is, certificates that are self-
signed and can be considered the "root" of other chains. Note that
receiving agents SHOULD NOT simply trust any self-signed certificates
as valid CAs, but SHOULD use some other mechanism to determine if this
is a CA that should be trusted."

The provision of self-signed CA certificates corrupts the rigid heirarchical
model, and I think the hand-waving "should use some other mechanism" casts the
huge body of arms-length users unable or unwilling to check such a CA's bona
fides adrift. It can ruin the "bank check/credit card" model of S/MIME as
practiced in Netscape and Explorer via Verisign and the many other certifiers,
where CAs are required to conform to specified standards, and are audited to
that, just as banks are supervised by the Controller of the Currency, and
credit card issuers by VISA, MASTER CARD, etc. While I have no objection to
web of trust as a separate model in some other standard, to weaken S/MIME in
this way can destroy its usefulness as a routinely trusted medium (just
as are VISA and MASTER CARDS and checks after perhaps checking only the
individual account's validity--corresponding to a user's public key).

I speak as a professional economist. For details, read any good introductory
economics text on money and banking. The conceptual issues are exactly the
same for trust here (whether for e-mail or transactions) as they were in the
abolition of specie money and the rise of national banking systems, and
subsequently national and international credit card systems.

My recommendation is that the subject paragraph, and any other opening for
self-signed CA certificates be dropped from the standard.

David

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Weakening rigid heirarchical certification
Date: Mon, 29 Dec 1997 17:55:01 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0081_01BD1482.E321F780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>This is not an objection to web-of-trust. In a separate standard such as
Open
>PGP, it has a very useful place. But it should be just that--embedded in a
>separate standard. Let the market decide, not some partisans of one
>commmercial interest or another, and please do not corrupt a good trust
model
>(for its purposes) to try to make it universal.

I fail to see the dichotemy. The difference between PGP and X.509 as
implemented in Outlook Express or Explorer is much less than the
marketing implies.

PGP certificates have severe liability problems that would make it
difficult for anyone to offer a commercial CA service. Somehow I don't
like the idea of signing a contract with an unspecified and unlimited
relying party liability.

Once the PEM dogama of a rigid hierachy is abandoned there is only
one major difference between PGP and X.509. In the PGP model
everyone issues certificates, in the X.509 model there are people
who issue certs and people who only use them.

Existing clients have the capability to add certs for non native roots
(try the cert I used to sign this!). Supporting the PGP trust model
in S/MIME means no more than someone writing 'My Personal
Cert Server' as a certain resident of Redmont WA has suggested.

The decision to trust someone to certify other keys is intrinsically
more onerous than the decision to trust their particular key. Hence
my grandmother is unlikely to be trusting a David Sternlight key
signed by Tim May any time soon. Trusted third parties genuinely
add value.

If explicitly supporting the PGP web of trust model will end the
pointless message format battle and get the PGP userbase to
realize that S/MIME has won the email security standards war
I am all for it. There are 25 million clients in the hands of end
users today. I want to see everything done to encourage people
to start using them.

PGP's Web of Trust is no threat to the CA model. If that population
of 25 million folk each certify ten users the minimum diameter of
the resulting graph is seven. That means that folk are going to have
to deal with certificate paths of seven certs on a regular basis. - and
that's with less than 1% of the planet's population using it!

I don't think many people would want to depend on cert paths longer
than 2 certs unless the issuers were making very strong assurances
about the subjects. This implies that there have to be at least some
nodes with very high degree which in turn implies specialist CAs.

>Something that attempts to be all things to all men will inevitably end up
>being nothing to no one.

Which read literally implies everyone is partially satisfied!

Seriously, lets not go goring folks favourite oxen when they can be
roasted instead.

            Phill

------=_NextPart_000_0081_01BD1482.E321F780
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0081_01BD1482.E321F780--

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESS ContentHints Comments
Date: Mon, 29 Dec 1997 11:16:02 -0800
Sender: [email-masked]

I agree with John's changes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 29, 1997 10:27 AM
To: Jim Schaad (Exchange); [email-masked]
Subject: RE: ESS ContentHints Comments

All,

I agree with Jim's proposals regarding the ContentHints attribute with a
few
minor comments:  

In Jim's bullet 2, he stated: "For example,signed receipts state that a
contentHint MUST be included if encryption is to be added."  I believe
that
this should be changed to "For example, when a signedData/Receipt (i.e.
signedData including Receipt content) is encrypted within an
envelopedData
object, then an outer signedData object MUST be created that
encapsulates
the envelopedData object and a contentHints attribute with contentType
set
to the id-ct-receipt OID MUST be included in the outer signedData
SignerInfo
authenticatedAttributes."

In Jim's bullet 3, he stated: 

"3.   Change section 2.4 bullet 6.1

6.1 If a receipt is to be enclosed in an encryption layer, an outer
signedData object must be created and a contentHints attribute 
SHOULD be created and added to the SignerInfo structure's 
authenticated attributes."

IMHO, this should be re-worded as follows:

"3.   Change section 2.4 bullet 6.1

6.1  If the signedData/Receipt is to be encrypted within an
envelopedData
object, then an outer signedData object MUST be created that
encapsulates
the envelopedData object and a contentHints attribute with contentType
set
to the id-ct-receipt OID MUST be included in the outer signedData
SignerInfo
authenticatedAttributes.  When the receiving agent process the outer
signedData object, then the presence of the id-ct-receipt OID in the
contentHints contentType indicates that a signedData/Receipt is
encrypted
within the envelopedData object encapsulated by the outer signedData."

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

Date: Mon, 29 Dec 1997 13:27:05 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: ESS ContentHints Comments
Sender: [email-masked]

All,

I agree with Jim's proposals regarding the ContentHints attribute with a few
minor comments:  

In Jim's bullet 2, he stated: "For example,signed receipts state that a
contentHint MUST be included if encryption is to be added."  I believe that
this should be changed to "For example, when a signedData/Receipt (i.e.
signedData including Receipt content) is encrypted within an envelopedData
object, then an outer signedData object MUST be created that encapsulates
the envelopedData object and a contentHints attribute with contentType set
to the id-ct-receipt OID MUST be included in the outer signedData SignerInfo
authenticatedAttributes."

In Jim's bullet 3, he stated: 

"3.   Change section 2.4 bullet 6.1

6.1 If a receipt is to be enclosed in an encryption layer, an outer
signedData object must be created and a contentHints attribute 
SHOULD be created and added to the SignerInfo structure's 
authenticated attributes."

IMHO, this should be re-worded as follows:

"3.   Change section 2.4 bullet 6.1

6.1  If the signedData/Receipt is to be encrypted within an envelopedData
object, then an outer signedData object MUST be created that encapsulates
the envelopedData object and a contentHints attribute with contentType set
to the id-ct-receipt OID MUST be included in the outer signedData SignerInfo
authenticatedAttributes.  When the receiving agent process the outer
signedData object, then the presence of the id-ct-receipt OID in the
contentHints contentType indicates that a signedData/Receipt is encrypted
within the envelopedData object encapsulated by the outer signedData."

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

Date: Mon, 29 Dec 1997 10:04:58 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
Subject: Weakening rigid heirarchical certification
Sender: [email-masked]

Forwarded for its possible usefulness:

Ed Stone wrote:
> 
> Source: http://mcg.org.br/cert.htm
> 
> E. Gerck,
> Copyright © 1997 by E. Gerck and MCG, published in April 17, 1997 by the MCG
> All rights reserved, free copying and citation allowed with source and author
> reference.

Stone is now  changing the subject of the comp.security.pgp.discuss discussion
from RH (rigid-heirarchical) implementations of X.509-like trust models with
certification that CA's meet accepted hardware, software, and identity
verification standards at specified levels, such as that used by hundreds of
CAs including Verisign, Thawte, the US and Canadian Post Offices, and embedded
in over 30 million copies of Netscape Communicator and Microsoft Internet
Explorer, and instead trying to raise concerns about admitted flaws in pure X.509.

The flaws in X.509 are largely there just because some wished the capability
for self-certifying CAs and other, more web-of-trust-like features to be
included in X.509. Some are now trying to structure IETF S/MIME along the same lines.

Likely if the weakening away from rigid heirarchical certification in IETF
S/MIME persists, the commercial vendors responsible for the massive installed
base and trust model already in place (in Navigator and Explorer) will resist
such features as extra-heirarchical CAs with users being left to unspecified
exogenous methods to verify such CAs' bona fides (as is apparently specified
in the current s/mime "draft-ietf"). For arms-length internet transactions
(using that word in its broadest sense) between strangers, system-insured
structural assurances as to any CA's bona fides (backed up with agreed and
audited practices) are essential. I thought that was a major purpose of a
structure with the IPRA at the top.

As IBM proved many years ago in the mainframe world, "it is better to have the
market than the product". A poor IETF implementation simply won't succeed in
the marketplace, and the "marketing advantage" of someone else yelling "But
Netscape isn't fully IETF compliant" will carry about as much weight as Sun
yelling, "But Internet Explorer isn't fully Java compliant". Though my
sympathies are with Sun, I don't see such cries much affecting Microsoft's
market share. If the IETF is to act in the best interests of the user base,
they must consider this.

This is not an objection to web-of-trust. In a separate standard such as Open
PGP, it has a very useful place. But it should be just that--embedded in a
separate standard. Let the market decide, not some partisans of one
commmercial interest or another, and please do not corrupt a good trust model
(for its purposes) to try to make it universal.

Something that attempts to be all things to all men will inevitably end up
being nothing to no one.

David

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: The address-in-certs issue
Date: Fri, 26 Dec 1997 13:56:37 -0800
Sender: [email-masked]

I have been following the discussions on this issue for a while and am
now ready to add my opinion and questions to the mix.

1.  It is my firm belief that all certificates should contain a name,
either as the subject name or as an alternate subject name that is in
the domain which is being dealt with application under question.  As
S/MIME is specified primarily as an Internet Mail system, this would
imply that RFC 822 e-mail names should be present in a subjectAltName
extension.  

I would expect that applications such as SHTTP would specify what they
consider their domain of names to be and require that a certificate
include this information.  (For SHTTP either a URI or an RFC 822 name
would both be reasonable.)  The Microsoft Exchange Key Management server
includes as the subject name the mailbox name associated with the
certificate, thus leading to a different way in which a domain specific
name is bound the certificate.  An X.400 mail system would require that
an X.400 name be contained in the certificate.  If the mail was expected
to go between an X.400 mail system and the internet, both the X.400 and
RFC 822 name would be present in the certificate as it would be used in
both naming domains.

2.  A question:  It appears to me that one of the arguments that is
currently being pressed as to why certificates should not include such
things as an e-mail name is lifetime of a certificate.  Is it possible
to use attribute certificates to solve this problem?  The concept would
be to allow for a longer lifetime certificate while giving us a shorter
lifetime certificate which could be re-bound on a more frequent basis.
The assumption that I am working under is that the Certs draft would say
that a certificates attributes would be determined first by the
attribute certificate and then by the real certificate.  I don't know
enough about attribute certificates to understand if this is a good or a
bad idea.

3.  It is my firm belief that our document should make no specific
statements on how the domain specific name should be used.  This should
be entirely left up to the MUA and not be specified by us.  If we were
to specify anything at all, I would recommend that it runs along the
following lines:

"It is recommended that MUAs provide decision logic (or user)
information about the primary domain name from the certificate used to
verify the signature.  This specification does not provide any direction
as to what should be done with this identity."

jim schaad

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Incorporate some PKCS#7 V2.0 items into CMS
Date: Fri, 26 Dec 1997 13:56:38 -0800
Sender: [email-masked]

I would like to propose to the WG that we look at adopting some of the
changes that are being examined in the V2 spec for PKCS#7 and modify the
CMS document accordingly.  

1.  We should allow for the usage of non X509 certificates in CMS for
encryption purposes.  This would additionally allow for non-public key
algorithms to be applied to envelopedData structures.  This proposal
would change the ASN to the following:

RecipientIdentifier :: = CHOICE {
	issuerAndSerialNumber	IsuerAndSerialNumber,
	rKeyId [0] RecipientKeyIdentifier,
	mlKeyId [1] MailListKeyIdentifier,
	otherKeyId [2] OtherKeyIdentifier }

OtherKeyIdentifier ::= SEQUENCE {
	keyIdentifier OBJECT IDENTIFIER,
	keyInformaton ANY DEFINED BY keyIdentifier OPTIONAL }

This allows for the following two scenarios to be included in the usage
of CMS:
1.  PGP certificates could have an OID defined for them and the
certificate would be the any field.  This allows for PGP certificates to
be used at the same time as X.509 certificates in encrypting a single
message.
2.  This would permit the use of other key agreement algorithms (such as
the derived password keys in PKCS#12) to be used.  This would be
especially useful with the new CRS syntaxes to permit a token to be used
for the purposes of authentication and enveloping the data in the
certificate request.  In this world identification information about the
sender could be placed in the UserKeyingMaterials field, and information
about the encryption of the bulk key would be carried in the
OtherKeyIdentifier field.  (It would be along the lines of the OID for
3DES followed by the parameters for 3DES).

2.  Apply similar changes to the signedData structures.  This would
change the ASN as follows:

SignerInfo ::= SEQUENCE {
	version Version,
	ukm [2] IMPLICIT UserKeyingMaterials OPTIONAL,
	rid RecipientIdentifier,
	digestAlgorithm DigestAlgorithmIdentifier,
	authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL,
	signatureAlgorithm signatureAlgorithmIdentifier,
	signature SignatureValue,
	unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL}

The switch from IssuerAndSerialNumber to Recipientidentifier allows for
the use of certificates other than X.509.  Additional
UserKeyingMaterials will permit the usage of algorithms such as HMAC to
be used.  Please note that I am intentionally only dealing with the case
were there are attributes present.  I am not suggesting that this be a
general purpose solution, rather I am trying to solve the case where we
are going to do a shared secret authentication message to a RA during
certificate enrollment.  This means that there are going to be
attributes present.  It also greatly simplifies the problem to a more
manageable set of issues.

jim schaad

P.S.  Please refrain from doing correctness passes on the ASN until we
decide if the problem should be dealt with in the working group.  This
does not apply to correcting security or algorithm flaws.  
thanks jls

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: ESS ContentHints Comments
Date: Fri, 26 Dec 1997 13:56:34 -0800
Sender: [email-masked]

On Dec 17, John wrote in part:

2) Sec 2.10, ContentHints section:  Change "Messages that contain a
signed
receipt MUST include this attribute with the
receipt value set to TRUE." to "When a SignedData/Receipt is
encapsulated by
another SignedData object, then the sending agent SHOULD include a
ContentHints attribute (with receipt set to TRUE) in the
authenticatedAttributes of the outermost SignedData object.  For
example, if
a SignedData/Receipt is encrypted within an EnvelopedData object which
is
then signed using an outer SignedData object, then the outer SignedData
object should include a ContentHints attribute with receipt set to
TRUE."  

Also, I believe that ESS Sec 1.3.4 should be left as is.  It implies
that a
contentHints attribute does not necessarily need to be authenticated.
When
the contentHints includes a contentDescription and receipt set to FALSE,
then it does not necessarily need to be authenticated. I believe that
the
ESS spec should continue to include the flexibility to
support that option.  When the contentHints includes receipt set to
TRUE,
then it should be authenticated.

[Jim Schaad]
I agree that this is a good idea.  The concept of having all of the
information be placed into the authenticated attributes multiple times
to be redundent and therefore we should avoid it.

I would however like to propose a change to the contentHints type which
I think will greatly improve it and potentially lead it to being used in
more situtations as above.  Specifically I would like to see more
accurate information being carried by the contentHints attribute.

Proposal:

1.  Change the ASN.1 for the type to be
	ConentHints ::= SEQUENCE {
		contentDescription	DirectoryString OPTIONAL,
		contentType			OID }

2.  Replace the final paragraph of section 2.10 with the following:

The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a
message subject.  If this field is set, then the attribute is expected
to appear on the signedData object enclosing an encrypted data object
and not on the inner signedData object.

Messages which contain a signed data wrapped around an encrypted data
object, thus masking the inner content type of the message SHOULD
include a content hint attribute except for the case of the data content
type.  Specific message content types may either force or preclude the
inclusion of the content hints attribute.  For example,signed receipts
state that a contentHint MUST be included if encryption is to be added.

3.   Change section 2.4 bullet 6.1

6.1 If a receipt is to be enclosed in an encryption layer, an outer
signedData object must be created and a contentHints attribute SHOULD be
created and added to the SignerInfo structure's authenticated
attributes.

Date: Tue, 23 Dec 1997 19:14:19 -0200 (EDT)
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: Solving the issue, was Re: The address-in-certs issue
Sender: [email-masked]

On Tue, 23 Dec 1997, Ed Gerck wrote:

-> 7. S/MIME primary motivation is to secure e-mail and e-mail depends on
-> e-mail addresses,

Tks to a private comment, pls correct the above to exactly mean:

"7. S/MIME primary motivation is to secure e-mail messages and e-mail
messages depend on e-mail adresses," 

as implictly written.

Thank you,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

Date: Tue, 23 Dec 1997 18:02:38 -0200 (EDT)
From: Ed Gerck <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Solving the issue, was Re: The address-in-certs issue
Sender: [email-masked]

On Tue, 23 Dec 1997, David P. Kemp wrote:

-> If we agree that relatively long-lived stable identities are a goal,
-> and that accommodating environments where mail can reach a given user
-> by multiple and occasionally or frequently changing addresses is also
-> a goal, then we can't reach both goals by putting all the delivery
-> addresses into a cert.
-> 

David and list:

IF we agree that:

1. A long-lived certificate should live one year (I can supply supporting
data if needed, while some might even want to assume a smaller lifetime),

2. An e-mail address may live one year in the owner's reference frame,
with its death being determined by job change over, ISP change over, spam
overfill, etc.  (admittedly, I lack data here but judging from all my
e-mail contacts in 8 years, I can remember only one address that lived
less than one year in the owner's reference frame),

3. An e-mail address may live much less in a recipient's reference frame
(as given by a Poisson distribution) but this is not important because the
recipient can of course receive a new certificate from the owner (sender) 
in several ways at any time, such as a routine message of e-mail change
with the owner's new address, as a request, etc.,

4. An e-mail address may not be used so often by an entity in its own
reference frame but may still live and so be useful to reach the same
entity from the recipient's reference frame,

5. Under X.509, the e-mail field may be invalid but the certificate is
still valid if the e-mail is NOT the DN (as it should NEVER be),

6. An invalid e-mail field in a valid X.509 cert is at least as useful as
a null e-mail field in a valid X.509 cert (maybe more useful, because if
you learn that Bob Jones is not any more at [email-masked] then you may
need to talk to someone else at IBM),

7. S/MIME primary motivation is to secure e-mail and e-mail depends on
e-mail addresses,

THEN

we should agree that including the e-mail as a referenced field in a X.509
cert is at least as useful as not including any e-mail, while it can be
very useful if the e-mail is correct and valid (which is the expected
behavior within a cert's lifetime in the owner's reference frame). 

THEREFORE, I suggest (exact STD wording not my goal here, just concepts): 

 The e-mail field as quoted in the "From:" field MUST always
 be verified by the receiving MUA against a correspondingly named field
 in the certificate, where the certificate may be supplied with the message
 or read from a local file, cache, etc. The same applies to the "From"
 field. If the e-mail uses S/MIME services then two cases of warning MUST
 be provided by MUAs, for each of the two fields, for any sender:
 (i) if the recipient allows uncertified e-mail addresses to be used in
 that field and the corresponding certificate field is "NULL", the
 receiving MUA MUST NOT detect any discrepancy in that field,
 (ii) if the recipient does NOT allow uncertified e-mail addresses to be
 used in that field and a discrepancy is detected, the receiving
 MUA MUST add a warning message to the recipient by inserting it as a
 first block in the message body itself, where the message MUST clearly
 indicate the discrepancy and the two field values.
 Further, in case of (ii) and if so desired by the recipient, the MUA MAY
 bounce, delete or otherwise process the message (forward, store, parse,
 etc.) as a function of the corresponding field values.

(Note that S/MIME services includes current services such as
signing/encryption as well as future services)

This suggestion would allow e-mail addresses to be effectively used in
S/MIME, while still allowing no e-mail address to be used (NULL). This
would solve the issue for all the needs/restrictions posted in this list. 

Cheers,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

Date: Tue, 23 Dec 1997 13:36:56 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS Signed Receipt Validation Proposal
Sender: [email-masked]

All,

On 12/16/97, I sent a message to the list proposing enhancements to the ESS
Signed Receipt Creation section.  This message proposes corresponding
enhancements to the ESS Signed Receipt Validation section.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1) ESS, Sec 2.1. Bullet 6, second sentence:  Please change to: "This
validation relies on the sender having retained either a copy of the
original message or information extracted from the original message."
Reason: At this early point in the section, we shouldn't provide the gory
details of exactly what "extracted" info must be saved.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2) ESS, Sec 2.2: Please add as last paragraph:

"The sending agent MUST retain at least one set of the following items to
support the validation of signed receipts returned by the recipients: 

1) original signedData object requesting the signed receipt; or

2) message signature digest value used to generate the original signedData
signerInfo signature value (as described in the CMS "Message Digest
Calculation Process" section) and Receipt content digest value (see "Signed
Receipt Validation" section) derived from the original signedData object
requesting the signed receipt.  Note: If signed receipts are requested from
multiple recipients, then retaining these digest values is a performance
enhancement because the sending agent can reuse the saved values when
verifying each returned signed receipt."

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3) ESS, Sec 2.6 and 2.7:  Please replace Sections 2.6 and 2.7 with the
following:

"2.6.  Signed Receipt Validation

A signed receipt is communicated as a single ASN.1 encoded object composed
of a signedData object directly including a Receipt content (i.e.
signedData/Receipt).  It is identified by the presence of the id-ct-receipt
OID in the contentInfo contentType value of the signedData object including
the Receipt content.

A signedData/Receipt is validated as follows:

1. ASN.1 decode the signedData object including the Receipt content.

2. Extract the encapsulatedContentType, signedContentIdentifier and
originatorSignatureValue from the decoded Receipt structure to identify the
original signedData signerInfo that requested the signedData/Receipt.

3. Acquire the message signature digest value calculated by the sender to
generate the signature value included in the original signedData signerInfo
that requested the signedData/Receipt.  

    3.1. If the sender-calculated message signature digest value has 
    been saved locally by the sender, it must be located and 
    retrieved.
    
    3.2. If it has not been saved, then it must be re-calculated 
    based on the original signedData content and
    authenticatedAttributes as described in the CMS 
    "Message Digest Calculation Process" section.  

4. The message signature digest value calculated by the sender is then
compared with the value of the msgSigDigest authenticatedAttribute included
in the signedData/Receipt signerInfo.  If these digest values are identical,
then that proves that the message signature digest value calculated by the
recipient based on the received original signedData object is the same as
that calculated by the sender.  This proves that the recipient received
exactly the same original signedData content and authenticatedAttributes as
sent by the sender because that is the only way that the recipient could
have calculated the same message signature digest value as calculated by the
sender.  If the digest values are different, then the signedData/Receipt
signature verification process fails. 

5. Acquire the digest value calculated by the sender for the Receipt content
constructed by the sender (including the encapsulatedContentType,
signedContentIdentifier and signature value that were included in the
original signedData signerInfo that requested the signedData/Receipt). 

    5.1. If the sender-calculated Receipt content digest value has 
    been saved locally by the sender, it must be located and 
    retrieved.
    
    5.2. If it has not been saved, then it must be re-calculated.  As 
    described in the "Signed Receipt Creation" section, step 2, create 
    a Receipt structure including the encapsulatedContentType, 
    signedContentIdentifier and signature value that were included
    in the original signedData signerInfo that requested the signed 
    receipt.  The Receipt structure is then ASN.1 DER encoded to 
    produce a data stream which is then digested to produce the 
    Receipt content digest value.

6. The Receipt content digest value calculated by the sender is then
compared with the value of the messageDigest authenticatedAttribute included
in the signedData/Receipt signerInfo.  If these digest values are identical,
then that proves that the values included in the Receipt content by the
recipient are identical to those that were included in the original
signedData signerInfo that requested the signedData/Receipt.  This proves
that the recipient received the original signedData signed by the sender,
because that is the only way that the recipient could have obtained the
original signedData signerInfo signature value for inclusion in the Receipt
content.  If the digest values are different, then the signedData/Receipt
signature verification process fails. 

7. The ASN.1 DER encoded authenticatedAttributes of the signedData/Receipt
signerInfo are digested as described in CMS, Section 5.3.    

8. The resulting digest value is then used to verify the signature value
included in the signedData/Receipt signerInfo.  If the signature
verification is successful, then that proves the integrity of the
signedData/receipt signerInfo authenticatedAttributes and authenticates the
identity of the signer of the signedData/Receipt signerInfo.  Note that the
authenticatedAttributes include the recipient-calculated Receipt content
digest value (messageDigest attribute) and recipient-calculated message
signature digest value (msgSigDigest attribute).  Therefore, the
aforementioned comparison of the sender-generated and recipient-generated
digest values combined with the successful signedData/Receipt signature
verification proves that the recipient received the exact original
signedData content and authenticatedAttributes (proven by msgSigDigest
attribute) that were signed by the sender of the original signedData object
(proven by messageDigest attribute).  If the signature verification fails,
then the signedData/Receipt signature verification process fails."

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4) ESS, Sec 2.8 and 2.9: Please renumber as Sec 2.7 and 2.8, respectively.

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

From: Bill Barry <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: The address-in-certs issue
Date: Tue, 23 Dec 1997 09:34:31 -0800
Sender: [email-masked]

> David P. Kemp wrote:

> If we agree that relatively long-lived stable identities are a goal,=20
> and that accommodating environments where mail can reach a given user
> by multiple and occasionally or frequently changing addresses is also
> a goal, then we can't reach both goals by putting all the delivery
> addresses into a cert.

Sorting out the above statement I get (and agree with) these goals:

Goal 1 - Long lived stable identities/certs (i.e. like a S.S. number)
Goal 2 - Allowing frequent change of address (i.e. like moving)
Goal 3 - Accepting use of multiple addresses

IMHO the dichotomy is clear; we cannot achieve all goals at the same =
time. It is the issue of adding and/or editing addresses that would =
result in an unstable certificate. I add my voice to those proposing =
that the certificate not contain any address. =20

If we had some other form of permanent ID in our cyber world then I =
would vote that we put it in the cert.  Ideally, a recipient would only =
need one certificate for their entire life.

William M. Barry

Date: Tue, 23 Dec 1997 10:09:49 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
> Date: Fri, 19 Dec 1997 14:50:07 -0800
> 
> David P. Kemp wrote:
> > Reasons include 1) the more information that goes into a cert, the shorter
> > the expected lifetime,
> 
> Then take out other information.  RFC822 identities are what are used in
> Internet Mail, and if you're securing Internet Mail objects, those are
> the identities you need to certify.

  --- and ---

> From: John Gardiner Myers <[email-masked]>
> Date: Mon, 22 Dec 1997 18:09:51 -0800
> 
> Even simpler, I could have a certificate with both
> 12345,[email-masked] and "John Gardiner Myers"@netscape.com. 

Is it too much to ask that your arguments at least be self-consistent?
You can't simultaneously take extra information out of and put extra
information into a certificate.

If we agree that relatively long-lived stable identities are a goal,
and that accommodating environments where mail can reach a given user
by multiple and occasionally or frequently changing addresses is also
a goal, then we can't reach both goals by putting all the delivery
addresses into a cert.

   [address-book-subversion discussion]

> Paul needs to send you an important, private message.  Paul is a busy
> person.  He's the co-founder of an industry consortium for Internet
> mail.  Having much familiarity with Internet mail, he uses the same,
> simple, interface he has always used for informing his UA to whom the
> mail is intended: he types "[email-masked]" into the To: field of
> his compose window.

Paul is a busy person, so he types "kemp" into his compose window.  His
MUA has a database of certificates, each of which has a subject name
bound to a public key.  The list of subjects matching "kemp" pops up,
and Paul clicks on the correct one.  If there is only one match, the
MUA displays the full name and either asks for confirmation if Paul has
previously checked the "always ask" option, or proceeds if the option is
unchecked.

> That is because Paul, being a busy person, doesn't have the time to
> parse the DN for every message he receives.  Being an Internet mail kind
> of person, he thinks in terms of RFC822 syntax.
>   [...]
> Most Internet mail users can't distinguish a DN from base64-encoded
> line noise.

That is a remarkably insulting statement - I'm glad you said it about
Paul and not me :-).  I give even computer-using mothers-in-law* credit
for being able to recognize "O=imc.org, CN=Paul Hoffman" as easily as
they would "Paul Hoffman / IMC <[email-masked]>".

And I give credit to MUA designers to be able to present "Paul Hoffman"
to the user given either form as input, and allow the curious to
explicitly seek further details.

---
* I love my mother-in-law, really!  And she does use a computer.

Date: Tue, 23 Dec 1997 09:06:18 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

1) This is not an interoperability issue. Every UA should be able to
present a string, and the UA does not need to interpret it. 
2) Since its not an interoperability issue, why dictate the form of the
identity? 
3) We MUST require the UA to present to the user whatever identifiers are
in the cert.

Elliott Ginsburg

At 06:09 PM 12/22/97 -0800, John Gardiner Myers wrote:
>David P. Kemp wrote:
>> The point is not that a compuserve user could get a certificate with that
>> DN, it is that a person having a certificate with a real name (sorry to
pick
>> on you, but use "O=netscape.com, CN=John Gardiner Myers" as an example
again)
>> could use a cryptically-named compuserve email account *and* an
>> employer-provided email account, both with the same certificate.
>
>Even simpler, I could have a certificate with both
>12345,[email-masked] and "John Gardiner Myers"@netscape.com. 
>What's the advantage of putting it in DN syntax?
>
>> > If the standard permits eithe syntax, some CA's only use DN syntax, and
>> > some UAs only use RFC822 syntax, then you have "conforming but
>> > noninteroperable".
>> 
>> If the standard requires that a DN, an RFC822 name, or both be present
>> in a certificate, and requires that UAs to support DN and RFC822 forms,
>> then conformance implies interoperability.
>
>This is one of the possible solutions to this interoperability issue. 
>Later in this message I will argue that the solution of mandating RFC822
>names only is better for the Internet mail application, but can we first
>get consensus on the basics:
>
>JGM1) In order to interoperate, each application of S/MIME must specify
>mandatory minimum idenitfier syntax requirements on CAs and receiving
>UAs, such that every conforming cert has identifiers interperable
>(subject to policy) by every conforming UA.
>
>JGM2) The mandatory identifier syntax requirements of Internet mail
>should be specified in a base S/MIME document.
>
>JGM3) Applications other than Internet mail may profile S/MIME to change
>these identifier syntax requirements as necessary.
>
>> > If an attacker can subvert the UA's mapping, they can cause the UA to
>> > choose the wrong public key.  Suppose I am able to add a mapping into
>> > Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
>> > "[email-masked]".
>> 
>> The UA does not choose a public key, the user chooses the public key
>> based on the name bound to that key in a certificate.
>
>No interface I know of has the user typing in a public key.  Some
>software somewhere chooses
>a public key based on some input it got from the user and some system
>for mapping that input to a public key.
>
>> If Paul encrypts a message to "O=netscape.com, CN=John Gardiner Myers"
>> and his address book causes the message to be sent to
>> [email-masked], then I get (unreadable) copies of messages
>> intended for you, and you don't get copies unless I'm kind enough to
>> forward them to you :-).
>
>You have mixed up who is the attacker and who is the attackee.  I am the
>attacker.  For purposes of this exercise, we postulate that I am able to
>make modifications to Paul's address book and that I am able to subvert
>the mail transport between Paul and you.
>
>Paul needs to send you an important, private message.  Paul is a busy
>person.  He's the co-founder of an industry consortium for Internet
>mail.  Having much familiarity with Internet mail, he uses the same,
>simple, interface he has always used for informing his UA to whom the
>mail is intended: he types "[email-masked]" into the To: field of
>his compose window.
>
>Since you have a perfectly conforming cert which fails to certify the
>mapping of "[email-masked]" to your public key, the UA needs some
>database mapping that either to a public key or to some other name which
>has a certified mapping to a public key.  Since I have subverted that
>database, I get the UA to map that to "O=netscape.com, CN=John Gardiner
>Myers", which has a certified mapping to my public key.  Thus I cause
>mail intended for you to be encrypted with my public key.
>
>Since I have subverted the delivery system, I can intercept that message
>and prevent it from being delivered to you.  After decrypting and
>reading the message, I can re-encrypt it with your real public key and
>inject that into the delivery system destined for you.
>
>> >  I can now make Paul believe that things I
>> > signed came from you, and I can decrypt any mail from him to you that I
>> > am able to snoop off the wire.
>> 
>> Say what?  If Paul receives a message signed by your key which is bound
>> in a cert to your DN, why would he believe it came from me (regardless
>> of any tampered SMTP header or any misconfiguration of his address book)?
>
>That is because Paul, being a busy person, doesn't have the time to
>parse the DN for every message he receives.  Being an Internet mail kind
>of person, he thinks in terms of RFC822 syntax.  He uses a UA which
>checks the header against the certification using the mapping in the
>subverted address book and displays a simple icon stating "yup, this was
>signed."
>
>Suppose the UA always displays the DN that was certified.  Now suppose
>the attacker has the legal name "David P. Kemp".  What is the likelihood
>that Paul will notice that fields in the DN other than CN aren't what
>they should be?  Most Internet mail users can't distinguish a DN from
>base64-encoded line noise.
>
>> And if Paul encrypts a message to my DN using my certified public key,
>> how would you be able to read it?
>
>Paul doesn't encrypt a message to your DN.  I trick his UA into using my
>DN.
>
>If you claim that Paul should always be picking a DN to use out of an
>address book or directory and that his UA should display every single
>component of the DN, then I would say you have given Paul's UA all the
>simplicity and ease of use of X.400.
>
>> > > If I want to send mail to the person I know as
>> > > "O=netscape.com, CN=John Gardiner Myers", or the person I know as
>> > > "[email-masked]", then what difference does it make if the mail gets
>> > > addressed and delivered to [email-masked] as long as it
eventually
>> > > winds up in a location where the person holding the private key
>> > > corresponding to the certified identity can read it?
>> >
>> > This is not the issue.
>> 
>> The difference between the identity in a certificate and SMTP delivery
>> information is precisely the issue.
>
>The issue is the syntax of identities.  An identity which is different
>than the SMTP delivery information can still be in RFC822 syntax.
>
>> Do you believe that the above scenario and others like it should be
>> precluded by the S/MIME specification?
>
>It is perfectly legitimate for a cert which contains the identities
>"John Gardiner Myers"@netscape.com and/or [email-masked] to be used for
>mail delivered to [email-masked].  I believe such is an uncommon
>case, and retail UAs are likely to express this situation with a more
>complex UI than they use for the case where the delivery address matches
>an identifier in the cert.
>
>It greatly complicates matters if the UA has to do something with
>identities not in RFC822 syntax.
>
>
>

Date: Tue, 23 Dec 1997 08:59:14 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

First of all, all identifers are strings; there should be no problem
presenting them. Secondly, I want to choose my identity, how I am
represented to the world for purposes of trust. One of my email accounts is
"[email-masked]", and this conveys nothing to recipients about who sent
this message. I also have mail forwarder accounts with yet other cryptic
addresses.

I suggest again that we allow, or even encourage the use of RFC822
identifiers, but don't require them or force the UA to validate them
against the From address. When I receive a signed message, and am informed
that the signature is valid, I want to see whatever info I can about who
the signer was.

Elliott Ginsburg

At 03:52 PM 12/22/97 -0800, John Gardiner Myers wrote:
>Paul Hoffman / IMC wrote:
>> 
>> At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
>> >Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
>> >some sort of mandatory identity syntax.  Otherwise it is likely that
>> >conforming implementations will fail to interoperate.
>> 
>> I'm not sure if I agree here (and I really mean "not sure"). When checking
>> the validity of a signature in S/MIME, the receiving agent looks at a
>> certificate from a mutually-trusted CA. I think that there is an assumption
>> that maybe we need to state more clearly in the document: If you trust the
>> CA, you also trust the CA's method(s) of identifying users. A CA might use
>> RFC822 addressess, might use DNs, or might use both (or others).
>
>If a CA only uses DNs and the receiving UA is only able to present
>RFC822 addresses in a way that is comprehensible to the receiving
>end-user, then the CA and the UA have failed to interoperate.  If both
>conform to the S/MIME specification, then the S/MIME specification has
>failed.
>
>Having a user indicate to a UA that a given CA is trusted does not
>magically give that UA the ability to present whatever identity syntaxes
>that CA chooses to put in its certificaes.   Different identity syntaxes
>require different code.
>
>> Putting it a different way, you must accept whatever your CA gives you for
>> an identifier when validating a signature. If you are an RFC822 kind of
>> program, you can still use a CA that uses other blobs for the identifiers.
>
>In such an appplication, a CA that does not use RFC822-syntax
>identifiers is not appropriate, and the standard for such an application
>needs to state that such CAs do not conform.
>
>> However, you won't be able to do much with those blobs after validating a
>> signature other than storing them for future reference.
>
>Then what's the point of having a CA involved in the first place?
> 
>> [...] but I don't see a need to force
>> everyone to use a single identifier if any identifier will work as long as
>> you have a mutual agreement with your CA as to what the identifiers mean.
>
>Likewise, any cipher suite will work as long as you have a mutual
>agreement between the sender and recipient as to which to use.  Such an
>approach does not lead to interoperability.
>
>> However, elevating it to a MUST seems to stymie some potential uses of
>> S/MIME without adding value that isn't already added in the inherent trust
>> model between users and their CAs.
>
>Those uses can profile S/MIME to fit their needs.  For example, a
>commerce application could replace the RFC822 identity requirement with
>a credit card identity for a purchase request.  Such an application
>doesn't have to interoperate with Internet mail--the only useful sender
>CAs and recipient UA's are those which understand credit cards.
>
>
>

Date: Tue, 23 Dec 1997 08:43:12 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

I don't think the question is whether RFC822 syntax identities are useful
for S/MIME; I think the issue is whether this identity must match the From
header address. A message on the list yesterday did a very good job of
distinguishing between an SMTP delivery address and an identifier and the
many reasons why I may have multiple addresses. If the RFC822 syntax
identity is what a user or domain wants to use to represent to recipients
that user, no problem. But to require that this identifier match the actual
header address will break mail. Just to try to summarize some of the
reasons why there could be different From addresses:

- multiple email accounts
- changing email accounts
- use of mail forwarding services
- gateways
- LAN-based mail not using RFC822 syntax internally
- use of someone else's account or a temporary account (e.g., at IETF)

Many RFC822 syntax addresses are not very descriptive of who the user is; I
would like the option of representing myself with the kind of flexibility I
get with a DN. All I ask is that the identity I choose be presented to the
recipient so they will know who signed the message.

Elliott Ginsburg

At 01:57 PM 12/22/97 -0800, John Gardiner Myers wrote:
>Elliott N Ginsburg wrote:
>> I don't see why everyone assumes that S/MIME equates with email. It is
>> likely to be carried over HTTP and there is an electronic commerce/EDI
>> group looking at it for use there.
>
>Internet mail is the primary application for S/MIME.  That is, if
>Internet mail applications using S/MIME fail to interoperate, then the
>S/MIME standard has clearly failed.  This is not true for any other
>application.
>
>If the choices made in S/MIME make it useful for other applications,
>then that is a bonus.  There is every reason to think that RFC822 syntax
>identities are usable for common Internet HTTP.
>
>If some other application does not need to fully interoperate with
>Internet mail, would like to use the bulk of S/MIME, but finds S/MIME's
>requirements insufficient or inappropriate, then the thing for that
>application to do is to *PROFILE* S/MIME, specifying whatever identity,
>cipher, etc. requirements it needs instead of or in addition to the base
>S/MIME standard.
>
>Interoperability and generality are diametrically opposed. 
>Interoperability is Job #1.  Generality is secondary.
>
>
>

Date: Mon, 22 Dec 1997 21:32:25 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

At 08:01 PM 12/22/97 -0800, John Gardiner Myers wrote:
>> >If a CA only uses DNs and the receiving UA is only able to present
>> >RFC822 addresses in a way that is comprehensible to the receiving
>> >end-user, then the CA and the UA have failed to interoperate.
>> 
>> True, but I assert that that failure is due to the presentation problem,
>> not to the protocol.
>
>Huh?  If the CA and receiving UA fail to interoperate, at least one of
>the following has occurred:
>
>A) The CA is non-conforming
>B) The UA is non-conforming
>C) Something in the path between the CA and UA is broken.
>D) The S/MIME standard is broken.
>
>For purposes of my statement above, we can rule out (C).  Which of the
>remaining is it?

OK, I misworded my answer. Instead of saying "True", I should have said
"False". The UA and CA can interoperate even if the UA can't present RFC822
addresses in a way that is comprehensible to the receiving end-user. It's
the UA and the end user that are not interoperating. That's out of scope.

>The format of the identifier controls how the UA has to
>present it, and it controls how humans are able to interpret it.

Yes to the former, no to the latter. Humans interpret it as we damn well
please. Saying one kind of opaque string is more understandable than
another, particularly when you are guaranteed that an intelligent piece of
software will be displaying it, is silly.

>If you can't do anything with the identity, what's the point in having
>it assured?

You have already said you can't do anything reliable with
"[email-masked]". It may not be a recipient for a future message, so
putting it in an address book is wrong. Comparing it to unauthenticated
information that came with the signed message is unsafe so should not be
done. What else were you planning on doing with it?

>It tells a user that the identity is something at "blobbo.com", and that
>the user can apply some external knowledge concerning the identifier
>policies of "blobbo.com" to get further knowledge of the identity.

Ah, I see where we are differing here. You are assuming that some
infrastructure will exist to aid users in getting further knowledge. You
hadn't said this before. Such an infrastructure could give further
knowledge about identifier policies for names in any format.

>An RFC822 name means exactly what the entity that controls the domain
>part wants it to mean, no more, no less.  The domain can choose to make
>the name usable as a delivery address or it could not.

...if the domain even exists. You're making lots of hidden assumptions
here, given that you already said that the identifier didn't have to be a
deliverable address. You are now saying that the right hand side (RHS) of
the identifier must be an existing domain name, not just a syntactically
correct one. I think you're also saying that it can somehow possibly
respond to queries about LHS names at that domain. This is a far cry from
what you said before.

Your repsonses leads to a lot of thorny questions.
- Does the RHS need to exist? If the RHS doesn't need to exist, the user
can't apply any external knowledge.
- If the RHS needs to exist, how does a disconnected user validate this? If
he can't validate it, what should he do with the signature?
- Does a domain named in the RHS have to be part of some policy-emitting
infrastructure? If not, what "external knowlege" does the user get from
knowing only that the RHS exists?
- If a domain named in the RHS has to be part of some policy-emitting
infrastructure, who at the domain named in the RHS controls the policy
emitter? Using what protocol? I admit I haven't followed all the other
security work as closely as I would like, but I've never heard of any such
protocol or the semantics associated with it.
- If the site in the RHS doesn't emit a policy, what should a user do with
a signature that has that RHS?

As you can see, I'm skeptical of all of this. I think a better protocol is
to say "UAs that trust a CA to validate signatures also must trust whatever
identifier the CA gives it". Anything else, including side-validation and
policy finding, is way outside the scope of the document.

Telling the user "you might recognize the format of the identifier and you
can make lots of possibly-wrong guesses based on that format" is OK, but I
wouldn't force it on every S/MIME implementation. I'd say that instead, we
could use RFC822 addresses as a SHOULD, and make it real clear in the spec
exactly what semantics they *don't* convey.

>Is it your position that other applications do not need to have
>restrictions on identifier syntaxes?  If not, what exactly is your
>position on mandatory minimum identifier syntaxes?

My position is that the "restrictions" on identifier syntaxes can be
something as general as "a UTF-8 string". UAs and CAs can interoperate with
this. UAs can display this to their human users. Making the humans
"understand" it is difficult, but as you can see from above, it is also
difficult for supposedly "simple" formats as well.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 20:01:05 -0800
Organization: Netscape Communications Corporation
Lines: 145
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 03:52 PM 12/22/97 -0800, John Gardiner Myers wrote:
> >If a CA only uses DNs and the receiving UA is only able to present
> >RFC822 addresses in a way that is comprehensible to the receiving
> >end-user, then the CA and the UA have failed to interoperate.
> 
> True, but I assert that that failure is due to the presentation problem,
> not to the protocol.

Huh?  If the CA and receiving UA fail to interoperate, at least one of
the following has occurred:

A) The CA is non-conforming
B) The UA is non-conforming
C) Something in the path between the CA and UA is broken.
D) The S/MIME standard is broken.

For purposes of my statement above, we can rule out (C).  Which of the
remaining is it?

> All UAs need to be able to present signature
> verification information to the "user" (human or otherwise) in a useful
> fashion.

"All" he says.  In the domain of retail Internet UA's, "useful fashion"
includes "in a simple enough form for anyone off the street to be able
to comprehend."

> For instance, I think it's perfectly reasonable for a receiving
> agent to say "it was signed properly, as verified by FooCA, with a
> signature of BlobboCorp."

You've lost most of the Internet mail user base right there.  Think:
Secure Mail for Dummies.

> As long as you trust your CA to give a unique ID to BlobboCorp, that's all
> that matters as far as interoperability goes. And that belief doesn't (as
> far as I can tell) rely on the format of the identifier.

On the contrary: the format of the identifier controls how the UA has to
present it, and it controls how humans are able to interpret it.

> >Having a user indicate to a UA that a given CA is trusted does not
> >magically give that UA the ability to present whatever identity syntaxes
> >that CA chooses to put in its certificaes.
> 
> It does if the spec says it does.

This was a source of amusement for the UI programmer in the next cube. 
Let's try an exercise: you are an S/MIME UA implementation.  Your user
indicates that the "John Gardiner Myers CA" is trusted.  You receive a
message that was signed using a key certified by the "John Gardiner
Myers CA".  In the cert, there is one identity, which has the "John
Gardiner Myers Special Sauce" syntax.  The value of that identity is the
base64 decoding of:

XyHzIC4v4D+7C1pMocjcx1H8HpfJqnxJXrhS5NfEZa6WigKALrE2z6rNNqtKFgPcNll5HMHT
g9ipla52LPhsiTNztakSmwGJP/Un+IKXa4SMRO80yyB36QfBq8U3lFYVSizzw74k1vbYBd7W
5Uucqz4Hk1q7EFGalaSTPY7Si0RxLqvSuCq3Wa7/UitRk7bhCcRlN5bRLTiaQWCIK9hnjOh8
0UiYdtEWG2D5mDRLeydyJCJtcvA4vsLCBKu8vXUHFMZsLxTulaxa2TM5mIhaqH2cxyXvWVXL
0hP4GB+VxHksF3qzMcmDvqRL4Y//VFhHf87I1F40GK4o7lMmX2vKvcTkBpmYzYkU2TrI5FzI

Present that identity to the user in a form they will be able to
comprehend.

> >> However, you won't be able to do much with those blobs after validating a
> >> signature other than storing them for future reference.
> >
> >Then what's the point of having a CA involved in the first place?
> 
> To assure you of the identity of the signer.

If you can't do anything with the identity, what's the point in having
it assured?

> Looking at it a different way, if "[email-masked]" does not have to be a
> deliverable address (which I agree it doesn't), what does it tell you that
> "BlobboCorp" or "c=zw, o=BlobboCorp" doesn't?

It tells a UA how to present the identity in a form an Internet mail
user can reasonably be expected to comprehend.

It tells a user that the identity is something at "blobbo.com", and that
the user can apply some external knowledge concerning the identifier
policies of "blobbo.com" to get further knowledge of the identity.

> >Likewise, any cipher suite will work as long as you have a mutual
> >agreement between the sender and recipient as to which to use.  Such an
> >approach does not lead to interoperability.
> 
> Completely right, but a bad analogy. If there is no meaning associated with
> the RFC822 address you want to insist on (that is, it doesn't mean anything
> as a useful recipient address), it's just a format that happens to have
> some syntactical limitations to it. 

You are incorrectly equating "it doesn't mean anything as a useful
recipient address" with "it doesn't mean anything".

An RFC822 name means exactly what the entity that controls the domain
part wants it to mean, no more, no less.  The domain can choose to make
the name usable as a delivery address or it could not.

This is the case with any identity syntax: the meaning of an identity is
entirely up to the issuer of that identity.  More information than that
can only be obtained through a series of bilateral agreements.

So I contend that an RFC822-syntax identifier has the meaning that it
identifies whatever the owner of the domain in the right hand part calls
the left hand part.  Receiving UA's can use this knowledge of the
identifier syntax and semantics to appropriately display and process the
identification in an interoperable fashion.  The analogy holds.

> Any format would work there. I'm happy
> to pick an ASN.1 string type and say "it must be one of these" in that
> case, and make sure that type is as general as possible.

Again, generality is the antithesis of interoperability.  In practice,
identifiers do need hierarchy in their namespaces.

> Stated another way, you want the "default" profile to be Internet mail, and
> other applications have to deviate from the default.

Other applications have to deviate from the default only if the default
profile does not suit their needs.

> I'd definitely be
> behind that *only if* the indentifier MUST be a valid, usable Internet mail
> address associated with the signer, therefore having some value other than
> its uniqueness.

Please give a technical justification for this requirement on
RFC822-syntax identifiers.

> However, we've seen many reasons why that is too
> restrictive, and why it's not useful (header spoofing), so I'd say forcing
> other applications to create separate profiles for just this one value is
> not useful.

Which reasons are these?  Please call them out so that I can
individually address them.

Is it your position that other applications do not need to have
restrictions on identifier syntaxes?  If not, what exactly is your
position on mandatory minimum identifier syntaxes?

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 18:09:51 -0800
Organization: Netscape Communications Corporation
Lines: 138
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

David P. Kemp wrote:
> The point is not that a compuserve user could get a certificate with that
> DN, it is that a person having a certificate with a real name (sorry to pick
> on you, but use "O=netscape.com, CN=John Gardiner Myers" as an example again)
> could use a cryptically-named compuserve email account *and* an
> employer-provided email account, both with the same certificate.

Even simpler, I could have a certificate with both
12345,[email-masked] and "John Gardiner Myers"@netscape.com. 
What's the advantage of putting it in DN syntax?

> > If the standard permits eithe syntax, some CA's only use DN syntax, and
> > some UAs only use RFC822 syntax, then you have "conforming but
> > noninteroperable".
> 
> If the standard requires that a DN, an RFC822 name, or both be present
> in a certificate, and requires that UAs to support DN and RFC822 forms,
> then conformance implies interoperability.

This is one of the possible solutions to this interoperability issue. 
Later in this message I will argue that the solution of mandating RFC822
names only is better for the Internet mail application, but can we first
get consensus on the basics:

JGM1) In order to interoperate, each application of S/MIME must specify
mandatory minimum idenitfier syntax requirements on CAs and receiving
UAs, such that every conforming cert has identifiers interperable
(subject to policy) by every conforming UA.

JGM2) The mandatory identifier syntax requirements of Internet mail
should be specified in a base S/MIME document.

JGM3) Applications other than Internet mail may profile S/MIME to change
these identifier syntax requirements as necessary.

> > If an attacker can subvert the UA's mapping, they can cause the UA to
> > choose the wrong public key.  Suppose I am able to add a mapping into
> > Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
> > "[email-masked]".
> 
> The UA does not choose a public key, the user chooses the public key
> based on the name bound to that key in a certificate.

No interface I know of has the user typing in a public key.  Some
software somewhere chooses
a public key based on some input it got from the user and some system
for mapping that input to a public key.

> If Paul encrypts a message to "O=netscape.com, CN=John Gardiner Myers"
> and his address book causes the message to be sent to
> [email-masked], then I get (unreadable) copies of messages
> intended for you, and you don't get copies unless I'm kind enough to
> forward them to you :-).

You have mixed up who is the attacker and who is the attackee.  I am the
attacker.  For purposes of this exercise, we postulate that I am able to
make modifications to Paul's address book and that I am able to subvert
the mail transport between Paul and you.

Paul needs to send you an important, private message.  Paul is a busy
person.  He's the co-founder of an industry consortium for Internet
mail.  Having much familiarity with Internet mail, he uses the same,
simple, interface he has always used for informing his UA to whom the
mail is intended: he types "[email-masked]" into the To: field of
his compose window.

Since you have a perfectly conforming cert which fails to certify the
mapping of "[email-masked]" to your public key, the UA needs some
database mapping that either to a public key or to some other name which
has a certified mapping to a public key.  Since I have subverted that
database, I get the UA to map that to "O=netscape.com, CN=John Gardiner
Myers", which has a certified mapping to my public key.  Thus I cause
mail intended for you to be encrypted with my public key.

Since I have subverted the delivery system, I can intercept that message
and prevent it from being delivered to you.  After decrypting and
reading the message, I can re-encrypt it with your real public key and
inject that into the delivery system destined for you.

> >  I can now make Paul believe that things I
> > signed came from you, and I can decrypt any mail from him to you that I
> > am able to snoop off the wire.
> 
> Say what?  If Paul receives a message signed by your key which is bound
> in a cert to your DN, why would he believe it came from me (regardless
> of any tampered SMTP header or any misconfiguration of his address book)?

That is because Paul, being a busy person, doesn't have the time to
parse the DN for every message he receives.  Being an Internet mail kind
of person, he thinks in terms of RFC822 syntax.  He uses a UA which
checks the header against the certification using the mapping in the
subverted address book and displays a simple icon stating "yup, this was
signed."

Suppose the UA always displays the DN that was certified.  Now suppose
the attacker has the legal name "David P. Kemp".  What is the likelihood
that Paul will notice that fields in the DN other than CN aren't what
they should be?  Most Internet mail users can't distinguish a DN from
base64-encoded line noise.

> And if Paul encrypts a message to my DN using my certified public key,
> how would you be able to read it?

Paul doesn't encrypt a message to your DN.  I trick his UA into using my
DN.

If you claim that Paul should always be picking a DN to use out of an
address book or directory and that his UA should display every single
component of the DN, then I would say you have given Paul's UA all the
simplicity and ease of use of X.400.

> > > If I want to send mail to the person I know as
> > > "O=netscape.com, CN=John Gardiner Myers", or the person I know as
> > > "[email-masked]", then what difference does it make if the mail gets
> > > addressed and delivered to [email-masked] as long as it eventually
> > > winds up in a location where the person holding the private key
> > > corresponding to the certified identity can read it?
> >
> > This is not the issue.
> 
> The difference between the identity in a certificate and SMTP delivery
> information is precisely the issue.

The issue is the syntax of identities.  An identity which is different
than the SMTP delivery information can still be in RFC822 syntax.

> Do you believe that the above scenario and others like it should be
> precluded by the S/MIME specification?

It is perfectly legitimate for a cert which contains the identities
"John Gardiner Myers"@netscape.com and/or [email-masked] to be used for
mail delivered to [email-masked].  I believe such is an uncommon
case, and retail UAs are likely to express this situation with a more
complex UI than they use for the case where the delivery address matches
an identifier in the cert.

It greatly complicates matters if the UA has to do something with
identities not in RFC822 syntax.

Date: Mon, 22 Dec 1997 16:40:42 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

At 03:52 PM 12/22/97 -0800, John Gardiner Myers wrote:
>If a CA only uses DNs and the receiving UA is only able to present
>RFC822 addresses in a way that is comprehensible to the receiving
>end-user, then the CA and the UA have failed to interoperate.

True, but I assert that that failure is due to the presentation problem,
not to the protocol. All UAs need to be able to present signature
verification information to the "user" (human or otherwise) in a useful
fashion. For instance, I think it's perfectly reasonable for a receiving
agent to say "it was signed properly, as verified by FooCA, with a
signature of BlobboCorp." without making any linkage between BlobboCorp and
the sender, or BlobboCorp and a return address. If the name BlobboCorp
doesn't mean anything to you, that tells you something about what you
should believe about the signature.

As long as you trust your CA to give a unique ID to BlobboCorp, that's all
that matters as far as interoperability goes. And that belief doesn't (as
far as I can tell) rely on the format of the identifier. 

>Having a user indicate to a UA that a given CA is trusted does not
>magically give that UA the ability to present whatever identity syntaxes
>that CA chooses to put in its certificaes.

It does if the spec says it does.

>> However, you won't be able to do much with those blobs after validating a
>> signature other than storing them for future reference.
>
>Then what's the point of having a CA involved in the first place?

To assure you of the identity of the signer. "BlobboCorp" and
"[email-masked]" are both identifiers that you might get back. 

Looking at it a different way, if "[email-masked]" does not have to be a
deliverable address (which I agree it doesn't), what does it tell you that
"BlobboCorp" or "c=zw, o=BlobboCorp" doesn't? If you can't do anything with
the RFC822 address, then it is as opaque as any of the other identifiers.

>Likewise, any cipher suite will work as long as you have a mutual
>agreement between the sender and recipient as to which to use.  Such an
>approach does not lead to interoperability.

Completely right, but a bad analogy. If there is no meaning associated with
the RFC822 address you want to insist on (that is, it doesn't mean anything
as a useful recipient address), it's just a format that happens to have
some syntactical limitations to it. Any format would work there. I'm happy
to pick an ASN.1 string type and say "it must be one of these" in that
case, and make sure that type is as general as possible.

>> However, elevating it to a MUST seems to stymie some potential uses of
>> S/MIME without adding value that isn't already added in the inherent trust
>> model between users and their CAs.
>
>Those uses can profile S/MIME to fit their needs.  For example, a
>commerce application could replace the RFC822 identity requirement with
>a credit card identity for a purchase request.  Such an application
>doesn't have to interoperate with Internet mail--the only useful sender
>CAs and recipient UA's are those which understand credit cards.

Stated another way, you want the "default" profile to be Internet mail, and
other applications have to deviate from the default. I'd definitely be
behind that *only if* the indentifier MUST be a valid, usable Internet mail
address associated with the signer, therefore having some value other than
its uniqueness. However, we've seen many reasons why that is too
restrictive, and why it's not useful (header spoofing), so I'd say forcing
other applications to create separate profiles for just this one value is
not useful.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 15:52:47 -0800
Organization: Netscape Communications Corporation
Lines: 55
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
> >Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
> >some sort of mandatory identity syntax.  Otherwise it is likely that
> >conforming implementations will fail to interoperate.
> 
> I'm not sure if I agree here (and I really mean "not sure"). When checking
> the validity of a signature in S/MIME, the receiving agent looks at a
> certificate from a mutually-trusted CA. I think that there is an assumption
> that maybe we need to state more clearly in the document: If you trust the
> CA, you also trust the CA's method(s) of identifying users. A CA might use
> RFC822 addressess, might use DNs, or might use both (or others).

If a CA only uses DNs and the receiving UA is only able to present
RFC822 addresses in a way that is comprehensible to the receiving
end-user, then the CA and the UA have failed to interoperate.  If both
conform to the S/MIME specification, then the S/MIME specification has
failed.

Having a user indicate to a UA that a given CA is trusted does not
magically give that UA the ability to present whatever identity syntaxes
that CA chooses to put in its certificaes.   Different identity syntaxes
require different code.

> Putting it a different way, you must accept whatever your CA gives you for
> an identifier when validating a signature. If you are an RFC822 kind of
> program, you can still use a CA that uses other blobs for the identifiers.

In such an appplication, a CA that does not use RFC822-syntax
identifiers is not appropriate, and the standard for such an application
needs to state that such CAs do not conform.

> However, you won't be able to do much with those blobs after validating a
> signature other than storing them for future reference.

Then what's the point of having a CA involved in the first place?
 
> [...] but I don't see a need to force
> everyone to use a single identifier if any identifier will work as long as
> you have a mutual agreement with your CA as to what the identifiers mean.

Likewise, any cipher suite will work as long as you have a mutual
agreement between the sender and recipient as to which to use.  Such an
approach does not lead to interoperability.

> However, elevating it to a MUST seems to stymie some potential uses of
> S/MIME without adding value that isn't already added in the inherent trust
> model between users and their CAs.

Those uses can profile S/MIME to fit their needs.  For example, a
commerce application could replace the RFC822 identity requirement with
a credit card identity for a purchase request.  Such an application
doesn't have to interoperate with Internet mail--the only useful sender
CAs and recipient UA's are those which understand credit cards.

From: Larry Layten <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: The address-in-certs issue
Date: Mon, 22 Dec 1997 16:52:18 -0600
Sender: [email-masked]

Paul,

I agree with you. But there also is a point in John's message that may be
worth noting in the S/MIME standard -- that is:

>If an attacker can subvert the UA's mapping, they can cause the UA to
>choose the wrong public key.  Suppose I am able to add a mapping into
>Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
>"[email-masked]".  I can now make Paul believe that things I
>signed came from you, and I can decrypt any mail from him to you that I
>am able to snoop off the wire.

I don't agree with the point of needing interoperability of address books, but
John further states:

>The security of such an address book is critical to the security of
>S/MIME.  The S/MIME protocol would then have to find a way to
>appropriately secure the mandatory address book protocol, as well as
>explicitly call out the security considerations of such address books.

It could be said that if a user agent utilizes such a mapping of addresses
to certificates, that the mapping should be appropriately protected by
the user agent, or display the mapping to the user prior to usage.
But this attack would only be successful once without a man-in-the-
middle attack, as the real recipient wouldn't be able to read the 
message, which should cause someone to look into the problem.

Larry

----------
From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
Sent: 	Monday, December 22, 1997 4:05 PM
To: 	[email-masked]
Subject: 	Re: The address-in-certs issue

At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
>Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
>some sort of mandatory identity syntax.  Otherwise it is likely that
>conforming implementations will fail to interoperate.

I'm not sure if I agree here (and I really mean "not sure"). When checking
the validity of a signature in S/MIME, the receiving agent looks at a
certificate from a mutually-trusted CA. I think that there is an assumption
that maybe we need to state more clearly in the document: If you trust the
CA, you also trust the CA's method(s) of identifying users. A CA might use
RFC822 addressess, might use DNs, or might use both (or others).

Putting it a different way, you must accept whatever your CA gives you for
an identifier when validating a signature. If you are an RFC822 kind of
program, you can still use a CA that uses other blobs for the identifiers.
However, you won't be able to do much with those blobs after validating a
signature other than storing them for future reference.

If you insist on being able to use the identifier for some additional
purpose (such as comparing it with the From: and Sender: headers), then you
must use a CA that uses the right kind of identifier. However, these
purposes are (as of the discussion of the last few weeks) not required by
S/MIME. We should do nothing to prevent them, and I think we should at
least discuss how some might do them, but I don't see a need to force
everyone to use a single identifier if any identifier will work as long as
you have a mutual agreement with your CA as to what the identifiers mean.

This isn't to say we can't make the RFC822 format a SHOULD for identifiers;
I think that would be exactly right given that much of what we do in S/MIME
is for Internet mail, and that format works just fine for that purpose.
However, elevating it to a MUST seems to stymie some potential uses of
S/MIME without adding value that isn't already added in the inherent trust
model between users and their CAs.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 22 Dec 1997 17:46:18 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
>
> > And by
> > extension is "12345,[email-masked]" also more simple and comprehensible
> > than a DN?
> 
> Yes.  The user clearly knows that it is the identity "12345,3924" issued
> by "compuserve.com".  To know more, they would have to know about the
> identity-issuing policies "compuserve.com".  (And possibly the
> delegation policies of ".com".)
> 
> The DN representation of this information would be something like:
> 
> C=US, O=CompuServe Inc., CN=12345,3924
> 
> give or take a few characters.

The point is not that a compuserve user could get a certificate with that
DN, it is that a person having a certificate with a real name (sorry to pick
on you, but use "O=netscape.com, CN=John Gardiner Myers" as an example again)
could use a cryptically-named compuserve email account *and* an
employer-provided email account, both with the same certificate.

> If the standard permits eithe syntax, some CA's only use DN syntax, and
> some UAs only use RFC822 syntax, then you have "conforming but
> noninteroperable".

If the standard requires that a DN, an RFC822 name, or both be present
in a certificate, and requires that UAs to support DN and RFC822 forms,
then conformance implies interoperability.

> > Please explain why there is any security issue involved.
> 
> If an attacker can subvert the UA's mapping, they can cause the UA to
> choose the wrong public key.  Suppose I am able to add a mapping into
> Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
> "[email-masked]".

The UA does not choose a public key, the user chooses the public key
based on the name bound to that key in a certificate.

If Paul encrypts a message to "O=netscape.com, CN=John Gardiner Myers"
and his address book causes the message to be sent to
[email-masked], then I get (unreadable) copies of messages
intended for you, and you don't get copies unless I'm kind enough to
forward them to you :-).  That's denial of service.  It is impossible
for a security protocol to prevent DoS - the best that can be done is
to avoid having security exacerbate problems that exist in non-secure
versions.  Since your run-of-the-mill non-secure MUA has an address
book that could be configured to send mail for "John Gardiner Myers" to
[email-masked], the S/MIME DoS situation is no worse.

>  I can now make Paul believe that things I
> signed came from you, and I can decrypt any mail from him to you that I
> am able to snoop off the wire.

Say what?  If Paul receives a message signed by your key which is bound
in a cert to your DN, why would he believe it came from me (regardless
of any tampered SMTP header or any misconfiguration of his address book)?

And if Paul encrypts a message to my DN using my certified public key,
how would you be able to read it?

Address book misconfiguration/tampering might cause your mail to be
delivered to me, or my mail to be delivered to you.  And sniffing could
result in mail showing up in lots of places not intended by the sender.
But without my private key you can't read my mail, regardless of how
you managed to get a copy of it.

> > If I want to send mail to the person I know as
> > "O=netscape.com, CN=John Gardiner Myers", or the person I know as
> > "[email-masked]", then what difference does it make if the mail gets
> > addressed and delivered to [email-masked] as long as it eventually
> > winds up in a location where the person holding the private key
> > corresponding to the certified identity can read it?
> 
> This is not the issue.

The difference between the identity in a certificate and SMTP delivery
information is precisely the issue.

Do you believe that the above scenario and others like it should be
precluded by the S/MIME specification?

Date: Mon, 22 Dec 1997 14:05:40 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
>Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
>some sort of mandatory identity syntax.  Otherwise it is likely that
>conforming implementations will fail to interoperate.

I'm not sure if I agree here (and I really mean "not sure"). When checking
the validity of a signature in S/MIME, the receiving agent looks at a
certificate from a mutually-trusted CA. I think that there is an assumption
that maybe we need to state more clearly in the document: If you trust the
CA, you also trust the CA's method(s) of identifying users. A CA might use
RFC822 addressess, might use DNs, or might use both (or others).

Putting it a different way, you must accept whatever your CA gives you for
an identifier when validating a signature. If you are an RFC822 kind of
program, you can still use a CA that uses other blobs for the identifiers.
However, you won't be able to do much with those blobs after validating a
signature other than storing them for future reference.

If you insist on being able to use the identifier for some additional
purpose (such as comparing it with the From: and Sender: headers), then you
must use a CA that uses the right kind of identifier. However, these
purposes are (as of the discussion of the last few weeks) not required by
S/MIME. We should do nothing to prevent them, and I think we should at
least discuss how some might do them, but I don't see a need to force
everyone to use a single identifier if any identifier will work as long as
you have a mutual agreement with your CA as to what the identifiers mean.

This isn't to say we can't make the RFC822 format a SHOULD for identifiers;
I think that would be exactly right given that much of what we do in S/MIME
is for Internet mail, and that format works just fine for that purpose.
However, elevating it to a MUST seems to stymie some potential uses of
S/MIME without adding value that isn't already added in the inherent trust
model between users and their CAs.

--Paul Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 13:57:36 -0800
Organization: Netscape Communications Corporation
Lines: 23
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Elliott N Ginsburg wrote:
> I don't see why everyone assumes that S/MIME equates with email. It is
> likely to be carried over HTTP and there is an electronic commerce/EDI
> group looking at it for use there.

Internet mail is the primary application for S/MIME.  That is, if
Internet mail applications using S/MIME fail to interoperate, then the
S/MIME standard has clearly failed.  This is not true for any other
application.

If the choices made in S/MIME make it useful for other applications,
then that is a bonus.  There is every reason to think that RFC822 syntax
identities are usable for common Internet HTTP.

If some other application does not need to fully interoperate with
Internet mail, would like to use the bulk of S/MIME, but finds S/MIME's
requirements insufficient or inappropriate, then the thing for that
application to do is to *PROFILE* S/MIME, specifying whatever identity,
cipher, etc. requirements it needs instead of or in addition to the base
S/MIME standard.

Interoperability and generality are diametrically opposed. 
Interoperability is Job #1.  Generality is secondary.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 12:58:26 -0800
Organization: Netscape Communications Corporation
Lines: 156
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

The key issue here is interoperability.  If it is possible to have a set
of components, each of which individually conform to the standard, yet
the comonents do not interoperate, then the standard has failed.  In a
security context, interoperate means "works when the security policy
permits, does not work when the security policy prohibits".

When protocols allow too much flexibility in what kinds of widgits
implementors can use to fill some critical slot, this sort of
"conforming but noninteroperable" problem can occur.  The solution is
for the standard to pick a small number of widgits (preferably one) to
make mandatory.  Examples of such widgits are cipher suites and identity
syntaxes.

Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
some sort of mandatory identity syntax.  Otherwise it is likely that
conforming implementations will fail to interoperate.

David P. Kemp wrote:
> > From: John Gardiner Myers <[email-masked]>
> >
> > In order for S/MIME agents to interoperate, receiving UA's need to be
> > able to present an identity of the signer to the user in a manner that
> > is simple and comprehensible.  This is not going to work if UA's have to
> > deal with presenting two entirely different syntaxes for identities,
> > especially if one of them is as complex as the DN syntax.'
> 
> This is irrelevant to the question at hand, but why do you feel that
> "O=netscape.com, CN=John Gardiner Myers" is complex and incomprehensible,
> whereas "[email-masked]" is simple and comprehensible?

Your strawman DN is simpler than DNs are in practice.  Also, that DN can
be trivially represented in RFC822 syntax: "John Gardiner
Myers"@netscape.com.  Representing it that way makes the UA's task of
presenting the identity far simpler.  Users know what "@" means, users
do not know what "O=", and "CN=" is.
 
> And by
> extension is "12345,[email-masked]" also more simple and comprehensible
> than a DN?

Yes.  The user clearly knows that it is the identity "12345,3924" issued
by "compuserve.com".  To know more, they would have to know about the
identity-issuing policies "compuserve.com".  (And possibly the
delegation policies of ".com".)

The DN representation of this information would be something like:

C=US, O=CompuServe Inc., CN=12345,3924

give or take a few characters.

> The reason this is irrelevant is that there is no reason to either
> require or prohibit users from choosing their preferred form of identity.
> If some users want identities in RFC822 syntax, that's fine.  If other
> users want identities in DN syntax (to enable the same cert to be used
> for S/MIME and non-S/MIME purposes, for example), then that's fine too.

If the standard permits eithe syntax, some CA's only use DN syntax, and
some UAs only use RFC822 syntax, then you have "conforming but
noninteroperable".

> You continue to ignore the distinction between an identity and a mailbox.

That's because any distinction is irrelevant.  Every mailbox is an
identity, and any identity can be represented in RFC822 syntax.  It is
not necessary that something represented in RFC822 syntax be
deliverable.

> People normally would want one (or just a few) identities.  But some users
> change mailboxes often, or have multiple contemporaneous mailboxes, or use
> mail mechanisms that have no meaningful identity at all (IETF terminal
> room - "[email-masked]" for example).

The identity "[email-masked]" is a useful one, it's just not
necessarily useful in the context of Internet mail.  That identity would
be useful in a cert used to access licensed software from a file
server.  That identity is unlikely to be useful in a cert used for
Internet mail, as it is unlikely to be useful in the From: header of an
RFC822 message.

> A mailbox is NOT an identity - and as long as you keep using the same word
> to refer to two different functions, you will continue to be confused
> about the difference between them.

On the contrary, every mailbox is an identity.  That identity may or may
not be useful for a given application.

> > What is more
> > likely is that UA's are going to have to add a subsystem to map
> > DN-syntax identites to RFC822 identities and UAs are going to be far
> > less likely to get the security issues of this mapping right than the
> > far fewer and better equipped CAs.
> 
> Please explain why there is any security issue involved.

If an attacker can subvert the UA's mapping, they can cause the UA to
choose the wrong public key.  Suppose I am able to add a mapping into
Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
"[email-masked]".  I can now make Paul believe that things I
signed came from you, and I can decrypt any mail from him to you that I
am able to snoop off the wire.

Suppose this attack is carried out by someone else named "David P.
Kemp".

> If I want to send mail to the person I know as
> "O=netscape.com, CN=John Gardiner Myers", or the person I know as
> "[email-masked]", then what difference does it make if the mail gets
> addressed and delivered to [email-masked] as long as it eventually
> winds up in a location where the person holding the private key
> corresponding to the certified identity can read it?

This is not the issue.
 
> To be redundantly didactic, the first two are *identities*, either of
> which (the choice is a matter of personal preference) can be used in a
> cert.  The third is a *mailbox* which does not belong in a cert at all.

The third is an identity, and it is useful to have it in a cert.

> S/MIME user agents will maintain an address book mapping identities
> to addresses.

If the interoperability of S/MIME depends on the existence of such an
address book, then S/MIME needs to mandate its presence.  If S/MIME
wishes to mandate its presence, then interoperation of different S/MIME
implementation run by a given user will require them to share this
address book data.  Thus, S/MIME would need to specify a mandatory
address book protocol.

The security of such an address book is critical to the security of
S/MIME.  The S/MIME protocol would then have to find a way to
appropriately secure the mandatory address book protocol, as well as
explicitly call out the security considerations of such address books.

> S/MIME user agents might also have a configurable option
> to allow checking that the identity and the mailbox are the same and
> warning if they are not, for people who choose to use their mailbox as
> their identity.  But there is no reason for S/MIME to mandate that:
>  1) certs contain mailbox addresses,
>  2) certs have identities in RFC822 format, or that
>  3) there be any mandatory checking between identities and mailbox
>     addresses.

It is necessary for there to be some sort of mandatory identity syntax,
otherwise conforming CAs and UAs can fail to interoperate.  For the vast
majority of implementors, RFC822 syntax is the simplest to implement. 
It is also the most appropriate for use in Internet mail.  

The simplest interface for a UA to present is for when the identity in
the From: header matches an identity in the cert.  I can see that for
senders to get these to match with today's technology can be difficult,
so I do not feel as strongly about the matching issue as I feel about
the need for the cert to contain at least one RFC822 syntax identity.

Date: Mon, 22 Dec 1997 15:33:36 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: 12/10/97 IETF S/MIME WG Minutes
Sender: [email-masked]

All,

This message includes the minutes of the IETF S/MIME Working Group meeting
held on 10 December 1997 in Washington, D.C.  These minutes have been
coordinated with the briefing presenters and their comments have been
incorporated.  Over one hundred people attended the meeting.

++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley

Russ reviewed the agenda.  Nobody objected to the agenda.  He then reviewed
the list of the S/MIME WG Internet Drafts (I-D): 

Latest
Revision            I-D Title  <Filename>
---------   ------------------------------------------
Nov 97      Cryptographic Message Syntax (CMS) 
               <draft-ietf-smime-cms-01.txt> 

18 Nov 97   Enhanced Security Services (ESS) for S/MIME
               <draft-ietf-smime-ess-00.txt> 

20 Nov 97   S/MIME Version 3 Message Specification (MSG3)
               <draft-ietf-smime-msg-00.txt> 

Nov 97      S/MIME Version 3 Certificate Handling (CERT3)
                <draft-ietf-smime-cert-00.txt> 

++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented several briefing slides regarding the history of and future
plans for the CMS I-D.  The slides and related discussion are included in
the following text.

Slides:

History

 CMS 00 included: 
   Algorithm Independence:
     No longer depends on RSA algorithms.
     Backwards compatible with PKCS #7 v1.5 when RSA algorithms  used.
   Includes SignedData and EnvelopedData

 CMS 01 included:
   Fixed errors in CMS 00.
   Included placeholder for ASN.1 module.

Future Plans

 CMS 02 proposed changes:
  1) Fixes errors in CMS 01.
  2) Forces originator to provide an encrypted content encryption key
      for himself.
  3) Includes ASN.1 module.
  4) Includes digestedData and encryptedData 
  5) Includes PKCS #9 attributes
  6) Includes placeholder for algorithm specifications             

 Beyond CMS 02
   AuthenticatedData object (facilitates Message Authentication Codes)

Discussion:

CMS 02 Proposal 2:  Russ explained that the inclusion of a copy of the
content encryption key encrypted for the originator in an envelopedData
object will ensure that the originator can decrypt the envelopedData object
if it is returned for non-delivery.  Several WG members objected to the
"mandatory" nature of the proposal.  A comment was made that there will be
one more copy of the content encryption key that can be attacked.  Another
comment was that it takes additional processing resources to encrypt the key
for the originator.  Another comment was that there are customers who
require that encrypted data must not be able to be decrypted by the
originator.  Another point was made that other protocols that use CMS might
not have the property that the originator could get a "bounced" message.
S-HTTP is one example where the originator does not need to have a copy of
the content encryption key encrypted for the originator.  Jeff Schiller
stated that the "MUST implement" requirement means that the implementer must
implement the feature, not that the feature must be present in every
message.  Jeff said that a vendor must implement the "MUST" requirements to
claim conformance to the specification, but that the customer can choose not
to populate the field.  Steve Kent made similar statements.  The consensus
of the WG was that the requirement must not be included in the CMS I-D, but
that it must be included in the MSG3 I-D as a SHOULD requirement.  Blake
Ramsdell took the action to add the requirement to MSG3.

CMS 02 Proposal 3: Russ proposed that the CMS ASN.1 module should use the
1988 ASN.1 syntax definitions with a few added enhancements (such as
BMPString, etc).  He stated that he would prefer not to include two modules
(one using 1988 rules and another using 1994 rules) in CMS.  He stated that
he had drafted a CMS module and that it had been successfully parsed using
three different ASN.1 compilers.  Russ asked if the WG preferred 1988 or
1994 ASN.1 syntax definitions.  The silence was deafening.  Because the 1994
proponents seemed to be absent, Paul Hoffman stood up for them and stated
that their concern (based on message traffic on the S/MIME WG mail list) was
that using the 1988 syntax rules with enhancements did not constitute valid
ASN.1 definitions.  Another WG member stated that the 1994 syntax rules
include the "table" format which tightly binds OIDs with ASN.1 definitions
(in contrast to 1988 OID/ANY pairs) that an ASN.1 compiler can process in
one pass and can check for correctness.  Eric Rescorla said that the "table"
format is not always a positive feature because there are cases in which the
ASN.1 decoding software can decode the object to the point of the OID/ANY
pair, but that other modules of the software can decode the ANY based on the
value of the OID.  The consensus was that the CMS ASN.1 module will use the
1988 ASN.1 syntax definitions with a few enhancements.

CMS 02 Proposal 4:  Russ stated that CMS 02 will include definitions for the
digestedData and encryptedData objects, but that those objects are not
intended for use with S/MIME applications.  The MSG3 I-D will not include
support for digestedData and encryptedData.  They are being added to CMS to
support requirements stated by the S-HTTP proponents.  The S-HTTP
specification needs to point to the CMS I-D because it includes
IETF-acceptable "MUST implement" algorithms.  Nobody objected to the proposal.

CMS 02 Proposal 5:  Russ stated that CMS 02 will include definitions of the
PKCS #9 attributes, so that CMS does not have to refer to the RSA PKCS #9
specification. Nobody objected to the proposal.

CMS 02 Proposal 6:  The WG agreed that the "MUST implement" algorithms are
SHA-1, DSA, Diffie-Hellman (D-H) and 3DES as specified in MSG3.  The D-H
will be one of the x9.42 variants.  The 3DES will use three independent keys
and CBC mode.  Russ stated that CMS 02 will include placeholders for the
algorithm specifications that will include details regarding the use of the
"MUST implement" cryptographic algorithms with CMS.  After a brief debate
regarding which I-D should include the "MUST implement" cryptographic
algorithms, it was agreed that the CMS I-D will specify the "MUST implement"
algorithms and that the MSG3 I-D will refer to the CMS I-D for the
specification of the "MUST implement" algorithms.

++++++++++++++++++++++++++++++++++++++++++++++++

MSG3 Draft Discussion - Blake Ramsdell

Blake stated that MSG3 is based on the S/MIME Version 2 Message
Specification.  It has been updated to support "MUST implement" algorithms
of SHA-1, DSA, D-H and 3DES.  It also includes the RSA algorithms as "SHOULD
implement" algorithms.  [Note that MSG3 will be modified to refer to the CMS
I-D for the specification of the "MUST implement" algorithms.]

Blake stated that the text regarding the Certificate Request message format
and certificate generation issues will be moved to CERT3.

Dave Solo asked which I-D will include text regarding the use of separate
digital signature (DS) and key management (KM) keys.  Blake answered that
CERT3 will include that text.  Paul Hoffman stated that the security section
should include text encouraging the use of separate DS and KM keys.

Jim Schaad stated that the attribute identifying which of a user's
certificates should be used for DS and KM should be included.  The attribute
will be defined as a CHOICE between IssuerandSerialNumber and
subjectKeyIdentifier.  Blake agreed that the attribute will be included in MSG3.

Jim Schaad stated that MSG3, Section 3.1 should be changed to remove the
requirement that the RFC822 "from-field" must be identical to the signer's
RFC822 address included in the signer's X.509 certificate.  Blake agreed.
Eric Rescorla stated that the recipient should be informed if there is a
difference. A WG member asked what requirement, if any, is there for an
RFC822 name in a KM X.509 certificate.  Steve Kent made the point that users
may wish to send messages from multiple mailboxes using the same X.509
certificate.  Steve went on to say that the receiving agent could display
the "from-field" in the normal in-box, but that the signer could be
identified in a security-related window.  Another WG member stated that the
WG should not dictate what the application displays.  The WG agreed with
this concept.  Paul Hoffman terminated the debate by asking that interested
parties send a message to the S/MIME WG mail list proposing specific changes
to MSG3, Section 3.1.

++++++++++++++++++++++++++++++++++++++++++++++++

CERT3 Draft Discussion - Blake Ramsdell

Blake stated that CERT3 refers to the PKIX X.509 Certificate and CRL Profile
(PKIX I).  CERT3 states that certificate extensions should be used as stated
in PKIX I.   CERT3 states that certificates should be allowed to include
RFC822 addresses.  Unless anybody complains, CERT3 will use the certificate
chaining strategy described in PKIX I.   PKIX I allows NULL issuer and
subject DNs, so the issuerAltName and subjectAltName extensions can be used
for chaining.  Nobody objected to the concepts presented by Blake.

++++++++++++++++++++++++++++++++++++++++++++++++

ESS Draft Discussion - Paul Hoffman

Paul stated that ESS describes features not included in the S/MIME v2
documents.  He stated that some of the additional security features
described in ESS can be used in conjunction with S/MIME v2 messages in
addition to S/MIME v3 messages.  He stated that the addition of ESS features
to CMS enables an implementation to meet U.S. Department of Defense (DOD)
requirements.  He described the additional features as follows:

Signed Receipts:  Paul stated that when an originator of a SignedData object
verifies the signature of an ESS Signed Receipt returned by the recipient of
the SignedData object, then the Signed Receipt verification provides proof
to the originator that the recipient received and was able to verify the
signature of the SignedData object (content and authenticated attributes).
Paul stated that ESS Signed Receipts are not intended to provide any other
services.  There have been suggestions discussed on the IETF S/MIME mail
list that additional services should be provided by ESS Signed Receipts.
Paul stated that there are IETF WGs dedicated to calendaring/scheduling
(calsch) and electronic commerce interchange (ediint) that are working on
similar services, so he does not recommend that those services should be
provided by the ESS Signed Receipt.  Nobody objected to this concept.

Security Label:  Identifies the sensitivity of the encapsulated content.  In
addition to meeting US DOD requirements, commercial industry needs this
capability also.  For example, the health care industry needs to label
personal medical data. Nobody objected to this concept.

Mail List Expansion History:  Provides information in the CMS header to warn
ML agents of looping conditions.  A WG member asked if the ML information
increased the risk of traffic analysis.  Paul said yes, but that the benefit
gained far outweighed the risk incurred. Nobody objected to the ML concepts
included in ESS.

A WG member stated that timestamping should be included in ESS.  Another WG
member stated that the IETF must design a standard for digital timestamps.
It was also stated that there would probably be more than one timestamping
service proposed and the S/MIME WG will need to choose the one best suited
for S/MIME.  Once the IETF proposals are stable, then the S/MIME WG can make
that decision.  Everybody agreed with this plan. 

++++++++++++++++++++++++++++++++++++++++++++++++

CRS Draft Discussion - Mike Myers

Background: One of the biggest issues facing the PKIX and S/MIME WGs was the
debate of whether the PKCS 10-based CRS or the PKIX Certificate Management
Protocol (CMP) would be endorsed by IETF as the standard Internet protocol.
The two proposed specifications contained redundant ASN.1 syntaxes for
Certificate Request and other formats.  Prior to the IETF meetings, there
was a proposal to move the CRS work into the S/MIME WG.  At the 8 December
97 IETF PKIX WG, it was decided that the CRS work belonged in the PKIX WG
rather than the S/MIME WG because the Certificate Request format is not an
S/MIME-specific issue, it is a general PKI issue.  The ideal situation would
be to have a common Certificate Request format (and other related
certificate management formats) that can be communicated via various
mechanisms (including S/MIME and others).

Mike presented a series of briefing slides regarding the history of CRS.
The slides and related discussion are included in the following text.

Slides:

TIMELINE:
  - Dec 96: Initial comment on Part 3
       - Floor call showed strong support for 7, 10 reuse
       - Action predicated on PKCS movement into IETF
  - April 97: Further group discussion in Memphis
       - still no constructive movement re: PKCS.
  - August 97: Draft put forward in Munich
       - In anticipation of PKCS 7, 10 movement.
       - A "supplement" to CMP
  - Dec 97: S/MIME now into IETF.
      - 7 &10 Information drafts, CMS proposed standard

CURRENT STATUS OF DRAFT
  - Algorithm Independence
  - Optional transaction ID, nonces
  - Protocol version
  - Separate Signature and Encryption keys
  - Optional encryption, two enveloping methods:
  - Outer signed, inner encrypted
  - Outer encrypted, inner signed
  - Added revocation request, response
  - Other minor edits

PLAN:
  - Standardize that which can be standardized
  - Integrate current comments
  - Active review and comment in Jan 98
  - Final Draft in Feb 98
  - Last Call by next IETF

Discussion:

Mike stated that the CRS and CMP authors and other interested parties had
developed a compromise solution referred to as the "harmonized" Certificate
Request format (which has not yet been publicized).  The end result of the
IETF meetings is that the PKIX WG will publish a separate RFC that includes
the "harmonized" Certificate Request and other related protocols.  The CMP
and CRS I-Ds will be changed to replace their redundant protocols with
pointers to the "harmonized" protocols.  The CRS I-D will define the use of
CMS for protecting the "harmonized" Certificate Request (and other related
certificate management protocols).  The CERT3 I-D will define how the CRS
objects are communicated using MIME.  The WG concluded that CERT3 should
point to the CRS I-D which will point to the "harmonized" protocol RFC.
Other WGs will define how the "harmonized" protocols will be communicated
via other mechanisms. 

++++++++++++++++++++++++++++++++++++++++++++++++++

Add CRS to Charter? - Russ Housley

Russ proposed that the S/MIME WG should concur with the PKIX WG decision
that the CRS work should stay in the PKIX WG.  In other words, the S/MIME WG
should not define a Certificate Request format.  The S/MIME WG agreed with
Russ' proposal.

++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Discussion - Tim Dean

Secure Interoperability Discussion - Tim Dean

Tim presented a series of briefing slides that are available from
http://sostdp.mod.uk/demo1a.html#pct.  Tim asked for the S/MIME WG's opinion
regarding a proposal to define a strategy for making Message Security
Protocol-protected X.400 applications interoperable with S/MIME applications
including preserving the originator's signature of the content.  Several WG
members stated that heterogeneous e-mail is a message format problem, not a
security problem.  Paul Hoffman stated that there is another IETF WG, MIXER,
that is working on X.400-MIME interoperability that may want to deal with
the issues raised by Tim, but that these issues should not be debated by the
S/MIME WG.  However, Jim Craigie pointed out that allowing CMS to carry any
kind of data object rather than just MIME entities would be a significant
enhancement to the protocol.  This would not only make secure
interoperability much easier, but also allow direct signing of various
objects such as word processor files etc.  Russ Housley agreed that it was
the intent to allow CMS to be pointed at by other documents for such
purposes.  Jeff Schiller agreed. Tim asked that any comments be sent to him
at [email-masked].

++++++++++++++++++++++++++++++++++++++++++++++++++

Signed Receipt Hashing - John Pawling

John presented a proposal for enhancing ESS, Section 2.4, Signed Receipt
Creation, so that the chain of digests leading to the signedData/Receipt
signature value includes digesting the authenticatedAttributes of the
original signedData signerInfo requesting the signedData/Receipt and
includes digesting the authenticatedAttributes of the signedData/Receipt
signerInfo.  This will allow the originator of the original signedData
object requesting the signedData/Receipt to verify that the recipient
received and was able to verify the signature of the original signedData
object including the content and authenticatedAttributes.  This will also
allow the originator of the original signedData object to verify the
integrity and authenticity of the authenticatedAttributes of the signerInfo
containing the signedData/Receipt signature value.  The meeting attendees
agreed with this proposal with one minor enhancement recommended by Jim
Schaad.  A separate message will be sent to the S/MIME WG mail list
proposing the exact text for inclusion in ESS, Section 2.4. 

These minutes were written and edited by:
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 22 Dec 1997 11:49:41 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

I very much agree. This is a very clear statement of the issues and the
necessary resolution. I'd hope we could agree on this.

Elliott Ginsburg

At 10:08 AM 12/22/97 -0500, David P. Kemp wrote:
>> From: John Gardiner Myers <[email-masked]>
>> 
>> In order for S/MIME agents to interoperate, receiving UA's need to be
>> able to present an identity of the signer to the user in a manner that
>> is simple and comprehensible.  This is not going to work if UA's have to
>> deal with presenting two entirely different syntaxes for identities,
>> especially if one of them is as complex as the DN syntax.'
>
>This is irrelevant to the question at hand, but why do you feel that
>"O=netscape.com, CN=John Gardiner Myers" is complex and incomprehensible,
>whereas "[email-masked]" is simple and comprehensible?  And by
>extension is "12345,[email-masked]" also more simple and comprehensible
>than a DN?
>
>The reason this is irrelevant is that there is no reason to either
>require or prohibit users from choosing their preferred form of identity.
>If some users want identities in RFC822 syntax, that's fine.  If other
>users want identities in DN syntax (to enable the same cert to be used
>for S/MIME and non-S/MIME purposes, for example), then that's fine too.
>
>You continue to ignore the distinction between an identity and a mailbox.
>People normally would want one (or just a few) identities.  But some users
>change mailboxes often, or have multiple contemporaneous mailboxes, or use
>mail mechanisms that have no meaningful identity at all (IETF terminal
>room - "[email-masked]" for example).
>A mailbox is NOT an identity - and as long as you keep using the same word
>to refer to two different functions, you will continue to be confused
>about the difference between them.
>
>> What is more
>> likely is that UA's are going to have to add a subsystem to map
>> DN-syntax identites to RFC822 identities and UAs are going to be far
>> less likely to get the security issues of this mapping right than the
>> far fewer and better equipped CAs.
>
>Please explain why there is any security issue involved.
>
>If I want to send mail to the person I know as
>"O=netscape.com, CN=John Gardiner Myers", or the person I know as
>"[email-masked]", then what difference does it make if the mail gets
>addressed and delivered to [email-masked] as long as it eventually
>winds up in a location where the person holding the private key
>corresponding to the certified identity can read it?
>
>To be redundantly didactic, the first two are *identities*, either of
>which (the choice is a matter of personal preference) can be used in a
>cert.  The third is a *mailbox* which does not belong in a cert at all.
>S/MIME user agents will maintain an address book mapping identities
>to addresses.  S/MIME user agents might also have a configurable option
>to allow checking that the identity and the mailbox are the same and
>warning if they are not, for people who choose to use their mailbox as
>their identity.  But there is no reason for S/MIME to mandate that:
> 1) certs contain mailbox addresses,
> 2) certs have identities in RFC822 format, or that
> 3) there be any mandatory checking between identities and mailbox
>    addresses.
>
>
>

Elliott N Ginsburg

Date: Mon, 22 Dec 1997 10:08:52 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
> 
> In order for S/MIME agents to interoperate, receiving UA's need to be
> able to present an identity of the signer to the user in a manner that
> is simple and comprehensible.  This is not going to work if UA's have to
> deal with presenting two entirely different syntaxes for identities,
> especially if one of them is as complex as the DN syntax.'

This is irrelevant to the question at hand, but why do you feel that
"O=netscape.com, CN=John Gardiner Myers" is complex and incomprehensible,
whereas "[email-masked]" is simple and comprehensible?  And by
extension is "12345,[email-masked]" also more simple and comprehensible
than a DN?

The reason this is irrelevant is that there is no reason to either
require or prohibit users from choosing their preferred form of identity.
If some users want identities in RFC822 syntax, that's fine.  If other
users want identities in DN syntax (to enable the same cert to be used
for S/MIME and non-S/MIME purposes, for example), then that's fine too.

You continue to ignore the distinction between an identity and a mailbox.
People normally would want one (or just a few) identities.  But some users
change mailboxes often, or have multiple contemporaneous mailboxes, or use
mail mechanisms that have no meaningful identity at all (IETF terminal
room - "[email-masked]" for example).
A mailbox is NOT an identity - and as long as you keep using the same word
to refer to two different functions, you will continue to be confused
about the difference between them.

> What is more
> likely is that UA's are going to have to add a subsystem to map
> DN-syntax identites to RFC822 identities and UAs are going to be far
> less likely to get the security issues of this mapping right than the
> far fewer and better equipped CAs.

Please explain why there is any security issue involved.

If I want to send mail to the person I know as
"O=netscape.com, CN=John Gardiner Myers", or the person I know as
"[email-masked]", then what difference does it make if the mail gets
addressed and delivered to [email-masked] as long as it eventually
winds up in a location where the person holding the private key
corresponding to the certified identity can read it?

To be redundantly didactic, the first two are *identities*, either of
which (the choice is a matter of personal preference) can be used in a
cert.  The third is a *mailbox* which does not belong in a cert at all.
S/MIME user agents will maintain an address book mapping identities
to addresses.  S/MIME user agents might also have a configurable option
to allow checking that the identity and the mailbox are the same and
warning if they are not, for people who choose to use their mailbox as
their identity.  But there is no reason for S/MIME to mandate that:
 1) certs contain mailbox addresses,
 2) certs have identities in RFC822 format, or that
 3) there be any mandatory checking between identities and mailbox
    addresses.

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: re: draft-ietf-smime-cert
Date: Fri, 19 Dec 1997 15:06:00 -0500
Sender: [email-masked]

On Wed, 17 Dec 1997 Ed Gerck ([email-masked]) wrote:

  -> -> An RA will now have to obtain a user's email address, and for
medium to
  ->-> high assurance certificates, the RA would also be expected to
validate
  ->-> it (probably through the LAN Mail administrator).  Every time the
user's
  ->-> email address changes, the CA will have to revoke and re-issue
the
  ->-> certificate.   Imagine how cumbersome certificate management
would
  ->-> become if all secure applications, e.g. secure fax, single
sign-on,
  ->-> required specific information in the certificates.

 ->This is simply not true. Certificates (such as X.509) carry fields
which
 ->are just "copied as received' by the CA and have zero semantics. In
fact,
 ->X.509 only mandates that the public-key be verified by the CA,
whereas the
 ->DN is accepted by the CA but not denoted by it (this is done by the
NA).
 ->So, unless so warranted by a particular CA (such as Verisign, in a
given
 ->cert class and under given liability limits) the e-mail field is
copied as
 ->is and means nothing more than that: a reference. An invalid e-mail
would
 ->certainly not make a X.509 cert invalid -- nor unuseful.

In the context of the Canadian Federal  Government, it is not the X.509
standard alone that binds the authentication trust model, but the
Certificate Policy (CP )and Certificate Practice Statements (CPSs) of
the CA that will make it legally binding.

Whether and how denotation 'is done by the NA" (Notary Authority), LRA
(Local Registration Authority) or some other agent of the CA, or the CA
itself, is determined by these policies. Therefore, "unless so warranted
by a particular CA",  which will be  the case for the Canadian
Government, an invalid DN or an invalid email address  would make a
X.509 cert standard conforming but invalid as per the CP, and then would
not be created.

 -> -> The more generic a
 ->-> certificate, the broader its use and the longer it lasts.
 -> ->

 ->No, the less it can be used for. Following your example, imagine a
cert
 ->which only has the subject's public-key and DN. What does it
authorize?
 ->How to contact the subject? Is that key useful for signing or for
 ->encryption?

Again, as defined in the CP, an X.509 authentication certificate does
not authorize anything.

All the authentication certificate does is give some degree of trust to
the binding of the information attribute values used in a certain
context to a unique, real life object  in the world. Authority
certificates (X.509 v3) issued by particular authorities will grant
authorization to different real world objects.

Bill Aitken
Government of Canada
[email-masked]
819-956-4850

 ----------
From: Ed Gerck
To: LancasterKent
Cc: [email-masked]; [email-masked]; CatleyBruce; AitkenBill
Subject: re: draft-ietf-smime-cert
Date: Wednesday, December 17, 1997 3:26PM

On Wed, 17 Dec 1997 [email-masked] wrote:

 -> I am also wary of mandating the inclusion of Internet mail addresses
in
 -> certificates.  From a PKI administration perspective, it is
preferable
 -> to keep application specific information out of certificates because
 -> they incur additional burdens on the CA and his/her Registration
 -> Authorities (RAs).
 ->

An e-mail is not an application-specific information. As we all know,
e-mail names can be (and are) used in several different contexts (such
as
anon-ftp, http POST command, etc.) An e-mail is a " name"  such as the
Social Security Number (which you use when the bank requires it in order
to identify your money transfer -- which has nothing to do with Social
Security purposes) or your Driver's License (which you may use to
clear a check in a CD store, even if the Driver's License has expired --
after all, you are still you).

The advantage of e-mail names (which can easily be globally unique) is
that it can provide for a challenge-response method in an easy way. For
example, when you receive an e-mail confirmation of an order, which
provides the PIN to retrieve the order.

Combining such protocol-based challenge-response with cryptography-based
tokens is a natural use of S/MIME, because it provides the user with a
choice.

 -> An RA will now have to obtain a user's email address, and for medium
to
 -> high assurance certificates, the RA would also be expected to
validate
 -> it (probably through the LAN Mail administrator).  Every time the
user's
 -> email address changes, the CA will have to revoke and re-issue the
 -> certificate.   Imagine how cumbersome certificate management would
 -> become if all secure applications, e.g. secure fax, single sign-on,
 -> required specific information in the certificates.

This is simply not true. Certificates (such as X.509) carry fields which
are just "copied as received' by the CA and have zero semantics. In
fact,
X.509 only mandates that the public-key be verified by the CA, whereas
the
DN is accepted by the CA but not denoted by it (this is done by the NA).
So, unless so warranted by a particular CA (such as Verisign, in a given
cert class and under given liability limits) the e-mail field is copied
as
is and means nothing more than that: a reference. An invalid e-mail
would
certainly not make a X.509 cert invalid -- nor unuseful.

 -> The more generic a
 -> certificate, the broader its use and the longer it lasts.
 ->

No, the less it can be used for. Following your example, imagine a cert
which only has the subject's public-key and DN. What does it authorize?
How to contact the subject? Is that key useful for signing or for
encryption?

Further, clearly, a cert without e-mail address can be beautifully used
in
a denial-of-service attack -- that's why PGP included an e-mail field.

After all, if send you my key-cert, tamperproof, and my e-mail, in
plaintext, I am just divorcing purpose from attitude.

 -> Requiring S/MIME agents to check the email address in the 'from'
field
 -> against the one in the signer's certificate and provide 'alternate
 -> processing' of the message, i.e. reject it, is overly restrictive.
It
 -> prevents a user, for example, from sending S/MIME messages from a
 -> colleague's mail account while on a business trip.  As Elliot noted
in
 -> his message, what is important is that the message content has been
 -> signed by its originator, not what mailbox the content came from.

This is not axiomatic. The mailbox whence it came provides for
accountability and may provide hints on possible interference, delays,
replays, etc.

For example, if you receive an e-mail from Clinton as sent by Khadaffi's
e-mail agent -- what would you think of it? Or, from a GM engineer as
sent
from a VW e-mail agent?

Further, there is a common misconception that security must always be
"perfect" as provided by cryptography -- with its costs. However,
oftentimes, all one needs is an assurance that miscreants will be caught
with a certain probability level. In an Intranet, such assurance might
be
sufficient for day-to-day activities (with a properly secured server).
If
more is needed, then the key may be used. Again, the user should be able
to choose.

 -> I
 -> realize this does not prevent 'spoofing' but who cares?  As long as
you
 -> can validate that the content was signed by the originator and has
not
 -> been tampered with why would you be concerned if it came from the
user's
 -> true and correct mail address or not?

As above. Note also that the fact you can validate its originator and
contents by the signature, does not mean that you can trust the clock
used
in that host, or its msg delay, or its hidden forwarding. Which may
render
the message totally useless for several purposes.

 -> Given the current trend to
 -> increase PKI portability via PCMCIA hardware tokens and smart cards,
 -> tying S/MIME users to their email addresses decreases portability.
 ->

I find your phrase difficult to accept on three counts. First, tokens do
not increase PKI portability -- they increase key security. Second, no
one
is tied to an e-mail address and the current trend is to have several
addresses. Third, one of the purposes of S/MIME was (or is) to secure
e-mail messages -- so, this means that if S/MIME does not allow that
then
something else will (because there is a need).

 -> Two other points: ->
 -> i) mandating that the email address be an RFC-822 address closes the
 -> door on future use of X.400 to transport S/MIME.  If the email
address
 -> *must* be in the certificate, subjectAltName allows it to be X.400
or
 -> RFC-822
 ->

Whatever X.400 turns out to be ;-)

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "John Gardiner Myers" <[email-masked]>
Subject: Re: Proposal: Re: The address-in-certs issue
Date: Mon, 22 Dec 1997 09:58:40 -0500
Sender: [email-masked]

>Phillip M Hallam-Baker wrote:
>> 1) We define a new OID with semantics 'Authenticated header'.
>
>This is solving a different problem, that of an intermediary modifying
>the headers.  The problem the email-in-certs issue is trying to solve is
>that of a signer misrepresenting their identity to the recipient.

The problem here is that many clients do not expose the email
address itself to the user. A user may legitimately have more than
one email. Thus there is disagreement as to whether email
address is necessarily a good signifier to use to establish
identity.

I tend to think it is a good signifier to use for identity since on
the Internet it may be considered the primary name... On the 
other hand it appears overly restrictive to insist on its inclusion
in the cert.

Note that even if one is using HTTP as a transport for S/MIME
the email address is likely to be needed. The point of using 
S/MIME in this way would be to support transaction layer
security, the principle advantage of which (over SSL) is that
it allows support for asynchronous communication models.
I would expect that a system using S/MIME in this way would
involve interleaved SMTP and HTTP responses.

Note also that if we really are interested in HTTP support we
have to consider it explicitly. There is a vast installed base 
of HTTP infrastructure which cannot be ignored but which
does not support MIME. If we really want to support HTTP 
we should consider specifying an opption to sign an HTTP
message using a detached PKCS#7 signature block carried
in a header.

Perhaps we can resolve the issue by saying that clients MUST
recognize the email address extension in the certificate if it
is present and not require anything more.

            Phill

Date: Mon, 22 Dec 1997 08:54:58 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

I don't see why everyone assumes that S/MIME equates with email. It is
likely to be carried over HTTP and there is an electronic commerce/EDI
group looking at it for use there. 

Elliott Ginsburg

At 02:50 PM 12/19/97 -0800, John Gardiner Myers wrote:
>David P. Kemp wrote:
>> Reasons include 1) the more information that goes into a cert, the shorter
>> the expected lifetime,
>
>Then take out other information.  RFC822 identities are what are used in
>Internet Mail, and if you're securing Internet Mail objects, those are
>the identities you need to certify.
>
>> 2) additional burdens on CAs/RAs to validate email
>> addresses (in cases other than the zero-assurance certs which are issued
>> to email addresses, not people), 
>
>If you remove this burden from CAs/RAs, you just move the burden to
>UAs.  There are far more UAs in the world than CAs, and UAs are far less
>well equipped to deal with validation tasks than CAs.
>
>> and 3) it's not clear that the user agent
>> can do anything at all useful with an email address in a cert, given that
>> users should be allowed to change addresses, mail authenticated messages
>> from a friend's account, etc.
>
>Technically speaking, if user A sends mail using user B's account, then
>RFC822 states that user A's RFC822 identity belongs in the From: header
>and user B's identity belongs in the Sender: header.  If mail submission
>agents become S/MIME aware, this could even work.
>
>
>

Elliott N Ginsburg

Date: Mon, 22 Dec 1997 07:59:21 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

This proposal will potentially force different certs for different uses:
one for email (SMTP) carrying an email address, and one for each other use
which sets a policy. This is certainly not desirable in the community I
represent.

There has been much discussion on this list about this issue, and many have
pointed out that there are valid reasons for the 'From' address not
matching the identifier in the cert: using a different account to send,
gateways, services which allow one to have a single mail address, etc. 

It seems clear to me that what is important is to PRESENT to a user
whatever identifiers are in a cert, and not make a decision for the user. I
know of email addresses like 'abc@<domain>', where 'abc' is not very
descriptive; in a case like this, I might also like to see other
identifiers in the cert which give me some additional clues as to who this is.

I suggest:

"S/MIME receiving agents that get signed messages from SMTP MUST alert the
recipient as to the validity of the signature and MUST present the subject
identifiers from the certificate as the signer of the message."

A cert which can be used in email will be just as valid for use in Web
authentication, or to sign and verify some data or software, or for any
other uses. At the same time, the mail recipient will be informed
unambiguously as to the signer of the message.

Elliott Ginsburg

At 10:10 AM 12/17/97 -0800, Paul Hoffman / IMC wrote:
>I'd like to start a new thread on this so that we are all on the same page.
>I'd like to be sure we all agree on the non-technical reasoning behind what
>we're doing in S/MIME v2 and what we want to do in S/MIME v3.
>
>We use a signature to say "I sent this". I believe that this group agrees
>on the definition of "sent" and "this" for the context of S/MIME. The
>question is who is "I", that is, the identifier of the signer.
>
>In S/MIME v2, we use an RFC822 email address (user@domain) to be the
>identifier of the signer. Email addresses can identify entities such as
>people or other mail senders. Further, CAs can do some reasonable checking
>before they certify the validity of and email address, such as verifying
>that that email address can respond to a challenge about the signature.
>
>Where we have a problem is when a recipent tries to validate "I sent this".
>The validation step involves checking the "I" identifier in the signature
>against something in the "this". However, the something against which they
>would be checking is not authenticated: it's out in the commonly-spoofed
>plaintext headers that precede the signed message, not in the authenticated
>part of the message.
>
>This is inherently a user interface issue. Because S/MIME messages can be
>carried in non-email systems, requiring the "I" identifier to match the
>spoofable headers is clearly wrong. Even in email, because the headers that
>are checked against are suseptable to both spoofing and munging by
>gateways, we cannot force actions based on the comparision of the signature
>address and the headers.
>
>I propose the following:
>
>- There will be no base-level interoperability statement for the content of
>the identifier: it's up to the application using S/MIME
>- S/MIME messages that are to be sent through SMTP MUST have the identifier
>be an RFC822 email address, and any cert that goes with that message also
>MUST use an RFC822 email address
>- S/MIME receiving agents that get messages from SMTP SHOULD check the
>email addresses in the signatures and certs of the message against the
>From: and Sender: headers of the message, SHOULD have a policy about what
>matches and doesn't match, and SHOULD alert the recipient if the address in
>the identifier and the header(s) don't match
>- Non-email agents SHOULD have a policy about what the content of the
>identifier is, SHOULD have a policy about what matches and doesn't match,
>and SHOULD have a policy about what to do if the addresses don't match
>- A detailed description of the logic of the above has to appear in the
>body of the -cert draft, and a warning about it has to appear in the
>security section
>
>Comments?
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>

Elliott N Ginsburg

Date: Sat, 20 Dec 1997 15:41:49 -0800
To: "Kurt Stammberger" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

At 08:17 AM 12/20/97 -0800, Kurt Stammberger wrote:
>I know a lot of you are going to be at the RSA Conference in January, and
>this seems to be an especially busy time for S/MIME. Would it be a good idea
>to reserve a meeting room where all you S/MIME types can get together, maybe
>at the Fairmont or the Masonic?

That's a nice offer on RSA's part, but I don't think we need it. The IETF
generally frowns on "side meetings" unless there is a core group of people
who really need to get together to break a logjam or something like that.
We don't have that situation in S/MIME, at least not yet. Our meeting in
Washington DC, just ten days ago, was very productive, and most people I
talked to came away feeling like good forward motion is being made.

The one area that I see potential weakness down the line is certs, but we
need to see what comes out of PKIX for CRS and CMP before we can do much
there, and that isn't expected to happen in the next two weeks.

Based on that, I'd say that a face-to-face next month is premature. If the
certs stuff bogs down after we get the next round of drafts from the PKIX
group, we might want to do one, but I tend to think the list is the best
place to have these kinds of discussions.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Kurt Stammberger" <[email-masked]>
To: <[email-masked]>
Subject: Re: The address-in-certs issue
Date: Sat, 20 Dec 1997 08:17:39 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BD0D1F.BC9572A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Just a thought, folks:

I know a lot of you are going to be at the RSA Conference in January, and
this seems to be an especially busy time for S/MIME. Would it be a good idea
to reserve a meeting room where all you S/MIME types can get together, maybe
at the Fairmont or the Masonic?

Kurt Stammberger
RSA
-----Original Message-----
From: Russ Housley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, December 19, 1997 9:27 AM
Subject: Re: The address-in-certs issue

>The S/MIME working group charter says that we are going to use the PKIX
>certificate infrastructure.  To this end, we should use the subjectAltName
>to carry an rfc822Name if an e-mail address is desired in the certificate.
>
>Russ
>
>
>

------=_NextPart_000_001B_01BD0D1F.BC9572A0
Content-Type: text/x-vcard;
	name="Kurt R. Stammberger.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Kurt R. Stammberger.vcf"

BEGIN:VCARD
N:Stammberger;Kurt;R.
FN:Kurt R. Stammberger
ORG:RSA Data Security, Inc.;Marketing
TITLE:Conference Director
TEL;HOME;VOICE:415-861-5878
TEL;CELL;VOICE:415-710-5054
ADR;WORK:;415-861-5878;22 Museum Way;San Francisco;CA;94114-1428;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:415-861-5878=3D0D=3D0A22 Museum =
Way=3D0D=3D0ASan Francisco, CA 94114-1428=3D0D=3D0AUSA
ADR;HOME:;;22 Museum Way;San Francisco;CA;94114-1428;USA
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:22 Museum Way=3D0D=3D0ASan =
Francisco, CA 94114-1428=3D0D=3D0AUSA
URL:http://www.rsa.com/conf98/
EMAIL;PREF;INTERNET:[email-masked]
EMAIL;INTERNET:[email-masked]
EMAIL;INTERNET:[email-masked]
END:VCARD

------=_NextPart_000_001B_01BD0D1F.BC9572A0--

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The address-in-certs issue
Date: Fri, 19 Dec 1997 14:50:07 -0800
Organization: Netscape Communications Corporation
Lines: 25
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

David P. Kemp wrote:
> Reasons include 1) the more information that goes into a cert, the shorter
> the expected lifetime,

Then take out other information.  RFC822 identities are what are used in
Internet Mail, and if you're securing Internet Mail objects, those are
the identities you need to certify.

> 2) additional burdens on CAs/RAs to validate email
> addresses (in cases other than the zero-assurance certs which are issued
> to email addresses, not people), 

If you remove this burden from CAs/RAs, you just move the burden to
UAs.  There are far more UAs in the world than CAs, and UAs are far less
well equipped to deal with validation tasks than CAs.

> and 3) it's not clear that the user agent
> can do anything at all useful with an email address in a cert, given that
> users should be allowed to change addresses, mail authenticated messages
> from a friend's account, etc.

Technically speaking, if user A sends mail using user B's account, then
RFC822 states that user A's RFC822 identity belongs in the From: header
and user B's identity belongs in the Sender: header.  If mail submission
agents become S/MIME aware, this could even work.

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Proposal: Re: The address-in-certs issue
Date: Fri, 19 Dec 1997 14:33:41 -0800
Organization: Netscape Communications Corporation
Lines: 24
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Phillip M Hallam-Baker wrote:
> 1) We define a new OID with semantics 'Authenticated header'.

This is solving a different problem, that of an intermediary modifying
the headers.  The problem the email-in-certs issue is trying to solve is
that of a signer misrepresenting their identity to the recipient.

Let me put the issue this way:  Internet identities have RFC822
local-part@domain syntax.  The semantics of these identities are
understood by end-users.  These identifiers are applicable to any
Internet protocol, not just mail.

I don't buy that RFC822-syntax identities are more likely to change than
DN-syntax identities.

In order for S/MIME agents to interoperate, receiving UA's need to be
able to present an identity of the signer to the user in a manner that
is simple and comprehensible.  This is not going to work if UA's have to
deal with presenting two entirely different syntaxes for identities,
especially if one of them is as complex as the DN syntax.  What is more
likely is that UA's are going to have to add a subsystem to map
DN-syntax identites to RFC822 identities and UAs are going to be far
less likely to get the security issues of this mapping right than the
far fewer and better equipped CAs.

Date: Fri, 19 Dec 1997 10:37:08 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: RE: Modifications to ESS document
Cc: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

John:

The insteadOf construct can be used in two ways.  First, as Jim desscribed,
teh MLA collects the receipts and provides a receipt on behalf of the
entire list.  Second, the receipts are redirected to a third party.

I do not think that we should argue about the desirablity of either use.
Both uses are supported by the single mechanism.

It would not surprise me if people find other ways to use this mechanism in
the future.

Russ

At 05:21 PM 12/18/97 -0500, John Pawling wrote:
>All,
>
>I agree with Jim's rubuttal of my comments to his original proposal. 
>
>I now agree with Jim's original table that looks like this:
>
>   Previous  |
>   Policy    |             MLA B's Receipt Policy
>  (MLA A's   |
>   Policy)   | none    insteadOf     inAdditionTo      missing
>--------------------------------------------------------------------
>none         | none       none          none             none
>insteadOf    | none  insteadOf(B)  insteadOf(A+B)     insteadOf(A)
>inAdditionTo | none  insteadOf(B)  inAdditionTo(A+B)  inAdditionTo(A)
>missing      | none  insteadOf(B)  inAddtionTo(B)     missing
>
>
>Jim stated:
>>Although it is not stated anywhere, my assumption here is that the most
>>general use of insteadOf is to combine receipts into a single receipt
>>coming back from the mailing list.
>
>I believe that this strategy is highly controversial.  IMHO, the MLA should
>return a signed receipt to the originator as soon as the MLA is able to
>verify the signature of the original message.  That is the intent of the
>signed receipt requested by the originator from the MLA.  IMHO, the intent
>of the signed receipt returned from the MLA is not to signify that every ML
>member returned a signed receipt to the MLA.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

Date: Thu, 18 Dec 1997 11:08:57 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

The S/MIME working group charter says that we are going to use the PKIX
certificate infrastructure.  To this end, we should use the subjectAltName
to carry an rfc822Name if an e-mail address is desired in the certificate.

Russ

Date: Thu, 18 Dec 1997 11:14:14 -0500
To: Larry Layten <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-smime-cert
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Larry:

>>The issue is whether someone can send confidential
>>information to the subject of the certificate. If there is no
>>email address they are not going to be able to use it for
>>S/MIME.
>
>I may have missed something here.  Is there an OID or 
>something in the X.509 certificate that identifies it as an
>S/MIME certificate?

No.

>>This is the real problem. But consider what happens if there is
>>no email address in the cert - you don't know how to contact the 
>>person.
>
>This is like saying that without caller id, you don't know how to
>call someone because you don't know what there phone number
>is.

If we want to include an e-mail address in the certificate, then it should
be included as an rfc822Name in subjectAltName.

>Another point -- If I am using a non-Internet client i.e. Microsoft
>Mail, and I am sending to a person inside of my local enclave, My
>client knows nothing about any RFC822 addresses. That only 
>comes into play when I send it out through a gateway.

The gateway has some mechanism for translating proprietary names to RFC 822
addresses.  Perhaps the same translation can be performed by the client.
If not all of the informatio is available to the client, then the client
wil have to deise another machnaism.  I see this as no different than
dealing with a certificate that does not include any rfc822Name.

Russ

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Russ Housley <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Modifications to ESS document
Date: Thu, 18 Dec 1997 15:05:12 -0800
Sender: [email-masked]

I agree that the change is not needed.  It was simply proposed as a way
to make things simplier.  The possible implication that John has makes
me want to retract this suggestion and quickly.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 18, 1997 12:58 PM
To: Russ Housley; Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Modifications to ESS document

All,

Jim Schaad wrote:
>>It might be nice from a strictly easy point of view to add a copy to
>>MLReciptPolicy of "all [4]" to make the text easier to deal with in
>>terms of refering to all or normal processing if this value is present
>>rather than refering to what to do if the value is missing.

I disagree with this proposed change because it is not needed.  If the
originator requests that "all" recipients should return a signed receipt
and
the MLA's MLReceiptPolicy policy is missing, then the net effect is that
all
recipients should return signed receipts.  In general, if the
MLReceiptPolicy is missing then the originator's receipt request is
honored.
Therefore, there is no need to add "all" or "normal" to MLReceiptPolicy.

Furthermore, I believe that the addition of "all" to MLReceiptPolicy
could
mislead people to believe that when the MLReceiptPolicy is "all" and the
originator has not requested a signed receipt, then the MLReceiptPolicy
"all" takes precedence over the originator's action of not requesting a
signed receipt.  This would be a bad result because the originator would
not
expect (or want) any signed receipts and could be bombarded with signed
receipts from every mail list recipient.

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

Date: Thu, 18 Dec 1997 17:21:22 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>, Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Modifications to ESS document
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

All,

I agree with Jim's rubuttal of my comments to his original proposal. 

I now agree with Jim's original table that looks like this:

   Previous  |
   Policy    |             MLA B's Receipt Policy
  (MLA A's   |
   Policy)   | none    insteadOf     inAdditionTo      missing
--------------------------------------------------------------------
none         | none       none          none             none
insteadOf    | none  insteadOf(B)  insteadOf(A+B)     insteadOf(A)
inAdditionTo | none  insteadOf(B)  inAdditionTo(A+B)  inAdditionTo(A)
missing      | none  insteadOf(B)  inAddtionTo(B)     missing

Jim stated:
>Although it is not stated anywhere, my assumption here is that the most
>general use of insteadOf is to combine receipts into a single receipt
>coming back from the mailing list.

I believe that this strategy is highly controversial.  IMHO, the MLA should
return a signed receipt to the originator as soon as the MLA is able to
verify the signature of the original message.  That is the intent of the
signed receipt requested by the originator from the MLA.  IMHO, the intent
of the signed receipt returned from the MLA is not to signify that every ML
member returned a signed receipt to the MLA.

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

Date: Thu, 18 Dec 1997 15:57:57 -0500
To: Russ Housley <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Modifications to ESS document
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

All,

Jim Schaad wrote:
>>It might be nice from a strictly easy point of view to add a copy to
>>MLReciptPolicy of "all [4]" to make the text easier to deal with in
>>terms of refering to all or normal processing if this value is present
>>rather than refering to what to do if the value is missing.

I disagree with this proposed change because it is not needed.  If the
originator requests that "all" recipients should return a signed receipt and
the MLA's MLReceiptPolicy policy is missing, then the net effect is that all
recipients should return signed receipts.  In general, if the
MLReceiptPolicy is missing then the originator's receipt request is honored.
Therefore, there is no need to add "all" or "normal" to MLReceiptPolicy.  

Furthermore, I believe that the addition of "all" to MLReceiptPolicy could
mislead people to believe that when the MLReceiptPolicy is "all" and the
originator has not requested a signed receipt, then the MLReceiptPolicy
"all" takes precedence over the originator's action of not requesting a
signed receipt.  This would be a bad result because the originator would not
expect (or want) any signed receipts and could be bombarded with signed
receipts from every mail list recipient.

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Russ Housley <[email-masked]>
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Modifications to ESS document
Date: Thu, 18 Dec 1997 12:51:04 -0800
Sender: [email-masked]

First, let me thank you for cleaning up my table,  the mail client I use
wants to use proprotial fonts and tables are messy to build in that
format.

I disagree with two of the changes and my comments on why are
intermingled below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 18, 1997 12:24 PM
To: Russ Housley; Jim Schaad (Exchange)
Cc: Ietf-Smime (E-mail)
Subject: Re: Modifications to ESS document

All,

I agree with the spirit of Jim's proposal and with Russ' proposed added
sentences.

However, I believe that we should discuss Jim's matrix before accepting
it.
I believe that the following modified matrix should apply:    

   Previous  |
   Policy    |             MLA B's Receipt Policy
  (MLA A's   |
   Policy)   | none      insteadOf     inAdditionTo      missing
--------------------------------------------------------------------
none         | none       none            none          none
insteadOf    | none  insteadOf(A+B)  insteadOf(A+B)     insteadOf(A)

inAdditionTo | none  insteadOf(A+B)  inAdditionTo(A+B)  inAditionTo(A)
missing      | none  insteadOf(B)    inAddtionTo(B)     missing

The changes are that Mail List Agent (MLA) B always includes MLA A's
insteadOf and inAdditionTo requirements.  Specifically, I changed "B" to
"A+B" in column 2 of Jim's matrix.  Consider the following examples:

1) Row 2, Col 2:  MLA A's MLReceiptPolicy states that the recipients
must
return a signedReceipt to MLA A instead of the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt
to
MLA B instead of the originator.  MLA B processes the SignedData sent by
MLA
A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to
the
ML that states that the recipients must return signedReceipts to both
MLA A
and MLA B instead of the originator.  This respects MLA A's requirement
to
send signed receipts to MLA A instead of the originator and includes MLA
B's
requirement for recipients to send signed receipts to MLA B instead of
the
originator.

[Jim Schaad] I think that insteadOf(B) is the correct line here.  The
policy of B at this point states that no reciepts should be sent to
"original people" and from the point of view of MLA B, MLA A's list of
insteadOfs is an "original people".  This means that MLA A may never get
back a receipt on this mail item, and that is the correct behavior.  If
MLA B is going to put receipts into a different box, then MLA A SHOULD
never get a receipt back.

Although it is not stated anywhere, my assumption here is that the most
general use of insteadOf is to combine receipts into a single receipt
coming back from the mailing list.  I think that the use you were
loading onto insteadOf does not generally make sense.  If an end user
(such as a CEO in a company) wants all of their receipts to go to a
different location, this should be specified in the ReceiptRequest
rather than having a mailing list try and override this.  

2) Row 2, Col 3:  MLA A's MLReceiptPolicy states that the recipients
must
return a signedReceipt to MLA A instead of the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt
to
MLA B in addition to the originator.  MLA B processes the SignedData
sent by
MLA A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent
to
the ML that states that the recipients must return signedReceipts to
both
MLA A and MLA B instead of the originator.  This respects MLA A's
requirement to send signed receipts to MLA A instead of the originator
and
includes MLA B's requirement for recipients to send signed receipts to
MLA B.

[Jim Schaad] I think that this is correct.

3) Row 3, Col 2:  MLA A's MLReceiptPolicy states that the recipients
must
return a signedReceipt to MLA A in addition to the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt
to
MLA B instead of the originator.  MLA B processes the SignedData sent by
MLA
A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to
the
ML that states that the recipients must return signedReceipts to both
MLA A
and MLA B instead of the originator.  This respects MLA A's requirement
to
send signed receipts to MLA A and includes MLA B's requirement for
recipients to send signed receipts to MLA B instead of the originator.

[Jim Schaad] I disagree with this for the same reasons that I think that
item 1 above is incorrect.

4) Row 3, Col 3:  MLA A's MLReceiptPolicy states that the recipients
must
return a signedReceipt to MLA A in addition to the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt
to
MLA B in addition to the originator.  MLA B processes the SignedData
sent by
MLA A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent
to
the ML that states that the recipients must return signedReceipts to
both
MLA A and MLA B in addition to the originator.  This respects MLA A's
requirement to send signed receipts to MLA A in addition to the
originator
and includes MLA B's requirement for recipients to send signed receipts
to
MLA B in addition to the originator.

[Jim Schaad] I agree with this also.

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

Date: Thu, 18 Dec 1997 15:24:18 -0500
To: Russ Housley <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Modifications to ESS document
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

All,

I agree with the spirit of Jim's proposal and with Russ' proposed added
sentences.

However, I believe that we should discuss Jim's matrix before accepting it.
I believe that the following modified matrix should apply:    

   Previous  |
   Policy    |             MLA B's Receipt Policy
  (MLA A's   |
   Policy)   | none      insteadOf     inAdditionTo      missing
--------------------------------------------------------------------
none         | none       none            none          none
insteadOf    | none  insteadOf(A+B)  insteadOf(A+B)     insteadOf(A)      
inAdditionTo | none  insteadOf(A+B)  inAdditionTo(A+B)  inAditionTo(A)
missing      | none  insteadOf(B)    inAddtionTo(B)     missing

The changes are that Mail List Agent (MLA) B always includes MLA A's
insteadOf and inAdditionTo requirements.  Specifically, I changed "B" to
"A+B" in column 2 of Jim's matrix.  Consider the following examples:

1) Row 2, Col 2:  MLA A's MLReceiptPolicy states that the recipients must
return a signedReceipt to MLA A instead of the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt to
MLA B instead of the originator.  MLA B processes the SignedData sent by MLA
A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to the
ML that states that the recipients must return signedReceipts to both MLA A
and MLA B instead of the originator.  This respects MLA A's requirement to
send signed receipts to MLA A instead of the originator and includes MLA B's
requirement for recipients to send signed receipts to MLA B instead of the
originator.

2) Row 2, Col 3:  MLA A's MLReceiptPolicy states that the recipients must
return a signedReceipt to MLA A instead of the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt to
MLA B in addition to the originator.  MLA B processes the SignedData sent by
MLA A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to
the ML that states that the recipients must return signedReceipts to both
MLA A and MLA B instead of the originator.  This respects MLA A's
requirement to send signed receipts to MLA A instead of the originator and
includes MLA B's requirement for recipients to send signed receipts to MLA B.

3) Row 3, Col 2:  MLA A's MLReceiptPolicy states that the recipients must
return a signedReceipt to MLA A in addition to the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt to
MLA B instead of the originator.  MLA B processes the SignedData sent by MLA
A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to the
ML that states that the recipients must return signedReceipts to both MLA A
and MLA B instead of the originator.  This respects MLA A's requirement to
send signed receipts to MLA A and includes MLA B's requirement for
recipients to send signed receipts to MLA B instead of the originator.

4) Row 3, Col 3:  MLA A's MLReceiptPolicy states that the recipients must
return a signedReceipt to MLA A in addition to the originator.  MLA B's
MLReceiptPolicy states that the recipients must return a signedReceipt to
MLA B in addition to the originator.  MLA B processes the SignedData sent by
MLA A.  MLA B creates a MLReceiptPolicy in the new SignedData to be sent to
the ML that states that the recipients must return signedReceipts to both
MLA A and MLA B in addition to the originator.  This respects MLA A's
requirement to send signed receipts to MLA A in addition to the originator
and includes MLA B's requirement for recipients to send signed receipts to
MLA B in addition to the originator.

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

From: "Rich Ankney" <[email-masked]>
To: "Tim Dean" <[email-masked]>, <[email-masked]>
Subject: Re: The address-in-certs issue
Date: Thu, 18 Dec 1997 13:03:53 -0500
Sender: [email-masked]

Tim Dean said:
>A neat solution would be to define another authenticated attribute,
something like 
>'signature reason', which would be some kind of enumerated type.  Reasons
could be 
>'Authenticate E-mail sender', 'Authenticated data', etc.  Depending on the
reason, 
>other attributes would be included in the signature.
>
>Without this, I could envisage a situation of having S/MIME signed a local
file for my 
>own private purposes, and someone sends it off in a mail, followed by an
interesting 
>non-repudiation debate...

We did this in ANSI X9.45, as well as a medical informatics signature
standard.
The "signature purpose" attribute was an object ID, rather than an
enumeration,
to allow for easy addition of new (possibly application-specific) purposes.

Regards,
Rich

Date: Thu, 18 Dec 1997 12:33:19 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: "John Pettitt" <[email-masked]>
> 
> The issue is we don't want addresses in certs because it shortens their
> life, but we need some authenticated way of knowing how to reply to whoever
> sent the mail and real names are not unique.   The 822 headers are outside
> the hash and get screwed with by all and sundry.
> 
> Perhaps what we need is reply to or originator info inside the hash but not
> in the cert.  That means you can be sure that the sender intended that
> address to be in the mail and the sender can change address at will without
> needing a new cert.  (I'm having a strong urge to duck and run for cover
> after saying that :-)
> 
> John

Why duck and run?  Including the desired sender/recipient/cc-list names
within the envelope but not in any cert is exactly what was suggested
by Phill, Larry, and others.

> From: "Anil R. Gangolli" <[email-masked]>
> 
> Binding
> 
> It is definitely important to bind the intended recipient or alleged
> sender with the key.   For example, consider the full binding picture when
> sending encrypted mail to an intended recipient.
> 
> a. The user or application has to name the intended recipient.
> b. The user and/or application must find or select the appropriate
>    certificate for that recipient based on the name supplied in (a).
> c. The user and/or application must validate the certificate path
>    to a CA trusted for this purpose.
> 
> If there is any confusion in the binding at any of these three
> points, then the security of the message is in doubt:  you have
> lost the desired strong guarantees that the resulting key
> (in the recipient's certificate) is actually that of the intended
> recipient.
> 
> Names in Certificates
> 
> If the name that is used in the application or user's setting does not
> actually appear anywhere in the certificate, it is hard for the
> application to ensure (b) above is done safely.  Some other
> information, either from the user or elsewhere, must be brought to
> bear in order to guarantee (b).

The user always has to be involved in (a) - if I don't know whether
I want to send mail to "Anil" or to "Larry", there is nothing the
application can do to ensure safety.

So given the fact that the user has to choose a name, there is nothing
in step (b) that requires that name to be an SMTP delivery address.
The name in the cert can be "O=StructuredArts, CN=Anil R. Gangolli",
or it could be "[email-masked]", neither of which
is the address to which mail should be sent in order to reach the
intended recipient.  Those are just names which are meaningful to
the user, which allow both steps (a) and (b) to be performed in as
secure a manner as wetware is capable of.  The missing step is:

  (d) the user/application must slap a To: header containing
      [email-masked] onto the already signed and sealed
      S/MIME data.

Forcing the name used in step (d) to be contained in the cert is both
unnecessary and wrong.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "John Pettitt" <[email-masked]>, "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Proposal: Re: The address-in-certs issue
Date: Thu, 18 Dec 1997 09:59:22 -0500
Sender: [email-masked]

OK a proposal.

1) We define a new OID with semantics 'Authenticated header'. The data value
associated with the OID is simply a string that corresponds to an RFC 822
format header. E.g.

12.3.45.67 "From: Fred Hapgood <[email-masked]>"
12.3.45.67 "To: Jane Witherspooon <[email-masked]>"
12.3.45.67 "Content-Type: text/xml"

Clients are required to consider such authenticated headers as being
authoratative. There is no need to create an error because unauthenticated
data does not agree, the unauthenticated data can simply be supressed.

2) The mail address in the cert becomes optional.

3) Signer purpose OIDs are an important but very separate problem.

            Phill

From: Tim Dean <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: The address-in-certs issue
Date: Thu, 18 Dec 1997 14:10:33 -0000
Sender: [email-masked]

John Pettit said:

>Perhaps what we need is reply to or originator info inside the hash but =
not
>in the cert.  That means you can be sure that the sender intended that
>address to be in the mail and the sender can change address at will =
without
>needing a new cert.

I would like to second that suggestion.  Firstly because as has been =
observed there are many good reasons not to mandate putting an  822 =
address in a certificate.  Secondly, IMHO the address is something which =
should be associated with the *signature* not the *certificate*.  I.e. =
there are several reasons to want to sign something.  Only one of them =
is that I want to be the authenticated sender of the E-mail.  Another is =
that I want to claim ownership of the data (but not send it out as an =
e-mail). A third is that I want to parallel sign the content but not be =
implicated as having sent the mail.  There are probably several more.

A neat solution would be to define another authenticated attribute, =
something like 'signature reason', which would be some kind of =
enumerated type.  Reasons could be 'Authenticate E-mail sender', =
'Authenticated data', etc.  Depending on the reason, other attributes =
would be included in the signature.

Without this, I could envisage a situation of having S/MIME signed a =
local file for my own private purposes, and someone sends it off in a =
mail, followed by an interesting non-repudiation debate...

Tim

-----Original Message-----
From:	John Pettitt [SMTP:[email-masked]]
Sent:	Thursday, December 18, 1997 3:46 AM
To:	David P. Kemp; [email-masked]
Subject:	Re: The address-in-certs issue

 << File: smime.p7s >>=20
The issue is we don't want addresses in certs because it shortens their
life, but we need some authenticated way of knowing how to reply to =
whoever
sent the mail and real names are not unique.   The 822 headers are =
outside
the hash and get screwed with by all and sundry.

Perhaps what we need is reply to or originator info inside the hash but =
not
in the cert.  That means you can be sure that the sender intended that
address to be in the mail and the sender can change address at will =
without
needing a new cert.  (I'm having a strong urge to duck and run for cover
after saying that :-)

John

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 17, 1997 11:29 AM
Subject: Re: The address-in-certs issue

>> From: Paul Hoffman / IMC <[email-masked]>
>>
>> I propose the following:
>>
>> - There will be no base-level interoperability statement for the =
content
of
>> the identifier: it's up to the application using S/MIME
>> - S/MIME messages that are to be sent through SMTP MUST have the
identifier
>> be an RFC822 email address, and any cert that goes with that message =
also
>> MUST use an RFC822 email address
>
>Paul, the content of the cert is the crux of the issue.  I agree with =
the
>many recent comments that email addresses should not be required or =
even
>recommended in the cert at all, irrespective of any S/MIME User Agent
>requirements.
>
>Reasons include 1) the more information that goes into a cert, the =
shorter
>the expected lifetime, 2) additional burdens on CAs/RAs to validate =
email
>addresses (in cases other than the zero-assurance certs which are =
issued
>to email addresses, not people), and 3) it's not clear that the user =
agent
>can do anything at all useful with an email address in a cert, given =
that
>users should be allowed to change addresses, mail authenticated =
messages
>from a friend's account, etc.
>
>One topic that came up on the PKIX list many months ago was the use of
>RFC822-style strings as identities.  It is quite reasonable that some
>people might find RFC822 names to be more comfortable than DNs, and it
>might even be reasonable for CAs to issue certs to RFC822-style =
identities,
>whatever it means to certify something like that.
>
>But an RFC822 identity is a completely separate thing than an SMTP =
delivery
>address - there are forwarding services now that let you keep the same
>identity regardless of how often you change ISPs.  Doing any sort of
>checking of an SMTP delivery address against an RFC822 identity, if it
exists,
>will often be futile (more than one account, kiosks/friend's =
account/IETF
>terminal room, address-munging gateways/listservs, etc).
>
>Requiring or recommending the existence of an RFC822 identity in certs
>solely for the purpose of enabling a check against a totally volatile
>delivery address is not warranted.
>
>Dave Kemp
>

From: Scott Hollenbeck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: The address-in-certs issue
Date: Thu, 18 Dec 1997 03:29:08 PST
Sender: [email-masked]

I, too, don't like the idea of putting e-mail addresses in
certificates.

Why not use a PKCS #9 emailAddress attribute in the authenticated
attributes list of a signed message?  That way the address gets
included in the signature calculation, and the attribute value
is set on a per-message basis.

Scott

-----Original Message-----
From:	John Pettitt [SMTP:[email-masked]]
Sent:	Wednesday, December 17, 1997 10:46 PM
To:	David P. Kemp; [email-masked]
Subject:	Re: The address-in-certs issue

The issue is we don't want addresses in certs because it shortens their
life, but we need some authenticated way of knowing how to reply to whoever
sent the mail and real names are not unique.   The 822 headers are outside
the hash and get screwed with by all and sundry.

Perhaps what we need is reply to or originator info inside the hash but not
in the cert.  That means you can be sure that the sender intended that
address to be in the mail and the sender can change address at will without
needing a new cert.  (I'm having a strong urge to duck and run for cover
after saying that :-)

John

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 17, 1997 11:29 AM
Subject: Re: The address-in-certs issue

>> From: Paul Hoffman / IMC <[email-masked]>
>>
>> I propose the following:
>>
>> - There will be no base-level interoperability statement for the content
of
>> the identifier: it's up to the application using S/MIME
>> - S/MIME messages that are to be sent through SMTP MUST have the
identifier
>> be an RFC822 email address, and any cert that goes with that message also
>> MUST use an RFC822 email address
>
>Paul, the content of the cert is the crux of the issue.  I agree with the
>many recent comments that email addresses should not be required or even
>recommended in the cert at all, irrespective of any S/MIME User Agent
>requirements.
>
>Reasons include 1) the more information that goes into a cert, the shorter
>the expected lifetime, 2) additional burdens on CAs/RAs to validate email
>addresses (in cases other than the zero-assurance certs which are issued
>to email addresses, not people), and 3) it's not clear that the user agent
>can do anything at all useful with an email address in a cert, given that
>users should be allowed to change addresses, mail authenticated messages
>from a friend's account, etc.
>
>One topic that came up on the PKIX list many months ago was the use of
>RFC822-style strings as identities.  It is quite reasonable that some
>people might find RFC822 names to be more comfortable than DNs, and it
>might even be reasonable for CAs to issue certs to RFC822-style identities,
>whatever it means to certify something like that.
>
>But an RFC822 identity is a completely separate thing than an SMTP delivery
>address - there are forwarding services now that let you keep the same
>identity regardless of how often you change ISPs.  Doing any sort of
>checking of an SMTP delivery address against an RFC822 identity, if it
exists,
>will often be futile (more than one account, kiosks/friend's account/IETF
>terminal room, address-munging gateways/listservs, etc).
>
>Requiring or recommending the existence of an RFC822 identity in certs
>solely for the purpose of enabling a check against a totally volatile
>delivery address is not warranted.
>
>Dave Kemp
>
 << File: smime.p7s >> 

From: Stefan Kelm <[email-masked]>
Date: Thu, 18 Dec 1997 12:06:30 +0100 (MET)
To: [email-masked]
Subject: Re: The address-in-certs issue
Reply-To: [email-masked]
Sender: [email-masked]

John,

> The issue is we don't want addresses in certs because it shortens their
> life, but we need some authenticated way of knowing how to reply to whoever
> sent the mail and real names are not unique.   The 822 headers are outside
> the hash and get screwed with by all and sundry.

while I certainly do agree with the second part of above's sentence I
don't think that the first part is quite correct. How often do (email)
addresses change in reality and how often would one apply for a new cert
to be issued? I do think that the latter will happen more often by
comparison so I can't see why addresses within a cert should shorten
their validity period. On the other hand, if the address changes one
would need a new cert in a lot of cases anyway.

Am I missing something?

> Perhaps what we need is reply to or originator info inside the hash but not
> in the cert.  That means you can be sure that the sender intended that
> address to be in the mail and the sender can change address at will without
> needing a new cert.  (I'm having a strong urge to duck and run for cover
> after saying that :-)

Well, this sounds like a good idea to me.

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

Date: Wed, 17 Dec 1997 19:45:40 -0500
To: Tim Dean <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: S/MIME counter-signature: comment and question
Cc: [email-masked]
Sender: [email-masked]

Tim:

> ... it seems that the encryptedDigest attribute has been removed 
>from SignerInfo in CMS-01, though it is in PKCS#7.  Is this an 
>inconsistency or have I missed something? 

The encryptedDigest name was changed.  This is an RSA specific name.  The
new name is signatureValue.

Rus

Date: Wed, 17 Dec 1997 18:00:30 -0500
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Modifications to ESS document
Cc: "Ietf-Smime (E-mail)" <[email-masked]>
Sender: [email-masked]

I agree with Jim.  We want to make sure that the ultimate recipient need
only process the last item in the ML expansion history.  His proposal makes
sure tha the MLA builds the expansion history to meet this requirement. It
would be useful to state this rationale in an introduction paragraph.

Russ

At 11:54 PM 12/16/97 -0800, Jim Schaad (Exchange) wrote:
>I have a change that I want to put into the Mail List agent processing
>-- probably as a new section
>
>4.X Mail List Agent Recipt Policy Processing.
>
>If you have two mailing lists A and B where list B is a member of list
>A, list B needs to propigate forward the mailing list recipt policy of A
>in many cases.  This section will describe what propigation should be
>done and in what circumstances.  As a general rule a mailing list should
>be conservitive in propigating forward the rmailing list receipt policy.
>
>
> Previous Policy                 Mail List Agent B's Recipt Policy
>  (A's Policy)          none      insteadOf     inAdditionTo
>missing
>none                    ----------  Must be set to none in all cases
>-------
>insteadOf               none      insteadOf (B)  insteadOf (A+B)
>insteadOf(A)      
>inAdditionTo            none      insteadOf (B)  inAdditionTo (A+B)
>inAddtionTo(A)
>missing                 none      insteadOf (B)  inAddtionTo (B)
>missing
>
>The interesting cases are combining insteadOf with inAddtionTo,
>producing a union of where mailing list A and mailing list B want the
>receipt to go and inAddtionTo with inAddtionTo producing a union.  The
>rest of the cases either put in B's policy or propigate forward A's
>policy.
>
>
>
>It might be nice from a strictly easy point of view to add a copy to
>MLReciptPolicy of "all [4]" to make the text easier to deal with in
>terms of refering to all or normal processing if this value is present
>rather than refering to what to do if the value is missing.
>

Date: Wed, 17 Dec 1997 15:05:40 -0500
To: Uri Blumenthal <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Checking the From address against the cert (was RE:
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I agree.

I have not heard anyone support this checking.  Therefore, we should remove
this check from the document.

Russ

At 12:52 PM 12/17/97 -0500, Uri Blumenthal wrote:
>> There are definitely some of us who do not want the checking against From
>> address to be mandatory. Someone just pointed out to me that S/MIME objects
>> will be carried in HTTP, where email address is not an issue. That is the
>> issue that must be decided on the list.
>
>People, "From" address checking is a VERY BAD idea.
>
>
>Regards,
>Uri
>-=-=-==-=-=-
><Disclaimer>
>

From: "John Pettitt" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: The address-in-certs issue
Date: Wed, 17 Dec 1997 19:45:33 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BD0B24.56C63380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The issue is we don't want addresses in certs because it shortens their
life, but we need some authenticated way of knowing how to reply to whoever
sent the mail and real names are not unique.   The 822 headers are outside
the hash and get screwed with by all and sundry.

Perhaps what we need is reply to or originator info inside the hash but not
in the cert.  That means you can be sure that the sender intended that
address to be in the mail and the sender can change address at will without
needing a new cert.  (I'm having a strong urge to duck and run for cover
after saying that :-)

John

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, December 17, 1997 11:29 AM
Subject: Re: The address-in-certs issue

>> From: Paul Hoffman / IMC <[email-masked]>
>>
>> I propose the following:
>>
>> - There will be no base-level interoperability statement for the content
of
>> the identifier: it's up to the application using S/MIME
>> - S/MIME messages that are to be sent through SMTP MUST have the
identifier
>> be an RFC822 email address, and any cert that goes with that message also
>> MUST use an RFC822 email address
>
>Paul, the content of the cert is the crux of the issue.  I agree with the
>many recent comments that email addresses should not be required or even
>recommended in the cert at all, irrespective of any S/MIME User Agent
>requirements.
>
>Reasons include 1) the more information that goes into a cert, the shorter
>the expected lifetime, 2) additional burdens on CAs/RAs to validate email
>addresses (in cases other than the zero-assurance certs which are issued
>to email addresses, not people), and 3) it's not clear that the user agent
>can do anything at all useful with an email address in a cert, given that
>users should be allowed to change addresses, mail authenticated messages
>from a friend's account, etc.
>
>One topic that came up on the PKIX list many months ago was the use of
>RFC822-style strings as identities.  It is quite reasonable that some
>people might find RFC822 names to be more comfortable than DNs, and it
>might even be reasonable for CAs to issue certs to RFC822-style identities,
>whatever it means to certify something like that.
>
>But an RFC822 identity is a completely separate thing than an SMTP delivery
>address - there are forwarding services now that let you keep the same
>identity regardless of how often you change ISPs.  Doing any sort of
>checking of an SMTP delivery address against an RFC822 identity, if it
exists,
>will often be futile (more than one account, kiosks/friend's account/IETF
>terminal room, address-munging gateways/listservs, etc).
>
>Requiring or recommending the existence of an RFC822 identity in certs
>solely for the purpose of enabling a check against a totally volatile
>delivery address is not warranted.
>
>Dave Kemp
>

------=_NextPart_000_0013_01BD0B24.56C63380
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0013_01BD0B24.56C63380--

From: "Blake Ramsdell" <[email-masked]>
To: "'Elliott N Ginsburg'" <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Checking the From address against the cert (was RE: draft-ietf-smime-cert)
Date: Wed, 17 Dec 1997 15:13:07 -0800
Sender: [email-masked]

On Wednesday, December 17, 1997 8:04 AM, Elliott N Ginsburg
[SMTP:[email-masked]] wrote:
> There are definitely some of us who do not want the checking against From
> address to be mandatory. Someone just pointed out to me that S/MIME
> objects
> will be carried in HTTP, where email address is not an issue. That is the
> issue that must be decided on the list.

I get it.

The current language is as follows (from
http://www.imc.org/draft-ietf-smime-cert section 3.1):

> Sending agents SHOULD make the address in the From header in a mail
> message match an Internet mail address in the signer's certificate.
> Receiving agents MUST check that the address in the From header of a
> mail message matches an Internet mail address in the signer's
> certificate. A receiving agent MUST provide some explicit alternate
> processing of the message if this comparison fails, which may be to
> reject the message.

Anil pointed out that the current language was very carefully worded --
"You MUST do the check, but what you do as a result of the success or
failure of that check is up to you".  I don't know why this isn't
adequate, but I'm willing to keep discussing it if someone can point out
why it isn't.  In the case of HTTP, you MUST do the check (which MAY
fail), and then you take MUST take some action (which is nothing, since
HTTP doesn't care about email address).

Did I miss the boat?

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: EMail address in KM certs (was RE: draft-ietf-smime-cert)
Date: Wed, 17 Dec 1997 14:59:07 -0800
Sender: [email-masked]

On Wednesday, December 17, 1997 9:06 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> ii) a question: for dual key pair architectures such as Entrust's is it
> the intention to put the email addresses in both the signature
> validation certificate and the encryption certificate?

This was the intention, but there was some discussion about this at the
WG meeting.  Opinions?

Basically, when encrypting a mail message, mail clients need to create
an association between a KM certificate and an email address.  The
easiest way to do this is to use the email address from the certificate.
 Arbitrary association is the most flexible way to do this, but is not
necessarily the most user friendly.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: What email address format to use in subjectAltName (was RE: draft-ietf-smime-cert)
Date: Wed, 17 Dec 1997 14:55:21 -0800
Sender: [email-masked]

On Wednesday, December 17, 1997 9:06 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> i) mandating that the email address be an RFC-822 address closes the
> door on future use of X.400 to transport S/MIME.  If the email address
> *must* be in the certificate, subjectAltName allows it to be X.400 or
> RFC-822

Yes, subjectAltName allows X.400, RFC-822, DNS host name, IP Address and
a cheese sandwich as valid name formats.  I'm not trying to trivialize
your position, I'm just showing the great flexibility that we are given
for naming.

Is the X.400 name useful in the certificate?  Definitely.  Is it useful
for Internet-transmitted mail (the scope of the current draft)?  I
personally don't think it is.

I certainly think that another certificate profile that deals with
transmitting S/MIME messages over X.400 would be interesting...  There
was at least one other person that had in mind some kind of S/MIME <->
X.400 world at the WG meeting.

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: Wed, 17 Dec 1997 14:53:20 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Computing Corp.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

Here are some points to consider.

Binding

It is definitely important to bind the intended recipient or alleged
sender with the key.   For example, consider the full binding picture when
sending encrypted mail to an intended recipient.

a. The user or application has to name the intended recipient.
b. The user and/or application must find or select the appropriate
   certificate for that recipient based on the name supplied in (a).
c. The user and/or application must validate the certificate path
   to a CA trusted for this purpose.

If there is any confusion in the binding at any of these three
points, then the security of the message is in doubt:  you have
lost the desired strong guarantees that the resulting key
(in the recipient's certificate) is actually that of the intended
recipient.

The picture is only slightly different when verifying received signed
e-mail, but again what is important is that the name 
understood in the application/user's setting actually corresponds
to the same entity as that in the certificate.

Names in Certificates

If the name that is used in the application or user's setting does not
actually appear anywhere in the certificate, it is hard for the
application to ensure (b) above is done safely.  Some other
information, either from the user or elsewhere, must be brought to
bear in order to guarantee (b).

In the SMTP/electronic mail context, RFC822 addresses are
very natural names for intended recipients, so at least
in this context it seems reasonable to include them in
certificates and have the application easily be able to
do (b) properly without any external information.

It is true that a user or some other information can
sometimes be brought in to guarantee that step (b) is
done safely.  It would be nice not to have to rely on this.

It is also true that S-MIME will be useful over other transports and
with other naming schemes.  I think the same principles will
come to bear there but concede that different names may be needed.

--a.

-- 
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 16:41:22 -0600
Sender: [email-masked]

----------
>From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
>Sent: 	Wednesday, December 17, 1997 3:54 PM
>
>The issue is whether someone can send confidential
>information to the subject of the certificate. If there is no
>email address they are not going to be able to use it for
>S/MIME.

I may have missed something here.  Is there an OID or 
something in the X.509 certificate that identifies it as an
S/MIME certificate?

>This is the real problem. But consider what happens if there is
>no email address in the cert - you don't know how to contact the 
>person.

This is like saying that without caller id, you don't know how to
call someone because you don't know what there phone number
is.

>       Phill

Another point -- If I am using a non-Internet client i.e. Microsoft
Mail, and I am sending to a person inside of my local enclave, My
client knows nothing about any RFC822 addresses. That only 
comes into play when I send it out through a gateway.

Larry

From: "Ron Craswell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: The address-in-certs issue
Date: Wed, 17 Dec 1997 14:33:14 -0800
Sender: [email-masked]

On Wed, Dec 17, 1997 1:26 PM, Paul Hoffman / IMC <[email-masked]>
wrote:
> David, I'm not sure what you *would* put in the signature and the cert,
> then. When I receive a signed message, I want to verify that it came
> from someone I trust. The "came from" information is in the unauthenticated
> RFC822 headers. With some DN in the signature and cert, I can verify that
> the signature was made by someone our mutually-trusted CA says it does, but
> there is no binding between that and the message I received.

The "came from" information is in the authenticated attributes of the
cert. Imagine the cool new S/MIME e-mail client that displayed the
sender certificate's subjectAltName (or whatever) instead of the rfc822
From: to tell you who sent the message.

> My question is, if we don't use mail addresses in mail signatures and
> certs, what do we use? Or, are you suggesting we say "you cannot
> validate signatures on email as being associated with them messages"?

The only binding that is important is that between the cert and the
signature which is provided by the signature validation process.  The
user says, "I have a signed message that can be validated by the 'Paul
Hoffman' cert so I know Paul sent the message.  The rfc822 From: field
says <[email-masked]> but I still know it's Paul because of the cert
so I'm happy."
--
Ron Craswell
Worldtalk Corp.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 16:54:52 -0500
Sender: [email-masked]

Kent's mail helped me refine my earlier position. I think
the answer to this problem is certificates issued for use 
with S/MIME must have an Internet email address in them.
Otherwise it is difficult to understand what issuing a
cert for S/MIME use could mean.

This does not imply that a client be prohibited from using 
a generic X.509v3 cert in conjunction with S/MIME, its just
that such certs cannot be considered 'S/MIME certificates',
should not be marketed as such etc.

The problem of using a different email address can occur in
two different ways:

1) The user acquires a new email address and the old one
remains usable.
2) The user acquires a new email address and the old one
is withdrawn.

I see scenario 1 as being something we need to address 
with an authenticated header attribute and scenario 2 as
ineviatably requiring the revocation of the certificate.

The issue is whether someone can send confidential
information to the subject of the certificate. If there is no
email address they are not going to be able to use it for
S/MIME.

>I am also wary of mandating the inclusion of Internet mail addresses in
>certificates.  From a PKI administration perspective, it is preferable
>to keep application specific information out of certificates because
>they incur additional burdens on the CA and his/her Registration
>Authorities (RAs).

Only inrespect to certs to be used for email.

>An RA will now have to obtain a user's email address, and for medium to
>high assurance certificates, the RA would also be expected to validate
>it (probably through the LAN Mail administrator).

This is one of the easiest identifications to check on the Internet
however. It it checked even in VeriSign class 1 certs.

>  Every time the user's
>email address changes, the CA will have to revoke and re-issue the
>certificate.   Imagine how cumbersome certificate management would
>become if all secure applications, e.g. secure fax, single sign-on,
>required specific information in the certificates.  The more generic a
>certificate, the broader its use and the longer it lasts.

This is the real problem. But consider what happens if there is
no email address in the cert - you don't know how to contact the 
person.

Secure fax sounds like a bogus application to me. How does it
differ from sending a TIFF of JPEG S/MIME attachment ? Similarly
single sign on requires an unambiguous machine readable 
username, why should this be different from a person's email?
After all if single sign on means anything it means that a single
account gains access to both email and filestore.

I don't think that the plethora of identifiers is a problem because 
there is only really one application. 

>Requiring S/MIME agents to check the email address in the 'from' field
>against the one in the signer's certificate and provide 'alternate
>processing' of the message, i.e. reject it, is overly restrictive.  It
>prevents a user, for example, from sending S/MIME messages from a
>colleague's mail account while on a business trip. 

I agree but the problem appears to be with the clients. 
Authenticated data trumps unauthenticated. What is needed 
is a secure means of saying 'i'm temporarily away from
my usual desk'.

>i) mandating that the email address be an RFC-822 address closes the
>door on future use of X.400 to transport S/MIME.  If the email address
>*must* be in the certificate, subjectAltName allows it to be X.400 or
>RFC-822

Is this a bug or a feature? One could argue that making S/MIME
deliberately incompatible will speed the demise of X.400 :-)

Seriously though, I'm somewhat skeptical as to the value of 
an S/MIME X.400 hybrid talking to the world at large to 
start with but if we decide this is desirable we have to take
a more thorough approach. Simply refering to X.400 as
a tie breaker when corner cases come up strikes me as 
pointless.

I don't want there to be any requirement for Internet clients
to deal with legacy email systems whether they be Decnet
phase VI, bitnet, Janet or OSI. This is no longer a current 
standards battle. For better or worse SMTP is the email
dialtone of the Internet. Ergo if we require an email
address it has to be an RFC-822 email address.

>ii) a question: for dual key pair architectures such as Entrust's is it
>the intention to put the email addresses in both the signature
>validation certificate and the encryption certificate?

I would say both.

        Phill

From: Trevor Freeman <[email-masked]>
To: "'Darren Harter'" <[email-masked]>, [email-masked]
Subject: RE: S/MIME counter-signature: comment and question -Reply
Date: Wed, 17 Dec 1997 13:30:11 -0800
Sender: [email-masked]

Hi Darren,
Anyone can resign documents, and there  is no ASN.1 construct which can
prevent this if they are happy to discard signatures, so what is it you are
trying to really do? If you are trying to show a series of signatures then
S\MIME can do that, if someone wants to parallel sign a object, then time
will identify who signed first, and yes you need to work out which time
source to use.
Trevor
> -----Original Message-----
> From:	Darren Harter [SMTP:[email-masked]]
> Sent:	17 December, 1997 5:25 AM
> To:	[email-masked]
> Subject:	RE: S/MIME counter-signature: comment and question -Reply
> 
> Trevor,
> 
> First, I sure this news will have hit the grapevine by now, but if not the
> following URL will be of great interest to the group...
> 
> http://www.cesg.gov.uk/ellisint.htm
> 
> It describes CESG's prior invention of RSA and DH ;-)
> 
> Secondly,
> 
> >>> Trevor Freeman <[email-masked]> 12/16 6:13 pm >>>
> >Tim,
> >If you want to show unequivocally you sent the message then you construct
> >a new signing data layer with the existing data nested within, rather
> than
> >add a new signer info block to the existing signed. If you want to know
> >the sequence a series of parallel signatures where constructed then use
> >time to differentiate the signatures.
> >Trevor
> 
> I think the issue that Tim was trying to convey is that there is no way of
> preventing somebody else from adding their signature to your SignedData. 
> The problem then, as a receiving application, is who to take as the
> originator of the message.  This problem is compounded if we do the
> suggested check of cert altSubjectName against the From: field.
> Timestamps
> are great so long as you can trust that the User has a good time source
> (and
> has used it), and that all signers fill the field.
> 
> As far as I can see, the only way of preventing other users from appending
> their signature after you have sent the message is to have a variant of
> SignedData called LockedSignedData defined as follows:
> 
> LockedSignedData ::= SIGNED{ SignedData }
> 
> i.e. Take MSP's SequenceSignature approach and sign the SignedData ;-)
> 
> Darren
> 
> Darren Harter
> CASM Programme Office,
> Communications-Electronics Security Group
> Cheltenham, UK

Date: Wed, 17 Dec 1997 13:26:07 -0800
To: [email-masked] (David P. Kemp), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The address-in-certs issue
Sender: [email-masked]

David, I'm not sure what you *would* put in the signature and the cert,
then. When I receive a signed message, I want to verify that it came from
someone I trust. The "came from" information is in the unauthenticated
RFC822 headers. With some DN in the signature and cert, I can verify that
the signature was made by someone our mutually-trusted CA says it does, but
there is no binding between that and the message I received.

My question is, if we don't use mail addresses in mail signatures and
certs, what do we use? Or, are you suggesting we say "you cannot validate
signatures on email as being associated with them messages"?

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 17 Dec 1997 18:26:08 -0200 (EDT)
From: Ed Gerck <[email-masked]>
Reply-To: Ed Gerck <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: re: draft-ietf-smime-cert
Sender: [email-masked]

On Wed, 17 Dec 1997 [email-masked] wrote:

-> I am also wary of mandating the inclusion of Internet mail addresses in
-> certificates.  From a PKI administration perspective, it is preferable
-> to keep application specific information out of certificates because
-> they incur additional burdens on the CA and his/her Registration
-> Authorities (RAs).
-> 

An e-mail is not an application-specific information. As we all know,
e-mail names can be (and are) used in several different contexts (such as
anon-ftp, http POST command, etc.) An e-mail is a " name"  such as the
Social Security Number (which you use when the bank requires it in order
to identify your money transfer -- which has nothing to do with Social
Security purposes) or your Driver's License (which you may use to
clear a check in a CD store, even if the Driver's License has expired -- 
after all, you are still you). 

The advantage of e-mail names (which can easily be globally unique) is
that it can provide for a challenge-response method in an easy way. For
example, when you receive an e-mail confirmation of an order, which
provides the PIN to retrieve the order.

Combining such protocol-based challenge-response with cryptography-based
tokens is a natural use of S/MIME, because it provides the user with a
choice.

-> An RA will now have to obtain a user's email address, and for medium to
-> high assurance certificates, the RA would also be expected to validate
-> it (probably through the LAN Mail administrator).  Every time the user's
-> email address changes, the CA will have to revoke and re-issue the
-> certificate.   Imagine how cumbersome certificate management would
-> become if all secure applications, e.g. secure fax, single sign-on,
-> required specific information in the certificates. 

This is simply not true. Certificates (such as X.509) carry fields which
are just "copied as received' by the CA and have zero semantics. In fact,
X.509 only mandates that the public-key be verified by the CA, whereas the
DN is accepted by the CA but not denoted by it (this is done by the NA).
So, unless so warranted by a particular CA (such as Verisign, in a given
cert class and under given liability limits) the e-mail field is copied as
is and means nothing more than that: a reference. An invalid e-mail would
certainly not make a X.509 cert invalid -- nor unuseful. 

-> The more generic a
-> certificate, the broader its use and the longer it lasts.
-> 

No, the less it can be used for. Following your example, imagine a cert
which only has the subject's public-key and DN. What does it authorize? 
How to contact the subject? Is that key useful for signing or for
encryption?

Further, clearly, a cert without e-mail address can be beautifully used in
a denial-of-service attack -- that's why PGP included an e-mail field.

After all, if send you my key-cert, tamperproof, and my e-mail, in
plaintext, I am just divorcing purpose from attitude.

-> Requiring S/MIME agents to check the email address in the 'from' field
-> against the one in the signer's certificate and provide 'alternate
-> processing' of the message, i.e. reject it, is overly restrictive.  It
-> prevents a user, for example, from sending S/MIME messages from a
-> colleague's mail account while on a business trip.  As Elliot noted in
-> his message, what is important is that the message content has been
-> signed by its originator, not what mailbox the content came from. 

This is not axiomatic. The mailbox whence it came provides for
accountability and may provide hints on possible interference, delays,
replays, etc.

For example, if you receive an e-mail from Clinton as sent by Khadaffi's
e-mail agent -- what would you think of it? Or, from a GM engineer as sent
from a VW e-mail agent? 

Further, there is a common misconception that security must always be
"perfect" as provided by cryptography -- with its costs. However,
oftentimes, all one needs is an assurance that miscreants will be caught
with a certain probability level. In an Intranet, such assurance might be
sufficient for day-to-day activities (with a properly secured server). If
more is needed, then the key may be used. Again, the user should be able
to choose.

 -> I
-> realize this does not prevent 'spoofing' but who cares?  As long as you
-> can validate that the content was signed by the originator and has not
-> been tampered with why would you be concerned if it came from the user's
-> true and correct mail address or not?  

As above. Note also that the fact you can validate its originator and
contents by the signature, does not mean that you can trust the clock used
in that host, or its msg delay, or its hidden forwarding. Which may render
the message totally useless for several purposes.

-> Given the current trend to
-> increase PKI portability via PCMCIA hardware tokens and smart cards,
-> tying S/MIME users to their email addresses decreases portability.
-> 

I find your phrase difficult to accept on three counts. First, tokens do
not increase PKI portability -- they increase key security. Second, no one
is tied to an e-mail address and the current trend is to have several
addresses. Third, one of the purposes of S/MIME was (or is) to secure
e-mail messages -- so, this means that if S/MIME does not allow that then
something else will (because there is a need).

 -> Two other points: -> 
-> i) mandating that the email address be an RFC-822 address closes the
-> door on future use of X.400 to transport S/MIME.  If the email address
-> *must* be in the certificate, subjectAltName allows it to be X.400 or
-> RFC-822
-> 

Whatever X.400 turns out to be ;-)

Cheers,

Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck                        [email-masked]
http://novaware.cps.softex.br

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 14:15:06 -0600
Sender: [email-masked]

One of the things that ArmorMail products have done from
the start is based upon some Military message requirements.
We include the From:, To: and cc: addresses along with the
date as part of the signed message body. This is because
of a requirement to know who the message was really 
sent to for action, as well as who else was copied on the
message -- as part of the trusted content.

The format of the address that we put in the header was
argued for quite some time, and it was decided by a
consensus of our customers that the "alias" (which is usually
the name of the individual) is what they want to see. This 
information in combination with display of the signer's DN,
along with optional display of the certificate hierarchy, gives
the user all the information they need to make any judgment
calls they wish, without having to worry about rfc822 addresses
or how the mail got there.

Larry

----------
From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
Sent: 	Wednesday, December 17, 1997 11:49 AM
To: 	[email-masked]; Elliott N Ginsburg
Cc: 	[email-masked]
Subject: 	Re: draft-ietf-smime-cert

[...]
One solution to this problem is to simply require an email address in
the certificate. A better one may be to provide a means of identifying
the 'reply-to' address within the signed envelope, possibly as an
attribute. Then the user can overide it if necessary.

            Phill

Date: Wed, 17 Dec 1997 14:38:14 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: The address-in-certs issue
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> I propose the following:
> 
> - There will be no base-level interoperability statement for the content of
> the identifier: it's up to the application using S/MIME
> - S/MIME messages that are to be sent through SMTP MUST have the identifier
> be an RFC822 email address, and any cert that goes with that message also
> MUST use an RFC822 email address

Paul, the content of the cert is the crux of the issue.  I agree with the
many recent comments that email addresses should not be required or even
recommended in the cert at all, irrespective of any S/MIME User Agent
requirements.

Reasons include 1) the more information that goes into a cert, the shorter
the expected lifetime, 2) additional burdens on CAs/RAs to validate email
addresses (in cases other than the zero-assurance certs which are issued
to email addresses, not people), and 3) it's not clear that the user agent
can do anything at all useful with an email address in a cert, given that
users should be allowed to change addresses, mail authenticated messages
from a friend's account, etc.

One topic that came up on the PKIX list many months ago was the use of
RFC822-style strings as identities.  It is quite reasonable that some
people might find RFC822 names to be more comfortable than DNs, and it
might even be reasonable for CAs to issue certs to RFC822-style identities,
whatever it means to certify something like that.

But an RFC822 identity is a completely separate thing than an SMTP delivery
address - there are forwarding services now that let you keep the same
identity regardless of how often you change ISPs.  Doing any sort of
checking of an SMTP delivery address against an RFC822 identity, if it exists,
will often be futile (more than one account, kiosks/friend's account/IETF
terminal room, address-munging gateways/listservs, etc).

Requiring or recommending the existence of an RFC822 identity in certs
solely for the purpose of enabling a check against a totally volatile
delivery address is not warranted.

Dave Kemp

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 12:04:19 -0600
Sender: [email-masked]

Another reason people or corporations may not want an
email address in their certificates is that a directory
containing certificates now becomes yet another mail list 
source for spammers.

Larry

----------
From: 	[email-masked][SMTP:[email-masked]]
Sent: 	Wednesday, December 17, 1997 11:06 AM
To: 	[email-masked]; [email-masked]
Cc: 	[email-masked]; [email-masked]
Subject: 	re: draft-ietf-smime-cert

i) mandating that the email address be an RFC-822 address closes the
door on future use of X.400 to transport S/MIME.  If the email address
*must* be in the certificate, subjectAltName allows it to be X.400 or
RFC-822

Date: Wed, 17 Dec 1997 10:10:51 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: The address-in-certs issue
Sender: [email-masked]

I'd like to start a new thread on this so that we are all on the same page.
I'd like to be sure we all agree on the non-technical reasoning behind what
we're doing in S/MIME v2 and what we want to do in S/MIME v3.

We use a signature to say "I sent this". I believe that this group agrees
on the definition of "sent" and "this" for the context of S/MIME. The
question is who is "I", that is, the identifier of the signer.

In S/MIME v2, we use an RFC822 email address (user@domain) to be the
identifier of the signer. Email addresses can identify entities such as
people or other mail senders. Further, CAs can do some reasonable checking
before they certify the validity of and email address, such as verifying
that that email address can respond to a challenge about the signature.

Where we have a problem is when a recipent tries to validate "I sent this".
The validation step involves checking the "I" identifier in the signature
against something in the "this". However, the something against which they
would be checking is not authenticated: it's out in the commonly-spoofed
plaintext headers that precede the signed message, not in the authenticated
part of the message.

This is inherently a user interface issue. Because S/MIME messages can be
carried in non-email systems, requiring the "I" identifier to match the
spoofable headers is clearly wrong. Even in email, because the headers that
are checked against are suseptable to both spoofing and munging by
gateways, we cannot force actions based on the comparision of the signature
address and the headers.

I propose the following:

- There will be no base-level interoperability statement for the content of
the identifier: it's up to the application using S/MIME
- S/MIME messages that are to be sent through SMTP MUST have the identifier
be an RFC822 email address, and any cert that goes with that message also
MUST use an RFC822 email address
- S/MIME receiving agents that get messages from SMTP SHOULD check the
email addresses in the signatures and certs of the message against the
From: and Sender: headers of the message, SHOULD have a policy about what
matches and doesn't match, and SHOULD alert the recipient if the address in
the identifier and the header(s) don't match
- Non-email agents SHOULD have a policy about what the content of the
identifier is, SHOULD have a policy about what matches and doesn't match,
and SHOULD have a policy about what to do if the addresses don't match
- A detailed description of the logic of the above has to appear in the
body of the -cert draft, and a warning about it has to appear in the
security section

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium

From: Uri Blumenthal <[email-masked]>
Subject: Re: Checking the From address against the cert (was RE:
To: [email-masked] (Elliott N Ginsburg)
Date: Wed, 17 Dec 1997 12:52:25 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> There are definitely some of us who do not want the checking against From
> address to be mandatory. Someone just pointed out to me that S/MIME objects
> will be carried in HTTP, where email address is not an issue. That is the
> issue that must be decided on the list.

People, "From" address checking is a VERY BAD idea.

Regards,
Uri
-=-=-==-=-=-
<Disclaimer>

From: "John Pettitt" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, <[email-masked]>, "'Elliott N Ginsburg'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Checking the From address against the cert (was RE: draft-ietf-smime-cert)
Date: Wed, 17 Dec 1997 09:48:12 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01BD0AD0.E3E25C20
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Elliott N Ginsburg <[email-masked]>
To: Blake Ramsdell <[email-masked]>; [email-masked]'
<[email-masked]>; 'Elliott N Ginsburg' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Date: Wednesday, December 17, 1997 7:52 AM
Subject: Re: Checking the From address against the cert (was RE:
draft-ietf-smime-cert)

>There are definitely some of us who do not want the checking against From
>address to be mandatory. Someone just pointed out to me that S/MIME objects
>will be carried in HTTP, where email address is not an issue. That is the
>issue that must be decided on the list.
>
>elliott ginsburg
>
>

I think the desired MUA actions look like this:
    If there is a signature use it when displaying "from" info.
        else use the regular mail headers and warn about
        unauthenticated sender (this for encrypted only data)
    On reply if there are multiple addresses AND they are
        different prompt user to pick one (indicating which
        one is authenticated).

In other words I think the signature supersedes the mail headers.  I also
think most of this stuff is SHOULD's not MUST's since so much of it depends
on what the user is trying to do.

All that said S/MIME is a transport - why are we taking about user agent
actions?  It's one thing to say the MUA must be able to process a particular
type of data, saying what it should do with it, particularly data from other
protocols seems odd to me.

Lastly - IMHO whatever we do should provide for the case where no
From:/Sender: line is supplied (non smtp transport).

John

------=_NextPart_000_0061_01BD0AD0.E3E25C20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0061_01BD0AD0.E3E25C20--

Date: Wed, 17 Dec 1997 09:41:57 -0800
From: Jeff Thompson <[email-masked]>
To: [email-masked]
Subject: email header heebie jeebies
Sender: [email-masked]

Matching From: addreses in email headers to certificates always gave me
the layer violation heebie jeebies.  I add my vote for removing mandated
processing of email headers.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Elliott N Ginsburg" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 12:49:27 -0500
Sender: [email-masked]

>At the S/MIME working group last week, some suggested that the requirement
>for email addresses in certs should be removed. I agree with this and have
>suggested wording to do so. I think we at least have to discuss this issue.
>My customers do not want email addresses in certs.

There seems to be a lot of confusion caused by this issue. I'm trying
to work out where the problem really lies.

An oft quoted problem with the address in the certificate approach
is that a personmay legitimately use more than one address. Company
names also change, people change departments yet these need not
necessarily require a new certificate or private key.

Obviously proof of message origin is important, yet many S/MIME clients
conceal email addresses from the user unless display is specifically
requested. Maybe an S/MIME client that receives a signed message
should just display the distinguished name from the certificate and
ignore any information in the headers.

Providing an authenticated return address appears to me to be
important as well. Relying on the information in an unauthenticated
'reply-to' field seems unsatisfactory to me.

One solution to this problem is to simply require an email address in
the certificate. A better one may be to provide a means of identifying
the 'reply-to' address within the signed envelope, possibly as an
attribute. Then the user can overide it if necessary.

            Phill

From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: re: draft-ietf-smime-cert
Date: Wed, 17 Dec 1997 12:06:00 -0500
Sender: [email-masked]

I am also wary of mandating the inclusion of Internet mail addresses in
certificates.  From a PKI administration perspective, it is preferable
to keep application specific information out of certificates because
they incur additional burdens on the CA and his/her Registration
Authorities (RAs).

An RA will now have to obtain a user's email address, and for medium to
high assurance certificates, the RA would also be expected to validate
it (probably through the LAN Mail administrator).  Every time the user's
email address changes, the CA will have to revoke and re-issue the
certificate.   Imagine how cumbersome certificate management would
become if all secure applications, e.g. secure fax, single sign-on,
required specific information in the certificates.  The more generic a
certificate, the broader its use and the longer it lasts.

Requiring S/MIME agents to check the email address in the 'from' field
against the one in the signer's certificate and provide 'alternate
processing' of the message, i.e. reject it, is overly restrictive.  It
prevents a user, for example, from sending S/MIME messages from a
colleague's mail account while on a business trip.  As Elliot noted in
his message, what is important is that the message content has been
signed by its originator, not what mailbox the content came from.  I
realize this does not prevent 'spoofing' but who cares?  As long as you
can validate that the content was signed by the originator and has not
been tampered with why would you be concerned if it came from the user's
true and correct mail address or not?  Given the current trend to
increase PKI portability via PCMCIA hardware tokens and smart cards,
tying S/MIME users to their email addresses decreases portability.

Two other points:

i) mandating that the email address be an RFC-822 address closes the
door on future use of X.400 to transport S/MIME.  If the email address
*must* be in the certificate, subjectAltName allows it to be X.400 or
RFC-822

ii) a question: for dual key pair architectures such as Entrust's is it
the intention to put the email addresses in both the signature
validation certificate and the encryption certificate?

Kent Lancaster
Government of Canada
[email-masked]
819-956-4866

 ----------
From: Elliott N Ginsburg
To: [email-masked]
Cc: [email-masked]
Subject: re: draft-ietf-smime-cert
Date: Tuesday, December 16, 1997 2:48PM

There are several issues to be addressed in this draft:
1) Should there be mandatory processing of email addresses in
certificates
2) The processing descriptions must recognize that not only do receiving
agents process certificates during signature validation, but sending
agents process certificates used for encryption.
3) The current PKIX profile recommends that subject, if not null,
contain a Directory Name; and that an email address, if present, be in
subjectAltName.

Rather than require an email address in the certificate, and require the
matching of the email address and header information, I think that when
a signature is declared valid, it is essential to present the owner
names bound into the certificate, because it is from the certificate
owner that the message originated,
regardless of what is in the header of the message. This allows the
choice of how to
present the owner name in the certificate, where email address is only
one of the possible choices.

I recommend that the end of section 3.1 should read something like:

<snipped>

Date: Wed, 17 Dec 1997 11:09:37 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS ContentHints Comments
Sender: [email-masked]

All,

In a previous message, I proposed changes to ESS Section 2.4, Signed Receipt
Creation, regarding the chain of digests leading to the SignedData/Receipt
signature value.  My message included the following concepts that were
previously documented in the CMS/ESS specs:

1) Mandatory inclusion of contentType attribute in authenticatedAttributes
of signedData/Receipt signerInfo (as per CMS, Sec 5.2).

2) Mandatory inclusion of id-ct-receipt OID in contentInfo contentType in
signedData that includes the Receipt content (ESS, Sec 2.4).

3) Recommended inclusion of contentHints with "receipt" set to TRUE (ESS,
Sec 2.4 and Sec 2.10).

In effect, these are three different fields in the SignedData object that
identify the content as being a Receipt.  We definitely need to include the
id-ct-receipt OID in contentInfo contentType, but do we also need to include
both the contentType and contentHints in the authenticatedAttributes of the
SignedData/Receipt signerInfo?  It seems that the inclusion of both of these
attributes is redundant.  Propose that the ESS Sec 2.4 text should be
changed so that it does not recommend that the ContentHints attribute should
be included in the authenticatedAttributes of the SignedData/Receipt
signerInfo.  Also, text should be added which states when the ContentHints
attribute should be used.  Recommend the following  specific changes to ESS:

1) Sec 2.4, Bullet 7: Change to: "7. A signingTime attribute indicating the
time that the signedData/Receipt is signed SHOULD be created and added to
the authenticated attributes of the signerInfo which will eventually contain
the signedData/Receipt signature value.  Other attributes (except
receiptRequest) may be added to the authenticatedAttributes of the
signerInfo."  contentHints was deleted from the bullet.

2) Sec 2.10, ContentHints section:  Change "Messages that contain a signed
receipt MUST include this attribute with the
receipt value set to TRUE." to "When a SignedData/Receipt is encapsulated by
another SignedData object, then the sending agent SHOULD include a
ContentHints attribute (with receipt set to TRUE) in the
authenticatedAttributes of the outermost SignedData object.  For example, if
a SignedData/Receipt is encrypted within an EnvelopedData object which is
then signed using an outer SignedData object, then the outer SignedData
object should include a ContentHints attribute with receipt set to TRUE."  

Also, I believe that ESS Sec 1.3.4 should be left as is.  It implies that a
contentHints attribute does not necessarily need to be authenticated.  When
the contentHints includes a contentDescription and receipt set to FALSE,
then it does not necessarily need to be authenticated. I believe that the
ESS spec should continue to include the flexibility to
support that option.  When the contentHints includes receipt set to TRUE,
then it should be authenticated.
  
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Wed, 17 Dec 1997 11:04:05 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Elliott N Ginsburg'" <[email-masked]>
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: Checking the From address against the cert (was RE: draft-ietf-smime-cert)
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

There are definitely some of us who do not want the checking against From
address to be mandatory. Someone just pointed out to me that S/MIME objects
will be carried in HTTP, where email address is not an issue. That is the
issue that must be decided on the list.

elliott ginsburg

At 09:50 PM 12/16/97 -0800, Blake Ramsdell wrote:
>On Tuesday, December 16, 1997 3:51 PM, Anil R. Gangolli
>[SMTP:[email-masked]] wrote:
>> Elliott N Ginsburg wrote:
>> > 
>> > There are several issues to be addressed in this draft:
>> > 1) Should there be mandatory processing of email addresses in
>> > certificates
>> 
>> Yes, we discussed this at length in forming the current draft.  I believe
>> it was
>> agreed that we should make a check mandatory, but there was well-
>> warranted
>> resistance toward putting anything about how success or failure of this
>> check would end up at any presentation or application layer.  It was
>> agreed
>> this was outside the scope of the spec.
>
>We had another discussion about this at the WG meeting in DC.  I believe
>that Jim Schaad and I come down on the side of "the RFC822 name is
>unauthenticated, so any comparison to information in the certificate is
>interesting, but not necessarily useful."
>
>I don't know if there is any further action we should take with this,
>but the rathole detector went off during the WG meeting and we squashed
>the discussion (Paul suggested we should bring it up on the list, which
>has happened).  As you point out, perhaps more discussion in the
>Security Considerations section would be useful.
>
>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
>
>
>

Elliott N Ginsburg

Date: Wed, 17 Dec 1997 10:59:44 -0500
To: [email-masked], Elliott N Ginsburg <[email-masked]>
From: Elliott N Ginsburg <[email-masked]>
Subject: Re: draft-ietf-smime-cert
Cc: [email-masked]
Sender: [email-masked]

At the S/MIME working group last week, some suggested that the requirement
for email addresses in certs should be removed. I agree with this and have
suggested wording to do so. I think we at least have to discuss this issue.
My customers do not want email addresses in certs.

elliott ginsburg 

At 03:51 PM 12/16/97 -0800, Anil R. Gangolli wrote:
>Elliott N Ginsburg wrote:
>> 
>> There are several issues to be addressed in this draft:
>> 1) Should there be mandatory processing of email addresses in certificates
>
>Yes, we discussed this at length in forming the current draft.  I believe
it was
>agreed that we should make a check mandatory, but there was well-warranted
>resistance toward putting anything about how success or failure of this
>check would end up at any presentation or application layer.  It was agreed
>this was outside the scope of the spec.
>
>The end result was a rather weak statement in the Security Considerations 
>section.  I agree there is some room for making this stronger.
>
>> 2) The processing descriptions must recognize that not only do receiving
agents process certificates during signature validation, but sending agents
process certificates used for encryption.
>
>Yes, we had the same comment on the last (pre-)draft.
>
>> 3) The current PKIX profile recommends that subject, if not null,
contain a Directory Name;
>>    and that an email address, if present, be in subjectAltName.
>> 
>[ alot of other worthwhile text deleted ]
>
>Yes, and I agree with the PKIX recommendation here.
>The current SMIME draft was intended to compromise to allow for the fact
that existing 
>implementations and many "e-mail certs" already out there are using 
>PKCS-9 EmailAddress (aka "E") in the DN for this purpose.
>
>I think the right approach is to recommend roughly that issuers SHOULD put
>e-mail addresses in the subjectAltName extension and that SMIME
implementations
>MUST look for them in both places.  Eventually one hopes for a transition to
>use of the extension.
>
>--a.
>
>
>-- 
>Anil R. Gangolli
>Structured Arts Computing Corp.
>http://www.StructuredArts.com
>mailto:[email-masked]
>
>

Elliott N Ginsburg

To: Darren Harter <[email-masked]>
Cc: [email-masked]
Subject: Re: S/MIME counter-signature: comment and question -Reply
From: EKR <[email-masked]>
Date: 17 Dec 1997 07:32:14 -0800
Lines: 60
Sender: [email-masked]

Darren Harter <[email-masked]> writes:
> http://www.cesg.gov.uk/ellisint.htm
> 
> It describes CESG's prior invention of RSA and DH ;-)
Yeah, well, too bad you guys didn't publish and save us 20 years
of PKP.

> >>> Trevor Freeman <[email-masked]> 12/16 6:13 pm >>>
> >Tim,
> >If you want to show unequivocally you sent the message then you construct
> >a new signing data layer with the existing data nested within, rather than
> >add a new signer info block to the existing signed. If you want to know
> >the sequence a series of parallel signatures where constructed then use
> >time to differentiate the signatures.
> >Trevor
> 
> I think the issue that Tim was trying to convey is that there is no way of
> preventing somebody else from adding their signature to your SignedData. 
> The problem then, as a receiving application, is who to take as the
> originator of the message.  This problem is compounded if we do the
> suggested check of cert altSubjectName against the From: field.  Timestamps
> are great so long as you can trust that the User has a good time source (and
> has used it), and that all signers fill the field.
> 
> As far as I can see, the only way of preventing other users from appending
> their signature after you have sent the message is to have a variant of
> SignedData called LockedSignedData defined as follows:
> 
> LockedSignedData ::= SIGNED{ SignedData }
> 
> i.e. Take MSP's SequenceSignature approach and sign the SignedData ;-)
The attack, as I understand it, is that you trick
someone into co-signing a message and then pretend it's from them.
This is stopped, as you say, by having co-signing be a different
operation from signing. (This is what countersigning provides, and
it's analagous to your approach above.)

However, if you believe that there is a role for multiple signatures
at the same level (i.e. multiple SignerInfos) by different entities,
then (at the moment) receivers can't  know which one of those entities
sent it. (The semantics of multiple signatures have always been pretty
confused.) The obvious fix for this is an attribute that says 'I'm
just a co-signer, not a signer'. But I'm not sure what semantics
that would have different from countersign. It's obvious that
we need multiple signatures from the same entity for mixed-algorithm
environments so we certainly can't do away with multiple signatures
altogether.

There's no way AFAIK, to stop someone who has access to a message
from tacking on their own signature (and stripping yours), which
is the attack you describe. Even with LockSignedData, since
they have access to the plaintext one can therefore simply generate
a new SignedData. 

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 17 Dec 1997 13:25:24 +0000
From: Darren Harter <[email-masked]>
To: [email-masked]
Subject: RE: S/MIME counter-signature: comment and question -Reply
Sender: [email-masked]

Trevor,

First, I sure this news will have hit the grapevine by now, but if not the
following URL will be of great interest to the group...

http://www.cesg.gov.uk/ellisint.htm

It describes CESG's prior invention of RSA and DH ;-)

Secondly,

>>> Trevor Freeman <[email-masked]> 12/16 6:13 pm >>>
>Tim,
>If you want to show unequivocally you sent the message then you construct
>a new signing data layer with the existing data nested within, rather than
>add a new signer info block to the existing signed. If you want to know
>the sequence a series of parallel signatures where constructed then use
>time to differentiate the signatures.
>Trevor

I think the issue that Tim was trying to convey is that there is no way of
preventing somebody else from adding their signature to your SignedData. 
The problem then, as a receiving application, is who to take as the
originator of the message.  This problem is compounded if we do the
suggested check of cert altSubjectName against the From: field.  Timestamps
are great so long as you can trust that the User has a good time source (and
has used it), and that all signers fill the field.

As far as I can see, the only way of preventing other users from appending
their signature after you have sent the message is to have a variant of
SignedData called LockedSignedData defined as follows:

LockedSignedData ::= SIGNED{ SignedData }

i.e. Take MSP's SequenceSignature approach and sign the SignedData ;-)

Darren

Darren Harter
CASM Programme Office,
Communications-Electronics Security Group
Cheltenham, UK

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Modifications to ESS document
Date: Tue, 16 Dec 1997 23:54:13 -0800
Sender: [email-masked]

I have a change that I want to put into the Mail List agent processing
-- probably as a new section

4.X Mail List Agent Recipt Policy Processing.

If you have two mailing lists A and B where list B is a member of list
A, list B needs to propigate forward the mailing list recipt policy of A
in many cases.  This section will describe what propigation should be
done and in what circumstances.  As a general rule a mailing list should
be conservitive in propigating forward the rmailing list receipt policy.

 Previous Policy                 Mail List Agent B's Recipt Policy
  (A's Policy)          none      insteadOf     inAdditionTo
missing
none                    ----------  Must be set to none in all cases
-------
insteadOf               none      insteadOf (B)  insteadOf (A+B)
insteadOf(A)      
inAdditionTo            none      insteadOf (B)  inAdditionTo (A+B)
inAddtionTo(A)
missing                 none      insteadOf (B)  inAddtionTo (B)
missing

The interesting cases are combining insteadOf with inAddtionTo,
producing a union of where mailing list A and mailing list B want the
receipt to go and inAddtionTo with inAddtionTo producing a union.  The
rest of the cases either put in B's policy or propigate forward A's
policy.

It might be nice from a strictly easy point of view to add a copy to
MLReciptPolicy of "all [4]" to make the text easier to deal with in
terms of refering to all or normal processing if this value is present
rather than refering to what to do if the value is missing.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Elliott N Ginsburg'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Checking the From address against the cert (was RE: draft-ietf-smime-cert)
Date: Tue, 16 Dec 1997 21:50:04 -0800
Sender: [email-masked]

On Tuesday, December 16, 1997 3:51 PM, Anil R. Gangolli
[SMTP:[email-masked]] wrote:
> Elliott N Ginsburg wrote:
> > 
> > There are several issues to be addressed in this draft:
> > 1) Should there be mandatory processing of email addresses in
> > certificates
> 
> Yes, we discussed this at length in forming the current draft.  I believe
> it was
> agreed that we should make a check mandatory, but there was well-
> warranted
> resistance toward putting anything about how success or failure of this
> check would end up at any presentation or application layer.  It was
> agreed
> this was outside the scope of the spec.

We had another discussion about this at the WG meeting in DC.  I believe
that Jim Schaad and I come down on the side of "the RFC822 name is
unauthenticated, so any comparison to information in the certificate is
interesting, but not necessarily useful."

I don't know if there is any further action we should take with this,
but the rathole detector went off during the WG meeting and we squashed
the discussion (Paul suggested we should bring it up on the list, which
has happened).  As you point out, perhaps more discussion in the
Security Considerations section would be useful.

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Elliott N Ginsburg'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Where does the E-Mail address go in a cert (was RE: draft-ietf-smime-cert)
Date: Tue, 16 Dec 1997 21:06:26 -0800
Sender: [email-masked]

On Tuesday, December 16, 1997 3:51 PM, Anil R. Gangolli
[SMTP:[email-masked]] wrote:
> I think the right approach is to recommend roughly that issuers SHOULD
> put
> e-mail addresses in the subjectAltName extension and that SMIME
> implementations
> MUST look for them in both places.  Eventually one hopes for a transition
> to
> use of the extension.

Yup.  I like this.  Any other comments?

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: Tue, 16 Dec 1997 19:59:16 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS Signed Receipt Creation Proposal
Sender: [email-masked]

All,

At the 10 Dec 97 IETF S/MIME Working Group meeting, I presented a proposal
for enhancing ESS, Section 2.4, Signed Receipt Creation, so that the chain
of digests leading to the signedData/Receipt signature value includes
digesting the authenticatedAttributes of the original signedData signerInfo
requesting the signedData/Receipt and includes digesting the
authenticatedAttributes of the signedData/Receipt signerInfo.  This allows
the originator of the original signedData object requesting the
signedData/Receipt to verify that the recipient received and was able to
verify the signature of the original signedData object including the content
and authenticatedAttributes.  This also allows the originator of the
original signedData object to verify the integrity and authenticity of the
authenticatedAttributes of the signerInfo containing the signedData/Receipt
signature value.  The meeting attendees agreed with this proposal with one
minor enhancement recommended by Jim Schaad.  This message proposes the
exact text and diagrams for inclusion in ESS, Section 2.4 (including Jim's
recommended enhancement).

Note: The proposed msgSigDigest attribute will be an OCTET STRING and needs
to have an OID assigned in the "OIDS User with S/MIME" document.

Note: I will send a follow-up message with the corresponding proposed
changes to ESS Section 2.7, Receipt Digest Value section.

"2.4 Signed Receipt Creation

A signed receipt (i.e. signedData object encapsulating a Receipt content
(signedData/Receipt)) is created as follows:

1. The signature of the original signedData signerInfo that includes the
receiptRequest authenticated attribute MUST be successfully verified before
creating the signedData/Receipt.  Figure 2.4.1 and the following text
summarize the message signature digest calculation process described in CMS,
Section 5.3, as applied to the verification of the signature of the original
signedData signerInfo.  The ASN.1 DER encoded content of the original
signedData object is digested as described in CMS, Section 5.3.  The
resulting digest value is then compared with the value of the messageDigest
attribute included in the authenticatedAttributes of the original signedData
signerInfo.  If these digest values are different, then the signature
verification process fails and the signedData/Receipt MUST NOT be created.
The ASN.1 DER encoded authenticatedAttributes (including messageDigest,
receiptRequest and, possibly, others) in the original signedData signerInfo
are digested as described in CMS, Section 5.3.  The resulting digest value
(msgSigDigest) is then used to verify the signature of the original
signedData signerInfo.  If the signature verification fails, then the
signedData/Receipt MUST NOT be created. 

   Original
  SignedData
   Content
*            *
 *          *
  * digest *  
      |         Original SignedData SignerInfo
      v            Authenticated Attributes
 ------------------------------------------------------  
| messageDigest | receiptRequest | other attributes ...|
 ------------------------------------------------------
 *                                                    *
           *                                 *     
                  *      digest      *      
                           |
                           v
                      msgSigDigest

Figure 2.4.1.  Original SignedData Signature Digest Calculation 

2. A Receipt structure is created (see "Receipt Syntax" section).

    2.1. The value of the Receipt version field is set to 1.
    
    2.2. The encapsulatedContentType and signedContentIdentifier
    values are copied from the original signedData signerInfo 
    receiptRequest attribute into the corresponding fields in the 
    Receipt structure.
    
    2.3. The signature value from the original signedData signerInfo
    that includes the receiptRequest attribute is copied into the 
    originatorSignatureValue field in the Receipt structure.
    
3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1.

4. D1 is digested.  As depicted in Figure 2.4.2, the resulting digest value
is included as the messageDigest attribute in the authenticatedAttributes of
the signerInfo which will eventually contain the signedData/Receipt
signature value.  

Receipt Content
*            *
 *          *
  * digest *  
      |            SignedData/Receipt SignerInfo
      v              Authenticated Attributes
 ------------------------------------------------------------------  
| messageDigest | msgSigDigest | contentType | other attributes ...|
 ------------------------------------------------------------------
 *                                                               *
           *                                       *     
                      *     digest     *   
                              |
                              v
                       receiptSigDigest

Figure 2.4.2.  SignedData/Receipt Signature Digest Calculation 

5. The digest value (msgSigDigest) calculated in Step 1 to verify the
signature of the original signedData signerInfo is included as the
msgSigDigest attribute in the authenticatedAttributes of the signerInfo
which will eventually contain the signedData/Receipt signature value.  

6. A contentType attribute including the id-ct-receipt OID MUST be created
and added to the authenticated attributes of the signerInfo which will
eventually contain the signedData/Receipt signature value.

7. contentHints (with receipt set to TRUE) and signingTime (indicating the
time that the signedData/Receipt is signed) attributes SHOULD be created and
added to the authenticated attributes of the signerInfo which will
eventually contain the signedData/Receipt signature value.  Other attributes
(except receiptRequest) may be added to the authenticatedAttributes of the
signerInfo.

8. The authenticatedAttributes (messageDigest, msgSigDigest, contentType
and, possibly, others) of the signerInfo are ASN.1 DER encoded and digested
as described in CMS, Section 5.3.  The resulting digest value
(receiptSigDigest) is used to calculate the signature value which is then
included in the signedData/Receipt signerInfo.

9. The ASN.1 DER encoded Receipt content MUST be directly encoded within the
signedData contentInfo content ANY field.  The id-ct-receipt OID MUST be
included in the signedData contentInfo contentType.  This results in a
single ASN.1 encoded object composed of a signedData including the Receipt
content.  The Data content type MUST NOT be used.  The Receipt content MUST
NOT be encapsulated in a MIME header or any other header prior to being
encoded as part of the signedData object."

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

Date: Tue, 16 Dec 1997 15:51:29 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Computing Corp.
To: Elliott N Ginsburg <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-smime-cert
Sender: [email-masked]

Elliott N Ginsburg wrote:
> 
> There are several issues to be addressed in this draft:
> 1) Should there be mandatory processing of email addresses in certificates

Yes, we discussed this at length in forming the current draft.  I believe it was
agreed that we should make a check mandatory, but there was well-warranted
resistance toward putting anything about how success or failure of this
check would end up at any presentation or application layer.  It was agreed
this was outside the scope of the spec.

The end result was a rather weak statement in the Security Considerations 
section.  I agree there is some room for making this stronger.

> 2) The processing descriptions must recognize that not only do receiving agents process certificates during signature validation, but sending agents process certificates used for encryption.

Yes, we had the same comment on the last (pre-)draft.

> 3) The current PKIX profile recommends that subject, if not null, contain a Directory Name;
>    and that an email address, if present, be in subjectAltName.
> 
[ alot of other worthwhile text deleted ]

Yes, and I agree with the PKIX recommendation here.
The current SMIME draft was intended to compromise to allow for the fact that existing 
implementations and many "e-mail certs" already out there are using 
PKCS-9 EmailAddress (aka "E") in the DN for this purpose.

I think the right approach is to recommend roughly that issuers SHOULD put
e-mail addresses in the subjectAltName extension and that SMIME implementations
MUST look for them in both places.  Eventually one hopes for a transition to
use of the extension.

--a.

-- 
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Date: Tue, 16 Dec 1997 14:48:44 -0500
To: [email-masked]
From: Elliott N Ginsburg <[email-masked]>
Subject: re: draft-ietf-smime-cert
Cc: [email-masked]
Sender: [email-masked]

There are several issues to be addressed in this draft:

1) Should there be mandatory processing of email addresses in
certificates

2) The processing descriptions must recognize that not only do receiving
agents process certificates during signature validation, but sending
agents process certificates used for encryption.

3) The current PKIX profile recommends that subject, if not null, contain
a Directory Name; and that an email address, if present, be in
subjectAltName.

Rather than require an email address in the certificate, and require the
matching of the email address and header information, I think that when a
signature is declared valid, it is essential to present the owner names
bound into the certificate, because it is from the certificate owner that
the message originated, 

regardless of what is in the header of the message. This allows the
choice of how to 

present the owner name in the certificate, where email address is only
one of the possible choices.

I recommend that the end of section 3.1 should read something like:

"End-entity certificates MAY contain an Internet mail address as
described in [RFC-822]. The address must be an "addr-spec" as defined in
Section 6.1 of thatspecification. If present, it SHOULD be in the
subjectAltName field.

Receiving agents MUST recognize email addresses in the subjectAltName
field. Sending gents MAY make the address in the From header in a mail
message match an Internet mail address in the signer's certificate.
Receiving agents MAY check that the address in the From header of a mail
message matches an Internet mail address in the signer's certificate. 

The signature validation function MUST make available the subject and
subjectAltName when it reports a successful signature validation; the
client receiving and presenting the results of the validation SHOULD
present these names."

This allows both human users and automated processes to make their own
judgement as to validity based on the bound names.

Note also that I have not specified any name processing for sending
agents processing encryption certificates. It seems reasonable to inform
a user about the owners of the certificates actually being used (as
opposed to whom the message is addressed), but because of the unlimited
number of recipients allowed, this could get very cumbersome. 

Section 3.2 no longer requires an email address in a certificate. It
would read:

"3.2 Required Name Attributes

Receiving agents MUST support parsing of zero, one, or more instances of
each of the following set of name attributes within the Distinguished
Names in certificates.

Guidelines for the inclusion, omission, and ordering of the name
attributes during the creation of a distinguished name will most likely
be dictated by the policies associated with the certification service
that will certify the corresponding name and public key.

CountryName

StateOrProvinceName

Locality

CommonName

Title

Organization

OrganizationalUnit

StreetAddress

PostalCode

PhoneNumber

EmailAddress

All attributes other than EmailAddress are described in X.520 [X.520].
EmailAddress is an IA5String that can have multiple attribute values."

Elliott Ginsburg

MITRE Corporation

Elliott N Ginsburg

From: Trevor Freeman <[email-masked]>
To: "'Tim Dean'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: S/MIME counter-signature: comment and question
Date: Tue, 16 Dec 1997 10:13:12 -0800
Sender: [email-masked]

Tim,
If you want to show unequivocally you sent the message then you construct a
new signing data layer with the existing data nested within, rather than add
a new signer info block to the existing signed. If you want to know the
sequence a series of parallel signatures where constructed then use time to
differentiate the signatures.
Trevor

> -----Original Message-----
> From:	Tim Dean [SMTP:[email-masked]]
> Sent:	16 December, 1997 7:45 AM
> To:	[email-masked]'
> Subject:	S/MIME counter-signature: comment and question
> 
> CMS-01.txt states (section 5.3) that countersigning can be done by
> including a PKCS#9 countersignature attribute as an unauthenticated
> attribute. Looking at CounterSignature in PKCS#9, it specifies that it is
> what is signed is 'the contents octets of the DER encoding of the
> encryptedDigest field of the SignerInfo value with which the attribute is
> associated.'  However, it seems that the encryptedDigest attribute has
> been removed from SignerInfo in CMS-01, though it is in PKCS#7.  Is this
> an inconsistency or have I missed something? 
> 
> A related question: As a receiver, how do I tell who sent an S/MIME
> message in the case where there are multiple signatures (or
> countersignatures) on it. How can I be prevented as a sender from getting
> someone to parallel-sign or counter-sign my S/MIME document, sending it
> out as a mail message, and claiming it was they who sent it (e.g. by
> putting their E-mail address in the From: field).  Thoughts?
> 
> Tim
> 
>  
> -----------------------------------------------
> Tim Dean
> -----------------------------------------------
>  (Standard Disclaimer applies)
> 
> 
> 

To: Tim Dean <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: S/MIME counter-signature: comment and question
From: EKR <[email-masked]>
Date: 16 Dec 1997 08:23:04 -0800
Lines: 41
Sender: [email-masked]

Tim, please try to keep your line length down to below 80 characters.

Tim Dean <[email-masked]> writes:
> CMS-01.txt states (section 5.3) that countersigning can be done by
> including a PKCS#9 countersignature attribute as an unauthenticated
> attribute. Looking at CounterSignature in PKCS#9, it specifies that
> it is what is signed is 'the contents octets of the DER encoding of
> the encryptedDigest field of the SignerInfo value with which the
> attribute is associated.'  However, it seems that the
> encryptedDigest attribute has been removed from SignerInfo in
> CMS-01, though it is in PKCS#7.  Is this an inconsistency or have I
> missed something?
I believe this should say 'signatureValue' rather than 
'encryptedDigest'. 

> A related question: As a receiver, how do I tell who sent an S/MIME
> message in the case where there are multiple signatures (or
> countersignatures) on it. How can I be prevented as a sender from
> getting someone to parallel-sign or counter-sign my S/MIME document,
> sending it out as a mail message, and claiming it was they who sent
> it (e.g. by putting their E-mail address in the From: field).
> Thoughts?
Well, countersignature is not a problem since you're signing the
cryptographic signature, not the message text. MUAs (and by extension,
users) shouldn't treat a countersignature the same as a message
signature.

Parallel signatures are a harder problem. You could imagine having some
attribute that says 'I'm signing this, but I didn't write it'
but since we don't have a really clear definition of what a document
with multiple signatures means in the first place, this seems a bit
premature. I'd say that if you want to add your signature
to something but don't want to be confused with the sender, you
should use countersignature.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

From: Tim Dean <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME counter-signature: comment and question
Date: Tue, 16 Dec 1997 15:44:36 -0000
Sender: [email-masked]

CMS-01.txt states (section 5.3) that countersigning can be done by =
including a PKCS#9 countersignature attribute as an unauthenticated =
attribute. Looking at CounterSignature in PKCS#9, it specifies that it =
is what is signed is 'the contents octets of the DER encoding of the =
encryptedDigest field of the SignerInfo value with which the attribute =
is associated.'  However, it seems that the encryptedDigest attribute =
has been removed from SignerInfo in CMS-01, though it is in PKCS#7.  Is =
this an inconsistency or have I missed something?=20

A related question: As a receiver, how do I tell who sent an S/MIME =
message in the case where there are multiple signatures (or =
countersignatures) on it. How can I be prevented as a sender from =
getting someone to parallel-sign or counter-sign my S/MIME document, =
sending it out as a mail message, and claiming it was they who sent it =
(e.g. by putting their E-mail address in the From: field).  Thoughts?

Tim

=20
-----------------------------------------------
Tim Dean
-----------------------------------------------
 (Standard Disclaimer applies)

Date: Sat, 06 Dec 1997 14:51:30 -0500
To: Tim Dean <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME Working Group Session Agenda
Cc: [email-masked]
Sender: [email-masked]

Here is the agenda for the session from 1300 to 1500 on Wednesday.  We eill
be in the Hampton room.  See y'all there....

Russ

- - - - 

1300   Introductions			Russ Housley
1305   CMS Draft Discussion		Russ Housley
1325   MSG Draft Discussion		Blake Ramsdell
1345   CERT Draft Discussion		Blake Ramsdell
1405   ESS Draft Discussion		Paul Hoffman
1425   CRS Draft Discussion		Mike Myers
1445   Add CRS to Charter?		Russ Housley
1450   Interoperability Discussion	Tim Dean
1500   Adjourn

Date: Thu, 04 Dec 1997 17:49:48 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Carlisle Adams <[email-masked]>
CC: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: draft-ietf-smime-crs-00.txt
Sender: [email-masked]

Carlisle Adams wrote:
> 
> Hi Blake,
> 
> >----------
> >From:  Blake Ramsdell[SMTP:[email-masked]]
> >Sent:  Thursday, December 04, 1997 3:46 AM
> >To:    [email-masked]'; [email-masked]'
> >Subject:       RE: draft-ietf-smime-crs-00.txt
> >
> >If there are problems with CMP then we should fix them.  Coming up with
> >a new protocol is fun, but I think it fragments the effort.  I will read
> >the CRS spec more closely to find out what the differences are, but I
> >think that CMP can be fixed to satisfy our needs.  From my
> >understanding, CMP is in last call, but I really think we should fix it
> >right, and I think that "right" means fixing CMP if it is broken and
> >can't be used for S/MIME.
> 
> PKIX-CMP is actually past both WG and IETF-wide Last Call; it is
> currently pending IESG vote at their next teleconference (which will
> take place shortly after Washington, I believe).
> 
> I don't know of anything that would make CMP unsuitable for S/MIME, but
> please do have a look and let me know as soon as possible.  If you find
> anything within the next few days we may be able to get changes in
> (providing that it doesn't affect PKIX understanding/use of the
> protocol, of course).
> 
> See you in Washington!
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------

Does CMP being in the "currently pending IESG vote" stage mean
that the PKIX standard version that mixes ANY DEFINED BY and 
BMPString to create invalid ASN.1 definitions is to approved
as a standard? 

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-smime-crs-00.txt
Date: Thu, 4 Dec 1997 10:07:02 -0500
Sender: [email-masked]

Hi Blake,

>----------
>From: 	Blake Ramsdell[SMTP:[email-masked]]
>Sent: 	Thursday, December 04, 1997 3:46 AM
>To: 	[email-masked]'; [email-masked]'
>Subject: 	RE: draft-ietf-smime-crs-00.txt
>
>If there are problems with CMP then we should fix them.  Coming up with
>a new protocol is fun, but I think it fragments the effort.  I will read
>the CRS spec more closely to find out what the differences are, but I
>think that CMP can be fixed to satisfy our needs.  From my
>understanding, CMP is in last call, but I really think we should fix it
>right, and I think that "right" means fixing CMP if it is broken and
>can't be used for S/MIME.

PKIX-CMP is actually past both WG and IETF-wide Last Call; it is
currently pending IESG vote at their next teleconference (which will
take place shortly after Washington, I believe).

I don't know of anything that would make CMP unsuitable for S/MIME, but
please do have a look and let me know as soon as possible.  If you find
anything within the next few days we may be able to get changes in
(providing that it doesn't affect PKIX understanding/use of the
protocol, of course).

See you in Washington!

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: draft-ietf-smime-crs-00.txt
Date: Thu, 4 Dec 1997 00:46:55 -0800
Sender: [email-masked]

On Tuesday, December 02, 1997 7:07 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> 
> If this working group takes on this task, (I think it would be more
> appropriate within the PKIX WG, but like Mike, don't have any strong
> objection to pursuing it here - many of the participants are members
> of both groups), then it MUST ensure that the result is compatible
> with PKIX, not an independent and incompatible protocol based on
> straight unmodified PKCS#10.

I agree.  This whole thing has caught me kind of off guard as a behind
the scenes effort.  I am still trying to sort out the spec and figure
out what exactly can't be accomplished with existing protocols
(specifically CMP) by constraining those protocols to fit in our
profile, and/or modifying them to fix any shortcomings that make them
unsuitable for our profile (non-persistent connections, etc.)

> Note the key last sentence - "an interpretation of PKIX-3 messages over
> PKCS7".  This means that any usage of PKCS#10 certificate requests MUST
> be in the form of PKIX-3 "p10cr" messages, in order to allow implementors
> to quickly develop "Basic functionality" certificate request messages
> based on existing technology, while remaining compatible with, and allowing
> smooth migration to, the "Full functionality" (and more difficult to
> implement) CMP.

I agree, and this option was discussed in an earlier thread also I
believe.

> If this WG adds a certificate request work item to it's charter, it
> should be clearly stated that the result must be compatible with
> PKIX CMP, not an independent, non-interoperable syntax based on raw
> PKCS#10.

If there are problems with CMP then we should fix them.  Coming up with
a new protocol is fun, but I think it fragments the effort.  I will read
the CRS spec more closely to find out what the differences are, but I
think that CMP can be fixed to satisfy our needs.  From my
understanding, CMP is in last call, but I really think we should fix it
right, and I think that "right" means fixing CMP if it is broken and
can't be used for S/MIME.

There may certainly be issues and forces at work here that I don't
understand, and someone should feel free to correct me if I am too
unenlightened to see the value in having a separate incompatible
specification instead of a profile constraint on (potentially modified)
PKIX CMP.

Blake

Date: Thu, 04 Dec 1997 00:37:10 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: Gunther Schadow <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 15:54 30/11/97 -0800, David Sternlight wrote:

>[...] For instance it is
>mutually exclusive to allow anyone to be a signer and to allow only those
>meeting certain standards to be signers.

Leaving aside, for the moment, any reference to any particular system:  is
this necessarily true?

I can imagine a system in which the signature itself may carry an
authority.  So those signers meeting certain standards may supply a
credential (as part of the signature) which is verifiable using a public
key of the body which set those standards.

But as a non-expert in this field, I may be missing something.

GK.
---

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

Date: Wed, 3 Dec 1997 16:36:05 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: S/MIME v3 Cert Handling Comments
Sender: [email-masked]

Blake (and friends),

I have the following comments to the 20 Nov 97 S/MIME v3 Certificate
Handling specification.

In general, I believe that we should at least mention Attribute Certificates
(AC) in the spec since they are included in the CMS CertificateChoices
syntax.  I don't believe that we need to solve every problem regarding
validating ACs, but we should at least make some statements regarding their
use.  The following comments included some specific recommendations
regarding ACs and other topics:

1) Sec 1.1: Please add the following text (some of the following text that
was paraphrased from the X.509 spec): "Attribute Certificate (AC): An X.509
AC is a separate structure from a subject's public key X.509 Certificate.  A
subject may have multiple X.509 ACs associated with each of its public key
X.509 Certificates.  Each X.509 AC binds a SEQUENCE OF Attributes with one
of the subject's public key X.509 Certificates.  The X.509 AC syntax is
defined in [X.509]" 

2) Sec 2.2: Please add as last sent: "Receiving agents SHOULD support X.509
ACs."

3) Sec 2.3: Please add as last para (some of the following text that was
paraphrased from the X.509 spec): "Receiving agents SHOULD support X.509
ACs.  At a minimum, receiving agents SHOULD at least support the decoding of
X.509 ACs.  Please note that there is no requirement that the same CA create
both the public key X.509 Certificate and X.509 AC(s) for a user.  Each
organization's local policy will define how X.509 ACs are validated and
used.  The implications of performing multiple certification path
validations should be considered when defining local policy.  Exchanges
between a subject and the CA dealing with the generation of X.509 ACs are
outside the scope of this specification." 

4) Sec 5.2: Section 5.2 strongly implies that S/MIME v3 agents must use PKCS
#10 to request certificates. IHMO, this is a significant issue that needs to
be debated further.  The issue is should the Spec discuss using PKCS #10,
PKIX CMP or some other variant?  Or should the topic of requesting
certificates be included in a separate document such as a PKIX document?

5) Sec 5.2, 3rd para:  Please replace with: "Receiving agents MUST support
the identification of a DSA key with the id-dsa OID and related syntaxes
defined in [KEYM].  Receiving agents MUST support the identification of a DH
key with the dhpublicnumber OID and related syntaxes defined in [KEYM].  CAs
MUST support id-dsa-with-sha1 as defined in [KEYM] for verification of
signatures on certificate requests as described in [SMIME-MSG].

Receiving agents SHOULD support the identification of an RSA key with the
rsa defined in X.509 and the rsaEncryption OID. CAs SHOULD support
sha-1WithRSAEncryption and md5WithRSAEncryption and SHOULD support
md2WithRSAEncryption for verification of signatures on certificate requests
as described in [SMIME-MSG]."

6) Sec 5.3: Please replace with: "CAs SHOULD use the id-dsa-with-sha1
signature algorithms when signing certificates.  CAs may use the
sha-1WithRSAEncryption signature algorithms when signing certificates."

7) Sec A.7: The most recent definition of KeyUsage extension defines bits 7
and 8 as encipherOnly and decipherOnly, respectively.  The cert spec needs
to address the usage (or non-usage) of these bits.

8) App B: Add reference for CMS.

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

Date: Wed, 3 Dec 1997 16:16:14 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: More 11/20/97 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

Blake (and friends),

Here is another comment to the "20 Nov 97 S/MIME Version 3 Message
Specification".

1) Sec H: "Need OIDs for DH"  PKIX X.509 Certificate and CRL Profile, sec
7.3.2 defines the use of the dhpublicnumber OID for DH keys in X.509 Certs
as follows:

"7.3.2 Diffie-Hellman Key Exchange Key

   This diffie-hellman object identifier supported by this standard is
   defined by ANSI X9.42.

        dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                  us(840) ansi-x942(10046) number-type(2) 1 }

   The dhpublicnumber object identifier is intended to be used in the
   algorithm field of a value of type AlgorithmIdentifier. The
   parameters field of that type, which has the algorithm-specific
   syntax ANY DEFINED BY algorithm, would have ASN.1 type DHParameter
   for this algorithm.

        DHParameter ::= SEQUENCE {
          prime INTEGER, -- p
          base INTEGER, -- g }

   The fields of type DHParameter have the following meanings:

      prime is the prime p.

      base is the base g.

   The Diffie-Hellman public key (an INTEGER) is mapped to a
   subjectPublicKey (a BIT STRING) as follows: the most significant bit
   (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least
   significant bit (LSB) of the INTEGER becomes the LSB of the BIT
   STRING.

   If the keyUsage extension is present in a certificate which conveys a
   DH public key, the following values may be present:

      keyAgreement;
      encipherOnly; and
      decipherOnly.

   At most one of encipherOnly and decipherOnly shall be asserted in
   keyUsage extension."

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

Date: Wed, 03 Dec 1997 13:53:03 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 Receipt Requests
Cc: "'IETF S/MIME'" <[email-masked]>
Sender: [email-masked]

Scott:

I agree with you.  The authenticated attribute should be absent if no
receipts are desired.  To this end, the "none" option should be removed.

Given that, the "allOrNone" name should be changed....

Russ

At 04:17 AM 11/21/97 PST, Scott Hollenbeck wrote:
>I think we have a situation with our current receipt request
>syntax that leads to a bit of extra complexity.  Here's the
>issue:
>
>Suppose a message creator does not request a signed receipt.
>Using the current syntax there are two ways to indicate this
>desire:
>
>1. Do not include a receiptRequest attribute, or
>2. Add a receiptRequest attribute, setting the value
>of receiptsFrom->allOrNone to noReceipt.
>
>In the MSP world we don't have the luxury of option number
>1, so we used the noReceipt value to indicate that a receipt
>isn't requested.  I don't think we need to support a noReceipt
>value in S/MIME to indicate that a receipt isn't requested
>because option #1 provides a clearer and easier to process
>mechanism.
>
>Having made that argument, I propose that we alter the ESS
>syntax as follows:
>
>ReceiptsFrom ::= CHOICE {
>  allOrFirstTier  [0] AllOrFirstTier, -- formerly "allOrNone [0]AllOrNone",
>  receiptList     [1] SEQUENCE OF GeneralNames }
>
>AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
>-- Remove noReceipt and move the other values up by one.
>  allReceipts          (0),
>  firstTierRecipients  (1) }
>
>Thoughts?
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>

Date: Wed, 03 Dec 1997 14:26:10 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: SigningTime
Cc: [email-masked]
Sender: [email-masked]

Phil:

I understand your concern, but I do not plan to change the OID.

PKIX Part 1 changed the notBefore and notAfter syntax in exactly the same
way.  And, the version number was not changed.  In fact, I think that
X.509is picking up the PKIX syntax.

Implementations have 52 years to be ready for the new syntax.  I do not
think that will cause an interoperabilty problem.  [Or, if it does, we will
all be retired.]

Russ

At 04:38 PM 11/13/97 -0500, Phillip H. Griffin wrote:
>Since the proposed choice type SigningTime will be a different
>type that that defined by RSA in PKCS #9, will there be a new
>S/MIME OID assigned to this type?
>
>John Pawling wrote:
>> 
>> All,
>> 
>> I now agree with Dave and Blake's original argument that the SigningTime
>> should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
>> Dave's point that it is straightforward for the decoding software to
examine
>> the Tag field of the SigningTime to determine if the time is encoded as a
>> UTCTime or GeneralizedTime.
>> 
>> In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be
copied
>> to an IETF-controlled S/MIME-related spec.  When that happens, the
>> SigningTime needs to be changed to the following syntax:
>> 
>> CHOICE {
>>   utcTime           UTCTime,
>>   generalizedTime   GeneralizedTime }
>> 
>> I assume that we want to adopt text similar to PKIX I such as:
>> 
>> When encoding the SigningTime attribute, sending agents MUST encode dates
>> through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
>> GeneralizedTime.
>> 
>> - John Pawling
>> 
>> At 12:51 PM 11/13/97 -0500, David P. Kemp wrote:
>> >> From: "Blake Ramsdell" <[email-masked]>
>> >>
>> >> > Constructing the ChoiceOfTime is the easy part.  My point is that
it adds
>> >> > complexity to the SignedData decoding software that must determine
which
>> >> > choice was chosen.  For example, in 2051, our code will need to be
able to
>> >> > decode stored SignedData objects some of which include SigningTime
with
>> >> > UTCTime choice and others that include SigningTime with
GeneralizedTime
>> >> > choice.  Sure, there are ways of determining which choice was
chosen, but
>> >> > the OID check for the signingTime or NewSigningTime attributes
would be
>> >> > quicker and easier.
>> >>
>> >> I understand.  Point taken.
>> >>
>> >> > In the signingTime or NewSigningTime attributes environment, you
could use
>> >> > an equivalent strategy to ensure backwards compatibility by
including the
>> >> > signingTime (UTCTime) attribute in SignedData objects generated
thru the
>> >> > year 2049 and including newSigningTime (GeneralizedTime) in SignedData
>> >> > objects generated on 2050 or after.  Using this strategy, in 2051,
the
>> >> > software can easily determine which flavor of signing time was
included
>> in a
>> >> > SignedData object simply by examining the attribute OID.
>> >>
>> >> Yup -- I agree with this.  This does sound better.
>> >
>> >
>> >I agree with the goal of reducing complexity, but I believe having two
>> >different OIDs is more complex than having only a single OID.
>> >
>> >There are (at least) three ways of determining the encoding of the
>> >SigningTime field:  examining the attribute OID (SigningTime or
>> >NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
>> >or examining the time string itself.  For the 2051 example where either
>> >choice may be present, it's easiest to examine the one byte tag type,
>> >rather than to match against two different attribute OIDs or parse
>> >the time string.
>> >
>> >If Blake & John are now agreed that two attributes are better than one,
>> >I'm not against it.  But IMHO adding a NewSigningTime attribute both:
>> >
>> > * makes the spec uglier (having two different attributes to accomplish
>> >    the identical functionality, just using different syntax), and
>> > * makes the resulting software more complex.
>> >
>
>Phil
>-- 
>Phillip H. Griffin         Griffin Consulting
>[email-masked]        ASN.1-SET-Java-Security
>919.828.7114               1625 Glenwood Avenue
>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>

Date: Wed, 3 Dec 1997 14:38:02 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: 11/20/97 S/MIME V3 Msg Spec Comments
Sender: [email-masked]

Blake (and friends),

Thank you for incorporating some of my comments into the "20 Nov 97 S/MIME
Version 3 Message Specification".  I have the following comments regarding
the 11/20/97 spec:

1) Sec 1.1, sec 3.7: The spec "defines how to create certification requests
that conform to PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for
transporting those requests."  IHMO, this is a significant issue that needs
to be debated further.  The issue is should the Spec discuss using PKCS #10,
PKIX CMP or some other variant?  Or should the topic of requesting
certificates be included in a separate document such as a PKIX document?
 
2) Sec 2.1, DigestAlgorithmIdentifier: Recommend changing to: "Receiving
agents MUST support SHA-1 [SHA1].  Receiving agents SHOULD support MD5 [MD5]
for the purpose of providing backward compatibility with MD5-digested S/MIME
v2 SignedData objects.  Sending agents SHOULD use SHA-1."

3) Sec H, Needed Changes: "Section 2.5.2 Add certs as an
authenticatedAttribute"  What does this mean?

4) Sec H: "What do we need to do for 4.1 in order to make it
Diffie-Hellman?" and "Section 4.1 needs to talk about DSS and DH minimum key
lengths for strong crypto."  I believe that there should be separate
documents describing the use of SHA-1, DSA and DH with the CMS and ESS
specs.  I don't believe that the details of DH key generation need to be
included in the base S/MIME v3 Message Spec.

5) Sec H:  IMHO, the S/MIME v2 Msg Spec Sec 2.6.1-2.6.3 text regarding the
process by which the applications chooses the encryption algorithm to use to
encrypt data was useful and should be reinstated into the S/MIME v3 Msg Spec
with the few text changes required to make RC2 optional and 3DES the default.

6) Sec H: IMHO, the X9.57 spec should be a reference for the id-sha1 and
id-dsa OIDs.  The following should be the reference for the DSA definition:
DIGITAL SIGNATURE STANDARD (DSS), FEDERAL INFORMATION PROCESSING STANDARDS
PUBLICATION (FIPS PUB) 186, 1994 May 19 published by the U.S. DEPARTMENT OF
COMMERCE/National Institute of Standards and Technology. (PDF and PostScript
versions are available from
http://www.armadillo.huntsville.al.us/Fortezza_docs/basic.html)

7) Sec H: "Is id-dsa the correct OID to use for
DigestEncryptionAlgorithmIdentifier?"  IMHO, yes (with parameters always
absent).

8) Sec H: "Is section 4.1 worded correctly?" IMHO, yes.

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

Date: Wed, 03 Dec 1997 09:53:25 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: Scott Hollenbeck <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MSG-00 Signing-Time Attribute
Sender: [email-masked]

Russ Housley wrote:
> 
> I'll meet you half way.  I am concerned about importing from that
> specification since it does not use the 1988 ASN.1.
> 
> Russ
> 

I think that ignoring current standards work is just a bad idea in
general, whether it's ASN.1, PKCS #7, or June '97 X.509. Too many
disbenefits just to use ANY DEFINED BY. The current ASN.1 standards 
contain corrections to numerous defects that must be assumed to 
still exist in 1988 (http://www.furniss.co.uk/maint/maintop.htm).
Does using the ASN.1:1988 defects help promote interoperability?

I prefer the following language from the current X.509, that the
authors included with their ASN.1 definition. If all of the ASN.1
types referenced in the ASN.1 definition in X.509x97 are also
defined in X.208:1988 then they can be used by SMIME:88. (Not sure 
if GeneralizedTime is part of 1988 or not. It is in 1990.) 

  "Before a value of Time is used in any comparison operation, e.g. 
  as part of a matching rule in a search, and if the syntax of Time 
  has been chosen as the UTCTime type, the value of the two digit 
  year field shall be rationalized into a four digit year value as 
  follows:

  - If the 2 digit value is 00 through 49 inclusive, the value 
    shall have 2000 added to it.
  - If the 2 digit value is 50 through 99 inclusive, the value 
    shall have 1900 added to it.

  Note - The use of GeneralizedTime may prevent interworking with 
  implementations unaware of the possibility of choosing either 
  UTCTime or GeneralizedTime. It is the responsibility of those 
  specifying the domains in which certificates defined in this 
  Directory Specification will be used, e.g. profiling groups, as 
  to when the GeneralizedTime may be used. In no case shall UTCTime 
  be used for representing dates beyond 2049."

I see no reason for SMIME to have different rules for handling 
type Time than X.509 specifies. It would seem a burden for 
implementors to have more than one handling mechanism.

Phil

> At 10:58 AM 12/2/97 PST, Scott Hollenbeck wrote:
> >Russ,
> >
> >The June '97 ITU-T X.509 recommendation includes this definition:
> >
> >Time ::= CHOICE {
> >  utcTime          UTCTime,
> >  generalizedTime  GeneralizedTime }
> >
> >which is used for the notBefore and notAfter values within the X.509
> >certificate validity period.  Could you just import this definition
> >and define SigningTime as follows:
> >
> >SigningTime ::= Time
> >
> >We're already importing the Certificate definition, and I think it
> >makes sense to reuse this Time definition instead of defining a new,
> >identical type for SigningTime.
> >
> >Scott
> >
> >-----Original Message-----
> >From:  Russ Housley [SMTP:[email-masked]]
> >Sent:  Monday, December 01, 1997 2:59 PM
> >To:    Scott Hollenbeck
> >Cc:    [email-masked]
> >Subject:       Re: MSG-00 Signing-Time Attribute
> >
> >I am in the process of adding PKCS#9 attributes that are needed for secure
> >e-mail to the CMS document.  In the process, I fixed the syntax.  here is
> >what I did:
> >
> >10.3  Signing Time
> >
> >The signing-time attribute type specifies the time at which the signer
> >(purportedly) performed the signing process. The signing-time attribute
> >type is intended for use in signed-data.
> >
> >The signing-time attribute is identified by the following object identifier:
> >
> >   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> >       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
> >
> >Signing-time attribute values have ASN.1 type SigningTime:
> >
> >SigningTime ::= CHOICE {
> >  utcTime UTCTime,
> >  generalTime GeneralizedTime }
> >
> >Dates through the year 2049 must be encoded as UTCTime, and dates in the
> >year 2050 or later must be encoded as GeneralizedTime.
> >
> >A signing-time attribute must have a single attribute value.
> >
> >No requirement is imposed concerning the correctness of the signing time,
> >and acceptance of a purported signing time is a matter of a recipient's
> >discretion. It is expected, however, that some signers, such as time-stamp
> >servers, will be trusted implicitly.
> >
> >
> >Russ
> >
> >At 05:42 AM 12/1/97 PST, Scott Hollenbeck wrote:
> >>In section 2.5.1 of the S/MIME v3 Message Specification, it states
> >>that "Sending agents MUST encode signing time through the year 2049
> >>as UTCTime; signing times in 2050 or later MUST be encoded as
> >>GeneralizedTime".  However, the current PKCS #9 syntax for the
> >>signingTime attribute doesn't support a choice:
> >>
> >>SigningTime ::= UTCTime
> >>
> >>If an updated definition is available somewhere, where is it?
> >>The document doesn't include a reference for attribute definitions.
> >>If an updated definition hasn't been proposed, how about this:
> >>
> >>SigningTime ::= CHOICE {
> >>  utcTime           UTCTime,  -- for years 2049 and earlier
> >>  generalizedTime   GeneralizedTime -- for years 2050 and later -- }
> >>
> >>----->
> >>Scott Hollenbeck (mailto: [email-masked])
> >>Xerox Special Information Systems
> >>Arlington, Virginia, USA
> >>
> >

-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 3 Dec 1997 07:28:36 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
cc: Tony Mione <[email-masked]>
Subject: PGP Implementor's survey : First results snapshot available
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

	I have compiled the surveys returned to me so far. You can find the
results from my web page (look for 'IETF involvment') or go directly to the
survey page:

http://www-ns.rutgers.edu/~mione/openpgp/

	I will be updating the page regularly (I am hoping to do this on at
least a weekly basis).

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B  0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report   ***** Important: John 17:3 *****

Date: Tue, 02 Dec 1997 16:51:49 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: MSG-00 Signing-Time Attribute
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

I'll meet you half way.  I am concerned about importing from that
specification since it does not use the 1988 ASN.1.

Russ

At 10:58 AM 12/2/97 PST, Scott Hollenbeck wrote:
>Russ,
>
>The June '97 ITU-T X.509 recommendation includes this definition:
>
>Time ::= CHOICE {
>  utcTime          UTCTime,
>  generalizedTime  GeneralizedTime }
>
>which is used for the notBefore and notAfter values within the X.509
>certificate validity period.  Could you just import this definition
>and define SigningTime as follows:
>
>SigningTime ::= Time
>
>We're already importing the Certificate definition, and I think it
>makes sense to reuse this Time definition instead of defining a new,
>identical type for SigningTime.
>
>Scott
>
>-----Original Message-----
>From:	Russ Housley [SMTP:[email-masked]]
>Sent:	Monday, December 01, 1997 2:59 PM
>To:	Scott Hollenbeck
>Cc:	[email-masked]
>Subject:	Re: MSG-00 Signing-Time Attribute
>
>I am in the process of adding PKCS#9 attributes that are needed for secure
>e-mail to the CMS document.  In the process, I fixed the syntax.  here is
>what I did:
>
>10.3  Signing Time
>
>The signing-time attribute type specifies the time at which the signer
>(purportedly) performed the signing process. The signing-time attribute
>type is intended for use in signed-data.
>
>The signing-time attribute is identified by the following object identifier:
>
>   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
>       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
>
>Signing-time attribute values have ASN.1 type SigningTime:
>
>SigningTime ::= CHOICE {
>  utcTime UTCTime,
>  generalTime GeneralizedTime }
>
>Dates through the year 2049 must be encoded as UTCTime, and dates in the
>year 2050 or later must be encoded as GeneralizedTime.
>
>A signing-time attribute must have a single attribute value.
>
>No requirement is imposed concerning the correctness of the signing time,
>and acceptance of a purported signing time is a matter of a recipient's
>discretion. It is expected, however, that some signers, such as time-stamp
>servers, will be trusted implicitly.
>
>
>Russ
>
>At 05:42 AM 12/1/97 PST, Scott Hollenbeck wrote:
>>In section 2.5.1 of the S/MIME v3 Message Specification, it states
>>that "Sending agents MUST encode signing time through the year 2049
>>as UTCTime; signing times in 2050 or later MUST be encoded as
>>GeneralizedTime".  However, the current PKCS #9 syntax for the
>>signingTime attribute doesn't support a choice:
>>
>>SigningTime ::= UTCTime
>>
>>If an updated definition is available somewhere, where is it?
>>The document doesn't include a reference for attribute definitions.
>>If an updated definition hasn't been proposed, how about this:
>>
>>SigningTime ::= CHOICE {
>>  utcTime           UTCTime,  -- for years 2049 and earlier
>>  generalizedTime   GeneralizedTime -- for years 2050 and later -- }
>>
>>----->
>>Scott Hollenbeck (mailto: [email-masked])
>>Xerox Special Information Systems
>>Arlington, Virginia, USA
>>
>

From: Scott Hollenbeck <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: MSG-00 Signing-Time Attribute
Date: Tue, 2 Dec 1997 10:58:10 PST
Sender: [email-masked]

Russ,

The June '97 ITU-T X.509 recommendation includes this definition:

Time ::= CHOICE {
  utcTime          UTCTime,
  generalizedTime  GeneralizedTime }

which is used for the notBefore and notAfter values within the X.509
certificate validity period.  Could you just import this definition
and define SigningTime as follows:

SigningTime ::= Time

We're already importing the Certificate definition, and I think it
makes sense to reuse this Time definition instead of defining a new,
identical type for SigningTime.

Scott

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Monday, December 01, 1997 2:59 PM
To:	Scott Hollenbeck
Cc:	[email-masked]
Subject:	Re: MSG-00 Signing-Time Attribute

I am in the process of adding PKCS#9 attributes that are needed for secure
e-mail to the CMS document.  In the process, I fixed the syntax.  here is
what I did:

10.3  Signing Time

The signing-time attribute type specifies the time at which the signer
(purportedly) performed the signing process. The signing-time attribute
type is intended for use in signed-data.

The signing-time attribute is identified by the following object identifier:

   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Signing-time attribute values have ASN.1 type SigningTime:

SigningTime ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime }

Dates through the year 2049 must be encoded as UTCTime, and dates in the
year 2050 or later must be encoded as GeneralizedTime.

A signing-time attribute must have a single attribute value.

No requirement is imposed concerning the correctness of the signing time,
and acceptance of a purported signing time is a matter of a recipient's
discretion. It is expected, however, that some signers, such as time-stamp
servers, will be trusted implicitly.

Russ

At 05:42 AM 12/1/97 PST, Scott Hollenbeck wrote:
>In section 2.5.1 of the S/MIME v3 Message Specification, it states
>that "Sending agents MUST encode signing time through the year 2049
>as UTCTime; signing times in 2050 or later MUST be encoded as
>GeneralizedTime".  However, the current PKCS #9 syntax for the
>signingTime attribute doesn't support a choice:
>
>SigningTime ::= UTCTime
>
>If an updated definition is available somewhere, where is it?
>The document doesn't include a reference for attribute definitions.
>If an updated definition hasn't been proposed, how about this:
>
>SigningTime ::= CHOICE {
>  utcTime           UTCTime,  -- for years 2049 and earlier
>  generalizedTime   GeneralizedTime -- for years 2050 and later -- }
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>

Date: Tue, 02 Dec 1997 09:24:42 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Antonio Mana Gomez wrote:

> 
>    You mean that we should be glad that the company that produced the
> browser has saved us the effort of finding who to trust, registering,
> configuring and all those tedious procedures? 

<much more of the same excised>

Let me cut through all the rhetoric with two simple analogies. They are
intended to be heuristic, not syllogistic. Hopefully they will close this
sub-discussion. 

1. Web of trust is like trusting a friend, without which personal relations
would be difficult. People aren't going to get a Visa logo on their foreheads
for this. Open PGP developers should, I assert, focus on maximizing their
model's efficiency and ease of use for this model and not try to move further
to a mixed model.

2. Rigid hierarchical is like the major credit card certifiers, without which
effective transaction systems at scale would be difficult. People aren't going
to roll their own credit cards for this. S/MIME 3 developers should, I assert,
focus on maximizing their model's efficiency and ease of use for this model
and not try to move further to a mixed model.

Each has its place. Corrupting either leads to its losing some of its unique
advantages. For instructive details consult any good text on the evolution of
national banking systems, or the appropriate chapters in introductory
economics texts.

David

From: Scott Hollenbeck <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: ESS-00 ContentHints and Signed Receipt Hashing
Date: Tue, 2 Dec 1997 08:09:12 PST
Sender: [email-masked]

I agree with John's recommendations.

Scott

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Tuesday, December 02, 1997 10:34 AM
To:	Scott Hollenbeck; 'Russ Housley'
Cc:	[email-masked]
Subject:	RE: ESS-00 ContentHints and Signed Receipt Hashing

Scott and Russ,

IMHO, when contentDescription is present and receipt is FALSE, then the
contentHints attribute does not necessarily need to be authenticated.  I
believe that the ESS spec should continue to include the flexibility to
support that option.

If contentHints includes receipt set to TRUE, then it needs to be
authenticated.  However, this is a problem with the current ESS spec because
it does not include the authenticatedAttributes in the data to be hashed to
calculate the signature value for the SignedData/Receipt, so it is
impossible to inlcude an authenticated contentHints in a SignedData/Receipt.
Therefore,  I believe that Section 2.4 of ESS should be changed so that it
includes hashing the authenticatedAttributes included in the SignerInfo
containing the receipt signature value included in the SignedData/Receipt.
This allows the recipient of a signedData/Receipt to verify the authenticity
of the authenticatedAttributes such as contentHints, signingTime, etc.  If
people agree with this recommendation then I could draft a new section 2.4
that is similar to the CMS text for hashing either the content or content
with authenticatedAttributes.

- John Pawling

Reply-To: James M Galvin <[email-masked]>
To: Colin Robbins <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Steve Crocker'" <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? 
Date: Tue, 02 Dec 1997 10:59:05 -0500
From: James M Galvin <[email-masked]>
Sender: [email-masked]

On Tue, 02 Dec 1997 10:30:29 GMT, Colin Robbins said (and I quote):

    This suggests the choice between S/MIME and MOSS is being made on
    the basis of what is easy to implement.  This is never a good
    argument to use, as it loses sight of one major consideration - the
    users.

    Any choice ought to be focusing on what the users - at the end of
    the day our customers - will find integrates into the desktop
    environment in the simplest and cleanest way.  My understanding is
    this debate suggests this is a MOSS based approach.

Funny you should say this.  I agree with the conclusion but not how you
got there.

In the debate over X.400, PEM, PGP, MOSS, MSP, or S/MIME, one
observation I like to make is that the user doesn't care what you
choose.  Frankly, all these protocols provide the security services of
the greatest interest to users.  Further, all these protocols could be
made to support the trust model of your choice and the algorithms of
your choice.  (Some may have made policy choices in these areas but
those choices could be changed!)  It just doesn't matter.

What the user cares about is interoperability, i.e., when I send you a
secure email message you can process it.  This is problematic given so
many choices.  That is the problem!

The differences in these protocols are in the implementation.  Only
developers care about the differences in these protocols (setting aside
politics).  Each of these protocols requires a different amount of
effort to be integrated with various email clients and applications, as
well as other applications, e.g., the web.  Each of these protocols made
different design choices based on different assumptions and
requirements.  It is these things we should be evaluating in our quest
to make a choice.

On the issue of deployment, it's nice that S/MIME is integrated with
Netscape/Microsoft.  I suspect it will get a certain market share
because of this.  But let us not forget there are a lot more email user
agents out there than just Microsoft/Netscape.  And many of them are far
better than Microsoft/Netscape (although probably not for long).  S/MIME
is not going to just slip in to that market.

Jim
--
James M. Galvin                       Executive Director, Trust and Security
CommerceNet Consortium                +1 410.203.2707
3209A Corporate Court                 +1 410.203.2709 FAX
Ellicott City, MD  21042              http://www.commerce.net

Date: Tue, 2 Dec 1997 10:34:21 -0500
To: Scott Hollenbeck <[email-masked]>, "'Russ Housley'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-00 ContentHints and Signed Receipt Hashing
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Scott and Russ,

IMHO, when contentDescription is present and receipt is FALSE, then the
contentHints attribute does not necessarily need to be authenticated.  I
believe that the ESS spec should continue to include the flexibility to
support that option.

If contentHints includes receipt set to TRUE, then it needs to be
authenticated.  However, this is a problem with the current ESS spec because
it does not include the authenticatedAttributes in the data to be hashed to
calculate the signature value for the SignedData/Receipt, so it is
impossible to inlcude an authenticated contentHints in a SignedData/Receipt.
Therefore,  I believe that Section 2.4 of ESS should be changed so that it
includes hashing the authenticatedAttributes included in the SignerInfo
containing the receipt signature value included in the SignedData/Receipt.
This allows the recipient of a signedData/Receipt to verify the authenticity
of the authenticatedAttributes such as contentHints, signingTime, etc.  If
people agree with this recommendation then I could draft a new section 2.4
that is similar to the CMS text for hashing either the content or content
with authenticatedAttributes.

- John Pawling

Date: Tue, 2 Dec 1997 10:07:11 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: draft-ietf-smime-crs-00.txt
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> >At the meeting in Washington, DC, I will ask the attendees whether we
> >should expand the Charter to cover this work.
> 
> I, for one, think it's just fine for this WG to take on this task. Having a
> clear, open revision of PKCS 10 that works with our new certificates is a
> must in my mind.

Paul,

I do not believe that this WG was chartered to "IETF-standardize the
PKCS series".  Instead, it was chartered to define an IETF-standard
messaging protocol based on S/MIME.  We have already agreed that there
needed to be a few changes to PKCS#7 to turn it into the Cryptographic
Message Syntax (CMS).  The issue is whether changes need to be made to
PKCS#10 to make it compatible with the IETF Certificate Management Protocol
(CMP, as described by PKIX part 3).

If this working group takes on this task, (I think it would be more
appropriate within the PKIX WG, but like Mike, don't have any strong
objection to pursuing it here - many of the participants are members
of both groups), then it MUST ensure that the result is compatible
with PKIX, not an independent and incompatible protocol based on
straight unmodified PKCS#10.

The PKIX working group has already considered the PKCS#7/PKCS#10 issue,
and it reached the following conclusion in Munich:

> Date: Thu, 21 Aug 1997 11:58:02 -0700
> To: [email-masked]
> From: Warwick Ford <[email-masked]>
> Subject: PKIX-3 and PKCS7/10
> 
> Folks:
> 
> I believe we are not all on the same page regarding PKIX-3 and PKCS7/10.
> For the benefit, in particular, of those on the list who were not at
> Munich, let me try to summarize where we are, what happened at Munich, and
> where we are going from here. (Given my affiliation, you should probably
> consider this a personal posting - not a statement as Co-Chair.)
> 
>   [lots of explanation snipped]
>
> So, that's where we are.  PKIX-3 appears technically ready to at least be
> issued for WG last call. (Editorial and, possibly, technical improvements
> are not ruled out in the last call stage.)  Proponents of the PKCS
> protection alternative have been encouraged to proceed with the development
> of a PKIX-3 supplement which is an interpretation of PKIX-3 messages over
> PKCS7 (using the Myers et al I-D as a starting point), in conjunction with
> resolving the various technical and administrative issues surrounding PKCS7
> and PKCS10 themselves.
> 
> Hope this helps fill in the picture,
> Warwick

Note the key last sentence - "an interpretation of PKIX-3 messages over
PKCS7".  This means that any usage of PKCS#10 certificate requests MUST
be in the form of PKIX-3 "p10cr" messages, in order to allow implementors
to quickly develop "Basic functionality" certificate request messages
based on existing technology, while remaining compatible with, and allowing
smooth migration to, the "Full functionality" (and more difficult to
implement) CMP.

If this WG adds a certificate request work item to it's charter, it
should be clearly stated that the result must be compatible with
PKIX CMP, not an independent, non-interoperable syntax based on raw
PKCS#10.

Date: Tue, 02 Dec 1997 07:41:56 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: ASN.1 Errors in draft-ietf-smime-crs-00.txt 
Sender: [email-masked]

A quick look at the draft posted yesterday reveals several 
syntax errors.

   - The underscore character '_' is not a legal ASN.1 
     character. All instances of this character should 
     be removed from the ASN.1. Note that dash, '-' is
     a legal character.

   - All instances of "SEQUENCE OF {" are invalid. 

   - Type names should begin with an uppercase letter, so
     type names such as "pkiStatus" and "failInfo" are
     invalid.

   - The "attributes" component of type "CertificationRequest"
     is missing a comma.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Tue, 02 Dec 1997 12:14:34 +0100
From: Antonio Mana Gomez <[email-masked]>
Reply-To: [email-masked]
Organization: Universidad de Málaga (SPAIN)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

--------------E5A56DE0BBF27BFD865EEDB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

___________________________________________________________________
Mon, 01 Dec 1997 10:07:02 -0800
David Sternlight wrote:

> Phillip M Hallam-Baker wrote:
> > ...
> >
> > The only sense in which the built in client certs are in any
> > way special is that the browser company (Microsoft/Netscape)
> > has reviewed their Certification Practices Statement and
> > their operations and determined that their certificates
> > may generally be considered trustworthy. If you disagree
> > with this assement then uncheck the box next to VeriSign,
> > MCI, Thawte etc and you are entirely OK.
>
> This is the point, though I may have expressed it imprecisely. For
> S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
> "Certification Practices Statements" and sets of hardware and software
> standards for CAs. Second of all they are reviewed and only those considered
> trustworthy in general are pre-installed in general-user browsers (as distinct
> from some possible intranet practice). This is a distinct advantage of the
> model, as implemented, for arms-length interaction between strangers.

   You mean that we should be glad that the company that produced the
browser has saved us the effort of finding who to trust, registering,
configuring and all those tedious procedures? Just like Microsoft did,
saving us the effort to select, get and install a WEB browser by
including Explorer in the Windows package?. Of course, you can always
choose not to use those pre-installed features, but you know that the
average user will use them without questioning whether there are
alternatives and then the others will have to follow in order to
mantain compatibility and interoperatibility. Only those users who have
knowledge about computer security and do not like the kind of trust
model proposed will uncheck those boxes. But those are just commercial
practices (Not very ethical, by the way). Trust CAN NOT be started that
way. By definition. Period. Trust MUST be originated in the real 3D
world and then expressed by the tools that the technology provide. If
the actual tools are not satisfactory (not easy to use, not natural, not
efficient or not elegant...) then what we have to do is to develop new
tools not to try to adapt the world to the tools we have.
   By the way, Gunther, the solution to this problem has not been here
for more than ten years. We're just starting to develop it. Please do not
think that the theory of information security is just a few encipherment
algorithms. There are new questions and problems arising every day that
need a solution. Examples? Legal communication interception that does not
destroy the citizens rights, Electronic Commerce and many others.
   We have seen lately that the kind of marketing described above has led
to the success of products that are not the best ones, based on letting
everybody use them for free until the product has swep the competitors
and then, without alternatives, imposing the company's rules. I wont
mention any of them, but I suppose everybody has in mind at least a kind
of computer and one Operating System (both of them used by me to send
this message). The importance of the issue we are speaking of in this
group forces us to consider different alternatives and being very
careful when we choose one. The main point is that people can use the
Internet for their private communications, business or whatever without
loosing not even one of their rights. That's not guaranteed with the
actual trust models and certification schemes.

> In contrast, the web of trust model, as practiced, doesn't require such
> practice statements, nor central checking, nor any particular CA
> standard-sets. Instead each user creates his own trust heirarchy and rules.
> This is a distinct advantage of that model, for small workgroups where
> participants know each other and have an opportunity to verify fingerprints or keys
> to identities directly.

The advantage of this model is that trust comes from the real world but it
fails when:
-we have to communicate with people that are not linked by a trust
 (certificate) chain to us.
-we have to revocate trust on somebody.
-we have lost our certificates.
-we have to check a certificate with a long trus chain.
-etc.,
Some of those problems are common to the S/MIME model.

> Clearly the first approach is useful in some environments, and the second in
> others. It would be a mistake for users in arms-length interaction to trust
> unverified signatures just as it would be a mistake to force small
> self-contained work groups to adopt the overhead of CAs, trust statements,
> etc. And unless the canonical models are distinct, a degree of user education
> well beyond pragmatic practice is required, and the possibility is opened for
> much mischief.

  I really believe that the simultaneous use of the two models is not a good
idea, it just seems to me a proposal to close this discussion. There are too
many problems involved in any of those models alone to combine them in one
model with two options.

> ...
> To avoid misunderstanding I repeat my basic mantra--each trust model in its
> pure form has its place and to combine one with the other in the base design
> is a bad idea,

I agree as I have just said above, in the second part, but I don't think
that the coexistence of both models is an advance, maybe you just want to
put them out there and let the market do its job selecting one of them.

> thought providing a fail-safe multi-step escape hatch giving
> users some flexibility (as you've illustrated for S/MIME in Explorer) may be
> useful. Nevertheless I suggest the canonical forms are distinct, and should
> remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
> keys which meet CPS tests; in web of trust as practiced, users must build
> their own CA structure on a case by case basis but aren't limited by anyone
> else's idea of CPS tests (pace Thawte).
>
> Frankly speaking, I have the impression this is really not a useful discussion
> to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
> got two standards evolving and the commonality is likely mostly to be in the
> area of envelopes. But it is not for me to try to shut off discussion on this
> interesting topic, if others find it useful.

I agree. It's time to close the debate of PGP vs. S/MIME but it's also time to DEVELOP
some new alternatives. Please, if conforming to an old standard like
X.500 or any other makes it difficult to develop those new alternatives we
should try to develop those alternatives without the old standards. I want
to note that we are witnessing the difficulties of the development of a
standard, and the different points of view that arise in every question,
so we should be aware that a standard (specially those never used before)
is likely to have imperfections (small or big). That means that NOTHING
should be taken as the indisputable basis of our design.
   I really think that the point of view of all the people that
participated in this discussion has enrichted this group.
   Antonio.
                          ~~~~~
                         ( o o )
  +----------------o000-----U------000o--------------------+
  !           _   ,                                        !
  ! Antonio Mana-Gomez               eMail: [email-masked] !
  !                                                        !
  ! http://www.lcc.uma.es/personal/mana/mana.html          !
  !                                                        !
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !        E.T.S.I.Informatica.    Desp. 1.2.B.19          !
  !                Campus de Teatinos.                     !
  !               29071 MALAGA (SPAIN)                     !
  !                                                        !
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+

--------------E5A56DE0BBF27BFD865EEDB2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#990000" ALINK="#CC33CC">
<TT>___________________________________________________________________</TT>
<BR><TT>Mon, 01 Dec 1997 10:07:02 -0800</TT>
<BR><TT>David Sternlight wrote:</TT>
<BLOCKQUOTE TYPE=CITE><TT>Phillip M Hallam-Baker wrote:</TT>
<BR><TT>> ...</TT>
<BR><TT>></TT>
<BR><TT>> The only sense in which the built in client certs are in any</TT>
<BR><TT>> way special is that the browser company (Microsoft/Netscape)</TT>
<BR><TT>> has reviewed their Certification Practices Statement and</TT>
<BR><TT>> their operations and determined that their certificates</TT>
<BR><TT>> may generally be considered trustworthy. If you disagree</TT>
<BR><TT>> with this assement then uncheck the box next to VeriSign,</TT>
<BR><TT>> MCI, Thawte etc and you are entirely OK.</TT>

<P><TT>This is the point, though I may have expressed it imprecisely. For</TT>
<BR><TT>S/MIME-X509-Verisign et al (what can we call that as shorthand?)
there are</TT>
<BR><TT>"Certification Practices Statements" and sets of hardware and software</TT>
<BR><TT>standards for CAs. Second of all they are reviewed and only those
considered</TT>
<BR><TT>trustworthy in general are pre-installed in general-user browsers
(as distinct</TT>
<BR><TT>from some possible intranet practice). This is a distinct advantage
of the</TT>
<BR><TT>model, as implemented, for arms-length interaction between strangers.</TT></BLOCKQUOTE>
<TT>&nbsp;&nbsp; You mean that we should be glad that the company that
produced the</TT>
<BR><TT>browser has saved us the effort of finding who to trust, registering,</TT>
<BR><TT>configuring and all those tedious procedures? Just like Microsoft
did,</TT>
<BR><TT>saving us the effort to select, get and install a WEB browser by</TT>
<BR><TT>including Explorer in the Windows package?. Of course, you can
always</TT>
<BR><TT>choose not to use those pre-installed features, but you know that
the</TT>
<BR><TT>average user will use them without questioning whether there are</TT>
<BR><TT>alternatives and then the others will have to follow in order to</TT>
<BR><TT>mantain compatibility and interoperatibility. Only those users
who have</TT>
<BR><TT>knowledge about computer security and do not like the kind of trust</TT>
<BR><TT>model proposed will uncheck those boxes. But those are just commercial</TT>
<BR><TT>practices (Not very ethical, by the way). Trust CAN NOT be started
that</TT>
<BR><TT>way. By definition. Period. Trust MUST be originated in the real
3D</TT>
<BR><TT>world and then expressed by the tools that the technology provide.
If</TT>
<BR><TT>the actual tools are not satisfactory (not easy to use, not natural,
not</TT>
<BR><TT>efficient or not elegant...) then what we have to do is to develop
new</TT>
<BR><TT>tools not to try to adapt the world to the tools we have.</TT>
<BR><TT>&nbsp;&nbsp; By the way, Gunther, the solution to this problem
has not been here</TT>
<BR><TT>for more than ten years. We're just starting to develop it. Please
do not</TT>
<BR><TT>think that the theory of information security is just a few encipherment</TT>
<BR><TT>algorithms. There are new questions and problems arising every
day that</TT>
<BR><TT>need a solution. Examples? Legal communication interception that
does not</TT>
<BR><TT>destroy the citizens rights, Electronic Commerce and many others.</TT>
<BR><TT>&nbsp;&nbsp; We have seen lately that the kind of marketing described
above has led</TT>
<BR><TT>to the success of products that are not the best ones, based on
letting</TT>
<BR><TT>everybody use them for free until the product has swep the competitors</TT>
<BR><TT>and then, without alternatives, imposing the company's rules. I
wont</TT>
<BR><TT>mention any of them, but I suppose everybody has in mind at least
a kind</TT>
<BR><TT>of computer and one Operating System (both of them used by me to
send</TT>
<BR><TT>this message). The importance of the issue we are speaking of in
this</TT>
<BR><TT>group forces us to consider different alternatives and being very</TT>
<BR><TT>careful when we choose one. The main point is that people can use
the</TT>
<BR><TT>Internet for their private communications, business or whatever
without</TT>
<BR><TT>loosing not even one of their rights. That's not guaranteed with
the</TT>
<BR><TT>actual trust models and certification schemes.</TT>
<BR><TT>&nbsp;</TT>
<BLOCKQUOTE TYPE=CITE><TT>In contrast, the web of trust model, as practiced,
doesn't require such</TT>
<BR><TT>practice statements, nor central checking, nor any particular CA</TT>
<BR><TT>standard-sets. Instead each user creates his own trust heirarchy
and rules.</TT>
<BR><TT>This is a distinct advantage of that model, for small workgroups
where</TT>
<BR><TT>participants know each other and have an opportunity to verify
fingerprints or keys to identities directly.</TT></BLOCKQUOTE>
<TT>The advantage of this model is that trust comes from the real world
but it</TT>
<BR><TT>fails when:</TT>
<BR><TT>-we have to communicate with people that are not linked by a trust</TT>
<BR><TT>&nbsp;(certificate) chain to us.</TT>
<BR><TT>-we have to revocate trust on somebody.</TT>
<BR><TT>-we have lost our certificates.</TT>
<BR><TT>-we have to check a certificate with a long trus chain.</TT>
<BR><TT>-etc.,</TT>
<BR><TT>Some of those problems are common to the S/MIME model.</TT>
<BLOCKQUOTE TYPE=CITE><TT>Clearly the first approach is useful in some
environments, and the second in</TT>
<BR><TT>others. It would be a mistake for users in arms-length interaction
to trust</TT>
<BR><TT>unverified signatures just as it would be a mistake to force small</TT>
<BR><TT>self-contained work groups to adopt the overhead of CAs, trust
statements,</TT>
<BR><TT>etc. And unless the canonical models are distinct, a degree of
user education</TT>
<BR><TT>well beyond pragmatic practice is required, and the possibility
is opened for</TT>
<BR><TT>much mischief.</TT></BLOCKQUOTE>
<TT>&nbsp; I really believe that the simultaneous use of the two models
is not a good</TT>
<BR><TT>idea, it just seems to me a proposal to close this discussion.
There are too</TT>
<BR><TT>many problems involved in any of those models alone to combine
them in one</TT>
<BR><TT>model with two options.</TT>
<BLOCKQUOTE TYPE=CITE><TT>...</TT>
<BR><TT>To avoid misunderstanding I repeat my basic mantra--each trust
model in its</TT>
<BR><TT>pure form has its place and to combine one with the other in the
base design</TT>
<BR><TT>is a bad idea,</TT></BLOCKQUOTE>
<TT>I agree as I have just said above, in the second part, but I don't
think</TT>
<BR><TT>that the coexistence of both models is an advance, maybe you just
want to</TT>
<BR><TT>put them out there and let the market do its job selecting one
of them.</TT>
<BLOCKQUOTE TYPE=CITE><TT>thought providing a fail-safe multi-step escape
hatch giving</TT>
<BR><TT>users some flexibility (as you've illustrated for S/MIME in Explorer)
may be</TT>
<BR><TT>useful. Nevertheless I suggest the canonical forms are distinct,
and should</TT>
<BR><TT>remain so: In S/MIME-X509 as practiced, users are provided with
high-level CA</TT>
<BR><TT>keys which meet CPS tests; in web of trust as practiced, users
must build</TT>
<BR><TT>their own CA structure on a case by case basis but aren't limited
by anyone</TT>
<BR><TT>else's idea of CPS tests (pace Thawte).</TT>

<P><TT>Frankly speaking, I have the impression this is really not a useful
discussion</TT>
<BR><TT>to continue in the PGP and S/MIME 3 IETF lists since I think de
facto we've</TT>
<BR><TT>got two standards evolving and the commonality is likely mostly
to be in the</TT>
<BR><TT>area of envelopes. But it is not for me to try to shut off discussion
on this</TT>
<BR><TT>interesting topic, if others find it useful.</TT></BLOCKQUOTE>
<TT>I agree. It's time to close the debate of PGP vs. S/MIME but it's also
time to DEVELOP some new alternatives. Please, if conforming to an old
standard like</TT>
<BR><TT>X.500 or any other makes it difficult to develop those new alternatives
we</TT>
<BR><TT>should try to develop those alternatives without the old standards.
I want</TT>
<BR><TT>to note that we are witnessing the difficulties of the development
of a</TT>
<BR><TT>standard, and the different points of view that arise in every
question,</TT>
<BR><TT>so we should be aware that a standard (specially those never used
before)</TT>
<BR><TT>is likely to have imperfections (small or big). That means that
NOTHING</TT>
<BR><TT>should be taken as the indisputable basis of our design.</TT>
<BR><TT>&nbsp;&nbsp; I really think that the point of view of all the people
that</TT>
<BR><TT>participated in this discussion has enrichted this group.</TT>
<BR><TT>&nbsp;&nbsp; Antonio.</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
~~~~~</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
( o o )</TT>
<BR><TT>&nbsp; +----------------o000-----U------000o--------------------+</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_&nbsp;&nbsp; ,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Antonio Mana-Gomez&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
eMail: [email-masked] !</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! <A HREF="http://www.lcc.uma.es/personal/mana/mana.html">http://www.lcc.uma.es/personal/mana/mana.html</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Departamento de Lenguajes y Ciencias de la Computacion
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E.T.S.I.Informatica.&nbsp;&nbsp;&nbsp;
Desp. 1.2.B.19&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Campus de Teatinos.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
29071 MALAGA (SPAIN)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</TT>
<BR><TT>&nbsp; ! Phone: (+34) 5 213 27 54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax: (+34) 5 213 13 97 !</TT>
<BR><TT>&nbsp; +--------------------------------------------------------+</TT>
<BR><TT>&nbsp;</TT>
</BODY>
</HTML>

--------------E5A56DE0BBF27BFD865EEDB2--

From: Colin Robbins <[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]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Steve Crocker'" <[email-masked]>
Subject: RE: Why do people fight about S/MIME vs. PGP rather than use   MOSS?
Date: Tue, 2 Dec 1997 10:30:29 -0000
Sender: [email-masked]

On 30 November 1997 14:11, Steve Crocker[SMTP:[email-masked]] =
wrote:

> Meanwhile, S/MIME adherents usually take the position that MOSS cannot =
be
> implemented easily unless one has a complete MIME implementation =
already.

This suggests the choice between S/MIME and MOSS is being made on the =
basis of what is easy to implement.  This is never a good argument to =
use, as it loses sight of one major consideration - the users.

Any choice ought to be focusing on what the users - at the end of the =
day our customers - will find integrates into the desktop environment in =
the simplest and cleanest way.  My understanding is this debate suggests =
this is a MOSS based approach.

Colin

Date: Mon, 01 Dec 1997 18:44:42 -0800
To: Russ Housley <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: draft-ietf-smime-crs-00.txt
Sender: [email-masked]

>At the meeting in Washington, DC, I will ask the attendees whether we
>should expand the Charter to cover this work.

I, for one, think it's just fine for this WG to take on this task. Having a
clear, open revision of PKCS 10 that works with our new certificates is a
must in my mind.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 01 Dec 1997 15:39:12 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-smime-crs-00.txt
Sender: [email-masked]

All:

I want to provide a bit of background on this new Internet Draft.

The S/MIME Working Group is developing standards that are derived from PKCS
documents.  The first such document is CMS, which is derived from PKCS#7.

Since our working group is associated with the standardization of PKCS
documents, we are also considering a derivative of PKCS#10 as a standard.
The CRS document is the first draft.

At the meeting in Washington, DC, I will ask the attendees whether we
should expand the Charter to cover this work.

Russ

>From: [email-masked]
>Reply-To:  <[email-masked]>
>To: [email-masked]
>Cc: [email-masked]
>Subject: I-D ACTION:draft-ietf-smime-crs-00.txt
>Date: Mon, 1 Dec 1997 06:35:00 -0800
>
>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		: Certificate Request Syntax
>	Author(s)	: H. Prafullchandra, B. Fox, X. Liu, 
>                          M. Myers, J. Weinstein
>	Filename	: draft-ietf-smime-crs-00.txt
>	Pages		: 19
>	Date		: 26-Nov-97
>	
>This document defines an Internet PKI Certificate Request Syntax (CRS).
>It addresses a growing need within the Internet PKI community for an
>interface to public key certification products and services based on
>PKCS7 [PKCS7] and PKCS10 [PKCS10]. A small number of additional services
>are defined to supplement the core certificate request service. Current
>industry practice regarding the use of PKCS7 and PKCS10 is also
>documented for the benefit of the Internet community.
> 
>In general, the use of PKCS7 in this document is aligned to the
>Cryptographic Message Syntax [CMS] which provides a superset of the
>PKCS7 syntax.  Throughout this document, the term CMS should be taken to
>include the PKCS #7 document as defined in [PKCS7].  The term CRS refers
>to this specification.
> 
>The chief differences between CRS and PKIXMGMT are:
> 
>- Use of PKCS7 for security encapsulation and transaction framework
>- Use of PKCS10 as the certification request message content
>- Certification of Diffie-Hellman Public Keys based on PKCS10 requests
>- No assumption of reliable connectivity or persistent on-line operation
>- Single request/response transaction model
>
>
>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-crs-00.txt".
>A URL for the Internet-Draft is:
>ftp://internet-drafts/draft-ietf-smime-crs-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: 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-crs-00.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.

Date: Mon, 1 Dec 1997 16:30:15 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>As far as I remember, MOSS is a MIMEisation of PEM.
>PEM is based on X.509 and X.500. PEM imposed a centric view of the securi=
>ty
>world (1 IPCA)
>
>So MOSS imply X.509 and then ASN.1 as S/MIME does.

Wrong.

MOSS supports lots of different ways of identifying the participants,
X.509, user/mail name, key,...  with different trust models.

You might want to read the specs - see rfc1848, section 4.

--Sandy Murphy

From: "Alain Zahm" <[email-masked]>
To: "Gunther Schadow" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 20:59:07 +0100
Sender: [email-masked]

As far as I remember, MOSS is a MIMEisation of PEM.
PEM is based on X.509 and X.500. PEM imposed a centric view of the security
world (1 IPCA)

So MOSS imply X.509 and then ASN.1 as S/MIME does.

----------
> De : Gunther Schadow <[email-masked]>
> A : [email-masked]; [email-masked]; [email-masked];
[email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
> Objet : Why do people fight about S/MIME vs. PGP rather than use MOSS?
> Date : dimanche 30 novembre 1997 14:39
> 
> TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY.
> 
> I am  a member of a  EDI standards organization currently  preparing a
> recommendation  for   their   members on  applying    Internet  E-Mail
> standards.  Of course, security is a major issue here. Our observation
> is that the  field is everything else than  clear while PGP and S/MIME
> camps  are fighting each   other.  Unfortunately, marketing  interests
> seem to play the major role  in that fight. As  much as I am confident
> in the IETF  to stick to its  former  policy propagating open,  freely
> available, simple and effective standards, I am nevertheless concerned
> that industry is  on the edge to do  a lot of harm in  that field.  It
> seems already that the  "Internet Mail Consortium"  will have a strong
> impact in  IETF   standardization, and  as  the   IMC is   an industry
> consortium, is not committed to the IETF policy.
> 
> I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> require ASN.1, X500 and other OSI stuff that  does not merge very well
> with  the rest of  the Internet infrastructure.  Of  course the use of
> patent encumbered algorithms is  a deleterious "feature" of S/MIME  --
> this also shows whose only real interest  it is to  have S/MIME. It is
> not common sense, it is the profit  of one company: RSA Data Security,
> Inc.  The other  industry that present  itself as deciples of RSA D.S.
> Inc.  is  there to serve as distributors  of patent license royalties.
> This is a very similar marketing strategy as  we all know far too much
> from Bill Gates. Do  you really want  such attitudes to  influence the
> Internet?
> 
> On the other hand PGP  is doing  a  definite cut  in its tradition  in
> order to move  away from  patent  encumbered algorithms. However,  PGP
> uses an ad-hoc binary format as  well. Even though  it is simpler than
> ASN.1/DER,   it is still unnecessarily  obscure,  when  applied in the
> world of MIME. 
> 
> Unfortunately, the MOSS  specification   RFC1848 seems to   have  been
> forgotten. MOSS beats both S/MIME  and PGP in terms  of being open and
> straight forward. It fits  very well into the MIME  world and does not
> require any other technology than MIME. And  most important, it is not
> engaged  in any way  to a  certain set of    algorithms.  MOSS can  be
> translated from and  to S/MIME as well as  traditional or Open PGP. It
> transcends the specifics of any of these technology.
> 
> I really   much like to  see MOSS  having   a future in   the Internet
> community. I would myself write a concise implementation of a flexible
> multi-algorithm   MOSS that would be   freely available.  And I think,
> others would do so as well. 
> 
> Anyway, what I refuse to accept is that the two camps (PGP and S/MIME)
> do not try to collaborate.  Why don't they sit together, listing their
> features in an abstract manner, independent from any format like ASN.1
> or PGP's  or any technology  like X509?  These feature-lists  could be
> merged, in order to  come up with  an abstract security  specification
> that includes both approaches.  This abstract specification could then
> be mapped to concrete technologies, whether  MIME (=> MOSS), ASN.1 (=>
> PKCS) or the PGP-style.  Conversion software could be used as gateways
> between these protocols.
> 
> If this where done,  the IMC or any other  involved party  could show,
> whether their work  in the IETF is  for the sake  of the community  or
> just  for their own  market share. Get back  to common sense, now! Get
> the Internet back into people's hands!
> 
> regards
> -Gunther
> 
> Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany
> Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin.
> [email-masked]               http://userpage.fu-berlin.de/~gusw
> ----------------------------------#include <usual/disclaimer>-----------

Date: Mon, 01 Dec 1997 14:59:08 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: MSG-00 Signing-Time Attribute
Cc: [email-masked]
Sender: [email-masked]

I am in the process of adding PKCS#9 attributes that are needed for secure
e-mail to the CMS document.  In the process, I fixed the syntax.  here is
what I did:

10.3  Signing Time

The signing-time attribute type specifies the time at which the signer
(purportedly) performed the signing process. The signing-time attribute
type is intended for use in signed-data.

The signing-time attribute is identified by the following object identifier:

   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Signing-time attribute values have ASN.1 type SigningTime:

SigningTime ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime }

Dates through the year 2049 must be encoded as UTCTime, and dates in the
year 2050 or later must be encoded as GeneralizedTime.

A signing-time attribute must have a single attribute value.

No requirement is imposed concerning the correctness of the signing time,
and acceptance of a purported signing time is a matter of a recipient's
discretion. It is expected, however, that some signers, such as time-stamp
servers, will be trusted implicitly.

Russ

At 05:42 AM 12/1/97 PST, Scott Hollenbeck wrote:
>In section 2.5.1 of the S/MIME v3 Message Specification, it states
>that "Sending agents MUST encode signing time through the year 2049
>as UTCTime; signing times in 2050 or later MUST be encoded as
>GeneralizedTime".  However, the current PKCS #9 syntax for the
>signingTime attribute doesn't support a choice:
>
>SigningTime ::= UTCTime
>
>If an updated definition is available somewhere, where is it?
>The document doesn't include a reference for attribute definitions.
>If an updated definition hasn't been proposed, how about this:
>
>SigningTime ::= CHOICE {
>  utcTime           UTCTime,  -- for years 2049 and earlier
>  generalizedTime   GeneralizedTime -- for years 2050 and later -- }
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>

Date: Mon, 01 Dec 1997 10:07:02 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Phillip M Hallam-Baker <[email-masked]>
CC: Gunther Schadow <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Phillip M Hallam-Baker wrote:
> 
> >> 3. Either has "unique" advantages
> >>
> >> see above. If they had, why not listing them and join all advantages
> >> into one standard?
> >
> >Perhaps I should have said "unique and mutually exclusive" to drive the
> point
> >home, though I thought I had done that with my examples. For instance it is
> >mutually exclusive to allow anyone to be a signer and to allow only those
> >meeting certain standards to be signers.
> 
> With respect David this is simply not true.

It is logically true. There are ways around it, as you show with respect to S/MIME.

 <way round it via user intervention omitted>

> 
> The only sense in which the built in client certs are in any
> way special is that the browser company (Microsoft/Netscape)
> has reviewed their Certification Practices Statement and
> their operations and determined that their certificates
> may generally be considered trustworthy. If you disagree
> with this assement then uncheck the box next to VeriSign,
> MCI, Thawte etc and you are entirely OK.

This is the point, though I may have expressed it imprecisely. For
S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
"Certification Practices Statements" and sets of hardware and software
standards for CAs. Second of all they are reviewed and only those considered
trustworthy in general are pre-installed in general-user browsers (as distinct
from some possible intranet practice). This is a distinct advantage of the
model, as implemented, for arms-length interaction between strangers.

In contrast, the web of trust model, as practiced, doesn't require such
practice statements, nor central checking, nor any particular CA
standard-sets. Instead each user creates his own trust heirarchy and rules.
This is a distinct advantage of that model, for small workgroups where
participants know each other and have an opportunity to verify fingerprints or
keys to identities directly.

Clearly the first approach is useful in some environments, and the second in
others. It would be a mistake for users in arms-length interaction to trust
unverified signatures just as it would be a mistake to force small
self-contained work groups to adopt the overhead of CAs, trust statements,
etc. And unless the canonical models are distinct, a degree of user education
well beyond pragmatic practice is required, and the possibility is opened for
much mischief.

In your own prior message you speak about the mountains having decided how
it's going to be. This is another such example. One may argue (and such
arguments may be interesting and even useful during design of some new
standard if the mountains will go along) that in theory it could be different.
But the proof of the pudding is in the eating and the current menu on offer
involves Certification Practices Statements on the one hand, and roll your own
on the other.

Thus I continue to disagree that there ought to be a single standard in its
base form, but rather two. PGP fans who believe your earlier sketch about
Phil's unmoving view vs. the "mountains" ought to take delight in that
position. The alternative--under your sketch--is for PGP to go away except as
a niche application and S/MIME to continue to be the de facto standard and
eventually become the de jure standard. It would also mean, under a
single-standard view and the reality of the mountains, that the IETF PGP group
is largely wasting its time. Note that I do not hold that view.

To avoid misunderstanding I repeat my basic mantra--each trust model in its
pure form has its place and to combine one with the other in the base design
is a bad idea, thought providing a fail-safe multi-step escape hatch giving
users some flexibility (as you've illustrated for S/MIME in Explorer) may be
useful. Nevertheless I suggest the canonical forms are distinct, and should
remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
keys which meet CPS tests; in web of trust as practiced, users must build
their own CA structure on a case by case basis but aren't limited by anyone
else's idea of CPS tests (pace Thawte).

Frankly speaking, I have the impression this is really not a useful discussion
to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
got two standards evolving and the commonality is likely mostly to be in the
area of envelopes. But it is not for me to try to shut off discussion on this
interesting topic, if others find it useful.

David

From: "Phillip M Hallam-Baker" <[email-masked]>
To: <[email-masked]>, "Gunther Schadow" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 12:02:54 -0500
Sender: [email-masked]

>> 3. Either has "unique" advantages
>>
>> see above. If they had, why not listing them and join all advantages
>> into one standard?
>
>Perhaps I should have said "unique and mutually exclusive" to drive the
point
>home, though I thought I had done that with my examples. For instance it is
>mutually exclusive to allow anyone to be a signer and to allow only those
>meeting certain standards to be signers.

With respect David this is simply not true. An S/MIME client can be
used in precisely the PGP web of trust mode. I will take Outlook
Express as an example but the same holds for other S/MIME
clients such as Navigator only the process is slightly different.

If someone sends me a certificate that is either self signed
or signed by a root not trusted by the browser I simply click
a few buttons to add the sender to my address book then go
to 'properties->digital ids' I select the untrusted cert and
select 'explicitly trust this certificate'. If I want to trust the
key as a signing key I click 'inherit trust from this cert.'.

The only sense in which the built in client certs are in any
way special is that the browser company (Microsoft/Netscape)
has reviewed their Certification Practices Statement and
their operations and determined that their certificates
may generally be considered trustworthy. If you disagree
with this assement then uncheck the box next to VeriSign,
MCI, Thawte etc and you are entirely OK.

This is precisely what many people using VeriSign
private label (aka OnSite) certificates do. There is no
reason to force them to recognize the public certs
on an Intranet.

There is a rather nice poster put out by PGP which shows
all the various options for arranging certificate issue. As
the poster shows PGP can be used in hierarchical fashion
if desired. Unfortunately it overlooks the fact that X.509v3
certificates are equally flexible.

Please don't start the tiresome flames about personal interest.
Its not as if PGP Inc.had no vested interest. I happen to believe
that the more ways certificates can be used the larger the
market for them will become. It is certainly not in our interest
to be dogmatic.

Let us all stop being dogmatic about all this then. If there was
indeed a problem with the certificate structure of S/MIME that
would not make its transport formats invalid. There would be
no need to obsolete 25 million clients simply to introduce
a different trust model. Evolve the certificate spec to a new
level, either in ISO or if need be in the IETF.

This is starting to look like one of those programming language/
editor/ Operating System wars*. Ho hum...

                Phill

* BTW the answers are occam, LSE and VMS or Java, does not
matter, NT.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Gunther Schadow" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Date: Mon, 1 Dec 1997 11:13:46 -0500
Sender: [email-masked]

>But back to the internet. Tell me, who invented it? Industry
>was in fact not really interested in it before some Physicists at CERN
>(again a governmentally founded research organization) invented the
>WWW. The industry discovered the WWW as a perfect marketing tool, and
>helped spread the HTTP/TCP/IP as the most important informational
>revolution since the Television. But did they add any technological
>benefit to these protocols? Tell me? 

As one of the longtime membersof that CERN team I can
assure you that Marc Andressen, the founder of Netscape
had more than a minor role in helping develop the technology.
Just because a Netscape PR flack may occasionally give
the impression that he invented everything all by himself
does not mean his contribution should be ignored. I am
also thinking of people such as Ari Luotenen (inventor of
the Web proxy), Rob Mcool (co invented CGI with Ari
along with much else) and Eric Binna (whose contibutions to 
HTML are extensive). Throughout the entire time that 
Dave Raggett has worked on HTML he has been paid 
by HP.

The other reason the 'government funded the Web' meme
is simply inaccurate is that CERN never authorized the 
project. To my knowledge the limit of CERN's support
was to provide two student interns for a year (Henrick
and Ari), thats not to say they were not incredible interns
but from the reports one would imagine that there was a
team of twenty people. Everyone else who worked on the
Web did so by diverting resources from some other 
project. I was meant to be working on C++, instead I 
became the security 'team'. There is absolutely no way
that the resources that CERN provided could have allowed
the Web to come a tenth of the way it has. Support from
industry was absolutely essential. Without it there would 
not have been the money to fund the Web consortium 
after our CERN contracts expired and folk asked about
the stuff we had been 'supposed' to do.

Industry has always had a major role in setting IETF standards.
Anyone who thinks that an IPV6 protocol that was not supported
by CISCO, 3COM et al could survive does not understand the
process. 

>First of all it was not RSADSI. It was Rivest, Shamir and Adleman, who
>worked at MIT founded by governmental grants (a fact that -- in your
>voice -- should discredit the innovative nature of the RSA
>algorithm). As much as five (5!) years later, the patent was
>claimed. 

This is not true. It was issued five years later but the application
date was six months after it was published. RSADSI was formed
by the patentees to exploit their invention. Ron Rivest was 
Chairman until the SDI buyout and still plays an active role.

>This is rubbish, and you know it. There is not much to be
>theoretically developed in security today, all knowledge is there for
>more than ten years. 

That is simply not true Micali's certificate revocation technique
and the Pedderson phone tick modulus appeared in the past
three years. You may be unaware of developments but that
does not mean that they are not happening. Bruce's book
only contains developments that happened before it went to 
press, funny that.

>1. The "userbase"
>
>The userbase that you cite comes easily by having Netscape and
>Microsoft select S/MIME. But don't ask how many S/MIME installations
>do exist, but how many of them are actually *used*. I'd be interested
>in a good statistics that compares actual *users* not posessors of
>S/MIME vs. PGP software.

That is not the appropriate measure. What does it take for a
user to abandon a built in facility to use another one?

If I wish to sign an email I know that almost every recipient will
have S/MIME and only a very small number will have gone
to the trouble of downloading PGP. If I wish to allow people
to send me encrypted mail the same argument means that
an X.509 cert wins over a PGP key.

The IETF has been talking about encrypted and signed mail
for the past ten years. The main reason it has not taken off is
that security enhanced mail clients have only ever reached
a fraction of the userbase. As a direct result of SSL every
browser already has a complete RSA suite and X.509v3
certificate suite. It is no accident that they are interested in
a solution that is compatible with that base.

Look at the penetration of plug in applications for browsers.
Shockwave, Vivo, RealAudio etc appear on only a small
fraction of sites despite the ready avaliability of plug ins
and the growing trend for them to be made available at
the same time the browser is.

I can't debug other companies business plans. Hey maybe
Phil Z. is right and he can win this battle. Just don't imagine
that because it is logical to have a common standard and 
Phil Z. is determined not to budge that the mountains are
going to move to him. The mountains seem to have figured
out their idea of what the common standard is and be quite
happy where they are. 

                Phill

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-crs-00.txt
Date: Mon, 01 Dec 1997 09:35:00 -0500
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		: Certificate Request Syntax
	Author(s)	: H. Prafullchandra, B. Fox, X. Liu, 
                          M. Myers, J. Weinstein
	Filename	: draft-ietf-smime-crs-00.txt
	Pages		: 19
	Date		: 26-Nov-97
	
This document defines an Internet PKI Certificate Request Syntax (CRS).
It addresses a growing need within the Internet PKI community for an
interface to public key certification products and services based on
PKCS7 [PKCS7] and PKCS10 [PKCS10]. A small number of additional services
are defined to supplement the core certificate request service. Current
industry practice regarding the use of PKCS7 and PKCS10 is also
documented for the benefit of the Internet community.
 
In general, the use of PKCS7 in this document is aligned to the
Cryptographic Message Syntax [CMS] which provides a superset of the
PKCS7 syntax.  Throughout this document, the term CMS should be taken to
include the PKCS #7 document as defined in [PKCS7].  The term CRS refers
to this specification.
 
The chief differences between CRS and PKIXMGMT are:
 
- Use of PKCS7 for security encapsulation and transaction framework
- Use of PKCS10 as the certification request message content
- Certification of Diffie-Hellman Public Keys based on PKCS10 requests
- No assumption of reliable connectivity or persistent on-line operation
- Single request/response transaction model

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-crs-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-crs-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: 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-crs-00.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-crs-00.txt

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

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

--OtherAccess--

--NextPart--

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: MSG-00 Signing-Time Attribute
Date: Mon, 1 Dec 1997 05:42:55 PST
Sender: [email-masked]

In section 2.5.1 of the S/MIME v3 Message Specification, it states
that "Sending agents MUST encode signing time through the year 2049
as UTCTime; signing times in 2050 or later MUST be encoded as
GeneralizedTime".  However, the current PKCS #9 syntax for the
signingTime attribute doesn't support a choice:

SigningTime ::= UTCTime

If an updated definition is available somewhere, where is it?
The document doesn't include a reference for attribute definitions.
If an updated definition hasn't been proposed, how about this:

SigningTime ::= CHOICE {
  utcTime           UTCTime,  -- for years 2049 and earlier
  generalizedTime   GeneralizedTime -- for years 2050 and later -- }

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA