headers
Matt Bishop | 2 Jul 1997 21:15
Picon

CFP: 1998 SNDSS (updated; last reminder!)

CALL FOR PAPERS

The Internet Society Symposium on Network and Distributed System Security

Where: Catamaran Resort, San Diego, California
When: March 11-13, 1998

GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory.  Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
  updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
  efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Gardiner Myers | 3 Jul 1997 02:28
Picon

Status of charter

So, where are we?

Jeff Schiller had imposed a deadline of July first to deal with the IP
issues around S/MIME.  It appears that RSA has dealt with the RC2 IP
issue.  The other issue I see as having been raised has to do with the
trademark on the name "S/MIME".  What is the status of that and how does
that affect the chartering process?

The milestones in the proposed charter appear to be off, since they
specify deliverables this month.
Permalink | Reply | 0 comments |
headers
John Gardiner Myers | 3 Jul 1997 03:04
Picon

Re: Comparing email header fields with certificate contents...?

Ron Craswell wrote:
>"At a minimum, either the Distinguished Name used to identify an
>Internet mail entity MUST include an Internet mail address, or some
>other mechanism MUST be implemented in the user agent to provide for
>mapping Distinguished Names to Internet mail address."
>
>It seems apparent that this will generate a set of CAs that are creating
>certs without an internet-style EA attribute (under the assumption that
>the user agent will handle the mapping) and a set of user agents that
>will assume they don't have to handle the mapping (under the reverse
>assumption.)
>
>Shouldn't either one or the other case be mandated?

I'll agree with that.

> I'll vote for the UA mapping.

We don't vote in the IETF, we present arguments to support our
positions.

S/MIME is primarily a security system for internet messages.  Internet
messaging identities are in the form of RFC 822 addresses.  It is thus
entirely reasonable and preferable to require that systems which provide
identity certification for the internet to deal with internet (rfc822)
identities.

Also, using a mapping system raises concerns about security and trust
weaknesses in the mapping system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Craswell | 3 Jul 1997 06:02

RE: Comparing email header fields with certificate contents...?


On Wednesday, July 02, 1997 6:05 PM, John Gardiner Myers
[SMTP:jgmyers <at> netscape.com] wrote:
> 
> S/MIME is primarily a security system for internet messages.  Internet
> messaging identities are in the form of RFC 822 addresses.  It is thus
> entirely reasonable and preferable to require that systems which provide
> identity certification for the internet to deal with internet (rfc822)
> identities.

Imagine that there is no UA mapping mechanism and certificates are bound
to people directly by the E-Mail Attribute.  Now imagine that you just
paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
you to undergo DNA testing and a polygraph scan.  Now imagine your
e-mail address gets changed.  Oh well... (or, heaven forbid, that you
have two e-mail addresses.  Nevermind, nobody has more than one e-mail
address.)

All sarcasm aside, the important thing is to map your understanding of a
person's identity with the contents of the data they're sending you.  If
your understanding is based on their e-mail address then that's an
appropriate binding.  If, OTOH, it's based on a VISA number, or Driver's
License, or SSN, etc. then that's what's appropriate to be in the cert.
--
Ron Craswell
Deming Internet Security
<http://www.deming.com>
Permalink | Reply | 2 comments |
headers
David P. Kemp | 3 Jul 1997 15:55

Re: Comparing email header fields with certificate contents...?

> From: John Gardiner Myers <jgmyers <at> netscape.com>
> 
> Ron Craswell wrote:
> >
> >Shouldn't either one or the other case be mandated?
> 
> I'll agree with that.
> 
> > I'll vote for the UA mapping.
> 
> We don't vote in the IETF, we present arguments to support our
> positions.

The identity associated with an email address is derived primarily by
the content that has historically been associated (in the mind of the
reader) with that address.  If the email address were unique and
permanent, it might be suitable for use as a primary identity.  But
email addresses typically change more often than Common Names, so
*requiring* the email address to be the primary identity is not
appropriate.  (If email address is the most stable thing in your life,
more stable than your employer, your residence address, or your ISP,
then you as an individual could choose to make it your Certified
primary identity for personal communications.  In that case, the
mapping from identity to email address is trivial.  But it is still a
mapping.)

When attribute certificates come into common use, it would be appropriate
to use them to provide a Certified mapping from identity to email address.
But if the only choice is between 1) using email as the primary identity
and mapping other attributes (public key, DN, etc) to it, and 2) requiring
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Myers | 3 Jul 1997 20:28
Picon

Re: Comparing email header fields with certificate contents...?

Ron Craswell wrote:
> Imagine that there is no UA mapping mechanism and certificates are bound
> to people directly by the E-Mail Attribute.  Now imagine that you just
> paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
> you to undergo DNA testing and a polygraph scan.  Now imagine your
> e-mail address gets changed.

Imagine you marry or divorce and your name gets changed.  Imagine you
move to another state and your drivers license and address gets
changed.  Imagine your employer is acquired or divests and your
organizational affiliation gets changed.  Imagine you emigrate to
another country and your national ID number changes.

>  Oh well... (or, heaven forbid, that you
> have two e-mail addresses.  Nevermind, nobody has more than one e-mail
> address.)

So you put two e-mail addresses in the cert, or you have two certs for
the same key pair.

> All sarcasm aside, the important thing is to map your understanding of a
> person's identity with the contents of the data they're sending you.  If
> your understanding is based on their e-mail address then that's an
> appropriate binding.  If, OTOH, it's based on a VISA number, or Driver's
> License, or SSN, etc. then that's what's appropriate to be in the cert.

If your understanding of an identity is based on something other than
their e-mail address, then there's no need for the UA to map their
identity to an e-mail address.  The appropriate thing then is for the UA
to present the identity in the form that it is based.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Breed | 3 Jul 1997 21:47
Favicon

Re: Comparing email header fields with certificate contents...?

These limitations are ALL related to the X.509 certificate structure. If S/MIME (PKCS #7) could handle
additional cert types, like PGP or SDSI, life would be better :)

A pgp 'certificate' is comprised of 1) Key Packet w/preferred algorithm, 2) User ID Packet, may contain DN,
CN, email,... 3) Signature Packets making the binding or assertion of Packet 1 and 2. Since X509 has only
one sig wrapped around the whole thing, it will always be very limiting.

cb

At 11:28 AM 7/3/97 -0700, John Myers wrote:
>Ron Craswell wrote:
>> Imagine that there is no UA mapping mechanism and certificates are bound
>> to people directly by the E-Mail Attribute.  Now imagine that you just
>> paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
>> you to undergo DNA testing and a polygraph scan.  Now imagine your
>> e-mail address gets changed.
>
>Imagine you marry or divorce and your name gets changed.  Imagine you
>move to another state and your drivers license and address gets
>changed.  Imagine your employer is acquired or divests and your
>organizational affiliation gets changed.  Imagine you emigrate to
>another country and your national ID number changes.
>
>>  Oh well... (or, heaven forbid, that you
>> have two e-mail addresses.  Nevermind, nobody has more than one e-mail
>> address.)
>
>So you put two e-mail addresses in the cert, or you have two certs for
>the same key pair.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Gardiner Myers | 3 Jul 1997 22:55
Picon

Re: Comparing email header fields with certificate contents...?

David P. Kemp wrote:

> The identity associated with an email address is derived primarily by
> the content that has historically been associated (in the mind of the
> reader) with that address.  If the email address were unique and
> permanent, it might be suitable for use as a primary identity.  But
> email addresses typically change more often than Common Names, so
> *requiring* the email address to be the primary identity is not
> appropriate.

But Common Names are far from being unique, so utterly fail to be
suitable for use as a primary identity.

In your argument, you compare the permanency qualities of email
addresses with Common Names, then assert that DNs are therefore are more
suitable than email addresses.  This arugment is bogus becuase DNs are
not the same as Common Names.  DNs contain Common Names, but since
Common Names do not fit the uniqueness requirement, DNs contain other
information.  This other information changes about as often as (if not
more frequently than) the email address, so DNs taken as a whole have no
better permanency properties than email addresses.

> (If email address is the most stable thing in your life,
> more stable than your employer, your residence address, or your ISP,
> then you as an individual could choose to make it your Certified
> primary identity for personal communications.

Historically my published email address has been more stable than any of
my employer, residence address, or ISP.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Ranger | 4 Jul 1997 15:00
Favicon

RE: Comparing email header fields with certificate contents...?


>----------
>From: 	John Gardiner Myers[SMTP:jgmyers <at> netscape.com]
>Sent: 	Wednesday, July 02, 1997 9:04 PM
>To: 	ietf-smime <at> imc.org
>Subject: 	Re: Comparing email header fields with certificate contents...?
>
>Ron Craswell wrote:
>>"At a minimum, either the Distinguished Name used to identify an
>>Internet mail entity MUST include an Internet mail address, or some
>>other mechanism MUST be implemented in the user agent to provide for
>>mapping Distinguished Names to Internet mail address."
>>
>>It seems apparent that this will generate a set of CAs that are creating
>>certs without an internet-style EA attribute (under the assumption that
>>the user agent will handle the mapping) and a set of user agents that
>>will assume they don't have to handle the mapping (under the reverse
>>assumption.)
>>
>>Shouldn't either one or the other case be mandated?
>
>I'll agree with that.
>
>> I'll vote for the UA mapping.
>
>We don't vote in the IETF, we present arguments to support our
>positions.
>
>S/MIME is primarily a security system for internet messages.  Internet
>messaging identities are in the form of RFC 822 addresses.  It is thus
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul E. Hoffman | 5 Jul 1997 20:19
Picon

New version of the S/MIME draft

And the other shoe drops. I've updated the S/MIME draft and submitted it to
the Internet Drafts editor. The draft is available at
<http://www.imc.org/draft-dusse-smime-msg>. The changes are:

========

Changed the "FOO" from the previous draft back to RC2 and gave a
reference to the Internet Draft describing it. Added back the
OIDs for RC2 in Appendix A.

All of section 3 was completely replaced.

Updated the reference section to point to Internet Drafts for PKCS
docs.

Removed the reference to PKCS #9 in 2.5.1 by stating the syntax.

Removed signedAndEnveloped from the draft.

========

There are still many open issues. Further, no one has been paying much
attention to the -cert document, although certificates have proven to be
problematic for S/MIME developers. Comments on that draft are still
certainly appropriate.

--Paul E. Hoffman, Director
--Internet Mail Consortium
(Continue reading)

Permalink | Reply | 0 comments |

Gmane