Re: Bridge Certification Authorities

[Sam Schaen <[e-mail]>]

Look at http://csrc.nist.gov/pki/twg/welcome.html#documents which
contains a link for "Proposed Federal PKI Architecture"  

Snow Katrina wrote:
> 
> Can anyone point me to documentation, books, websites, etc. that provide
> information on Bridge Certificate Authorities?  I am trying to learn as
> much as possible about this topic starting at the ground level.  Any
> input would be appreciated.
> 
> Katrina
> [e-mail]




Received: from wjao001.sita.int (wjao001.sita.int [57.250.224.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12608 for <[e-mail]>; Fri, 31 Dec 1999 03:01:07 -0800 (PST)
From: [e-mail]
Received: by wjao001.sita.int (Smap/SITAnet-firewall-2.1) id LAA25549 for <[e-mail]>; Fri, 31 Dec 1999 11:05:39 GMT
Received: from mx2.sita.int(57.6.21.40) by wjao001 via smap (3.2) id xma025543; Fri, 31 Dec 99 11:05:32 GMT
Received: from nice1.nce.sita.int (nice1.equant.com [57.4.26.95]) by mx2.sita.int (8.8.8/SITAnet-relay-2.5b) with SMTP id LAA21450 for <[e-mail]>; Fri, 31 Dec 1999 11:05:31 GMT
Received: by nice1.nce.sita.int(Lotus SMTP MTA v4.6.2  (693.3 8-11-1998))  id 41256858.003CE990 ; Fri, 31 Dec 1999 12:05:19 +0100
X-Lotus-FromDomain: SITA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 31 Dec 1999 12:05:13 +0100
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03824 for <[e-mail]>; Thu, 30 Dec 1999 11:24:14 -0800 (PST)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA11078; Thu, 30 Dec 1999 14:29:12 -0500 (EST)
Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id OAA01693; Thu, 30 Dec 1999 14:26:26 -0500 (EST)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 2319069; Thu, 30 Dec 1999 14:29:13 EST
Message-ID: <[e-mail]>
Date: Thu, 30 Dec 1999 14:31:35 -0500
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.7 [en]C-19991010M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Snow Katrina <[e-mail]>
CC: [e-mail]
Subject: Re: Bridge Certification Authorities
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Look at http://csrc.nist.gov/pki/twg/welcome.html#documents which
contains a link for "Proposed Federal PKI Architecture"  

Snow Katrina wrote:
> 
> Can anyone point me to documentation, books, websites, etc. that provide
> information on Bridge Certificate Authorities?  I am trying to learn as
> much as possible about this topic starting at the ground level.  Any
> input would be appreciated.
> 
> Katrina
> [e-mail]



Received: from mclean4-mail.usae.bah.com ([156.80.5.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03577 for <[e-mail]>; Thu, 30 Dec 1999 11:15:02 -0800 (PST)
Received: from bah.com ([156.80.187.157]) by mclean4-mail.usae.bah.com (Netscape Messaging Server 3.61)  with ESMTP id AAA57A3 for <[e-mail]>; Thu, 30 Dec 1999 14:15:41 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Dec 1999 14:19:59 -0500
From: "Snow Katrina" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: Bridge Certification Authorities
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can anyone point me to documentation, books, websites, etc. that provide
information on Bridge Certificate Authorities?  I am trying to learn as
much as possible about this topic starting at the ground level.  Any
input would be appreciated.

Katrina
[e-mail]


Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01719; Thu, 30 Dec 1999 08:10:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Thu, 30 Dec 1999 08:15:30 -0800
To: Bruschi Danilo <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Getting an OID
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:01 PM 12/30/99 +0100, Bruschi Danilo wrote:
>in the preliminary study for a PKI we ended up with the problem of
>defining new extension for X.509 V3 certificates. Does someone know
>which kind of procedure has to be followed in order to get them, I mean
>to have an OID and get it internationally approved?

The easiest way to get the beginning of an OID arc is to get a "private 
enterprise number" from IANA. See 
<http://www.isi.edu/cgi-bin/iana/enterprise.pl> for the form. The list of 
all folks who have gotten such OIDs is at 
<ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers>.


--Paul Hoffman, Director
--Internet Mail Consortium



Received: from mercurio.srv.dsi.unimi.it ([e-mail] [159.149.130.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00753 for <[e-mail]>; Thu, 30 Dec 1999 06:56:31 -0800 (PST)
Received: from dsi.unimi.it (exodus.usr.dsi.unimi.it [159.149.145.41]) by mercurio.srv.dsi.unimi.it (8.9.3/8.9.3) with ESMTP id QAA09593 for <[e-mail]>; Thu, 30 Dec 1999 16:00:00 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 30 Dec 1999 16:01:17 +0100
From: Bruschi Danilo <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Getting an OID
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello everybody,

in the preliminary study for a PKI we ended up with the problem of
defining new extension for X.509 V3 certificates. Does someone know
which kind of procedure has to be followed in order to get them, I mean
to have an OID and get it internationally approved?

Thanks for your answers

D. Bruschi

 
------------------------------------------------------------------------
Danilo Bruschi, Associate Professor of Computer Science
Dip. Scienze dell'Informazione          *   tel: [phone]
Universita' degli Studi di Milano       *   fax: [phone]   
Via Comelico 39,  20135 Milano- ITALY   *   email: [e-mail] 
------------------------------------------------------------------------


Received: from esebh01nok.ntc.nokia.com (esebh01nok.ntc.nokia.com [131.228.118.150]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29459 for <[e-mail]>; Thu, 30 Dec 1999 04:56:43 -0800 (PST)
From: [e-mail]
Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id <ZC3V1FZH>; Thu, 30 Dec 1999 15:01:38 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1011E75@eseis04nok>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Announcement of the Internet Spatial Location Forum 
Date: Thu, 30 Dec 1999 15:01:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

Dear Colleagues: 

Internet Spatial Location Forum, a discussion list on IP-related 
location issues is now active.

The setting up of the forum is sparked by the huge practical value 
and the unreadiness of the spatial location capability for the 
Internet. The missing capability becomes even more demanded with 
the integration of IP and various network technologies including 
cellular and mobile systems. The forum is thus set up after our 
discussions with the leaders and some other members of IETF. 
It serves as a pre-BOF mailing list for applying a BOF in 47th IETF 
to address those location issues. The detailed description can be 
found at 'http://www-nrc.nokia.com/ip-location'.

Its immediate goals are: (1) Collect the interests, concerns, and 
suggestions on an IP spatial location protocol, (2) Identify the 
further requirements of the location protocol, (3) Seek partners 
and enthusiasts for the joint effort, (4) Invite volunteers for 
their presentations on the location issues, and (5) Prepare the 
BOF charter for the location protocol.

In brief, there is now a well-evaluated concept in its pregnancy. 
Please add your own influences onto its progress.

To subscribe to the list, just email '[e-mail]'
with 'subscribe ext-ip-location' in the mail body. To discuss , just 
email the mailing list '[e-mail]'. More 
information (detailed forum description, mailing list archive, etc.) 
can be found at the web page 'http://www-nrc.nokia.com/ip-location'.

Thank you for reading this far! Please forward this mail to anyone 
else who may be interested. Please visit the forum's web page and 
contribute by sending email to the mailing list. Thanks again!


Yours truly,

Haitao Tang / Eric Brunner


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13507 for <[e-mail]>; Wed, 29 Dec 1999 07:14:17 -0800 (PST)
Received: from [171.78.30.107] (FIXED030-107.BBN.COM [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA26400; Wed, 29 Dec 1999 09:48:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b48fcdb31321@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 29 Dec 1999 09:42:05 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Certificate Extension
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Florida,

Yes, even if the extension is only destined for local use, it is 
preferable that you register it and get a unique OID assigned. 
Otherwise, there is the possibility that someone else will be 
assigned whatever OID you choose, for a registered extension, and a 
cert containing their extension will make its way into your 
environment.  At that point local software will not be able to 
interpret the extensions with the same OID unambiguously.

Steve


Received: from twingo.tiscalinet.it (twingo.tiscalinet.it [195.130.224.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11337 for <[e-mail]>; Wed, 29 Dec 1999 03:55:08 -0800 (PST)
Received: from lex.unict.it (62.10.154.223) by twingo.tiscalinet.it; 29 Dec 1999 12:58:08 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Dec 1999 12:59:54 +0100
From: Floridia Carmelo <[e-mail]>
Reply-To: [e-mail]
Organization: CEFRIEL
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Certificate Extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
I need to use certificate extension (non critical just inside my domain)
, is it necessary to register an OID?
if yes , what i have to do?
thanks
Carmelo




Received: from tsmtp3.ldap.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02007 for <[e-mail]>; Tue, 28 Dec 1999 16:12:34 -0800 (PST)
Received: from teleline.es ([62.82.35.172]) by tsmtp3.ldap.isp (Netscape Messaging Server 4.1 Nov 19 1999 19:47:43) with ESMTP id FNH7EA00.560 for <[e-mail]>; Wed, 29 Dec 1999 01:15:46 +0100 
Message-ID: <[e-mail]>
Date: Wed, 29 Dec 1999 01:19:30 +0100
From: "Jorge G." <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,es
MIME-Version: 1.0
To: [e-mail]
Subject: Help PKIX schedule
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello!
    I'm an Spanish studient, and I'll have to do a work for the
university about the PKIX and I need some texts who describes the
schedule of this protocol.

    Could you help me?

--
 Saludos.

 Jorge




Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00628 for <[e-mail]>; Tue, 28 Dec 1999 13:27:03 -0800 (PST)
Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZTSD4KPL; Tue, 28 Dec 1999 13:31:17 -0800
Sender: rcharlet
Message-ID: <[e-mail]>
Date: Tue, 28 Dec 1999 13:32:22 -0800
From: Ricky Charlet <[e-mail]>
Organization: RedCreek Communications Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: confirm
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

auth eda8db07 subscribe ietf-pkix \
Ricky Charlet <[e-mail]>


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17956 for <[e-mail]>; Tue, 21 Dec 1999 10:52:15 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <ZJC16LXV>; Tue, 21 Dec 1999 10:51:13 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Nick Pope'" <[e-mail]>
Cc: [e-mail]
Subject: RE: AC509 Login Name
Date: Tue, 21 Dec 1999 10:51:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

There are a number of ancillary subject-related
details that one would quite naturally wish
to associate with an identified subject, depending
upon its object type, to make PKIX more useful
to more technical communication processes. Whereas
PKIX has traditionally been focuses on persons
and organizations, this is not the limit
of PKIX applicability. Host, Domains and Routers
are now receiving certs in practice.

You have identified that object class "Account"
needs a naming or other type of subject attribute,
which describes a login name to be associated,
appropriately, with an id- or privilege cert. And you 
seem to be attempting to find a format
and transmission field for such information.

But there other examples of additional
subject information; I suggest the
scope of the question be widened slightly,
so that the PKIX community agreements for 
the login value case are reusable for 
other similar localized situations.

ftp://ftp.isi.edu/in-notes/rfc2714.txt describes
the CORBA object referencing framework in IETF
LDAP directories.  The various interface names and 
references are naturally tied to "Host" objects referred to 
by the names bound to X.509 id-certs. In that Internet deployment
scenario, the Host chooses to export a given set of named
interfaces, and wishes to bind those
formal interface names and/or references to
its id- or privilege cert.  

ftp://ftp.isi.edu/in-notes/rfc2713.txt describes
additional attributes that would need to
be similarly associated with an identified entity.
to ensure java protocol entity references are bound 
to the identified server.

-----Original Message-----
From: Nick Pope [mailto:[e-mail]]
Sent: Tuesday, December 21, 1999 9:30 AM
To: [e-mail]
Cc: [e-mail]
Subject: RE: AC509 Login Name


Thanks to Kensaku, Andy and Stephen for all their comments.

I don't think OTHER-NAME on its own meets my requirement.  This requires a
OBJECT (type) IDENTIFIER to be registered so that others can recognise the
type.

I do not want to use rfc822Name as this misuses the field and has the wrong
semantics associated with it.

We could :

a) register a new OTHER-NAME type (as has been done in the QC draft)with its
OBJECT IDENTIFIER
e.g. using ASN.1 93:
flatname OTHER-NAME ::= {
          UTF8String IDENTIFIED BY  id-on-flatname}
id-on-flatname OBJECT IDENTIFIER  ::=  {id-pkix-on ?}

b) use the FlatOrGeneralName syntax given below could be used.

Either of the above would suite me.  The implementor in me likes (b); the
structured designer in me prefers (a).

Nick


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: 21 December 1999 12:15
> To: Nick Pope
> Cc: [e-mail]
> Subject: Re: AC509 Login Name
>
>
>
> Hi Nick,
>
> > I am working on the use of attribute certificates for secure access to a
> > database, where the user's global identity authenticated using
> SSL/TLS needs
> > to be securely mapped to a local login name.
> >
> > I presume that the Access Identity, as defined in 4.5.2 of
> > <draft-ietf-pkix-ac509prof-01>, can be used for this function.
>
> That's the intent.
>
> > However, I cannot find an existing name form defined in X.509 for
> > GeneralNames which could be used for a local login name.
>
> Bit naughty, but what about using rfc822Name? It does map reasonably
> well in lots of cases so long as IA5String isn't a problem.
>
> > Could one be defined as part of the IETF attribute certificate profile?
> >
> > What syntax should this take?  A choice between UTF-8 and
> General Name would
> > be the simplest.
>
> So you mean you'd prefer something like:
>
>         SvceAuthInfo ::=    SEQUENCE {
>                 service   FlatOrGeneralName,
>                 ident     FlatOrGeneralName,
>                 authInfo  OCTET STRING OPTIONAL
>         }
>
>         FlatOrGeneralName ::= CHOICE {
>                 flat    UTF8String,
>                 gen     GeneralName
> 	}
>
> I wouldn't have a problem with this, if you're sure you can't
> use the rfc822 field (and I think I prefer the above to the use of
> otherName that Andy suggested). Anyone else?
>
> Regards,
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
>


Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16784 for <[e-mail]>; Tue, 21 Dec 1999 09:19:41 -0800 (PST)
Received: from npwork2 (e1h2p202.scotland.net [148.176.234.203]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id RAA02260; Tue, 21 Dec 1999 17:23:41 GMT
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AC509 Login Name
Date: Tue, 21 Dec 1999 17:30:18 -0000
Message-ID: <000d01bf4bd9$0c8bfaf0$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

Thanks to Kensaku, Andy and Stephen for all their comments.

I don't think OTHER-NAME on its own meets my requirement.  This requires a
OBJECT (type) IDENTIFIER to be registered so that others can recognise the
type.

I do not want to use rfc822Name as this misuses the field and has the wrong
semantics associated with it.

We could :

a) register a new OTHER-NAME type (as has been done in the QC draft)with its
OBJECT IDENTIFIER
e.g. using ASN.1 93:
flatname OTHER-NAME ::= {
          UTF8String IDENTIFIED BY  id-on-flatname}
id-on-flatname OBJECT IDENTIFIER  ::=  {id-pkix-on ?}

b) use the FlatOrGeneralName syntax given below could be used.

Either of the above would suite me.  The implementor in me likes (b); the
structured designer in me prefers (a).

Nick


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: 21 December 1999 12:15
> To: Nick Pope
> Cc: [e-mail]
> Subject: Re: AC509 Login Name
>
>
>
> Hi Nick,
>
> > I am working on the use of attribute certificates for secure access to a
> > database, where the user's global identity authenticated using
> SSL/TLS needs
> > to be securely mapped to a local login name.
> >
> > I presume that the Access Identity, as defined in 4.5.2 of
> > <draft-ietf-pkix-ac509prof-01>, can be used for this function.
>
> That's the intent.
>
> > However, I cannot find an existing name form defined in X.509 for
> > GeneralNames which could be used for a local login name.
>
> Bit naughty, but what about using rfc822Name? It does map reasonably
> well in lots of cases so long as IA5String isn't a problem.
>
> > Could one be defined as part of the IETF attribute certificate profile?
> >
> > What syntax should this take?  A choice between UTF-8 and
> General Name would
> > be the simplest.
>
> So you mean you'd prefer something like:
>
>         SvceAuthInfo ::=    SEQUENCE {
>                 service   FlatOrGeneralName,
>                 ident     FlatOrGeneralName,
>                 authInfo  OCTET STRING OPTIONAL
>         }
>
>         FlatOrGeneralName ::= CHOICE {
>                 flat    UTF8String,
>                 gen     GeneralName
> 	}
>
> I wouldn't have a problem with this, if you're sure you can't
> use the rfc822 field (and I think I prefer the above to the use of
> otherName that Andy suggested). Anyone else?
>
> Regards,
> Stephen.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
>



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14265 for <[e-mail]>; Tue, 21 Dec 1999 06:25:54 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 4367"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Tue, 21 Dec 1999 09:29:57 -500 (EST)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <YVGLDDFV>; Tue, 21 Dec 1999 09:29:56 -0500
Content-return: allowed
Date: Tue, 21 Dec 1999 09:29:54 -0500
From: "Sweigert, David" <[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
To: "Todd S. Glassey" <[e-mail]>, Paul Koning <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

Does anyone have knowledge of a commercial time-stamping service, or is 
anyone willing to suggest another alternative to obtaining time other than 
using the underlying O/S as described below.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf
Of Todd S. Glassey
Sent: Wednesday, March 31, 1999 1:45 PM
To: Paul Koning
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info


Hey Paul -
Does this mean that we are going to use NTP for timestamping? (This is not
such a bad idea and Michael McNeil and i suggested just this with the two
drafts on PKI extended NTP we did with Dave Mills),

The real issue is how timestamps are derived from a local timebase and that
the local timebase has to deal with Leap Seconds somehow... The current
Entrust protocol toolkit assumes that the time data it is handed by the
underlying OS is "legally sufficient" to use as core for timestamping-  but
the problem here is that NO COMMERCIAL OS's know about Leap Seconds and so
using the TOD clock is a gamble... that the BCP addresses these and that the
timebase services are managed out of band.

BTW, as a simple example of how most people just believe this has already
been handled, there is a paragraph in the TimeServe addition to the NT
resource kit (timeserve.txt file) that states the accuracy of the NT clock
is at best .45S/day. That in and of itself is an issue since the PC and
Server manufacturers are all worried about the bottom line so they use the
most "cost effective" (from their $$$ viewpoint) clock chips and the like.

My personal feeling is that without some BCP that has one dialing into the
ACTS servers at NIST on a once daily or twice daily model, we have know idea
what time it really is.

There are no secure NTP servers out there yet but we are woking on this and,
well - Stay tuned for the first one's announcement in the next 45 days.

Todd


-----Original Message-----
From: Paul Koning <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, March 31, 1999 10:03 AM
Subject: Re: Time-stamp server. TimePrecision info


>>>>>> "Todd" == Todd S Glassey <[e-mail]> writes:
>
> Todd> How will you deal with leap seconds?  T.
>
>The NTP RFC (RFC 1305) has an excellent discussion on this and the
>approaches it describes would be good to use.  In particular, it
>suggests using a two part date/time coding (day separate from
>time-in-day).  That way the existence of leap seconds merely increases
>the range of the second field by one.  (Analogy: if you sent the
>timestamp as yyyymmddhhmmss.ssss the impact is merely that ss can be
>from 0 to 60, not 0 to 59.)
>
> paul
>



Received: from apollon.greg.rim.or.jp ([e-mail] [202.248.64.24]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10644 for <[e-mail]>; Tue, 21 Dec 1999 04:37:09 -0800 (PST)
Received: from izanami.greg.rim.or.jp ([e-mail] [172.31.1.3]) by apollon.greg.rim.or.jp (8.9.3/3.7W) with SMTP id VAA95803 for [e-mail]; Tue, 21 Dec 1999 21:41:20 +0900 (JST)
Date: Tue, 21 Dec 1999 21:41:20 +0900 (JST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
To: [e-mail]
Subject: Re: AC509 Login Name
In-Reply-To: Your message of "Tue, 21 Dec 1999 12:15:15 +0000". <[e-mail]>
From: [e-mail] (Kensaku Masuda)
Content-Type: text/plain; charset=ISO-2022-JP
X-Mailer: mnews [version 1.21PL4] 1998-06/01(Mon)

Hi everyybody.

<[e-mail]>$B$N5-;v$K$*$$$F(B
[e-mail]$B$5$s$O=q$-$^$7$?!#(B

>> I am working on the use of attribute certificates for secure access to a
>> database, where the user's global identity authenticated using SSL/TLS needs
>> to be securely mapped to a local login name.

We going to implement ac's CA. And discus about same problem.

>Bit naughty, but what about using rfc822Name? It does map reasonably 
>well in lots of cases so long as IA5String isn't a problem.

It's same result of our implement. Because We need items that are
hostname and user name.
It is simplest choice for us.

---
Fingerprint16 = 4F CC 44 F8 54 BE 45 3A  4F 9F 1C 4E 5E 3B 91 E9
Fingerprint20 = 12CA 6B2D DC50 8248 A636  992B 0292 F548 D65F 4D5B
-----------------+-----------------------------------$BA}ED!!7r:n(B---+
$B;0!&O;$r<i$m$&!*(B | [e-mail]                            |
$B!!$*2H$X5"$m$&!*(B |   [e-mail]                    |
                 |     http://www.st.rim.or.jp/~greg/             |
-----------------+------------------------------------------------+


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10172 for <[e-mail]>; Tue, 21 Dec 1999 04:05:24 -0800 (PST)
Received: by balinese.baltimore.ie; id MAA04391; Tue, 21 Dec 1999 12:09:30 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma004359; Tue, 21 Dec 99 12:08:54 GMT
Received: from baltimore.ie ([192.168.21.76]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA07854; Tue, 21 Dec 1999 12:08:54 GMT
Message-ID: <[e-mail]>
Date: Tue, 21 Dec 1999 12:15:15 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Nick Pope <[e-mail]>
CC: [e-mail]
Subject: Re: AC509 Login Name
References: <000001bf4b13$f64cbfb0$0500000a@npwork2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Nick,

> I am working on the use of attribute certificates for secure access to a
> database, where the user's global identity authenticated using SSL/TLS needs
> to be securely mapped to a local login name.
> 
> I presume that the Access Identity, as defined in 4.5.2 of
> <draft-ietf-pkix-ac509prof-01>, can be used for this function.

That's the intent.

> However, I cannot find an existing name form defined in X.509 for
> GeneralNames which could be used for a local login name.

Bit naughty, but what about using rfc822Name? It does map reasonably 
well in lots of cases so long as IA5String isn't a problem.

> Could one be defined as part of the IETF attribute certificate profile?
> 
> What syntax should this take?  A choice between UTF-8 and General Name would
> be the simplest.

So you mean you'd prefer something like:

        SvceAuthInfo ::=    SEQUENCE {
                service   FlatOrGeneralName,
                ident     FlatOrGeneralName,
                authInfo  OCTET STRING OPTIONAL
        }

        FlatOrGeneralName ::= CHOICE {
                flat    UTF8String,
                gen     GeneralName
	}

I wouldn't have a problem with this, if you're sure you can't
use the rfc822 field (and I think I prefer the above to the use of 
otherName that Andy suggested). Anyone else?

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA05101 for <[e-mail]>; Tue, 21 Dec 1999 01:10:13 -0800 (PST)
Received: from mail0.sse.ie (actually localhost) by mail0.sse.ie; Tue, 21 Dec 1999 09:13:13 +0000
Received: from bowsy (bowsy.sse.ie [193.120.32.196]) by mail0.sse.ie (8.9.1a/8.9.1) with SMTP id JAA19207; Tue, 21 Dec 1999 09:13:11 GMT
Message-ID: <016901bf4b94$03e92fc0$[e-mail]>
From: "Andy Dowling" <[e-mail]>
To: "Nick Pope" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <000001bf4b13$f64cbfb0$0500000a@npwork2>
Subject: Re: AC509 Login Name
Date: Tue, 21 Dec 1999 09:16:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit

Nick,

I don't see the need to define any new name form.
Why not simply use the "otherName" (OCTET STRING) choice of GeneralName,
and encode the DER-encoded UTF8String (or whatever) inside that?
(i.e. just like AC/PKC extensions do it). The profile specifies that
otherName must not
be used as a GeneralName choice unless otherwise specified, but I'm sure an
exception
can be made in this case - eh Stephen? :-)

Regards,

Andy

> I am working on the use of attribute certificates for secure access to a
> database, where the user's global identity authenticated using SSL/TLS
needs
> to be securely mapped to a local login name.
>
> I presume that the Access Identity, as defined in 4.5.2 of
> <draft-ietf-pkix-ac509prof-01>, can be used for this function.
>
> However, I cannot find an existing name form defined in X.509 for
> GeneralNames which could be used for a local login name.
>
> Could one be defined as part of the IETF attribute certificate profile?
>
> What syntax should this take?  A choice between UTF-8 and General Name
would
> be the simplest.
>
> Nick Pope
>
>
>



Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24007 for <[e-mail]>; Mon, 20 Dec 1999 09:49:05 -0800 (PST)
Received: from npwork2 (e1h3p65.scotland.net [148.176.235.66]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id RAA07925; Mon, 20 Dec 1999 17:52:53 GMT
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: AC509 Login Name
Date: Mon, 20 Dec 1999 17:59:29 -0000
Message-ID: <000001bf4b13$f64cbfb0$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

I am working on the use of attribute certificates for secure access to a
database, where the user's global identity authenticated using SSL/TLS needs
to be securely mapped to a local login name.

I presume that the Access Identity, as defined in 4.5.2 of
<draft-ietf-pkix-ac509prof-01>, can be used for this function.

However, I cannot find an existing name form defined in X.509 for
GeneralNames which could be used for a local login name.

Could one be defined as part of the IETF attribute certificate profile?

What syntax should this take?  A choice between UTF-8 and General Name would
be the simplest.

Nick Pope




Received: from hotmail.com (f144.law4.hotmail.com [216.33.149.144]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA14316 for <[e-mail]>; Fri, 17 Dec 1999 14:09:32 -0800 (PST)
Received: (qmail 92952 invoked by uid 0); 17 Dec 1999 22:12:57 -0000
Message-ID: <[e-mail]>
Received: from 168.70.232.233 by www.hotmail.com with HTTP;
	Fri, 17 Dec 1999 14:12:57 PST
X-Originating-IP: [168.70.232.233]
From: "Franklin Lee" <[e-mail]>
To: [e-mail]
Subject: Sample source code for writing the HTTP/LDAP 
Date: Fri, 17 Dec 1999 22:12:57 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Dear all,

Could anyone kindly direct me where I could find the sample source code to 
write the

a) HTTP

b) LDAP

in accessing the LDAP directories serverices?


Thanks a lot.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com



Received: from delcluster4.vsnl.net.in (del6.vsnl.net.in [202.54.96.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01019 for <[e-mail]>; Fri, 17 Dec 1999 02:20:45 -0800 (PST)
Received: from progsoft ([202.54.108.115]) by delcluster4.vsnl.net.in (8.9.2/8.9.1) with SMTP id PAA29452 for <[e-mail]>; Fri, 17 Dec 1999 15:51:46 -0500 (GMT)
Message-ID: <001701bf4879$689940e0$015029c3@progdom>
Reply-To: "Progressive Software Pvt Ltd" <[e-mail]>
From: "Progressive Software Pvt Ltd" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Fri, 17 Dec 1999 15:58:05 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01BF48A7.8156F040"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01BF48A7.8156F040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_0014_01BF48A7.8156F040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0014_01BF48A7.8156F040--



Received: from VHOSTSQL ([202.130.1.93]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11502 for <[e-mail]>; Thu, 16 Dec 1999 19:56:37 -0800 (PST)
Received: from mail pickup service by ihw.com.cn with Microsoft SMTPSVC; Fri, 17 Dec 1999 11:59:07 +0800
Received: from one.eListX.com - 209.116.252.130 by mail.ihw.co.cn with Microsoft SMTPSVC; Tue, 14 Dec 1999 13:09:46 +0800
Received: from one.elistx.com by one.eListX.com id aa08633; 13 Dec 99 11:00 EST
Received: from caesar.udac.se by one.eListX.com id aa08621; 13 Dec 99 10:56 EST
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA12763; Mon, 13 Dec 1999 10:16:58 +0100
Received: by HYDRA with Microsoft Mail id <01BF4551.F3691180@HYDRA>; Mon, 13 Dec 1999 10:08:06 +0100
Message-ID: <01BF4551.F3691180@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Lyal Collins'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Matei (DSV)'" <[e-mail]>
Subject: RE: Online PIN & Server Wallet
Date: Mon, 13 Dec 1999 10:08:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
X-elistx: set-discuss
Source-Info:  From (or Sender) name not authenticated.

Lyal,

>- Why not have the Server wallet sign on behalf of the cardholder? - they've
>already authenticated themselves by PIN, thuis no need for a personalised
>certificate.

Well, your are right about the server-signature but if you put this statement in the 
IETF-PKIX-list you will get return messages like "not secure", "breaks the intention of PKI" ,
"the user-environment and equipment is more trustworthy than a server" etc.

Naturally these guys will simply be ignored, as today you get computer-generated invoices on
company-papers from energy companies and Telcos. When (if) they convert this into PKI,
I doubt that they will add a human clerk to push "OK" or key PIN-codes for each outgoing
digitally signed invoice.

I do believe though that it would be advantageous (but not absolutely necessary) that users also
performs a signature operation, preferably with the same device and mechanism as they do for
their Internet-banking account.  Here assuming that the server wallet is located at the user's bank
which though may not always be the case.  Some Internet-banks do not require signing yet, and
in those cases your original idea is exactly as good (or bad) as their on-line banking services.

Anders

-----------------------------------------------------------------------
Message addressed to: [e-mail]
Archive available at: http://lists.commerce.net/archives/set-discuss/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [e-mail]




Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29161 for <[e-mail]>; Thu, 16 Dec 1999 18:26:11 -0800 (PST)
Received: by florida.melco.co.jp (3.7W-florida) id LAA23005; Fri, 17 Dec 1999 11:29:34 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id LAA21245; Fri, 17 Dec 1999 11:30:13 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id LAA24346; Fri, 17 Dec 1999 11:30:33 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id LAA02776; Fri, 17 Dec 1999 11:30:15 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id LAA07921; Fri, 17 Dec 1999 11:34:10 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id LAA02713; Fri, 17 Dec 1999 11:29:34 +0900 (JST)
Message-ID: <007b01bf4836$50608580$78054a0a@belize>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Subject: RE: certificate which has both AIA and CRL DPs
Date: Fri, 17 Dec 1999 11:27:49 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700

Mr. Malpani

Thank you for your reply.
I am going to create the list of the order of priority and
give it to the application which uses certificates including 
CDPs and AIA.

Hiroyuki Sakakibara

>Hi,
>    The certificate that you are planning to issue is perfectly
>legal. Unfortunately, the answer to Question2 is not specified
>in the standards. It is up to the application to decide how it
>wants to prioritize the different validation methods.
>
>It is perfectly legal for the application to ask in the following
>order:
>
>OCSP server-2
>CRL DP-1
>OCSP server-1
>CRL DP-2
>
>or any other order it chooses.
>
>Regards,
>Ambarish
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                                650.567.5457
>ValiCert, Inc.                                  [e-mail]
>1215 Terra Bella Ave.                         http://www.valicert.com
>Mountain View, CA 94043-1833
>
>
>> -----Original Message-----
>> From: Hiroyuki Sakakibara [mailto:[e-mail]]
>> Sent: Tuesday, December 07, 1999 6:47 PM
>> To: [e-mail]
>> Subject: certificate which has both AIA and CRL DPs
>> 
>> 
>> Hello
>> 
>> I would like to generate a certificate which has
>> both AIA and CRL DPs.
>> 
>> Question1 : In RFC2459 specification, is this 
>>                     certificate legal or illegal ?
>> 
>> Question2 : If this certificate is legal, how does it describe the
>>                      order of priority to process those extensions?
>> 
>> For example, 
>> ------------------------------------------------
>> 1st.                        OCSP server-1
>> 2nd.                       OCSP server-2
>> 3rd.                       CRL DP-1
>> 4th.                        CRL DP-2
>> 
>> or
>> 
>> 1st.                        OCSP server-1
>> 2nd.                       CRL DP-1
>> 3rd.                        OCSP server-2
>> 4th.                        CRL DP-2
>> 
>> etc ...
>> ------------------------------------------------
>> 
>> Is a new extension(or any scheme) which describes the
>> list of these priorities needed?
>> 
>> like this
>> 
>> LIST  {
>> 1st    use AIA's 1st element,
>> 2nd   use CRL DPs 1st element,
>> 3rd    use "other method",
>> 4th    use  AIA's 2nd element,
>> 5th    use  CRL DPs 2nd element,
>> etc ...
>> }
>> 
>> Please, can anyone help? 
>> 
>> Hioryuki Sakakibara
>> 
>> =========================================
>> Hiroyuki Sakakibara
>> Research Engineer
>> Information Security Department
>> Mitsubishi Electric Corporation
>> Information Technology R&D Center
>> 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
>> PHONE: [phone]
>> FAX: [phone]
>> ==========================================
>> 
>



Received: from mx01.usbank.com ([170.135.240.14]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA18913 for <[e-mail]>; Thu, 16 Dec 1999 13:42:54 -0800 (PST)
From: [e-mail]
Received: from 172.18.31.14 by mx01.usbank.com with SMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 16 Dec 99 15:46:13 -0600
X-Server-Uuid: 44c0c3c9-f1db-11d2-a9aa-0000f6b9ab98
Received: from 10.88.129.211 by ntorccmx01.or.usbc.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 16 Dec 99 13:45:36 -0800
X-Server-Uuid: 903dc846-ce68-11d1-a9ea-000629b217d2
Subject: 
To: <[e-mail]>
cc: 
Sender: <[e-mail]>
Date: Thu, 16 Dec 1999 13:42:07 -0800
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on NTORCCEM07/OR/Servers/USB(Release 5.0.1a|August 17, 1999) at 12/16/99 01:42:07 PM
MIME-Version: 1.0
X-WSS-ID: 1447820A386441-01-01
X-WSS-ID: 1447822F4740113-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit

auth e21a932f subscribe ietf-pkix \
[e-mail]





Received: from gauntlet.corecom.com ([206.74.64.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17746 for <[e-mail]>; Thu, 16 Dec 1999 12:33:35 -0800 (PST)
Received: by gauntlet.corecom.com; id QAA23527; Thu, 16 Dec 1999 16:01:31 -0500 (EST)
Received: from unknown(207.86.152.184) by gauntlet.corecom.com via smap (V4.2) id xmaa23522; Thu, 16 Dec 99 16:01:13 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail2.netreach.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 16 Dec 1999 15:31:45 -0500
To: [e-mail]
From: Dave Piscitello <[e-mail]>
Subject: Internet Security Conference, Call for Papers, Abstracts
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

The Fourth Internet Security Conference will be held
April 24-28, 2000 in San Jose, CA, at the Fairmont
Hotel. TISC is an educational forum for security
professionals and practitioners. The TISC Security
Symposium is an opportunity for individuals to share
their expertise and practical experience with others
involved in the design, implementation and deployment
of networked security systems.

For April, we have invited a few original papers from
past TISC workshop instructors and speakers. Accepted
papers will be presented at the conference.

We cordially invite you to submit a session abstract for
consideration, or if you prefer, to present a topic as
a panel member. We encourage you to submit abstracts and
topics by December 20. Further information can be found
at http://tisc.corecom.com. Or send your proposal to me
directly (mailto:[e-mail]).

We look forward to your participation. Thank you.

Warm Regards,

Dave Piscitello
On behalf of the TISC Advisory Board 


-------------------
David M. Piscitello
Core Competence, Inc.
3 Myrtle Bank Lane
Hilton Head, SC 29926
1.843.683-9988
[e-mail]
PGP Fingerprint: 070A 9F01 C35C 4D41 A460 EF2C 2992 2F12 11D2 02DC
http://www.corecom.com



Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08534 for <[e-mail]>; Thu, 16 Dec 1999 04:15:35 -0800 (PST)
Received: from oass03.cstelecom.cie-signaux.fr (oass03.cstelecom.cie-signaux.fr [194.2.51.78]) by oass09.cstelecom.cie-signaux.fr  with ESMTP id NAA09071 for <[e-mail]>; Thu, 16 Dec 1999 13:17:48 +0100 (MET)
Received: from cssystemes.cie-signaux.fr by oass03.cstelecom.cie-signaux.fr (8.8.8/SMI-SVR4) id NAA21507; Thu, 16 Dec 1999 13:36:02 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 16 Dec 1999 13:25:14 +0100
From: LUBREZ =?iso-8859-1?Q?J=E9r=F4me?=  <[e-mail]>
Organization: CS Communications & Systems
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: multipart/mixed; boundary="------------CF738F2CE129F44FDD4DBE9E"

Il s'agit d'un message multivolet au format MIME.
--------------CF738F2CE129F44FDD4DBE9E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe

--------------CF738F2CE129F44FDD4DBE9E
Content-Type: text/x-vcard; charset=us-ascii;
 name="jerome.lubrez.vcf"
Content-Description: Carte pour LUBREZ Jérôme
Content-Disposition: attachment;
 filename="jerome.lubrez.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:LUBREZ;Jérôme
tel;fax:[phone]
tel;work:33 1 40 78 61 69
x-mozilla-html:FALSE
url:http://www.cie-signaux.fr/security
org:CS Communications & Systemes;Information Systems Security Unit
adr:;;88, rue Brillat Savarin;PARIS;;75013;FRANCE
version:2.1
email;internet:[e-mail]
title:Head of Development Department
x-mozilla-cpt:;-27440
fn:Jérôme LUBREZ
end:vcard

--------------CF738F2CE129F44FDD4DBE9E--



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03463 for <[e-mail]>; Thu, 16 Dec 1999 02:22:20 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.4) id NAA25388; Thu, 16 Dec 1999 13:25:49 +0300 (MSK)
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma025368; Thu, 16 Dec 99 13:25:30 +0300
Message-ID: <[e-mail]>
Date: Thu, 16 Dec 1999 13:25:34 +0300
From: Pavel Krylov <[e-mail]>
Organization: TrustWorks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CRLs' cycle
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,
I didn't find any limitations for CRL infrastructure .. I found out
one interesting CRL configuration, when revokation only one certificate
in it follows to automatic revokation all certificates, those in
the cycle. Basically it seems like:

         CA1
          |
          V
        cert_1 -~-~-~-~-~-> crl_2
          |                   &
          |                   |
          |                   |
          V                   |
         crl_1 <-~-~-~-~-~- cert_2 <----- CA2


 -~-~-~ line shows who references to a crl.
 ------ line shows who issued a crl.

When no one certificate is revoked in the infrastructure, then
it looks good and works best ( I think ). But if only one certificate
is revoked by appropriate crl, then it follows to the automatic
revokation of another certificate ( in this example ).
So my question: is this infrastructure illicit by rfc2459 or not?
Another question: have I missed something?

Thanks a lot.
Pavel.


Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26487 for <[e-mail]>; Thu, 16 Dec 1999 00:33:46 -0800 (PST)
Received: from oass03.cstelecom.cie-signaux.fr (oass03.cstelecom.cie-signaux.fr [194.2.51.78]) by oass09.cstelecom.cie-signaux.fr  with ESMTP id JAA24289 for <[e-mail]>; Thu, 16 Dec 1999 09:35:55 +0100 (MET)
Received: from cssystemes.cie-signaux.fr by oass03.cstelecom.cie-signaux.fr (8.8.8/SMI-SVR4) id JAA17287; Thu, 16 Dec 1999 09:54:08 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 16 Dec 1999 09:43:18 +0100
From: LUBREZ =?iso-8859-1?Q?J=E9r=F4me?=  <[e-mail]>
Organization: CS Communications & Systems
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: multipart/mixed; boundary="------------ECCC54071A727412C57AD802"

Il s'agit d'un message multivolet au format MIME.
--------------ECCC54071A727412C57AD802
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe

--------------ECCC54071A727412C57AD802
Content-Type: text/x-vcard; charset=us-ascii;
 name="jerome.lubrez.vcf"
Content-Description: Carte pour LUBREZ Jérôme
Content-Disposition: attachment;
 filename="jerome.lubrez.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:LUBREZ;Jérôme
tel;fax:[phone]
tel;work:33 1 40 78 61 69
x-mozilla-html:FALSE
url:http://www.cie-signaux.fr/security
org:CS Communications & Systemes;Information Systems Security Unit
adr:;;88, rue Brillat Savarin;PARIS;;75013;FRANCE
version:2.1
email;internet:[e-mail]
title:Head of Development Department
x-mozilla-cpt:;-27440
fn:Jérôme LUBREZ
end:vcard

--------------ECCC54071A727412C57AD802--



Received: from ns.koscom.co.kr (ns.koscom.co.kr [128.134.148.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23349 for <[e-mail]>; Wed, 15 Dec 1999 23:33:26 -0800 (PST)
Received: from koscom.co.kr ([128.134.151.24]) by ns.koscom.co.kr (8.9.1/8.9.1) with ESMTP id QAA12908 for <[e-mail]>; Thu, 16 Dec 1999 16:23:20 +0900 (KST)
Message-ID: <[e-mail]>
Date: Thu, 16 Dec 1999 16:36:08 +0900
From: Sungjin Lee <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Why should not the BC extension appear in end entity certificate?
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

RFC 2459 state that the BC extension should not appear

in EE certificates.

Let me know why the BC extension should not appear in EE certificates.

Is there any problem when cA in BC in EE certificates is set to false?


Sungjin Lee

SignKorea (http://www.signkorea.com)
Korea Securities Computer Corp.
Seoul, South Korea.


Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20542 for <[e-mail]>; Wed, 15 Dec 1999 15:21:43 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.156]) by mail-ewr-3.pilot.net with ESMTP id SAA10807; Wed, 15 Dec 1999 18:25:17 -0500 (EST)
Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id SAA15699; Wed, 15 Dec 1999 18:25:16 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256848.00805487 ; Wed, 15 Dec 1999 18:21:42 -0500
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 15 Dec 1999 15:19:46 -0800
Subject: Re: RFC 2527 Physical Security Controls Question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

there is slightly related thread running in sci.crypt newsgroup ("Attacks on a
PKI")  ... i've archived some of my postings at:

http://www.garlic.com/~lynn/99.html#226
http://www.garlic.com/~lynn/99.html#228

the full thread is available from places like dejanews




Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18733 for <[e-mail]>; Wed, 15 Dec 1999 13:59:27 -0800 (PST)
From: [e-mail]
Received: from [e-mail] by imo-d04.mx.aol.com (mail_out_v24.6.) id 7.0.d6fa5c2b (6398); Wed, 15 Dec 1999 17:02:40 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 15 Dec 1999 17:02:39 EST
Subject: Re: RFC 2527 Physical Security Controls Question
To: [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Windows AOL sub 44

In a message dated 12/15/99 3:17:16 PM Eastern Standard Time, 
[e-mail] writes:

<< So if public key becomes integral to the core operation (say on a 
transaction by
 transaction basis)  ... then its associated infrastructure has to at least 
meet
 the requirements of that infrastructure (w/o introducing new risk and failure
 modes).
 
 >>

Boy oh boy is that an important statement!  I paraphrase it as "If you 
integrate PKI into a business process, in such a way that the process DEPENDS 
on the PKI working properly, you've just held your business process hostage 
to your PKI." 

Thus, as you say, the PKI needs to meet the requirements and not introduce 
new risk.  I don't think there is any way to introduce PKI into a process 
without introducing some new failure modes, but that just means you have to 
compensate for those failure modes to keep the risk acceptable.

All of which means to me that we need to be VERY cautious when trying to 
"improve" a process with PKI.  Remember that it can take as long (or longer) 
to remove automation from a process as it did to add it.


Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18227 for <[e-mail]>; Wed, 15 Dec 1999 13:49:33 -0800 (PST)
From: [e-mail]
Received: from [e-mail] by imo-d04.mx.aol.com (mail_out_v24.6.) id 7.0.763bc5a6 (6398); Wed, 15 Dec 1999 16:52:43 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 15 Dec 1999 16:52:43 EST
Subject: Re: RFC 2527 Physical Security Controls Question
To: [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Windows AOL sub 44

In a message dated 12/15/99 1:42:10 PM Eastern Standard Time, 
[e-mail] writes:

<< There are certainly a number of commercial applications where the use 
 an armed, lethal, and strong response to a forcible intrusion or attack 
would 
 be both prudent and justifiable.  I am thinking about a nuclear reactor, a 
 control center that administers regional gas or electrical power supplies,
 a major banking facility, a printing company that prints Traveler's Checks,
 etc. >>

This is exactly the kind of debate I wanted to spark, and I agree 
wholeheartedly with your reasoned response.  I agree that the danger to a CA 
that only issues signing keys is minimal... A CA that issues encryption keys 
is another matter, since it's compromise or destruction could render 
extremely valuable information unrecoverable.

While in the US and UK, there is the common theme that you only take life to 
protect life, there are other countries (and subcultures like organized 
crime) who take a markedly different view.  God forbid one of us ever gets 
hired to build a CA for the Russian Mafia....

I think the Industrial Security Manual is an excellent starting point since 
it mirrors most DOD standards.  But it also has one significant weakness; it 
was initially written to protect paper documents and other concrete (as 
opposed to virtual) objects.  Special care must be taken to protect against 
the latest and greatest threats (perhaps EMP) to computers.


Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16413 for <[e-mail]>; Wed, 15 Dec 1999 12:13:21 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.156]) by mail02-ewr.pilot.net with ESMTP id PAA11513; Wed, 15 Dec 1999 15:17:02 -0500 (EST)
Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id PAA01565; Wed, 15 Dec 1999 15:17:01 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256848.006F0EB6 ; Wed, 15 Dec 1999 15:13:02 -0500
X-Lotus-FromDomain: FDC
To: [e-mail]
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 15 Dec 1999 12:13:30 -0800
Subject: Re: RFC 2527 Physical Security Controls Question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

one of the X9.59/AADS scenerios is that the public key operation becomes
integrated into the infrastructure of the financial transaction. If that
infrastructure has spent several hundred million on security & integrity
infrastructure ... then all components have to be at the same level of
security/integrity or it puts the infrastructure at risk (don't want to
introduce new risk and failure modes).

That somewhat reverses the question ... rather than how much has to be spent on
the PKI specific implementation ... it becomes all components have to meet same
minimum integrity/security requirements; that goes for both availability (denial
of service attacks) as well as compromise (& ability to then do fraudulent
transactions).

For some infrastructures, the security/integrity infrastructure may only
represent thousands of dollars ... while some commercial operations the
security/integrity infrastructure may represent hundreds of millions.

So if public key becomes integral to the core operation (say on a transaction by
transaction basis)  ... then its associated infrastructure has to at least meet
the requirements of that infrastructure (w/o introducing new risk and failure
modes).

Furthermore, there may be situations were there is no level of liability &
insurance that would make any kind of trusted 3rd parties acceptable

The other issue not to be overlooked ... is that one of the biggest threats to
(at least) commercial operations are insiders. Some of the human factors issues
may change when only hundreds of billions of dollars are at stake.




Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15778 for <[e-mail]>; Wed, 15 Dec 1999 11:37:07 -0800 (PST)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id LAA23254; Wed, 15 Dec 1999 11:37:59 -0800 (PST)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YMRLSYMB; Wed, 15 Dec 1999 11:39:54 -0800
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Wed, 15 Dec 1999 14:41:36 -0500
Message-ID: <007401bf4734$66b0d680$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>

Bob,

> However, in all of those cases the justification would be to 
> protect human life,
> and only secondarily to protect property and major financial 
> assets.  

I can't think of many cases in which a PKI would be the last barrier 
protecting such facilities. In the case of a reactor you can run the 
boron feed pumps and so on...

In the UK nuclear installations are guarded by the British Nuclear Police
which is the only part of the police force which is permitted to carry
firearms at all times. I suspect they are authorized to fire if someone
attempts to steal nuclear material but they have yet to shoot one of 
the many protestors who make a habit of unauthorized entries to such
facilties.


> Unlike 
> a government that could conceivably deploy automatic, lethal defenses to 
> protect nuclear missiles, 

Actually the US is one of a very small number of governments that could
do this. The rest have signed up for the landmine ban treaty!


> US law strongly frowns on people who 
> set up deadfall 
> devices or shotguns triggered to go off if someone attempts to 
> open a door.  

If for no other reason than such devices have a habit of going off
and killing innocent bystanders, in particular the emergency services.


> Another problem is how to deal with the conflicting demands of 
> the fire codes and security.

Quite so, deployment of deadfall devices is probably contrary to
every fire code in the country.

Failing to attend to fire codes can itself be a serious problem.
For example anyone who digs out a bunker has to be aware of the
possibility of methane gas build up. More than one pumping station 
has gone up as visitors have neglected the no-smoking signs.

Folk who build secure bunkers underground would be well advised
to consider such issues. After all a fire is likely to compromise 
one's security substantially...


	Phill 


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA14018 for <[e-mail]>; Wed, 15 Dec 1999 10:38:45 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Dec 1999 11:41:57 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Wed, 15 Dec 1999 11:41:45 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: RFC 2527 Physical Security Controls Question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA14019

There are certainly a number of commercial applications where the use 
an armed, lethal, and strong response to a forcible intrusion or attack would 
be both prudent and justifiable.  I am thinking about a nuclear reactor, a 
control center that administers regional gas or electrical power supplies,
a major banking facility, a printing company that prints Traveler's Checks,
etc.

However, in all of those cases the justification would be to protect human life,
and only secondarily to protect property and major financial assets.  Unlike 
a government that could conceivably deploy automatic, lethal defenses to 
protect nuclear missiles, US law strongly frowns on people who set up deadfall 
devices or shotguns triggered to go off if someone attempts to open a door.  
(Having said that, some states allow the use of deadly force to prevent arson, 
and a few allow deadly force to protect against theft, but not unattended force.)

In the case of a CA that is only protecting signing keys and not encryption keys, 
such defenses would be "overkill".  Instead, various trip-guards could and perhaps 
should be deployed to cause key zeroization in the event of an attack, in order 
to prevent compulsion of personnel.  This should be in addition to the 
tamper-detecting circuitry contained within a FIPS 140-1 level 3 or 4 device, for
unless they have been disarmed they will sign what they are told to.

To go back to the original request, I would suggest that the physical security 
requirements outlined in the Industrial Security Manual have stood the test of time, 
and are defensible as a reasonable and prudent set of precautions.

I no longer have a copy of the ISM, but I would suggest that the requirements for a 
Closed Area would be the minimum for a CA.  If I were doing it, I would tend to 
make the outer peripheral area a Closed Area, to be used for administrative and 
technical office space.

The next level up would be a Strong Room or Vault, one that is suitable for the storage
of Top Secret documents in the open.  This would be where I would put the firewalls,
servers, etc. -- everything but the crypto devices that actually sign the most important 
certificates.

The inner sanctum might very well deserve SCIF treatment, including Red/Black power 
separation, but would presumably not require the attention to acoustic controls, assuming
the personnel don't sit around reading off the content of the keys!  

But what is more important than the physical strength and the ability to withstand an overt 
penetration is the degree to which the area would withstand a covert attack.  Sheet rock 
walls can be penetrated, repaired, and repainted very easily within a shift, and maybe even 
within an hour or so, so it is important to have appropriate infrared or microwave area 
alarm systems that cover the walls, floor, and ceiling.

Another problem is how to deal with the conflicting demands of the fire codes and security.

When I was with GTE Laboratories, we set up a closed area for cellular fraud investigations
that was built to Strong Room specifications.  The main access was controlled by a fingerprint
reader which was under my control (with a backup person in my group).  The rear door had a 
strong three-position combination lock on it.

The combination to that lock was sealed in plastic in an envelope that was kept for emergency 
response purposes by the building guards, so they could gain entry in case of fire. The rear door was 
always alarmed, and the front door was alarmed after hours. More importantly, however, there were
TWO sets of alarms -- one of which was wired to the building alarm system, and one of which was 
internal to and controlled within our area, and physically protected.  So in the event of an emergency
the building guards could get in, but they couldn't get in undetected, even if they turned off the 
building alarm system.

In addition, the most sensitive inner area should be designated a Two Man No Lone Zone. 
Two people should be required to enter the area together, preferably using two fingerprint readers 
or at least two physical keys, and those people should also be required to use a fingerprint 
reader to exit the facility.  The interior alarm should be activated shortly after the first person 
exits, to make sure someone doesn't stay behind unsupervised.

Finally, it must be recognized that the most devastating security compromises have not been caused
by external attacks, but by authorized insiders.  All of the physical security in the world won't 
help if your people can be compromised by say an offer of $100,000. So you need personnel 
investigations, bonding, etc., etc. The problem is typically getting your HR department to accept 
those requirements.

Bob


>>> <[e-mail]> 12/14/99 06:22PM >>>
John Kennedy and Lynn Wheeler both made excellent points about the potential 
need for absolute top-grade physical security in a commercial CA operation.  
It all seems to come down (as always) to risk assessment and balancing the 
cost of security against it's benefits.

In the commercial world, especially in the financial and medical sectors, the 
potential liability for a CA operator could be enormous, easily justifying 
the cost of physical security measures rivalling that found around weapons of 
mass destruction.

This brings up an interesting question though...  For a government, it's very 
easy to designate a resourse as being sufficiently valuable to authorize the 
use of deadly force to protect it - try to get close to a stealth aircraft 
sometime. For commercial applications, however, even where billions of 
dollars may be at stake, it's harder (if not impossible) to implement that 
final line of security.  

So for you non-government types, would your CA physical security include 
lethal defenses?  Can anyone think of any application for a non-government CA 
that would require such defenses?  I'm not talking about just armed guards 
here...  I'm talking about defenses that would kill an unauthorized 
individual who entered protected space BEFORE they did any damage besides 
entering that space. 

Timothy M. Metzinger
Technical Director
Drug Enforcement Administration
Office of Information Systems
[phone]
[phone]


Received: from sentry ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10583 for <[e-mail]>; Wed, 15 Dec 1999 09:48:40 -0800 (PST)
Received: by sentry; id MAA03149; Wed, 15 Dec 1999 12:53:27 -0500 (EST)
Received: from unknown(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma003142; Wed, 15 Dec 99 12:53:08 -0500
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id MAA04247 for [e-mail]; Wed, 15 Dec 1999 12:52:22 -0500 (EST)
Date: Wed, 15 Dec 1999 12:52:22 -0500 (EST)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000)

                  R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 2000

The 7th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- An Introduction to Intrusion Detection Technology, Mr. Mark Wood 

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: [phone]         Fax: [phone]
  E-mail: [e-mail]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at [phone] or send e-mail to [e-mail].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02081 for <[e-mail]>; Wed, 15 Dec 1999 07:36:05 -0800 (PST)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id HAA11699; Wed, 15 Dec 1999 07:36:56 -0800 (PST)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YMRLSW6W; Wed, 15 Dec 1999 07:38:49 -0800
From: "Phillip M Hallam-Baker" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Wed, 15 Dec 1999 10:40:30 -0500
Message-ID: <006f01bf4712$b7c9c3a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>

Timothy Metzinger writes:

> So for you non-government types, would your CA physical security include
> lethal defenses?  Can anyone think of any application for a
> non-government CA
> that would require such defenses?  I'm not talking about just
> armed guards
> here...  I'm talking about defenses that would kill an unauthorized
> individual who entered protected space BEFORE they did any damage besides
> entering that space.

What an utterly bizare idea. This is PKI, not James Bond. Dr No
might require such a security system but I can't see that such a
system would serve any commercial purpose.

I would be very suspicious about any such system. I would see it
as introducing the very serious threat of complacency. I am much
happier trusting concrete and steel than 007 type booby-trap gadgets.

It isn't as if disarming explosive devices is impossible. Security is
a function of the difficulty of disarming preventative devices rather
than the seriousness of a device being triggered.

Besides which I doubt that operating such a system would be legal
in most countries. Burglars don't have many legal rights but in
the UK at least use of lethal force is only permitted in self defence.
Defence of property is not a justification. Anyone building such a
device would (quite rightly) face a murder charge if it went off.


Even in Texas I suspect that the fire dept would have something to
say on the matter.

Rather than kill the attacker it would surely be a much simpler
matter to destroy any cryptographic keying material. This should
not in itself be a problem if there was an equally well protected
disaster recovery site. The principal risk is not destruction of
keying material but theft of keying material - particularly if it
was undetected.

The NSA is rumoured to use explosives in certain crytosystems. My
understanding is that the purpose was to destroy the keying material
and not to kill someone probing.

		Phill



Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10097 for <[e-mail]>; Tue, 14 Dec 1999 19:00:24 -0800 (PST)
From: [e-mail]
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.certco.com [10.100.24.12]) by btec-fw.certco.com (Postfix) with ESMTP id BDE4032DE8; Tue, 14 Dec 1999 22:03:46 -0500 (EST)
Received: by nycertco-srv1.certco.com with Internet Mail Service (5.5.2650.21) id <YTHY6X1G>; Tue, 14 Dec 1999 22:05:22 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Tue, 14 Dec 1999 22:05:21 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)

Timothy,

I challenge your notion that high security equals lethal defense. A private
key used to sign certificates is very different than a stealth aircraft. I
may not be able to revoke a stealth aircraft that falls into the hands of an
adversary.

Frank Balluffi
CertCo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, December 14, 1999 8:23 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: RFC 2527 Physical Security Controls Question


John Kennedy and Lynn Wheeler both made excellent points about the potential

need for absolute top-grade physical security in a commercial CA operation.

It all seems to come down (as always) to risk assessment and balancing the 
cost of security against it's benefits.

In the commercial world, especially in the financial and medical sectors,
the 
potential liability for a CA operator could be enormous, easily justifying 
the cost of physical security measures rivalling that found around weapons
of 
mass destruction.

This brings up an interesting question though...  For a government, it's
very 
easy to designate a resourse as being sufficiently valuable to authorize the

use of deadly force to protect it - try to get close to a stealth aircraft 
sometime. For commercial applications, however, even where billions of 
dollars may be at stake, it's harder (if not impossible) to implement that 
final line of security.  

So for you non-government types, would your CA physical security include 
lethal defenses?  Can anyone think of any application for a non-government
CA 
that would require such defenses?  I'm not talking about just armed guards 
here...  I'm talking about defenses that would kill an unauthorized 
individual who entered protected space BEFORE they did any damage besides 
entering that space. 

Timothy M. Metzinger
Technical Director
Drug Enforcement Administration
Office of Information Systems
[phone]
[phone]


Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09439 for <[e-mail]>; Tue, 14 Dec 1999 18:18:48 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id SAA12007; Tue, 14 Dec 1999 18:22:26 -0800
From: "John C. Kennedy" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Tue, 14 Dec 1999 18:27:56 -0800
MIME-Version: 1.0
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007C_01BF4660.EF7D6340"
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

This is a multi-part message in MIME format.

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


Lethal?  You mean like the deadly nerve gas that is released if you tamper
with a SafeKeyper box?
(I'm *joking*, maybe... :-)  Actually, Steve's plug for the SafeKeyper box
is quite appropriate.  It remains a very elegant piece of
crypto-engineering.

I'd prefer to see a system design that spread the the risk around rather
than require the protection of a single box-of-bits with lethal defenses.
I mean, try explaining to a 60 Minutes news team why the accidental
vaporization of the cleaning lady was an unfortunate result of maintaining
the integrity of your high-assurance, We-are-the-only-source-of-trust.com,
e-commerce CA.

If you start with the assumptions that (1) root keys have a low but
much-greater-than-zero chance of compromise and (2) that they will
probably need to be replaced at the least convenient time, you will
probably end up with a more robust system and a more survivable business
model.

-John

>
> So for you non-government types, would your CA physical security include
> lethal defenses?  Can anyone think of any application for a
> non-government CA
> that would require such defenses?  I'm not talking about just
> armed guards
> here...  I'm talking about defenses that would kill an unauthorized
> individual who entered protected space BEFORE they did any damage
besides
> entering that space.
>
> Timothy M. Metzinger
> Technical Director
> Drug Enforcement Administration
> Office of Information Systems
> [phone]
> [phone]

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w
ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN
U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw
OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l
bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1
vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O
UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC
AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI
JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l
BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ
KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42
bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe
zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC
u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT
TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw
JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp
lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M
9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP
GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE
AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB
AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG
CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl
ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0
cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt
ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6
Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3
OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4
k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY
N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG
A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF
AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMjE1MDIy
NzUzWjAjBgkqhkiG9w0BCQQxFgQUt/AV7TLwRqOWlEBkrRyVIfduxPYwWAYJKoZIhvcNAQkPMUsw
STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF
Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290
IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN
BgkqhkiG9w0BAQEFAASBgAnVtCNCwTw6hd0GhCQv6aEln+2ppTzTV9R7hAUM2M+ODang4ojDjPP3
Wk4tVqJu7znAWx9cH+neK6yH4cJhEod8oUthuKC9l0urVUhJ3kZxtbxzI+nv4OI8lBowUjezYL1b
B56jW202Tg5iNxcZR2dwOKtXeQhLjFCfl6PskITjAAAAAAAA

------=_NextPart_000_007C_01BF4660.EF7D6340--



Received: from lh2.rdc1.sdca.home.com ([e-mail] [24.0.3.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09300 for <[e-mail]>; Tue, 14 Dec 1999 18:15:45 -0800 (PST)
Received: from cx47705a ([24.0.172.52]) by lh2.rdc1.sdca.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <19991215021924.CGDF1336.lh2.rdc1.sdca.home.com@cx47705a>; Tue, 14 Dec 1999 18:19:24 -0800
From: "Mike Davis" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Tue, 14 Dec 1999 18:19:31 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
In-Reply-To: <[e-mail]>

Tim,

Let's hope not!  Strong physical defenses on the order of a SCIF might well
represent an appropriate standard of physical security appropriate for a CA.
We are not talking about needing a huge facility here so the costs might in
fact be quite reasonable.  For the intrusion scenario, recall that the CA
key is protected by cryptographic methods as well.  The CA key should also
be protected within a tamper resistant module that would cause the key to
zeroize if attempts were made to open it.  This seems to work well enough
(is an accepted practice) for top secret keying material.  Would it really
be required to waste the CA compound and the intruder to protect theft of an
encrypted key?

Mike Davis
Senior Security Architect
SAIC
Center for Information Security Technology

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, December 14, 1999 5:23 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: RFC 2527 Physical Security Controls Question


John Kennedy and Lynn Wheeler both made excellent points about the potential
need for absolute top-grade physical security in a commercial CA operation.
It all seems to come down (as always) to risk assessment and balancing the
cost of security against it's benefits.

In the commercial world, especially in the financial and medical sectors,
the
potential liability for a CA operator could be enormous, easily justifying
the cost of physical security measures rivalling that found around weapons
of
mass destruction.

This brings up an interesting question though...  For a government, it's
very
easy to designate a resourse as being sufficiently valuable to authorize the
use of deadly force to protect it - try to get close to a stealth aircraft
sometime. For commercial applications, however, even where billions of
dollars may be at stake, it's harder (if not impossible) to implement that
final line of security.

So for you non-government types, would your CA physical security include
lethal defenses?  Can anyone think of any application for a non-government
CA
that would require such defenses?  I'm not talking about just armed guards
here...  I'm talking about defenses that would kill an unauthorized
individual who entered protected space BEFORE they did any damage besides
entering that space.

Timothy M. Metzinger
Technical Director
Drug Enforcement Administration
Office of Information Systems
[phone]
[phone]



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09002 for <[e-mail]>; Tue, 14 Dec 1999 18:03:44 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA10191; Tue, 14 Dec 1999 18:07:23 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 14 Dec 1999 18:07:44 -0800
To: [e-mail], [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: RFC 2527 Physical Security Controls Question
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:22 PM 12/14/1999 -0500, [e-mail] wrote:
>John Kennedy and Lynn Wheeler both made excellent points about the potential 
>need for absolute top-grade physical security in a commercial CA operation.  
>It all seems to come down (as always) to risk assessment and balancing the 
>cost of security against it's benefits.
>
>In the commercial world, especially in the financial and medical sectors, the 
>potential liability for a CA operator could be enormous, easily justifying 
>the cost of physical security measures rivalling that found around weapons of 
>mass destruction.
>
>This brings up an interesting question though...  For a government, it's very 
>easy to designate a resourse as being sufficiently valuable to authorize the 
>use of deadly force to protect it - try to get close to a stealth aircraft 
>sometime. For commercial applications, however, even where billions of 
>dollars may be at stake, it's harder (if not impossible) to implement that 
>final line of security.  
>
>So for you non-government types, would your CA physical security include 
>lethal defenses?  Can anyone think of any application for a non-government CA 
>that would require such defenses?  I'm not talking about just armed guards 
>here...  I'm talking about defenses that would kill an unauthorized 
>individual who entered protected space BEFORE they did any damage besides 
>entering that space. 

Tim,

I'm a University of California employee, so I will assume I'm not a
"government type" :)

It occurs to me that structures warranting the kind of protection we
are talking about would have several layers to penetrate.  Consequently,
an intruder would likely have to reveal themselves as bearing lethal
means in the course of an attempted apprehension by the "guards".
If the intruder brandishes a gun, I don't believe the guards need an
act of congress to use deadly force.

So we are really talking about an "army-sized" assault upon a facility.
Here, perhaps there are issues to be addressed.  If a breach of the
perimeter causes inner safeguards to kick in, such as (well-marked)
electric fences, so-to-speak, are these means allowed?

In general, are there non-lethal means that are effective when
applied with sufficient extension? (tear gas, paralyzing fields, etc.)

Granted, if the facility could be taken out by a 500 lb bomb delivered
by a private plane, I don't think one will be able to fire anti-aircraft
munitions under threat, but then I'm not an expert in law ;)

___tony___





Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08391 for <[e-mail]>; Tue, 14 Dec 1999 17:36:47 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id RAA28936 for <[e-mail]>; Tue, 14 Dec 1999 17:40:25 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 14 Dec 1999 17:40:08 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id RAA22918; Tue, 14 Dec 1999 17:40:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 14 Dec 1999 17:40:07 -0800
Subject: Re: RFC 2527 Physical Security Controls Question
From: "Aram Perez" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Tim,

> John Kennedy and Lynn Wheeler both made excellent points about the potential
> need for absolute top-grade physical security in a commercial CA operation.
> It all seems to come down (as always) to risk assessment and balancing the
> cost of security against it's benefits.
>
> In the commercial world, especially in the financial and medical sectors, the
> potential liability for a CA operator could be enormous, easily justifying
> the cost of physical security measures rivalling that found around weapons of
> mass destruction.
>
> This brings up an interesting question though...  For a government, it's very
> easy to designate a resourse as being sufficiently valuable to authorize the
> use of deadly force to protect it - try to get close to a stealth aircraft
> sometime. For commercial applications, however, even where billions of
> dollars may be at stake, it's harder (if not impossible) to implement that
> final line of security.
>
> So for you non-government types, would your CA physical security include
> lethal defenses?  Can anyone think of any application for a non-government CA
> that would require such defenses?  I'm not talking about just armed guards
> here...  I'm talking about defenses that would kill an unauthorized
> individual who entered protected space BEFORE they did any damage besides
> entering that space.

The only CA that I'm aware that might have this type of defense system is
one run by DigiCrime, Inc. (http://www.digicrime.com).

;-)

Aram Perez


Received: from imo14.mx.aol.com (imo14.mx.aol.com [152.163.225.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07893 for <[e-mail]>; Tue, 14 Dec 1999 17:19:32 -0800 (PST)
From: [e-mail]
Received: from [e-mail] by imo14.mx.aol.com (mail_out_v24.6.) id 7.0.57e7884f (3875); Tue, 14 Dec 1999 20:22:32 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 20:22:32 EST
Subject: Re: RFC 2527 Physical Security Controls Question
To: [e-mail]
CC: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Windows AOL sub 44

John Kennedy and Lynn Wheeler both made excellent points about the potential 
need for absolute top-grade physical security in a commercial CA operation.  
It all seems to come down (as always) to risk assessment and balancing the 
cost of security against it's benefits.

In the commercial world, especially in the financial and medical sectors, the 
potential liability for a CA operator could be enormous, easily justifying 
the cost of physical security measures rivalling that found around weapons of 
mass destruction.

This brings up an interesting question though...  For a government, it's very 
easy to designate a resourse as being sufficiently valuable to authorize the 
use of deadly force to protect it - try to get close to a stealth aircraft 
sometime. For commercial applications, however, even where billions of 
dollars may be at stake, it's harder (if not impossible) to implement that 
final line of security.  

So for you non-government types, would your CA physical security include 
lethal defenses?  Can anyone think of any application for a non-government CA 
that would require such defenses?  I'm not talking about just armed guards 
here...  I'm talking about defenses that would kill an unauthorized 
individual who entered protected space BEFORE they did any damage besides 
entering that space. 

Timothy M. Metzinger
Technical Director
Drug Enforcement Administration
Office of Information Systems
[phone]
[phone]


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05912 for <[e-mail]>; Tue, 14 Dec 1999 15:07:07 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA05522; Tue, 14 Dec 1999 18:10:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db47c6e14c53b@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 14 Dec 1999 17:21:26 -0500
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Cc: "'PKIX-List '" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>Steve,
>
>In response to your comments, I venture that my suggestion is wholly
>reasonable, I assert again. Concerning the factual basis of your
>counter-argument, the "latest" version  of 2459 merely advises a MODEL
>OF "prioritization and scope  -  for implementers (not operators)"
>concerning the subjectDirectoryAttributes field. (See quote, below.)

I'm not sure what document you're referring to, Peter.  A search for 
"prioritization" in 2459 yields no matches.

>
>In no sense do I read from the normative text that use of the disputed
>field is/was "discouraged". Now we have 2 local uses for subjectAttributes
>- NSA's and the biometric application  - and given we are revising 2459
>for bugs and timeliness of options and important processing steps, it is NOW
>
>appropriate to revise even this language so that X.509's design and intent
>can be realized in the Internet environment. Nothing in the "Internet
>environment" suggests that this quite properly standardized field is
>in someway fundamentally tainted. 2459 specifically encourages operators
>to change or refine the profile, as they see fit, furthermore.

I interpret the phrase "not recommended", reproduced in your quite 
below, as advising against use of this extension.  We don't prohibit 
its use, but we suggest that people not use it.  If we were neutral 
or wished to encourage its use, we have appropriate language for 
expressing those values, and that is not the language used here.

>Ander's bio-vendors group, like NSA/DoD, have a quite appropriate home
>for their  "local material" which binds to the subject. As the material
>is "local" and non-critical (per 2459), the authors/WGs opinion on
>suitability
>of any such local information in an operational id-cert infrastructure is,
>by definition, irrelevant. Local means we here have no particular opinion,
>beyond ensuring interoperability in maintained.

Yes, one can make such decisions and be compliant. However, for 
reasons we have already discussed on the list and documented 
elsewhere, there are good reasons to not incorporate the data in 
question in certs directly.  That is the crux of this argument.
>
>Encouragement or discouragement (at best a non-normative and
>political element of a standards process, subject to subjective
>biases and influence of lobbyists) is perhaps a specifically inappropriate
>position HERE, I venture, given the *explicit* local
>delegation specified in current AND expected versions of PKIX-1.
>
>"The subject directory attributes extension is not recommended as an
>    essential part of this profile, but it may be used in local environ-
>    ments.  This extension MUST be non-critical."

We disagree about the applicability of the explicit "not recommended' 
phrase in this case.  Obviously, it is not a prohibition, and your 
view is that it is not applicable.  My view is otherwise, and is 
based on the specific language cited above.  We are each entitled to 
our views. Good judgement cannot be legislated.

>I do suggest that it is quite appropriate for IETF to assist
>interworking-oriented and PKIX-cert conforming groups formulate standard
>syntaxes to represent information in cert which is designed
>for local, or "card-present/signature-device present" type,
>security enforcement processes. Many existing IETF-blessed LDAP
>attributes are local in scope; PKIX can similarly oblige.

I don't know what criteria the LDAP WG uses in deciding what to 
include in standard attributes. They need not be the same ones used 
by this WG re the contents of certificates.
>
>May I ask a Booz-Allen or DoD party to post a URL here to the excellent
>and current version of SDN706 before we sensibly discuss further
>the use of labels and the authorization issue, re
>subjectDirectoryAttributes?

You may ask, but it's not relevant to the discussion since, as I 
noted earlier, the sensitivity of disclosure of authorization data 
and of personal authentication data are distinct concerns.  One 
cannot infer that a decision by one group to include one type of data 
that it is generally, or specifically appropriate to include another 
type of data.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05890 for <[e-mail]>; Tue, 14 Dec 1999 15:07:03 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA05510; Tue, 14 Dec 1999 18:10:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080bb47c61add950@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 14 Dec 1999 16:10:02 -0500
To: "John C. Kennedy" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Cc: <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

John,

I don't mean to sound like a sales person, but the observations you 
made were part of what motivated the design of the SafeKeyper in the 
early 90s, as a CA crypto module.  To the extent that one can address 
physical security concerns with compact, technical security 
solutions, a lot of money can be saved, and a lot of attacks can be 
thwarted.   FIPS 140-1 does not address all of the concerns that are 
now part of the open literature, even at levels 3 and 4.  I expect 
140-2 will up the ante on evaluation to better address some of these 
attacks.  Fortunately, we designed our module to be resistant to such 
attacks because of our experience in the military crypto arena, and 
our understanding of what one might do with sufficient resources and 
expertise ...

Steve


Received: from mail02-ewr.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03981 for <[e-mail]>; Tue, 14 Dec 1999 12:40:59 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail02-ewr.pilot.net with ESMTP id PAA12993; Tue, 14 Dec 1999 15:44:33 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id PAA11344; Tue, 14 Dec 1999 15:44:32 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256847.00719A57 ; Tue, 14 Dec 1999 15:40:50 -0500
X-Lotus-FromDomain: FDC
To: "John C. Kennedy" <[e-mail]>
cc: "MHenry" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 12:40:50 -0800
Subject: RE: RFC 2527 Physical Security Controls Question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

in the commercial world ... it is almost alwas a cost benefit trade-off ...
there are both penetration exploits and denial-of-service exploits.

a financial operation might have assets where management operations yield a
couple billion a day. if the operation of the infrastructure is dependent on
security features ... then crippling the security infrastructure might disable
the ability to perform financial management transactions and result in the
significant losses for the duration of the security infrastructure outage.

theft because of security problems not only may put reputation at risk, but may
represent a problem in any court &/or litigation. Litigating theft of
trade-secrets valued at several billion can be put at risk if security
procedures aren't proportional to the value of the trade-secret (it was
explained to me as analogous to not having fence around swimming pool and being
liable if somebody fell in ... having value of several billion out in the open,
of course somebody will steal it ... and it won't really be their fault).
claimed value of several billion for trade-secrets may necessitate demonstrating
security procedures valued at tens of millions or more ... and have no
obvious/known weakness (the bigger the value the higher the fence).




Received: from gandalf.trustpoint.com (IDENT:[e-mail] [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02742 for <[e-mail]>; Tue, 14 Dec 1999 11:25:34 -0800 (PST)
Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id LAA09698; Tue, 14 Dec 1999 11:29:10 -0800
From: "John C. Kennedy" <[e-mail]>
To: "MHenry" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2527 Physical Security Controls Question
Date: Tue, 14 Dec 1999 11:34:40 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <408016D0F599D311A82B0008C7F450FD0B4267@EXCHNG-FAIRFAX>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal

Michael,

I do not think it is unreasonable to assume that a CA's adversaries might be
national services, organized crime, or other organizations of similar
strength.  With attacks based on differential power analysis
(http://www.cryptography.com/dpa/Dpa.pdf) and related techniques becoming at
least theoretically possible, a TEMPEST-shielded SCIF-style design might not
be a bad idea.

While this might be overkill for a private enterprise CA, a commercial CA
might very well find such protection measures reasonable and worth the cost.
Remember that the compromise of the CA's private key may never become
evident to the CA.  Also, given the loss of credibility that would be
incurred, the CA might be very reluctant to go through the very onerous task
of revoking and replacing its root keys.  I am fairly certain that
obligations to the CA's subscribers as well as its stockholders would be
part of the decision process.  As a point of reference, I have heard a
number of anecdotal stories about large banks that decided to simply absorb
losses from electronic break-ins rather than make such situations public and
risk loss of consumer confidence and/or higher insurance rates.

-John Kennedy
[e-mail]

> -----Original Message-----
> From: MHenry [mailto:[e-mail]]
> Sent: Friday, December 10, 1999 11:08 AM
> To: '[e-mail]'
> Cc: '[e-mail]'
> Subject: RFC 2527 Physical Security Controls Question
>
>
> All,
>
> RFC 2527( CP and CPS Framework), 4.5.1,Physical Security
> Controls, includes
> site location and CA facility construction , as topics that should be
> considered in a CP or CPS.
>
> I am in the process of writing a CP/CPS and I am looking for standards
> that would apply to this section.
>
> Can anyone point me towards an industry/private sector/civil side of
> government "standard" for hardening a facility. I am particularly looking
> for some sort of of construction standards that would permit me to
> distinguish between, for example, a CA facility that might fairly be
> described as being built to support a "high" standard of
> security/assurance
> and one built to a "medium" standard. Can it be wood? brick? steel? one
> story? windows?
> etc?
>
> I spent decades concerned with SCIF designs and vulnerabilities but
> I don't think that is what I need here. My potential adversaries are not
> national services and what I am protecting is not of such persistent high
> value to most people.
>
> Thanks,
> Michael C. Henry
> Principal Member of the Technical Staff
> Performance Engineering Corporation
> 3949 Pender Drive
> Fairfax, VA
>
>
>
>



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29632 for <[e-mail]>; Tue, 14 Dec 1999 08:23:40 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.4) id TAA02695; Tue, 14 Dec 1999 19:27:18 +0300 (MSK)
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma002659; Tue, 14 Dec 99 19:26:20 +0300
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 19:26:25 +0300
From: Pavel Krylov <[e-mail]>
Organization: TrustWorks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Biskupic <[e-mail]>
CC: [e-mail]
Subject: Re: cert == crl
References: <00a101bf464c$dfcff570$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi again,
please look in message body

Tom Biskupic wrote:
> 
> Pavel,
> 
> If you take the assumption that CRLs from only one issuer are placed in a
> given DP then could you just compare the DP in the CDP with the DP in the
> IDP (or CRLScope Extension) of the CRL?

Please, Tom, I don't understand the relations between your question and
mine.
You are talking about comparing of DP in CDP and IDP. That is not a
problem,
I suppose. FPDAM claims only one rule of it - at least one part of DP in
IDP ( if it's present ) must match with a part of DP in CDP. But my 
questions is how I need ( what are the rules ) to compare DN and GN in
CRL case? ( please, look at my previous message ).

> This seems kinda naive to me but will it work? Does it make sense/is it
> valid for multiple issuers to place CRLs in the same DP?

Sorry, but that is not my question. Tom, if you have more questions, may
be
it would be better to move them into private messages, what do you
think?

> Tom Biskupic

Pavel.

> > -----Original Message-----
> > From: Pavel Krylov [mailto:[e-mail]]
> > Sent: Tuesday, December 14, 1999 12:48 PM
> > To: Tom Biskupic
> > Cc: [e-mail]
> > Subject: Re: cert == crl
> >
> >
> >
> > Hi Tom,
> > may be I wrote my questions not clearly ( sorry for that ), but my
> > misunderstanding lies not in obtaining of a proper CRL by CRLDPs
> > certificate extension. It lies when I've obtained some CRLs by
> > crl distribution point ( pointed in CRLDPs certificate extension )
> > and I need to choose appropriate CRLs from that amount. One of
> > necessary tests is to check that crl.issuer matches with the cRLIssuer
> > ( which is in CRLDPs extension ). How I noticed in my
> > previous letters,
> > crl.issuer is DN, but cRLIssuer is GN, so I'm trying to discover all
> > limitations on their comparing. Hope, I make my problem clear.
> >
> > Pavel.
> >
> > Tom Biskupic wrote:
> > >
> > > Pavel, Russ,
> > >
> > > If I understand this correctly, the Location where the CRL
> > can be obtained
> > > is either determined by the DP or if the DP is absent by
> > the CRL Issuer
> > > Name.
> > >
> > > In the same way that you can have a DP Name that is a URI
> > or an email
> > > address etc couldn't the CRL Issuer name also be a URI? I
> > know it's a bit of
> > > a strange case but imagine the CRL Issuer certificate had
> > no subject but
> > > only a subject alternative name.
> > >
> > > In terms of Pavel's question - if both DP and issuer are
> > specified aren't
> > > they both quite independant? ie the location of the CRL
> > could be quite
> > > different to what is implied by the CRL Issuer name(s).
> > >
> > > Tom Biskupic
> > >
> > > > -----Original Message-----
> > > > From: Pavel Krylov [mailto:[e-mail]]
> > > > Sent: Tuesday, December 14, 1999 10:31 AM
> > > > Cc: [e-mail]
> > > > Subject: Re: cert == crl
> > > >
> > > >
> > > >
> > > > Thank you Russ for your reply. Okay, I understood the case I had
> > > > written.
> > > > Could you answer me the same question, if certificate's CRLDP
> > > > extension
> > > > had Distribution Point in it and crlIssuer in the same time. What
> > > > restrictions are applied to the crlIssuer?
> > > >
> > > > Thanks a lot.
> > > >
> > > > Pavel
> > > >
> > > > Russ Housley wrote:
> > > > >
> > > > > If the CRLIssuer GN is a DirectoryName, then the CRL can be
> > > > found in the
> > > > > LDAP or X.500 Directory.  I think that all of the other
> > > > cases are ambiguious.
> > > > >
> > > > > Russ
> > > > >
> > > > > At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
> > > > > >Hi all,
> > > > > >
> > > > > >I would be grateful if someone helped me with one case in CRL
> > > > > >processing.
> > > > > >A certificate has some information how to find appropriate CRLs
> > > > > >to check revokation status of the certificate. This
> > > > information includes
> > > > > >certificate issuer name (DN), alternative issuer name (GN)
> > > > and CRLDPs
> > > > > >extension, which in its order includes distribution
> > point (dp, i.e.
> > > > > >a choice between fullName(GN) and
> > nameRelativeToCRLIssuer (rdn) ),
> > > > > >reason codes and cRLIssuer name (GN).
> > > > > >
> > > > > >Okay, how I understand CRL processing begins from
> > certificate, i.e.
> > > > > >getting proper information to find appropriate CRL.
> > > > Suppose, we have
> > > > > >a certificate with following fields ( only mentioned to CRL ):
> > > > > >
> > > > > >         cert
> > > > > >          |_ issuer (DN)
> > > > > >          |_ altIssuer (GN)
> > > > > >          |_ certExtensions
> > > > > >             |_ CRLDPs extension
> > > > > >                |_ crldp
> > > > > >                   |_ cRLIssuer (GN)
> > > > > >
> > > > > >i.e. dp is absent, but cRLIssuer is present in CRLDPs
> > extension.
> > > > > >In this case I have a name of issuer of needed CRL, but it is
> > > > > >represented by GN type. Say, I have some CRLs to try
> > to apply them
> > > > > >for the certificate. But each CRL has issuer (DN) and
> > > > altIssuer (GN).
> > > > > >So my question is how cRLIssuer(GN) is supposed to be
> > compared with
> > > > > >crl.issuer(DN) and crl.altIssuer(GN)??
> > > > > >
> > > > > >Any ideas?
> > > > > >
> > > > > >Thanks a lot.
> > > > > >
> > > > > >Pavel Krylov
> > > >
> >


Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4-ext.email.verio.net [129.250.36.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29055 for <[e-mail]>; Tue, 14 Dec 1999 08:01:33 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMQMXI00.FI2 for <[e-mail]>; Tue, 14 Dec 1999 15:56:06 +0000 
Received: from nma.com ([209.21.28.70]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMQMWG00.GB1 for <[e-mail]>; Tue, 14 Dec 1999 15:55:28 +0000 
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 07:56:36 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Shifting around the risk burden, Re:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All:

This is a reply to a private comment I received,
which may be useful here.

Cheers -- Ed Gerck

-------- Original Message --------
Subject: Re: Shifting around the risk burden, Re: Consensus Text for
Date: Mon, 13 Dec 1999 00:41:01 -0800
From: Ed Gerck <[e-mail]>

,,, wrote:

> I doubt the correctness of the quoted assertion from X.509:
>
> >A number of practical methods
> >are available for the user to hold his private key in a
> >manner that provides adequate security
>
> It depends on what "adequate" means, but there are too many published
> attacks on known systems to leave me at all comfortable with the practical
> methods I'm aware of.
>

Yes, that affirmation is weak -- and it was put there IMO in order to
try to preempt doubts. However, in discussing X.509/PKIX in order
to try to develop a better base for interoperation, which is my 
main objective, I have found it more useful to hold to one part of
the PKIX spec while verifying fallacies in another -- rather than trying
to show that both (or, more) parts are wrong.

What is at stake here is the Grandma scenario, where Denis insists that
X.509/PKIX can be used to deal with the content of what was signed,
as well as its intent, which are respectively second- and third-order removed
from the act of signing a message *digest* -- which is all that X.509/PKIX
deals with.  The fact that I am fully aware (assuming this much) that I am
signing a message digest, does not mean that I agree with the content
and also does not mean that I had the intent of declaring my definitive
agreement to it, irrebuttably.

So, first, I need to show that (above) -- then, the fact that not even
that modicum of trust is granted. I have to leave to a separate argument
the fact you point out That I cannot assume I was fully aware of signing
a message digest -- my key might have been stolen, for example, and I
might have never signed it.

Now, if I would question this first then people may say that I am being
"impractical" because everyone knows that we all use credit-cards on the
Internet and it mostly works, that business has risks anyway, etc.

So, the real problem needs to be tackled first IMO -- that X.509/PKIX is
not about validation of message *content* or *intent*, it is about
authentication of credentials as data.  The semiotic confusion is between
the message as data (syntax -- that carries values, which are always
uninterpreted) and the message as "code" (semantics -- that carries
instructions, which can only be functional after interpreted according
to a trusted context).  X.509/PKIX  deals with data, not with "code"
--  X.509 is moot on validation procedures for "code" aspects.  Thus,
it cannot be applied to draw conclusions on that which it outrightly 
does not represent.

Cheers,

Ed Gerck


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28949 for <[e-mail]>; Tue, 14 Dec 1999 08:00:31 -0800 (PST)
Received: by balinese.baltimore.ie; id QAA22898; Tue, 14 Dec 1999 16:04:04 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma022793; Tue, 14 Dec 99 16:03:09 GMT
Received: from crown (crown.baltimore.ie [192.168.21.124]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id QAA28100; Tue, 14 Dec 1999 16:03:08 GMT
From: "Tom Biskupic" <[e-mail]>
To: "'Pavel Krylov'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cert == crl
Date: Tue, 14 Dec 1999 16:04:15 -0000
Message-ID: <00a101bf464c$dfcff570$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>

Pavel,

If you take the assumption that CRLs from only one issuer are placed in a
given DP then could you just compare the DP in the CDP with the DP in the
IDP (or CRLScope Extension) of the CRL?

This seems kinda naive to me but will it work? Does it make sense/is it
valid for multiple issuers to place CRLs in the same DP?

Tom Biskupic

> -----Original Message-----
> From: Pavel Krylov [mailto:[e-mail]]
> Sent: Tuesday, December 14, 1999 12:48 PM
> To: Tom Biskupic
> Cc: [e-mail]
> Subject: Re: cert == crl
>
>
>
> Hi Tom,
> may be I wrote my questions not clearly ( sorry for that ), but my
> misunderstanding lies not in obtaining of a proper CRL by CRLDPs
> certificate extension. It lies when I've obtained some CRLs by
> crl distribution point ( pointed in CRLDPs certificate extension )
> and I need to choose appropriate CRLs from that amount. One of
> necessary tests is to check that crl.issuer matches with the cRLIssuer
> ( which is in CRLDPs extension ). How I noticed in my
> previous letters,
> crl.issuer is DN, but cRLIssuer is GN, so I'm trying to discover all
> limitations on their comparing. Hope, I make my problem clear.
>
> Pavel.
>
> Tom Biskupic wrote:
> >
> > Pavel, Russ,
> >
> > If I understand this correctly, the Location where the CRL
> can be obtained
> > is either determined by the DP or if the DP is absent by
> the CRL Issuer
> > Name.
> >
> > In the same way that you can have a DP Name that is a URI
> or an email
> > address etc couldn't the CRL Issuer name also be a URI? I
> know it's a bit of
> > a strange case but imagine the CRL Issuer certificate had
> no subject but
> > only a subject alternative name.
> >
> > In terms of Pavel's question - if both DP and issuer are
> specified aren't
> > they both quite independant? ie the location of the CRL
> could be quite
> > different to what is implied by the CRL Issuer name(s).
> >
> > Tom Biskupic
> >
> > > -----Original Message-----
> > > From: Pavel Krylov [mailto:[e-mail]]
> > > Sent: Tuesday, December 14, 1999 10:31 AM
> > > Cc: [e-mail]
> > > Subject: Re: cert == crl
> > >
> > >
> > >
> > > Thank you Russ for your reply. Okay, I understood the case I had
> > > written.
> > > Could you answer me the same question, if certificate's CRLDP
> > > extension
> > > had Distribution Point in it and crlIssuer in the same time. What
> > > restrictions are applied to the crlIssuer?
> > >
> > > Thanks a lot.
> > >
> > > Pavel
> > >
> > > Russ Housley wrote:
> > > >
> > > > If the CRLIssuer GN is a DirectoryName, then the CRL can be
> > > found in the
> > > > LDAP or X.500 Directory.  I think that all of the other
> > > cases are ambiguious.
> > > >
> > > > Russ
> > > >
> > > > At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
> > > > >Hi all,
> > > > >
> > > > >I would be grateful if someone helped me with one case in CRL
> > > > >processing.
> > > > >A certificate has some information how to find appropriate CRLs
> > > > >to check revokation status of the certificate. This
> > > information includes
> > > > >certificate issuer name (DN), alternative issuer name (GN)
> > > and CRLDPs
> > > > >extension, which in its order includes distribution
> point (dp, i.e.
> > > > >a choice between fullName(GN) and
> nameRelativeToCRLIssuer (rdn) ),
> > > > >reason codes and cRLIssuer name (GN).
> > > > >
> > > > >Okay, how I understand CRL processing begins from
> certificate, i.e.
> > > > >getting proper information to find appropriate CRL.
> > > Suppose, we have
> > > > >a certificate with following fields ( only mentioned to CRL ):
> > > > >
> > > > >         cert
> > > > >          |_ issuer (DN)
> > > > >          |_ altIssuer (GN)
> > > > >          |_ certExtensions
> > > > >             |_ CRLDPs extension
> > > > >                |_ crldp
> > > > >                   |_ cRLIssuer (GN)
> > > > >
> > > > >i.e. dp is absent, but cRLIssuer is present in CRLDPs
> extension.
> > > > >In this case I have a name of issuer of needed CRL, but it is
> > > > >represented by GN type. Say, I have some CRLs to try
> to apply them
> > > > >for the certificate. But each CRL has issuer (DN) and
> > > altIssuer (GN).
> > > > >So my question is how cRLIssuer(GN) is supposed to be
> compared with
> > > > >crl.issuer(DN) and crl.altIssuer(GN)??
> > > > >
> > > > >Any ideas?
> > > > >
> > > > >Thanks a lot.
> > > > >
> > > > >Pavel Krylov
> > >
>



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26130 for <[e-mail]>; Tue, 14 Dec 1999 04:45:01 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.4) id PAA23983; Tue, 14 Dec 1999 15:48:38 +0300 (MSK)
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma023949; Tue, 14 Dec 99 15:47:48 +0300
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 15:47:53 +0300
From: Pavel Krylov <[e-mail]>
Organization: TrustWorks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Biskupic <[e-mail]>
CC: [e-mail]
Subject: Re: cert == crl
References: <009601bf462e$991fa0d0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tom,
may be I wrote my questions not clearly ( sorry for that ), but my 
misunderstanding lies not in obtaining of a proper CRL by CRLDPs 
certificate extension. It lies when I've obtained some CRLs by
crl distribution point ( pointed in CRLDPs certificate extension )
and I need to choose appropriate CRLs from that amount. One of 
necessary tests is to check that crl.issuer matches with the cRLIssuer
( which is in CRLDPs extension ). How I noticed in my previous letters,
crl.issuer is DN, but cRLIssuer is GN, so I'm trying to discover all
limitations on their comparing. Hope, I make my problem clear.

Pavel.

Tom Biskupic wrote:
> 
> Pavel, Russ,
> 
> If I understand this correctly, the Location where the CRL can be obtained
> is either determined by the DP or if the DP is absent by the CRL Issuer
> Name.
> 
> In the same way that you can have a DP Name that is a URI or an email
> address etc couldn't the CRL Issuer name also be a URI? I know it's a bit of
> a strange case but imagine the CRL Issuer certificate had no subject but
> only a subject alternative name.
> 
> In terms of Pavel's question - if both DP and issuer are specified aren't
> they both quite independant? ie the location of the CRL could be quite
> different to what is implied by the CRL Issuer name(s).
> 
> Tom Biskupic
> 
> > -----Original Message-----
> > From: Pavel Krylov [mailto:[e-mail]]
> > Sent: Tuesday, December 14, 1999 10:31 AM
> > Cc: [e-mail]
> > Subject: Re: cert == crl
> >
> >
> >
> > Thank you Russ for your reply. Okay, I understood the case I had
> > written.
> > Could you answer me the same question, if certificate's CRLDP
> > extension
> > had Distribution Point in it and crlIssuer in the same time. What
> > restrictions are applied to the crlIssuer?
> >
> > Thanks a lot.
> >
> > Pavel
> >
> > Russ Housley wrote:
> > >
> > > If the CRLIssuer GN is a DirectoryName, then the CRL can be
> > found in the
> > > LDAP or X.500 Directory.  I think that all of the other
> > cases are ambiguious.
> > >
> > > Russ
> > >
> > > At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
> > > >Hi all,
> > > >
> > > >I would be grateful if someone helped me with one case in CRL
> > > >processing.
> > > >A certificate has some information how to find appropriate CRLs
> > > >to check revokation status of the certificate. This
> > information includes
> > > >certificate issuer name (DN), alternative issuer name (GN)
> > and CRLDPs
> > > >extension, which in its order includes distribution point (dp, i.e.
> > > >a choice between fullName(GN) and nameRelativeToCRLIssuer (rdn) ),
> > > >reason codes and cRLIssuer name (GN).
> > > >
> > > >Okay, how I understand CRL processing begins from certificate, i.e.
> > > >getting proper information to find appropriate CRL.
> > Suppose, we have
> > > >a certificate with following fields ( only mentioned to CRL ):
> > > >
> > > >         cert
> > > >          |_ issuer (DN)
> > > >          |_ altIssuer (GN)
> > > >          |_ certExtensions
> > > >             |_ CRLDPs extension
> > > >                |_ crldp
> > > >                   |_ cRLIssuer (GN)
> > > >
> > > >i.e. dp is absent, but cRLIssuer is present in CRLDPs extension.
> > > >In this case I have a name of issuer of needed CRL, but it is
> > > >represented by GN type. Say, I have some CRLs to try to apply them
> > > >for the certificate. But each CRL has issuer (DN) and
> > altIssuer (GN).
> > > >So my question is how cRLIssuer(GN) is supposed to be compared with
> > > >crl.issuer(DN) and crl.altIssuer(GN)??
> > > >
> > > >Any ideas?
> > > >
> > > >Thanks a lot.
> > > >
> > > >Pavel Krylov
> >


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25719 for <[e-mail]>; Tue, 14 Dec 1999 04:23:58 -0800 (PST)
Received: by balinese.baltimore.ie; id MAA21271; Tue, 14 Dec 1999 12:27:31 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma021212; Tue, 14 Dec 99 12:26:41 GMT
Received: from crown (crown.baltimore.ie [192.168.21.124]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id MAA11881; Tue, 14 Dec 1999 12:26:26 GMT
From: "Tom Biskupic" <[e-mail]>
To: "'Pavel Krylov'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: cert == crl
Date: Tue, 14 Dec 1999 12:27:33 -0000
Message-ID: <009601bf462e$991fa0d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>

Pavel, Russ,

If I understand this correctly, the Location where the CRL can be obtained
is either determined by the DP or if the DP is absent by the CRL Issuer
Name.

In the same way that you can have a DP Name that is a URI or an email
address etc couldn't the CRL Issuer name also be a URI? I know it's a bit of
a strange case but imagine the CRL Issuer certificate had no subject but
only a subject alternative name.

In terms of Pavel's question - if both DP and issuer are specified aren't
they both quite independant? ie the location of the CRL could be quite
different to what is implied by the CRL Issuer name(s).

Tom Biskupic

> -----Original Message-----
> From: Pavel Krylov [mailto:[e-mail]]
> Sent: Tuesday, December 14, 1999 10:31 AM
> Cc: [e-mail]
> Subject: Re: cert == crl
>
>
>
> Thank you Russ for your reply. Okay, I understood the case I had
> written.
> Could you answer me the same question, if certificate's CRLDP
> extension
> had Distribution Point in it and crlIssuer in the same time. What
> restrictions are applied to the crlIssuer?
>
> Thanks a lot.
>
> Pavel
>
> Russ Housley wrote:
> >
> > If the CRLIssuer GN is a DirectoryName, then the CRL can be
> found in the
> > LDAP or X.500 Directory.  I think that all of the other
> cases are ambiguious.
> >
> > Russ
> >
> > At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
> > >Hi all,
> > >
> > >I would be grateful if someone helped me with one case in CRL
> > >processing.
> > >A certificate has some information how to find appropriate CRLs
> > >to check revokation status of the certificate. This
> information includes
> > >certificate issuer name (DN), alternative issuer name (GN)
> and CRLDPs
> > >extension, which in its order includes distribution point (dp, i.e.
> > >a choice between fullName(GN) and nameRelativeToCRLIssuer (rdn) ),
> > >reason codes and cRLIssuer name (GN).
> > >
> > >Okay, how I understand CRL processing begins from certificate, i.e.
> > >getting proper information to find appropriate CRL.
> Suppose, we have
> > >a certificate with following fields ( only mentioned to CRL ):
> > >
> > >         cert
> > >          |_ issuer (DN)
> > >          |_ altIssuer (GN)
> > >          |_ certExtensions
> > >             |_ CRLDPs extension
> > >                |_ crldp
> > >                   |_ cRLIssuer (GN)
> > >
> > >i.e. dp is absent, but cRLIssuer is present in CRLDPs extension.
> > >In this case I have a name of issuer of needed CRL, but it is
> > >represented by GN type. Say, I have some CRLs to try to apply them
> > >for the certificate. But each CRL has issuer (DN) and
> altIssuer (GN).
> > >So my question is how cRLIssuer(GN) is supposed to be compared with
> > >crl.issuer(DN) and crl.altIssuer(GN)??
> > >
> > >Any ideas?
> > >
> > >Thanks a lot.
> > >
> > >Pavel Krylov
>



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21952 for <[e-mail]>; Tue, 14 Dec 1999 02:28:17 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.4) id NAA18607; Tue, 14 Dec 1999 13:31:48 +0300 (MSK)
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma018577; Tue, 14 Dec 99 13:31:24 +0300
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 1999 13:31:29 +0300
From: Pavel Krylov <[e-mail]>
Organization: TrustWorks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: cert == crl
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thank you Russ for your reply. Okay, I understood the case I had
written.
Could you answer me the same question, if certificate's CRLDP extension
had Distribution Point in it and crlIssuer in the same time. What 
restrictions are applied to the crlIssuer?

Thanks a lot.

Pavel

Russ Housley wrote:
> 
> If the CRLIssuer GN is a DirectoryName, then the CRL can be found in the
> LDAP or X.500 Directory.  I think that all of the other cases are ambiguious.
> 
> Russ
> 
> At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
> >Hi all,
> >
> >I would be grateful if someone helped me with one case in CRL
> >processing.
> >A certificate has some information how to find appropriate CRLs
> >to check revokation status of the certificate. This information includes
> >certificate issuer name (DN), alternative issuer name (GN) and CRLDPs
> >extension, which in its order includes distribution point (dp, i.e.
> >a choice between fullName(GN) and nameRelativeToCRLIssuer (rdn) ),
> >reason codes and cRLIssuer name (GN).
> >
> >Okay, how I understand CRL processing begins from certificate, i.e.
> >getting proper information to find appropriate CRL. Suppose, we have
> >a certificate with following fields ( only mentioned to CRL ):
> >
> >         cert
> >          |_ issuer (DN)
> >          |_ altIssuer (GN)
> >          |_ certExtensions
> >             |_ CRLDPs extension
> >                |_ crldp
> >                   |_ cRLIssuer (GN)
> >
> >i.e. dp is absent, but cRLIssuer is present in CRLDPs extension.
> >In this case I have a name of issuer of needed CRL, but it is
> >represented by GN type. Say, I have some CRLs to try to apply them
> >for the certificate. But each CRL has issuer (DN) and altIssuer (GN).
> >So my question is how cRLIssuer(GN) is supposed to be compared with
> >crl.issuer(DN) and crl.altIssuer(GN)??
> >
> >Any ideas?
> >
> >Thanks a lot.
> >
> >Pavel Krylov


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA01431 for <[e-mail]>; Mon, 13 Dec 1999 19:29:25 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <YP1K7XX8>; Mon, 13 Dec 1999 19:28:11 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Date: Mon, 13 Dec 1999 19:28:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

David,

Please do not take any real exception to my language concerning
the synchronization of an acceptable use of the PKIX
subjectDirectoryAttributes field and the use made by a given
user community (NSA's various DoD-related customers.) That
field is suitably generic; DoD/NSA is to be commended for
arriving at its availability, and making use of it for
purposes critical to US national security interests.

Our own QC is written in an interesting & revealing manner - it expects 
to be sub-profiled, so "QC+local-extensions" meet the needs of
particular user communities.  Each of these include a subset of 
the internet community who are bound to one or more public or
private legal systems, depending upon context.

Should one such community, which will *by definition* fail to
be interoperable at the intended legal level with the entire
Internet community, choose  to mandate a particular biometric
inline data requirement tuned to the choice of biometric
protection afforded a particular national id smartcard,
then the architects have the perfect place to put such, non-naming,
but subject-oriented information in the PKIX-conforming cert, using
the sub-profiling authority provided by, and required by, 
QC. X.509 is pretty explicit about allowing use of such as
photo material in certs. An "animated gif", consisting of a 
facial profile base image using inline data, with more detail 
arriving from the net could  be a sensible data size compromise.

I assume those the US folk who wrote PKIX were aware of NSA 
requirements, and accommodated those needs. Just as MISSI designers chose
to then utilize the field for local-community authorization purposes,
so can other now use the field for biometric authorization,
or using biometrics to increase the confidence in user identification, 
as they see fit, as standardized by X.509.  

If nothing else, PKIX could assist such sub-profiling by
providing an OID arc, for registering attribute definitions
tuned to PKIX purposes. User organizations can of course
define their own attributes, for non-PKIX purposes,
pursuant to their sub-profiling responsibilities.

 


-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Monday, December 13, 1999 8:43 AM
To: [e-mail]
Subject: Re: Accessing/selecting biometrics was: Stray Poll:
Finger-printsin QCs



MISSI/Fortezza documentation is available, as always, from
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html

That includes the latest (12 May) versions of SDN.706: "X.509
Certificate and Certificate Revocation List Profiles and Certification
Path Processing Rules for MISSI" and SDN.801: "MISSI Access Control
Concept and Mechanisms".

I take mild exception to Peter's characterization that the
subjectDirectoryAttributes extension is somehow slanted toward MISSI's
use of the extension as a container for the "prbacInfo",
"sigOrKMPrivileges", and "commPrivileges" data structures.  Those data
structures are oriented toward a particular user community, but it is
silly to imply that the extension itself is anything other than
absolutely generic.

I agree with Steve that the place to define biometric interoperability
specifications is within a biometric interest group (open/closed
consortium or IETF BOF/WG), not within PKIX.  PKIX should provide a
container (sDA or hash+URL, neither of which are specific to biometric
data) but no more.

Dave Kemp



> From: Ed Gerck <[e-mail]>
> 
> Peter Williams wrote:
> 
> > May I ask a Booz-Allen or DoD party to post a URL here to the excellent
> > and current version of SDN706 before we sensibly discuss further
> > the use of labels and the authorization issue, re 
subjectDirectoryAttributes?
> 
> I second that. I can host a public copy, if needed.  This helps the 
interoperation
> goal.
> 
> Cheers,
> 
> Ed Gerck
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26530 for <[e-mail]>; Mon, 13 Dec 1999 18:50:57 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <YP1K7XVD>; Mon, 13 Dec 1999 18:49:44 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Hiroyuki Sakakibara'" <[e-mail]>, [e-mail]
Subject: RE: certificate which has both AIA and CRL DPs
Date: Mon, 13 Dec 1999 18:49:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi,
    The certificate that you are planning to issue is perfectly
legal. Unfortunately, the answer to Question2 is not specified
in the standards. It is up to the application to decide how it
wants to prioritize the different validation methods.

It is perfectly legal for the application to ask in the following
order:

OCSP server-2
CRL DP-1
OCSP server-1
CRL DP-2

or any other order it chooses.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[e-mail]]
> Sent: Tuesday, December 07, 1999 6:47 PM
> To: [e-mail]
> Subject: certificate which has both AIA and CRL DPs
> 
> 
> Hello
> 
> I would like to generate a certificate which has
> both AIA and CRL DPs.
> 
> Question1 : In RFC2459 specification, is this 
>                     certificate legal or illegal ?
> 
> Question2 : If this certificate is legal, how does it describe the
>                      order of priority to process those extensions?
> 
> For example, 
> ------------------------------------------------
> 1st.                        OCSP server-1
> 2nd.                       OCSP server-2
> 3rd.                       CRL DP-1
> 4th.                        CRL DP-2
> 
> or
> 
> 1st.                        OCSP server-1
> 2nd.                       CRL DP-1
> 3rd.                        OCSP server-2
> 4th.                        CRL DP-2
> 
> etc ...
> ------------------------------------------------
> 
> Is a new extension(or any scheme) which describes the
> list of these priorities needed?
> 
> like this
> 
> LIST  {
> 1st    use AIA's 1st element,
> 2nd   use CRL DPs 1st element,
> 3rd    use "other method",
> 4th    use  AIA's 2nd element,
> 5th    use  CRL DPs 2nd element,
> etc ...
> }
> 
> Please, can anyone help? 
> 
> Hioryuki Sakakibara
> 
> =========================================
> Hiroyuki Sakakibara
> Research Engineer
> Information Security Department
> Mitsubishi Electric Corporation
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
> PHONE: [phone]
> FAX: [phone]
> ==========================================
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19836 for <[e-mail]>; Mon, 13 Dec 1999 18:08:11 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <YP1K7XT2>; Mon, 13 Dec 1999 18:06:47 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Q: Are repeated OIDs allowed in the AIA extension?
Date: Mon, 13 Dec 1999 18:06:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Russ,
    The clarification of AIA is pretty good. However, it doesn't
address Terry's question, which is can there be an AIA extension,
which has multiple OIDs with an accessMethod of id-ad-ocsp and
different accessLocations.

    We have definitely assumed that you can have this kind of
a situation, if you have multple URLs that point to legitimate
OCSP responders for your server.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, December 08, 1999 8:02 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Q: Are repeated OIDs allowed in the AIA extension?
> 
> 
> Terry:
> 
> We tried to clarify AIA in the revision to RFC 2459.  Please review 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-
> 00.txt.  If 
> you still have questions, please post them in the context of 
> the new AIA text.
> 
> Russ
> 
> At 05:14 PM 12/7/99 -0800, Terry Hayes wrote:
> >All,
> >
> >This is a question about the constraints on the contents of the
> >Authority Information Access extension as defined in RFC 
> 2459.  This the
> >data value in this extension consists of a sequence of 
> OID/GeneralName
> >pairs.  The OID portion of the pair indicates the purpose of 
> the value,
> >while the GeneralName indicates where and (in some cases) 
> the protocol
> >to use to perform other operations related to the certificate.  The
> >current RFC does not specify any restriction on the values 
> stored in the
> >extension.  In particular, it doesn't seem to rule out pairs in the
> >sequence that have the same OID.
> >
> >I can imagine certificates that are issued that make use of the
> >capability to associate multiple location values (names) 
> with a single
> >OID.  For example:
> >
> >      OCSPResponder : http://ocsp.company.com
> >      OCSPResponder : http://ocsp.default.com
> >
> >This set of values in the AIA extension might indicate that two OCSP
> >responders are available for checking certificate status.  Also:
> >
> >      OCSPResponder: http://ocsp.company.com
> >      OCSPResponder: tcpmsg://ocsp.company.com:1111
> >
> >This configuration might indicate that OCSP is available over two
> >protocols (HTTP POST and a hypothetical standard TCP message 
> protocol).
> >The certificate client would be allowed to choose on that it has
> >implemented.
> >
> >Is this sort of repeated value allowed in AIA?
> >
> >Terry Hayes
> >[e-mail]
> 


Received: from oznet15.ozemail.com.au (oznet15.ozemail.com.au [203.2.192.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15423 for <[e-mail]>; Mon, 13 Dec 1999 16:22:39 -0800 (PST)
Received: from dallaptop (slsdn4p50.ozemail.com.au [210.84.9.242]) by oznet15.ozemail.com.au (8.9.0/8.6.12) with SMTP id LAA16615; Tue, 14 Dec 1999 11:26:05 +1100 (EST)
From: "Lyal Collins" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Online PIN & Server Wallet
Date: Tue, 14 Dec 1999 11:23:46 +1100
Message-ID: <000301bf45c9$7c807680$f20954d2@dallaptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <006a01bf45c3$10a2b0a0$[e-mail]>

I would have phrased it "control risk cost effectively".
AADS is the nearest I have seen to a cost effective PKI model, the rest cost
too much to implement and to operate.

Lyal

> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[e-mail]]
> Sent: Tuesday, 14 December 1999 10:38
> To: Lyal Collins; [e-mail]
> Cc: [e-mail]
> Subject: RE: Online PIN & Server Wallet
>
>
>
> > Who cares about "not in the spirit of PKI"?
>
> > I want to see affordable implementations and affordable
> operational models
> > for PKI, otherwise, don't waste our time with it.
>
> I thought that was the spirit of PKI!
>
> If I get a bill from my telco it is the telco that is authenticating
> itself to me as a corporate entity, not Kent the Clerk.
>
> One of the problems with the endless (and more than tedious)
> discussions of
> non repudiation and biometrics that infest the list could be avoided if
> people would recognize that:
>
> 1) The objective is to _control_ risk. Eliminating every possible
> threat is
> 	not necessary to achieve that objective.
>
> 2) Non repudiation is not a binary property. It is not a question
> of having
> 	NR or not having it but one of degree.
>
> 3) Corporations do not have biometrics.
>
>
>
> 		Phill
>
>
>



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14628 for <[e-mail]>; Mon, 13 Dec 1999 15:33:59 -0800 (PST)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id PAA00972; Mon, 13 Dec 1999 15:34:27 -0800 (PST)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by postal-gw2.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YMRLSJ5D; Mon, 13 Dec 1999 15:36:18 -0800
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Lyal Collins" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Online PIN & Server Wallet
Date: Mon, 13 Dec 1999 18:37:48 -0500
Message-ID: <006a01bf45c3$10a2b0a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <000d01bf45a8$5e2a0e60$070a54d2@here>

> Who cares about "not in the spirit of PKI"?

> I want to see affordable implementations and affordable operational models
> for PKI, otherwise, don't waste our time with it.

I thought that was the spirit of PKI!

If I get a bill from my telco it is the telco that is authenticating
itself to me as a corporate entity, not Kent the Clerk.

One of the problems with the endless (and more than tedious) discussions of
non repudiation and biometrics that infest the list could be avoided if
people would recognize that:

1) The objective is to _control_ risk. Eliminating every possible threat is
	not necessary to achieve that objective.

2) Non repudiation is not a binary property. It is not a question of having
	NR or not having it but one of degree.

3) Corporations do not have biometrics.



		Phill




Received: from fep6.mail.ozemail.net (fep6.mail.ozemail.net [203.2.192.123]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12133 for <[e-mail]>; Mon, 13 Dec 1999 12:24:54 -0800 (PST)
Received: from here (slsdn5p07.ozemail.com.au [210.84.10.7]) by fep6.mail.ozemail.net (8.9.0/8.6.12) with SMTP id HAA22681; Tue, 14 Dec 1999 07:28:18 +1100 (EST)
From: "Lyal Collins" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Online PIN & Server Wallet
Date: Tue, 14 Dec 1999 07:26:42 +1100
Message-ID: <000d01bf45a8$5e2a0e60$070a54d2@here>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <01BF4551.F3691180@HYDRA>

Who cares about "not in the spirit of PKI"?

The end result of what I described is the same, and it is no less secure
than  the password at keyboard models most think we can use 'safely'

I want to see affordable implementations and affordable operational models
for PKI, otherwise, don't waste our time with it.

Regards,
Lyal
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders
> Rundgren
> Sent: Monday, 13 December 1999 20:08
> To: [e-mail]; 'Lyal Collins'
> Cc: '[e-mail]'; 'Matei (DSV)'
> Subject: RE: Online PIN & Server Wallet
>
>
> Lyal,
>
> >- Why not have the Server wallet sign on behalf of the
> cardholder? - they've
> >already authenticated themselves by PIN, thuis no need for a personalised
> >certificate.
>
> Well, your are right about the server-signature but if you put
> this statement in the
> IETF-PKIX-list you will get return messages like "not secure",
> "breaks the intention of PKI" ,
> "the user-environment and equipment is more trustworthy than a
> server" etc.
>
> Naturally these guys will simply be ignored, as today you get
> computer-generated invoices on
> company-papers from energy companies and Telcos. When (if) they
> convert this into PKI,
> I doubt that they will add a human clerk to push "OK" or key
> PIN-codes for each outgoing
> digitally signed invoice.
>
> I do believe though that it would be advantageous (but not
> absolutely necessary) that users also
> performs a signature operation, preferably with the same device
> and mechanism as they do for
> their Internet-banking account.  Here assuming that the server
> wallet is located at the user's bank
> which though may not always be the case.  Some Internet-banks do
> not require signing yet, and
> in those cases your original idea is exactly as good (or bad) as
> their on-line banking services.
>
> Anders
>
> -----------------------------------------------------------------------
> Message addressed to: [e-mail]
> Archive available at: http://lists.commerce.net/archives/set-discuss/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [e-mail]
>



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08217 for <[e-mail]>; Mon, 13 Dec 1999 08:40:25 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA10554 for <[e-mail]>; Mon, 13 Dec 1999 11:44:26 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA10550 for <[e-mail]>; Mon, 13 Dec 1999 11:44:25 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA09883 for <[e-mail]>; Mon, 13 Dec 1999 11:43:34 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA21211 for <[e-mail]>; Mon, 13 Dec 1999 11:43:19 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 13 Dec 1999 11:43:19 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3jtEwPT9iGbMu/zN7XMP2w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

MISSI/Fortezza documentation is available, as always, from
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html

That includes the latest (12 May) versions of SDN.706: "X.509
Certificate and Certificate Revocation List Profiles and Certification
Path Processing Rules for MISSI" and SDN.801: "MISSI Access Control
Concept and Mechanisms".

I take mild exception to Peter's characterization that the
subjectDirectoryAttributes extension is somehow slanted toward MISSI's
use of the extension as a container for the "prbacInfo",
"sigOrKMPrivileges", and "commPrivileges" data structures.  Those data
structures are oriented toward a particular user community, but it is
silly to imply that the extension itself is anything other than
absolutely generic.

I agree with Steve that the place to define biometric interoperability
specifications is within a biometric interest group (open/closed
consortium or IETF BOF/WG), not within PKIX.  PKIX should provide a
container (sDA or hash+URL, neither of which are specific to biometric
data) but no more.

Dave Kemp



> From: Ed Gerck <[e-mail]>
> 
> Peter Williams wrote:
> 
> > May I ask a Booz-Allen or DoD party to post a URL here to the excellent
> > and current version of SDN706 before we sensibly discuss further
> > the use of labels and the authorization issue, re 
subjectDirectoryAttributes?
> 
> I second that. I can host a public copy, if needed.  This helps the 
interoperation
> goal.
> 
> Cheers,
> 
> Ed Gerck
> 



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07352 for <[e-mail]>; Mon, 13 Dec 1999 07:59:18 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA12763; Mon, 13 Dec 1999 10:16:58 +0100
Received: by HYDRA with Microsoft Mail id <01BF4551.F3691180@HYDRA>; Mon, 13 Dec 1999 10:08:06 +0100
Message-ID: <01BF4551.F3691180@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Lyal Collins'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Matei (DSV)'" <[e-mail]>
Subject: RE: Online PIN & Server Wallet
Date: Mon, 13 Dec 1999 10:08:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Lyal,

>- Why not have the Server wallet sign on behalf of the cardholder? - they've
>already authenticated themselves by PIN, thuis no need for a personalised
>certificate.

Well, your are right about the server-signature but if you put this statement in the 
IETF-PKIX-list you will get return messages like "not secure", "breaks the intention of PKI" ,
"the user-environment and equipment is more trustworthy than a server" etc.

Naturally these guys will simply be ignored, as today you get computer-generated invoices on
company-papers from energy companies and Telcos. When (if) they convert this into PKI,
I doubt that they will add a human clerk to push "OK" or key PIN-codes for each outgoing
digitally signed invoice.

I do believe though that it would be advantageous (but not absolutely necessary) that users also
performs a signature operation, preferably with the same device and mechanism as they do for
their Internet-banking account.  Here assuming that the server wallet is located at the user's bank
which though may not always be the case.  Some Internet-banks do not require signing yet, and
in those cases your original idea is exactly as good (or bad) as their on-line banking services.

Anders



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06154 for <[e-mail]>; Mon, 13 Dec 1999 07:24:39 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMOQOI00.BAH for <[e-mail]>; Mon, 13 Dec 1999 15:21:54 +0000 
Received: from nma.com ([209.21.28.70]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMOQNS00.J7U for <[e-mail]>; Mon, 13 Dec 1999 15:21:28 +0000 
Message-ID: <[e-mail]>
Date: Mon, 13 Dec 1999 07:22:21 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: DS, NR and their legal effects
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All:

>From  time to time, discussions in this WG have revolved 
around the issue of legal effects and intent of authentication
(as indicated by setting the DS bit) and non-repudiation (as 
indicated by setting the NR bit). Even though these discussions
exceed the technical charter of this WG, I understand that some
posters might feel that "something is missing" unless we 
introduce words about the legal or binding effects of the DS bit
and, especially, of the NR bit. This message intends to help 
clarify the issue and show that what is "missing" belongs indeed
to another layer -- the legal layer.  And, there should it rest 
if we want to improve interoperation lest we want PKIX to be tied
in to one particular legal system and time, and fail in others.

Technically, it has become clearer in these discussions that 
authentication and non-repudiation are distinct services (as 
clearly stated also in X.509v3) and that *both* the DS and NR 
bits are necessary to indicate what I might call the "signature 
state".

Many agree that we cannot "deprecate" either because we would be 
missing an essential state variable and we could not adequately 
describe some digital signature systems. Suffice as limitation 
that the DS bit applies only to asymmetric signature algorithms.

However, about the evidenciary consequences of authentication and
non-repudiation?  They would directly impact the ability of digital
signatures to be used in e-commerce and to be enforceable in a court
of law. Do we need to include words to this effect in PKIX, in order
to allow PKIX to be applied as a commercial tool?  Do we need to
include the legal layer in PKIX? My opinion has been that we should not 
-- even though we need to keep an eye on the legal layer in order to
verify if we are providing an adequate firm basis for it, whatever it
might reasonably be. 

In this aspect, I present the current interpretation provision
from the latest version of the UK Electronic Communications Bill 
(thanks to Nicholas Bohm for sending it to me):

"In this Act- 
                                 
(a) references to the authenticity of any communication or data are
references to any one or more of the
following- 
     
(i) whether the communication or data comes from a particular person or
other source;

(ii) whether it is accurately timed and dated;
     
(iii) whether it is intended to have legal effect"

The Act provides that an electronic signature is admissible as 
evidence of the authenticity of a message or data, and paragraph 
(iii) above was inserted to meet the reproach that the original 
version failed to acknowledge that a signature is more than 
evidence of authenticity, it is evidence of an intention to 
adopt and approve what is signed.

IMO, this provision thus does shed light into what the legal layer 
might include -- which largely solves the issue whether 
"something is missing" in PKIX. Indeed, "something is missing"
but on purpose, because it is out of scope and provided elsewhere.
 

Cheers,

Ed Gerck


Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04148 for <[e-mail]>; Mon, 13 Dec 1999 05:48:28 -0800 (PST)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id FAA24604 for <[e-mail]>; Mon, 13 Dec 1999 05:51:52 -0800 (PST)
Message-ID: <002e01bf4571$3bfcafa0$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: <[e-mail]>
Subject: PKI Forum
Date: Mon, 13 Dec 1999 08:51:57 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

I think this press release is of prime interest to this group

Juan Rodriguez-Torrent
[e-mail]

"It is better to sleep on things beforehand than lie awake about them
afterwards." Baltasar Gracian


For additional information on the PKI Forum:
Patrick Corman
Corman Communications
[phone]
[e-mail]
FOR IMMEDIATE RELEASE

Baltimore Technologies, Entrust, IBM, Microsoft and RSA Security Announce
Formation of PKI Forum
Leaders in Public Key Infrastructure Provide Industry Focal Point for PKI
Interoperability, Increased Customer Confidence for PKI-Based Solutions

MENLO PARK, Calif., Dec. 13, 1999 -- Leading public key infrastructure (PKI)
vendors Baltimore Technologies, Entrust Technologies Inc., IBM Corp.,
Microsoft Corp. and RSA Security Inc. today announced the formation of the
PKI Forum, an industry-led collaboration created to accelerate the adoption
of PKI technology and PKI-based solutions as the trusted, secure foundation
for e-business applications.
The PKI Forum will provide an opportunity for vendors to demonstrate support
for standards-based, interoperable PKI by developing PKI interoperability
profiles based on business-driven requirements in certificate
interoperability, directory-PKI interoperability, application
interoperability, certificate validation and other areas. The forum will
sponsor product interoperability demonstrations and work closely with
standards organizations and external test bodies. The forum also will bring
customers and vendors together to increase customer knowledge about the
value of PKI and demonstrate how PKI solves key security issues for
e-business.
"Infrastructure technologies like PKI succeed only when they can support a
large number of users and applications," said Jamie Lewis, CEO of The Burton
Group. "By addressing interoperability issues and raising business awareness
of PKI, the PKI Forum can increase the number of applications that rely on
PKI and thus accelerate the deployment of PKI-based solutions."
The five founding PKI Forum member companies have expressed their commitment
to working collaboratively with other vendors, as well as users, to ensure
greater interoperability and utility for PKI-based solutions:
Baltimore Technologies: "The PKI Forum will enable customers to see
demonstrable interoperability among the leading PKI vendors," said Paddy
Holahan, executive vice president of marketing. "Baltimore Technologies, as
a founding member, will work to ensure the practical implementation of open
standards to deliver manageable, robust PKI systems."
Entrust: "The PKI Forum is all about increasing customer's confidence in our
collective capabilities," said Brian O'Higgins, executive vice president and
CTO, Entrust Technologies. "Enhancing interoperability and ease-of-use of
PKI Technology will drive more value to our customers. Entrust is committed
to the objectives of the PKI Forum."
IBM: "IBM is committed to open standards, and our participation in the PKI
Forum will benefit our customers who rely on PKI-based applications to
provide a secure foundation for e-business," said Mark Greene, vice
president, IBM SecureWay. "Working with the other vendors committed to this
important forum and with the broader community of technology companies and
customers who will participate in the forum's working groups, IBM continues
to champion standards-based, interoperable PKI and the value it brings to
global e-business."
Microsoft: "As e-business evolves, PKI interoperability is crucial to
meeting customer demand for Internet security. Microsoft has made this
significant commitment to customers by providing PKI in Windows 2000® and is
proud to play a founding role in the innovation and vision that the PKI
Forum will provide to the industry and to customers," said Shanen Boettcher,
product manager, Windows 2000 Security, Microsoft. "Microsoft is committed
to keeping customers' information secure, and our membership in the PKI
Forum is an important part of meeting this commitment."
RSA Security: "Broad PKI interoperability is essential to advancing the
deployment of trusted, secure e-business applications, and RSA is happy to
have this opportunity to help make it a reality," said Scott Schnell, vice
president of RSA Security. "We look forward to working closely with the
other PKI Forum members in achieving this goal and lending our expertise to
help promote the adoption of PKI technology."
 Membership in the PKI Forum is open to product and service providers,
independent software vendors, consultants, integrators and end-user
organizations that have a demonstrated interest in promoting PKI technology
and PKI-based solutions. In addition to the five founding members, the PKI
Forum is supported by a variety of leading companies that are committed to
interoperable PKI-based solutions and have expressed interest in the PKI
Forum. These companies include British Telecommunications plc,
Hewlett-Packard Co., ID Certify, Novell Inc., The Open Group, Sun/Netscape
Alliance, SPYRUS, Thawte Certification, Trustpoint, ValiCert Inc. and Xcert
International Inc.
Public key technology and digital certificates have emerged as the preferred
enablers of strong security for a wide range of e-business applications,
including secure e-mail, secure Web access, virtual private networks and
digital signatures. The most common functions of a PKI are issuing
certificates, revoking certificates, creating and publishing Certificate
Revocation Lists (CRLs), storing and retrieving certificates and CRLs, and
policy enforcement. Enhanced or emerging PKI functions include time-stamping
and policy-based certificate validation. To successfully deploy a PKI,
organizations must develop a sound strategy, plan for interoperability,
determine how e-business applications will interface with the PKI, and plan
for technical staffing requirements.
The PKI Forum is being established within the legal framework of the managed
consortia program of The Open Group, a vendor and technology-neutral
consortium of IT buyers and suppliers.  Through defining and extending
industry standards, creating customer testing and conformance programs, and
educating on best industry practices, The Open Group is focused on helping
customers and vendors solve enterprise integration problems.
Members of the PKI Forum plan to establish two standing working groups:
? The Business Working Group will help ensure that the forum understands the
PKI needs of four constituencies: software developers, service providers,
vendors and customers. It will link those needs to the Technical Working
Group and carry out marketing activities.
? The Technical Working Group will develop PKI interoperability profiles to
address the use of PKI in business applications, link with appropriate
standards and other PKI organizations, and charter demonstration projects to
establish interoperability among vendor products.

The PKI Forum intends to conduct informational meetings and a reception for
interested companies in conjunction with the RSA Conference 2000, to be held
the week of Jan. 17-21, 2000, in San Jose, Calif. Organizations interested
in membership in the PKI Forum should contact Graham Bird of  The Open Group
by phone at [phone], by fax at [phone], or by e-mail at
[e-mail].
  Further information on The Open Group can be obtained at
www.opengroup.org.  For general information about the PKI Forum, see
www.pkiforum.org.
About Baltimore Technologies
Baltimore Technologies develops and markets security products and services
to enable companies to develop trusted, secure systems for e-business,
e-commerce and the Internet. Its products include a wide range of PKI
systems, cryptographic toolkits, security applications and hardware
cryptographic devices. Baltimore Technologies markets and sells its
solutions worldwide directly and through the TrustedWorld channel program.
The company employs over 450 people worldwide and operates from over 20
cities, with headquarters in Dublin, Ireland; London; Boston; and Sydney,
Australia. Baltimore Technologies plc is a public company with dual listings
on Nasdaq (BALT) and the London Stock Exchange (BLM).  For further
information and press releases on Baltimore Technologies, please visit
http://www.baltimore.com/.
About Entrust Technologies
Entrust Technologies Inc. (Nasdaq: ENTU) is a global leader in providing
products and services that allow e-businesses to manage trusted, secure
electronic transactions and communications over today's advanced networks,
including the Internet, extranets and intranets. Since 1994, Entrust
Technologies has been providing award-winning solutions to global
enterprises, government entities, small to midsize businesses and
individuals. Over 4 million Entrust Technologies users have been licensed
with digital certificates to date. Entrust Technologies Inc. is
headquartered in Plano, Texas, with offices in Canada, the United States,
the United Kingdom, Switzerland, Germany and Japan. For additional company
information, please visit http://www.entrust.com/.
About IBM
IBM is the world's largest information technology company, with 80 years of
leadership in helping businesses innovate. IBM Software offers the widest
range of applications, middleware and operating systems for all types of
computing platforms, allowing customers to take full advantage of the new
era of e-business. The fastest way to get more information about IBM
software is through the IBM Software home page at
http://www.ibm.com/software/.
About Microsoft
Founded in 1975, Microsoft (Nasdaq: MSFT) is the worldwide leader in
software for personal and business computing. The company offers a wide
range of products and services designed to empower people through great
software - any time, any place and on any device.
About RSA Security
RSA Security Inc. (Nasdaq: RSAS), The Most Trusted Name in e-SecurityT,
helps organizations build secure, trusted foundations for e-businesses
through its RSA SecurID® two-factor authentication, RSA BSAFE® encryption
and RSA KeonT public key management systems. As the global integration of
Security Dynamics and RSA Data Security, RSA Security has the proven
leadership, innovative technology and systems experience to address the
changing security needs of e-business and bring trust to the new, online
economy. RSA Security can be reached at http://www.rsasecurity.com/.
# # #
Entrust is a registered trademark of Entrust Technologies Inc. in the United
States and other countries. In Canada, Entrust is a registered trademark of
Entrust Technologies Ltd. All Entrust product names are trademarks of
Entrust Technologies.

BSAFE and SecurID are registered trademarks, and Keon, RSA and The Most
Trusted Name in e-Security are trademarks of RSA Security Inc.

Microsoft and Windows are either registered trademarks or trademarks of
Microsoft Corp. in the United States and/or other countries/regions.
All other company and product names are trademarks or registered trademarks
of their respective owners.

Editorial Contacts:
Baltimore Technologies
Tracy Ross
[phone]
[e-mail]

Entrust Technologies
Carrie Bendzsa
[phone]
[e-mail]

IBM
Nancy Riley
[phone]
[e-mail]

Microsoft
Luisa Vacca
Waggener Edstrom
[phone]
[e-mail]

RSA Security Inc.
Rick Mack
[phone]
[e-mail]

 Statements of support regarding the mission of the PKI Forum have been
received from the following organizations:

"We are delighted to be part of the PKI forum. As one of the leading
suppliers of eBusiness solutions in the UK, we are also committed to
providing organizations with the most secure
eBusiness infrastructure in the world. One of the crucial elements of
building trust in eBusiness is the promotion of industry standards which
will facilitate secure communication across open networks. The formation of
an industry body which actively promotes these standards is a positive step
forward and we look forward to working with all our partners." -- David
Furniss
General Manager, BT eBusiness

"Hewlett-Packard Company supports the efforts of the PKI Forum to achieve gr
eater interoperability among and faster adoption of PKI security
technologies.  E-Services require a robust security infrastructure to ensure
trust, and HP is leveraging standards-based, interoperable PKI to deliver
promise of this technology." - Roberto Medrano, General Manager, Internet
Security Division, Hewlett Packard Company

"ID Certify is looking forward to playing an active role in the PKI Forum.
The Forum goals of interoperability for certificates and education will be
critical for the growth and advancement of the industry." -- Linda
Mackintosh, President, ID Certify

"Novell believes the creation of the PKI Forum is an important step in
accelerating the adoption of PKI security technology. PKI technology, in
combination with directory services, is critical to the infrastructure of
e-business and is central to the success of future technology-based
commerce." -- Winston Bumpus, Director of Standards, Novell

"The Open Group is pleased to support the members of the PKI Forum in their
efforts to accelerate interoperability through industry standards,
certification testing and conformance programs. The expected results of the
PKI Forum will make a major contribution towards interoperability and
increased end-user confidence in the deployment of multi-vendor PKI-based
solutions." -- Allen Brown, President and CEO, The Open Group

"As a PKI solutions provider, SPYRUS enthusiastically supports the creation
of the PKI Forum. We look forward to an era of ubiquitous and interoperable
PKI solutions from all of the various technology and service providers in
this burgeoning industry. The PKI Forum is the first unified organization to
bring together the PKI market leaders to openly discuss and encourage
prompt response to critical business issues." - Sue Pontius, CEO, Spyrus

"Thawte is pleased to be a member of the PKI Forum. We are confident that
the PKI Forum will increase vendor awareness of the need for PKI
interoperability and provide a venue for PKI protocol testing and
adoption." - Mark Shuttleworth, President, Thawte Certification

"We fully support the efforts of the PKI Forum and look forward to working
with its members in creating open standards for interoperable PKI solutions.
Trustpoint's cross-platform JavaT-based PKI components and certification
authority systems enable standards-based trust management on the widest
range of networked computing and communication devices. The PKI Forum's
mission closely parallels our own, and we believe our recognized leadership
in open PKI standards development will be a valuable asset to this
organization." -- John Kennedy, Chief Technology Officer, Trustpoint

"Interoperability is a cornerstone of ValiCert's VA solution, and we look
forward to working with the other members of the PKI Forum on this and other
PKI issues. PKI offers the best security foundation for all e-business
applications, and we support the Forum's goal of accelerating PKI
adoption." -- Sathvik Krishnamurthy, Vice President of Marketing and
Business Development, ValiCert

"Xcert's commitment to open standards to facilitate interoperability is an
intrinsic part of our philosophy. We look at participating in the PKI Forum
from its inception as a formal opportunity to drive to successful resolution
one of the markets more pressing concerns, that of interoperability. Xcert
customers, including American Banker's Association and GSA ACES Project
(General Administration Services Access for Electronic Services Project),
have voiced their support of Xcert's leadership role in the PKI Forum,
reiterating that interoperability is a top priority in terms of their
ability to move forward in their multi-vendor PKI initiatives." -- Patrick
Richard, CTO of Xcert International, Inc.






Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26534 for <[e-mail]>; Sun, 12 Dec 1999 23:49:05 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA12540; Mon, 13 Dec 1999 08:54:26 +0100
Received: by HYDRA with Microsoft Mail id <01BF4546.6AE2F7F0@HYDRA>; Mon, 13 Dec 1999 08:45:33 +0100
Message-ID: <01BF4546.6AE2F7F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: PKIX-List <[e-mail]>
Subject: RE: QC Bio-info leak?
Date: Mon, 13 Dec 1999 08:45:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>??? not applicable to fingerprint??? ... which part? ... the AADS strawman with
>on-device fingerprint sensor for activation or x9.84?

Well, I EXPLICITLY referred to QC-002 were bio-metrics that need machine-verification
are BANNED (or not supported depending on how "political" you want to be), for reasons unknown.
That includes fingerprints.

If you have local/personal device sensors and thus reading etc. biometrics is completely outside
of the PKI.  You trust a device instead.  So it is another story.

Such a solution could be interesting for mobile phones  (has been shown actually) as a PIN-code
replacement or better as a PIN-code complement

IMO the QC-editors have quite some homework to do regarding other efforts in this area like
the one you mention.  Thank God I am not a QC editor!

Anders




Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01078 for <[e-mail]>; Sun, 12 Dec 1999 17:29:29 -0800 (PST)
Received: by florida.melco.co.jp (3.7W-florida) id KAA20983; Mon, 13 Dec 1999 10:32:32 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id KAA01633; Mon, 13 Dec 1999 10:33:03 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id KAA19680; Mon, 13 Dec 1999 10:33:23 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id KAA11898; Mon, 13 Dec 1999 10:33:15 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id KAA12812; Mon, 13 Dec 1999 10:36:58 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id KAA22228; Mon, 13 Dec 1999 10:32:36 +0900 (JST)
Message-ID: <007c01bf4509$b18c08f0$78054a0a@belize>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: certificate which has both AIA and CRL DPs
Date: Mon, 13 Dec 1999 10:30:52 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700

Mr.Housley

Thank you for your reply.

>Answer 1:  Yes, a certificate can contain both a CRL Distribution Point 
>(CRLDP) extension and an Authority Information Access (AIA) extension.
>
>Answer 2:  Precedence is not specified.  The client may either fetch the 
>CRLs or use OCSP to determine whether or not the certificate is revoked.
>
>Russ

I understand.
I will try to create certificates with both AIA and CRL DP.

Hiroyuki Sakakibara




Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00878 for <[e-mail]>; Sun, 12 Dec 1999 17:26:05 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id UAA19526; Sun, 12 Dec 1999 20:29:31 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id UAA08067; Sun, 12 Dec 1999 20:29:30 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256846.0007DE0B ; Sun, 12 Dec 1999 20:25:55 -0500
X-Lotus-FromDomain: FDC
To: "Anders Rundgren" <[e-mail]>
cc: "PKIX-List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 12 Dec 1999 17:27:43 -0800
Subject: Re: QC Bio-info leak?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

... and as a total aside ... did manage to get AADS/X9.59 announcement and press
releases at BAI show last week (something like Cebit for the world-wide retail
banking industry). Also had AADS financial transactions and AADS privacy-broker
transactions being demo'ed at the show ... the only thing missing from the demos
was AADS RADIUS authentication for ISP & webserver connections. references (and
pointer to press release) are at http://www.garlic.com/~lynn/




Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA29352 for <[e-mail]>; Sun, 12 Dec 1999 16:03:34 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net with ESMTP id TAA10406; Sun, 12 Dec 1999 19:07:02 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id TAA07782; Sun, 12 Dec 1999 19:07:01 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256846.000052D4 ; Sun, 12 Dec 1999 19:03:32 -0500
X-Lotus-FromDomain: FDC
To: "PKIX-List" <[e-mail]>
cc: "Anders Rundgren" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 12 Dec 1999 15:57:36 -0800
Subject: Re: QC Bio-info leak?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

oh yes, the AADS parameterized risk management is attempting to look at the
issues of deploying 50+ year lifetime infrastructures.

simplifying a bit, the public key becomes the serial number of the
infrastructure that performs the digital signature. That infrastructure has an
overall assessed integrity level and is registered when the public key is
registered. Incoming transactions can be authenticated ... and then
authorization can be decided, in part, based on the integrity level of the
signing infrastructure. Also the integrity level can be downgraded in real time
as discoveries are made in the future.

In theory, AADS strawman help reduce the integrity unknowns for doing risk
assesement portion of authorization. It is even possible that expensive
on-device bio-sensors can reduce the overall aggregate infrastructure expenses
by 1) reducing risk inaccuracies and 2) eliminating cycles currently being spent
in risk assesement things like expensive neural net applications.

Of course, the implication is that reasonable device activation bio-sensors can
have higher integrity properties than other device activation methodologies.




Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28734 for <[e-mail]>; Sun, 12 Dec 1999 15:13:57 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail01-ewr.pilot.net with ESMTP id SAA13378; Sun, 12 Dec 1999 18:17:21 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id SAA07609; Sun, 12 Dec 1999 18:17:20 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256845.007F9B7D ; Sun, 12 Dec 1999 18:13:48 -0500
X-Lotus-FromDomain: FDC
To: "Anders Rundgren" <[e-mail]>
cc: "PKIX-List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 12 Dec 1999 15:16:18 -0800
Subject: Re: QC Bio-info leak?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

??? not applicable to fingerprint??? ... which part? ... the AADS strawman with
on-device fingerprint sensor for activation or x9.84?

in the AADS scenerio the chip can be configured to be formfactor agnostic with
contactless/wireless infrastructure. the issue of thumb-reader costs
justification then becomes a parameterized risk management issue ... there is
some at least one application that justifies having the thumbreader for the
device ... or there isn't.

as to

x9.84

5.1 fingerprint
5.2 speaker recognition
5.3 eye scanning
5.4 face identification
5.5 hand geometry
5.6 signature verification




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27182 for <[e-mail]>; Sun, 12 Dec 1999 11:19:04 -0800 (PST)
Received: from mega (t4o69p13.telia.com [62.20.145.133]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id UAA15548; Sun, 12 Dec 1999 20:24:55 +0100
Message-ID: <000a01bf44de$20c20d40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "PKIX-List" <[e-mail]>
Subject: Re: QC Bio-info leak?
Date: Sun, 12 Dec 1999 20:19:00 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA27183

Lynn,
thanx for the info although it does not apply to the QC-002 spec as it does not support
finegerprints.

The question is therefore (unfortunately) limited to subject image and handwritten signature.

Although smart cards with built-in finerprint sensors could be great I believe
that this makes them too expensive for most purposes.

X9.84?  Does anyone within the QC-group care to comments on that?

Anders

-----Original Message-----
From: [e-mail] <[e-mail]>
To: Anders Rundgren <[e-mail]>
Cc: PKIX-List <[e-mail]>
Date: Sunday, December 12, 1999 15:36
Subject: Re: QC Bio-info leak?


>
>
>note in the AADS strawman case ... the fingerprint sensor can be configured  on
>the card and it used to activate the card ... in-place of PIN activation (with
>bio information never appearing in the infrastructure).
>
>the AADS w/PIN activation was what was announced at BAI this past week (BAI show
>is sort of the world-wide retail banking equivalent of cebit).  the AADS
>strawman also allows that the authentication function doesn't have to only
>appear in card formfactor ... that contactless/wireless protocol would allow for
>formfactor agnostic configurations.
>
>one of the challenges has been use in unfamiliar/unknown POS-like environments
>
>also within X9 ... there has been quite a bit of progress w/X9.84 (Management
>and Security For The Biometrics Financial Services Industry) in conjunction with
>various world-wide biometric standards organizations.
>
>as alwas ... references at http:/www.garlic.com/~lynn/
>




Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25327 for <[e-mail]>; Sun, 12 Dec 1999 07:27:13 -0800 (PST)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.166]) by mail-ewr-3.pilot.net with ESMTP id KAA26790; Sun, 12 Dec 1999 10:30:40 -0500 (EST)
Received: from lnsunr02.firstdata.com ([206.201.60.104]) by mailgw.firstdata.com with SMTP id KAA05482; Sun, 12 Dec 1999 10:30:39 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256845.0054E1FE ; Sun, 12 Dec 1999 10:27:08 -0500
X-Lotus-FromDomain: FDC
To: "Anders Rundgren" <[e-mail]>
cc: "PKIX-List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Sun, 12 Dec 1999 07:29:03 -0800
Subject: Re: QC Bio-info leak?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

note in the AADS strawman case ... the fingerprint sensor can be configured  on
the card and it used to activate the card ... in-place of PIN activation (with
bio information never appearing in the infrastructure).

the AADS w/PIN activation was what was announced at BAI this past week (BAI show
is sort of the world-wide retail banking equivalent of cebit).  the AADS
strawman also allows that the authentication function doesn't have to only
appear in card formfactor ... that contactless/wireless protocol would allow for
formfactor agnostic configurations.

one of the challenges has been use in unfamiliar/unknown POS-like environments

also within X9 ... there has been quite a bit of progress w/X9.84 (Management
and Security For The Biometrics Financial Services Industry) in conjunction with
various world-wide biometric standards organizations.

as alwas ... references at http:/www.garlic.com/~lynn/






"Anders Rundgren" <[e-mail]> on 12/11/99 11:48:36 PM

To:   "PKIX-List" <[e-mail]>
cc:    (bcc: Lynn Wheeler/CA/FDMS/FDC)
Subject:  QC Bio-info leak?



All,
I have another question for you smart-card experts.

I believe that biometrics as defined by the current QC-draft (002) will in 99%
be used
in conjunction with smart cards.

Q: How do you anticipate that the bio-template is going to be protected without
also requiring that the RP software is authenticating to the card?    The latter
will IMO not scale that well.

Or is there another genial solution?

My own solution to the problem is to never put "naked" smart cards in unknown
readers,
but to have them (or it) in a pesonal security terminal.  In my case the mobile
phone.

Anders







Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA16144 for <[e-mail]>; Sat, 11 Dec 1999 22:48:40 -0800 (PST)
Received: from mega (t2o69p76.telia.com [62.20.144.196]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA59182 for <[e-mail]>; Sun, 12 Dec 1999 07:54:33 +0100
Message-ID: <001301bf4475$4d111210$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: QC Bio-info leak?
Date: Sun, 12 Dec 1999 07:48:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA16145

All,
I have another question for you smart-card experts.

I believe that biometrics as defined by the current QC-draft (002) will in 99% be used
in conjunction with smart cards.

Q: How do you anticipate that the bio-template is going to be protected without
also requiring that the RP software is authenticating to the card?    The latter
will IMO not scale that well.

Or is there another genial solution?

My own solution to the problem is to never put "naked" smart cards in unknown readers,
but to have them (or it) in a pesonal security terminal.  In my case the mobile phone. 

Anders



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA09631 for <[e-mail]>; Sat, 11 Dec 1999 06:40:04 -0800 (PST)
Received: from mega (t2o69p4.telia.com [62.20.144.124]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA59010; Sat, 11 Dec 1999 15:03:00 +0100
Message-ID: <004101bf43e7$fc2e91c0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>
Subject: Re: QC biometrics needs re-engineering NOW!
Date: Sat, 11 Dec 1999 14:56:33 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA09633

All,
I have a couple of simple questions regarding biometrics as supported in the *current* QC-draft.
Please, I would love to get answers from a purely engineering point-of-view.  For a change.

Background information:

In several countries PKI-based identity-programs are being implemented.

We are talking about of populations with millions of subscribers so it is not that "local".

Many (but not all) use a static unique identifier (SSN-like but truly unique) to identify the subject.

Certificates or subject data is NOT published in any way.  Only CRLs.

The CA/RA should in these schemes be considerad as "trusted" for handling information
concerning its subscibers as this is the foundation for the entire scheme.  Like it or not.

Qyestions:

Q1: In what way could privacy be hampered if  there were an optional selectable version
of such an identity-certificate containing an in-line data object with an image
of the subject?  Note that the unique identity-case is already lost so this question
has only to do with the image.

Q2: In what way would the *user* and *RP* benefit from a system using proprietary protocols
for transmitting the bio-template (image file) and specialized GUIs telling: "Do you really
want to give your image to XYZ" instead of simply selecting between

-  Standard QC   ;Probably just "Name and number"
-  Photo ID           ;Preferably identified by an easy-to-interprete icon on the user display
-  etc etc             

and only using standard authentication protocols.

Note: I here refer to the QCdraft's non-URI version of biometric support, which if it has any
value (where are you Denis?), should be defended or simply deleted.

Anders




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20493 for <[e-mail]>; Fri, 10 Dec 1999 20:28:56 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMK79S00.GAN for <[e-mail]>; Sat, 11 Dec 1999 04:32:16 +0000 
Received: from nma.com ([209.21.28.92]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMK79F00.JVS; Sat, 11 Dec 1999 04:32:03 +0000 
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 1999 20:32:27 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, "'PKIX-List '" <[e-mail]>
Subject: Re: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:

> Ander's bio-vendors group, like NSA/DoD, have a quite appropriate home
> for their  "local material" which binds to the subject. As the material
> is "local" and non-critical (per 2459), the authors/WGs opinion on
> suitability of any such local information in an operational id-cert
> infrastructure is, by definition, irrelevant. Local means we here have no
> particular opinion, beyond ensuring interoperability in maintained.

Yes.  I think that Peter is quite correct to point out the value of
diversity. And, that is why interoperation is more important than seeking
the futile goal of perfect standardization -- because markets are local.

However,  there are evident problems of publishing private information,
from harmless impersonation to outright fraud. So, even though anyone
may feel free to promote unsafe standards in the private and even public
sector, at the end it is interoperation that suffers when one badly designed
protocol threatens to become the back-door of another, otherwise secure,
protocol.

The first goal is security not privacy, some may say -- but, what is it that
security secures? That which is private or at least secret. So, if a bit of
privacy is tossed out in order to obtain a bit of security then the means are
denying the end.  Security would thus be decreased -- e.g., by
impersonation attacks, by information leak  from unwanted recipients, etc.,
not increased.

So, notwithstanding the needs of local markets, and the the fact that we
should have here no particular opinion or demand on the local decisions
of others, it is possible to be a bit more forward-looking and point out that
quarantine may be the only solution to cope with a privacy-leaking protocol.
To isolate or deprecate a protocol is a valid tool to provide security by
confinement.  I  believe however that security cannot be based on
confinement only, especially on an open network such as the Internet.
We need to base security on understanding.

That is why encouragement or discouragement of certain identification
practices in regards to privacy and security (when based on technical
reasoning and understanding,  not on subjective biases and influence of
lobbyists or catcalls of 'politics") is thus a specifically appropriate position
HERE and NOW, I venture in contraposition to Peter, given the *explicit*
need for *global*  interoperation specified in current AND expected
versions of PKIX-1.

> I do suggest that it is quite appropriate for IETF to assist
> interworking-oriented and PKIX-cert conforming groups formulate standard
> syntaxes to represent information in cert which is designed
> for local, or "card-present/signature-device present" type,
> security enforcement processes. Many existing IETF-blessed LDAP
> attributes are local in scope; PKIX can similarly oblige.

I agree.  And, likewise it is appropriate for anyone in an IETF WG to point
out to such groups the overreaching problems which may be caused by
certain approaches when they extrapolate their parochial realm.  If, however,
they intend to remain parochial then, I venture, there is no need for
interoperation and no need for help from an IETF WG -- though such help
may be offered and taken at what it is worth.

However, to *demand* help for what seems to be from the start an  ill-fated
and ill-designed intrusion into privacy, and hence a security risk, is not
justified. Not even in the good name of local market need.  Because such need
cannot help the interoperation goal, lest we want to subvert from the outset
what we are designing.

> May I ask a Booz-Allen or DoD party to post a URL here to the excellent
> and current version of SDN706 before we sensibly discuss further
> the use of labels and the authorization issue, re subjectDirectoryAttributes?

I second that. I can host a public copy, if needed.  This helps the interoperation
goal.

Cheers,

Ed Gerck



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28728 for <[e-mail]>; Fri, 10 Dec 1999 16:38:57 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <YP1K74XB>; Fri, 10 Dec 1999 16:37:38 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'PKIX-List '" <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Date: Fri, 10 Dec 1999 16:37:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve,

In response to your comments, I venture that my suggestion is wholly
reasonable, I assert again. Concerning the factual basis of your 
counter-argument, the "latest" version  of 2459 merely advises a MODEL 
OF "prioritization and scope  -  for implementers (not operators)" 
concerning the subjectDirectoryAttributes field. (See quote, below.)

In no sense do I read from the normative text that use of the disputed
field is/was "discouraged". Now we have 2 local uses for subjectAttributes 
- NSA's and the biometric application  - and given we are revising 2459 
for bugs and timeliness of options and important processing steps, it is NOW

appropriate to revise even this language so that X.509's design and intent 
can be realized in the Internet environment. Nothing in the "Internet
environment" suggests that this quite properly standardized field is
in someway fundamentally tainted. 2459 specifically encourages operators
to change or refine the profile, as they see fit, furthermore.

Ander's bio-vendors group, like NSA/DoD, have a quite appropriate home 
for their  "local material" which binds to the subject. As the material 
is "local" and non-critical (per 2459), the authors/WGs opinion on
suitability 
of any such local information in an operational id-cert infrastructure is, 
by definition, irrelevant. Local means we here have no particular opinion,
beyond ensuring interoperability in maintained.

Encouragement or discouragement (at best a non-normative and
political element of a standards process, subject to subjective 
biases and influence of lobbyists) is perhaps a specifically inappropriate 
position HERE, I venture, given the *explicit* local
delegation specified in current AND expected versions of PKIX-1.

"The subject directory attributes extension is not recommended as an
   essential part of this profile, but it may be used in local environ-
   ments.  This extension MUST be non-critical."

I do suggest that it is quite appropriate for IETF to assist 
interworking-oriented and PKIX-cert conforming groups formulate standard 
syntaxes to represent information in cert which is designed
for local, or "card-present/signature-device present" type, 
security enforcement processes. Many existing IETF-blessed LDAP 
attributes are local in scope; PKIX can similarly oblige. 
 
May I ask a Booz-Allen or DoD party to post a URL here to the excellent
and current version of SDN706 before we sensibly discuss further 
the use of labels and the authorization issue, re
subjectDirectoryAttributes?

Peter.
 
-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Friday, December 10, 1999 11:07 AM
To: Peter Williams
Cc: 'PKIX-List '
Subject: RE: Accessing/selecting biometrics was: Stray Poll:
Finger-prints in QCs


Peter,

>
>Steve's argument really does not make sense, in a wider context.
>
>NSA defines, in SDN706, clearance and privilege attributes to
>instrument authorization regimes including NOFORN,
>RELUK, etc, and PKIX faciliates their transport & carriage in
>the PKIX flexible, subjectDirectoryAttributes field.

you mean the field that 2459 discourages use of?

>If PKIX id-certs transport such authorization info, they
>can transport similar bio-info, in other subjectDirectoryAttributes
>fields.

certainly you understand the difference between authorization and 
authentication info, so the analogy looks rather weak on that basis 
alone.

>The privacy argument concerning bio info is mostly the same
>as authorization info. A 100 byte compressed picture of me
>is no more sensitive than the level of my (non-existing) US
>security clearance.

no, it is not. the two concerns are incomparable, in general. people 
holding clearances have opted into a system which requires abandoning 
some privacy concerns, and adopting new ones imposed by the clearance 
issuer.  a private citizen who makes use of biometric data for 
authentication in a QC is operating under a different set of privacy 
assumption, constraints, etc.

>Given the seeming synchronization of PKIX work and NSA work, I
>have no doubt that knowledge of this authorization case is
>well known to all those who decide what goes into PKIX
>draft standards.

several of the authors of 2459 are aware of the SDN706 work, but they 
did not skew the document to endorse that NSA spec.  today, we would 
encourage putting that info into an AC.

>If my argument does not hold, then authorization info
>in PKIX-compliant certs should be restricted to a hash-reference,
>so it is aligned with the bio-data rationale.

if your analogy were valid, and if we did not disparage use of the 
directory attributes extension, this argument might make sense, 
however, ...

>This would of course make a large swath of NSA certs
>today PKIX non-complying. I doubt PKIX WG would make that
>decision, somehow: so PKIX stds should allow the same logic as
>enabled 100 bytes of authorization information to now
>also hold for embeddeding 100 bytes of bio-data.


we're not talking about backward compatibility here, so again the 
analogy is flawed.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25152 for <[e-mail]>; Fri, 10 Dec 1999 12:24:30 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA10012; Fri, 10 Dec 1999 15:27:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b476fb461a6a@[171.78.30.108]>
In-Reply-To: <01BF40CF.A1904DA0@HYDRA>
References: <01BF40CF.A1904DA0@HYDRA>
Date: Fri, 10 Dec 1999 13:51:52 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs
Cc: "'SEIS-List'" <[e-mail]>, PKIX-List <[e-mail]>, Tony Bartoletti <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>Anders,
>
>PKIX creates infrastructure standards.  Specifying a means of binding
>biometric data to a cert is within scope.  specifying a means of
>carrying this data in a wide range of application environments is out
>of scope.
>
>I would say that this sloppy definition requires that the maker of 
>the smart-card and
>the authenticating application are identical.  Interoperability=ZERO.
>

While interoperability is a prime focus of IETF WGs, we still have to 
have bounds on our work.  Smart cards are not the only means of 
dealing with certs. So, the fact that there is need for additional 
standards in specific contexts, in order to ensure interoperability 
is not new, nor surprising.

>  For example, we don't tell IPsec, SSL/TLS, or S/MIME how
>to transport certificates or CRLs in those applications;
>
>Odd examples.  AFAIK SSL/TLS specify exactly how and when client and
>server certificates are transmitted between client and server.

Unfortunately, your knowledge is lacking here. SSL/TLS do NOT specify 
cert usage details at all.  This is the province of HTTPS, a 
different (and not IETF standard) protocol.

>
>Having defined a means of binding biometric data to a cert,
>while not putting it in the cert and thus mitigating privacy
>problems, we have done the part of the job that is appropriate for
>this WG.

It is out of scope, starting with the assumption that certs live 
exclusively on smart cards.

>
>As noted by others, the URI+hash thing does not do the privacy job 
>the way you describe it and then
>the whole foundation is flawed.  I.e. we are back to "file-size" 
>discussions which are pretty trivial.
>
>User certificate selection is (so far) the only documented, 
>interoperable, general-purpose solution to privacy
>problems of the kind introduced by certificates containing 
>"sensitive" information like SSNs, biometrics etc.

I don't what point you are trying to make above.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25036 for <[e-mail]>; Fri, 10 Dec 1999 12:24:13 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA09992; Fri, 10 Dec 1999 15:27:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b476f88975b3@[171.78.30.108]>
In-Reply-To: <01BF4267.0CCA6A40@HYDRA>
References: <01BF4267.0CCA6A40@HYDRA>
Date: Fri, 10 Dec 1999 13:40:13 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC biometrics needs re-engineering NOW!
Cc: PKIX-List <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

By all means feel free to move your efforts to the context of 
industry consortia (not to be confused with open standards groups) on 
ways to achieve your ends.  Since we disagree about the scope of our 
work vs. what you wish to accomplish this may be beneficial for both 
camps. Just don't expect PKIX compliant systems to necessarily be 
compatible with the work you foster in such closed environments.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25007 for <[e-mail]>; Fri, 10 Dec 1999 12:24:02 -0800 (PST)
Received: from [171.78.30.108] (comsecpb.bbn.com [171.78.30.108]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA10034; Fri, 10 Dec 1999 15:27:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b476fcba71d9@[171.78.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 10 Dec 1999 14:06:31 -0500
To: Peter Williams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Cc: "'PKIX-List '" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>
>Steve's argument really does not make sense, in a wider context.
>
>NSA defines, in SDN706, clearance and privilege attributes to
>instrument authorization regimes including NOFORN,
>RELUK, etc, and PKIX faciliates their transport & carriage in
>the PKIX flexible, subjectDirectoryAttributes field.

you mean the field that 2459 discourages use of?

>If PKIX id-certs transport such authorization info, they
>can transport similar bio-info, in other subjectDirectoryAttributes
>fields.

certainly you understand the difference between authorization and 
authentication info, so the analogy looks rather weak on that basis 
alone.

>The privacy argument concerning bio info is mostly the same
>as authorization info. A 100 byte compressed picture of me
>is no more sensitive than the level of my (non-existing) US
>security clearance.

no, it is not. the two concerns are incomparable, in general. people 
holding clearances have opted into a system which requires abandoning 
some privacy concerns, and adopting new ones imposed by the clearance 
issuer.  a private citizen who makes use of biometric data for 
authentication in a QC is operating under a different set of privacy 
assumption, constraints, etc.

>Given the seeming synchronization of PKIX work and NSA work, I
>have no doubt that knowledge of this authorization case is
>well known to all those who decide what goes into PKIX
>draft standards.

several of the authors of 2459 are aware of the SDN706 work, but they 
did not skew the document to endorse that NSA spec.  today, we would 
encourage putting that info into an AC.

>If my argument does not hold, then authorization info
>in PKIX-compliant certs should be restricted to a hash-reference,
>so it is aligned with the bio-data rationale.

if your analogy were valid, and if we did not disparage use of the 
directory attributes extension, this argument might make sense, 
however, ...

>This would of course make a large swath of NSA certs
>today PKIX non-complying. I doubt PKIX WG would make that
>decision, somehow: so PKIX stds should allow the same logic as
>enabled 100 bytes of authorization information to now
>also hold for embeddeding 100 bytes of bio-data.


we're not talking about backward compatibility here, so again the 
analogy is flawed.

Steve



Received: from exchng-fairfax.pec.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23815 for <[e-mail]>; Fri, 10 Dec 1999 11:03:52 -0800 (PST)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.5.2650.21) id <XPJDQ71Q>; Fri, 10 Dec 1999 14:07:56 -0500
Message-ID: <408016D0F599D311A82B0008C7F450FD0B4267@EXCHNG-FAIRFAX>
From: MHenry <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RFC 2527 Physical Security Controls Question
Date: Fri, 10 Dec 1999 14:07:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

All,

RFC 2527( CP and CPS Framework), 4.5.1,Physical Security Controls, includes
site location and CA facility construction , as topics that should be
considered in a CP or CPS.

I am in the process of writing a CP/CPS and I am looking for standards
that would apply to this section.

Can anyone point me towards an industry/private sector/civil side of
government "standard" for hardening a facility. I am particularly looking
for some sort of of construction standards that would permit me to
distinguish between, for example, a CA facility that might fairly be
described as being built to support a "high" standard of security/assurance
and one built to a "medium" standard. Can it be wood? brick? steel? one
story? windows?
etc?

I spent decades concerned with SCIF designs and vulnerabilities but
I don't think that is what I need here. My potential adversaries are not
national services and what I am protecting is not of such persistent high
value to most people.

Thanks,
Michael C. Henry
Principal Member of the Technical Staff
Performance Engineering Corporation
3949 Pender Drive
Fairfax, VA







Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22279 for <[e-mail]>; Fri, 10 Dec 1999 09:06:42 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMJB3L00.OJF for <[e-mail]>; Fri, 10 Dec 1999 16:57:21 +0000 
Received: from nma.com ([209.21.28.110]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMJB2U00.1GX; Fri, 10 Dec 1999 16:56:54 +0000 
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 1999 08:57:38 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>
Subject: Shifting around the risk burden, Re: Consensus Text for key usage?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Denis:

My disagreement with you is not a matter of
opinion, but in basics. What you propose is
outside the scope of X.509.  Section 1 states
(my inserted *):

 Authentication (and other security services [including
 thus non-repudiation]) can only be provided within
 the context of a defined security policy. It is a matter for
 users of an application to define *their own* security
 policy which may be *constrained* by the services
 provided by a standard.

Further, the general scope of X.509 is *authentication*,
the verification of user credentials. What the user signs
with those credentials is outside the scope of X.509  --
the user is in no way constrained on the content, meaning
or legal implications of what is signed.

So, PKIX MAY constrain the security policies that users
can define but PKIX MUST NOT define that security
policy, NOR what it must include, NOR the legal or otherwise
any implication of what is signed.  PKIX  MAY only say
what a user's security policy MUST NOT allow -- and even
so, ONLY in regard to the scope of PKIX (authentication of
user credentials).

And, this makes pretty good sense. Why should it be
desirable, as you wish, for PKIX to impose upon
users the non-technical burden of risk for the *data*
signed with  a key when X.509 is moot on what is signed
and even on how users should verify what is signed prior
to signing?  And, what does this have to do with security
considerations on *private-keys* in PKIX -- are you really
still constraining user security policies for keys when you
set a mock criminal code  for data that is signed by keys?
After all, PKIX *refuses* to warn CAs on *any* security
risks in that very same NR security discussion you propose --
and thus CAs can become the back-door of user security
if one follows what you suggest and shift the burden of risk
100% to the user.

So, following your suggested additions and forceful defense
of them, I am forced to conclude that even though PKIX is not
willing to trust users to take the necessary precautions, it
does expect them to take the risk of failing to take the
precautions. Is this a fair conclusion?

Your suggestion is therefore: (i) not in accord with X.509
design framework (Section 1) and, (ii) does not allow
risk to be well balanced between user and CA.  In
effect, your suggestion *interferes* with the CA-user
relationship -- which is hands-off by design in X.509,
and intends to *impose* rules on the consequences
of content signed by users -- which is clearly outside
the scope of X.509.

Further, what you propose would amount to an
overreaching security policy set by PKIX over *all*
users, while any  CA is free to do whatever they
want and even to treat different users differently.

Note also that X.509 refrains from setting security
policies even for user identification (this is also
in accord with X.509 Section 1 cited above).  For
example, X.509 Section 11.2.a states that: "a
certification authority shall be satisfied of the
identity of a user before creating a certificate for
it",  which means that identity validation procedures
are to be satisfied in the CA's frame of reference by
following the CA's own rules (CPS), which are
declared outside the scope of X.509 and can be
entirely different for different CAs and even for
different users in the same CA.

So, what is this all about? It is about NOT including the
following text segments in PKIX security discussions,
for the reasons inlined:

1. NOT include:
 When such a  certificate [with NR bit set] is delivered, it
 implies that the owner of the corresponding private key
 should be warned that, in the event of a dispute, he may
 be held responsible of the data signed with this  key.

REASON:  Setting user's security policy on the data
*signed* by the user is outside the scope of PKIX.
The text seems to intend to allow CAs to hide behind
PKIX in order to impose upon users a burden which
not even CAs accept for the data they sign with their
own key.  Obviously, this would be unfair and is not
what this WG should recommend.

2. NOT include:
 If a certificate has both the digitalSignature and the
 nonRepudiation bit set, the owner of the private key
 should make sure that all the environments and
 applications where the corresponding private key is
 being used do not allow a misuse of that private key.

REASON: Obviously impossible -- the user has no way of
knowing that *all* the environments and applications where the
corresponding private key is being used do not allow a misuse of
that private key.  Further, setting user's security policy is outside
the scope of PKIX -- especially so in *applications*.

3. NOT include:
 If that confidence can only be obtained in some
 environments, two different certificates, one with one public
 key and the digitalSignature bit set and another one with a
 different public key and the nonRepudiation bit set, should be
 used, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is only used in secure
 environments.

REASON: Obviously, the private key corresponding to any
certificate [not only NR] should only used in secure
environments, where "secure" is a concept relative to risk
and cost.  Besides, X.509 *already* says this in "One of the
basic principles of strong authentication is that the user’s
private key remain secure. A number of practical methods
are available for the user to hold his private key in a
manner that provides adequate security".

Cheers,

Ed Gerck

PS: My early attempt to "save" some of your suggestions by
editing them to be in accord with X.509's factual text has
been unfruitful. Therefore, it seems better to me to just
delete them. This is however a matter of opinion and I would
welcome (as a second option) that number (2) and (3) be
edited. However, I see nothing of substance that would be
left if (1) is edited to reflect X.509 as an authentication spec,
not a one-sided surreptitious criminal code on content
signed -- as currently implied by it.




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13298 for <[e-mail]>; Fri, 10 Dec 1999 01:44:26 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id KAA20152; Fri, 10 Dec 1999 10:47:08 +0100
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 1999 10:46:50 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>
Subject: Re: Consensus Text for key usage?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

I would like to leave the bandwith of the PKIX mailing list for
other topics and thus I am not going to argument for ever on that
topic. So, (I do hope that) this is my last reply to you on that
topic and I let Tim, the editor, take the final decision. 

> > > > When such a
> > > >     certificate is delivered, it implies that the owner of the
> > > >     corresponding private key should be warned that, in the event of a
> > > >     dispute, he may be held responsible of the data signed with this
> > > >     key.
> >
> > > I am not in favor of this entire sentence.
> > ....
> > > Suggestion: delete the sentence.
> >
> >  If I re-use the example I
> > used during my presenation at the last PKIX session in Washington,
> > the user should really be warned, e.g. not to insert his key in an
> > unknown door lock so that instead of getting the door opened he
> > unknowingly signs a check of 5.000 $.
> 
> Or not. It depends on the CA's CPS, on what is disclaimed by the user
> in the signed data, etc.  My objection to that text segment is that PKIX
> is not the party that should "warn" the user of anything, or mandate that
> the user "should be warned" -- such "warning" is outside the scope of
> PKIX in the same way that the CPS is outside the scope of PKIX.

Your two arguments can be refuted:

1) CA's CPS will say that key that has the NR bit set has NR
properties for everything signed with that key.
So if someting is maliciously signed, it becomes rather hard for the
user to say that it was maliciously obtained. He has to make sure
that nothing can be maliciously signed using that key. The
environment where the key is being used should have a "What You See
Is What You Sign" (WYSIWYS) property.

2) In the example no disclaimer can be placed by the user because he
does not know what he signs while opening the door.

So we currently end up with a simple conclusion: we simply disagree.


> > There may be alternatives to
> > the proposed wording, but the warning should be kept. Do not forget
> > that this belongs to the security considerations section, where
> > warnings are fully appropriate.
> 
> But not for warnings that lie outside the scope of PKIX. For example, the
> user  is not warned to set the date correctly in his computer -- and yet,
> setting a wrong date may make an expired certificate, valid.  The
> justification/negation of user actions, or lack of actions,  lie outside the
> scope of PKIX in the same way that justification of CA's actions are not
> the concern of PKIX.

I would have no problem to extend warnings to the case you describe.
So I do not take this as an argument.

> > > >     If a certificate has both the digitalSignature and the
> > > >     nonRepudiation bit set, the owner of the private key should make
> > > >     sure that all the environments and applications where the
> > > >     corresponding private key is being used do not allow a misuse of
> > > >     that private key.
> > >
> > > I am not in favor of this entire sequence.
> > >....
> > > Suggestion: A toned-down statement might be useful, such as:
> > >
> > >     If a certificate has both the digitalSignature and the
> > >     nonRepudiation bit set, the private key owner should take
> > >     justified measures to prevent a misuse of that private key.
> >
> > I think your sentence creates more problems than the original one.
> > Some people might argument: what means a "justified measure" ? The
> > original sentence should be kept.
> 
> Your point is well taken. Perhaps an even more toned-down note would
> be useful, for example:
> 
>      If a certificate has both the digitalSignature and the
>      nonRepudiation bit set, the private key owner should take
>      measures to prevent a misuse of that private key.

Your proposal is missing the fact that the measures are related to
the environments where the key is being used. It may be sufficiently
explicit for you, but it would become hard to understand for the
novice. 

> where not even justification is predicated -- leaving the user
> responsible for deciding "how", while PKIX clearly warns
> about "what" should be protected when the NR and DS bits
> are set.
> 
> > > >  If that confidence can only be obtained in some
> > > >     environments, two different certificates, one with one public
> > > >     key and the digitalSignature bit set and another one with a
> > > >     different public key and the nonRepudiation bit set, should be used,
> > > >     so that the private key corresponding to the certificate with the
> > > >     nonRepudiation bit set is only used in secure environments.
> > >
> > > I am not in favor of this addition, which seems obvious
> > ....
> > > If one thinks though that saying something is necessary, I suggest, in
> > > agreement with the change proposed above:
> > >...
> >
> > Your proposed text is much more complicated to follow (and longer)
> > than the original one.
> 
> Your point is well taken. I go back to my first suggestion to simply delete
> the addition. Seems less confusing at this time.

You cannot say above " this addition [...] seems obvious " and a few
lines later "delete the addition. Seems less confusing at this
time". It cannot be both obvious and confusing.

Ed, I have done my best to answer your E-mails. We cannot argument
for ever. 

Tim, the final decision is yours.

Regards,

Denis

> Cheers,
> 
> Ed Gerck


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA12982 for <[e-mail]>; Fri, 10 Dec 1999 01:35:06 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA52792; Fri, 10 Dec 1999 10:40:27 +0100
Received: by HYDRA with Microsoft Mail id <01BF42F9.B87E5440@HYDRA>; Fri, 10 Dec 1999 10:31:29 +0100
Message-ID: <01BF42F9.B87E5440@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: PKIX-List <[e-mail]>, "'Ben Laurie'" <[e-mail]>
Subject: RE: QC biometrics needs re-engineering NOW!
Date: Fri, 10 Dec 1999 10:31:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ed,

>Anders Rundgren wrote:

>> Seeing the virtually ZERO progress on the biometric part of QC, I get the feeling it may be
>> a better idea (if speed counts) to keep things within a group with members that are more focused
>> on solutions rather than just making "noise" or running private political campaigns (Ed & Co).

>Anders:

>Sometimes, an attack is the best defense. Not here. Please either defend your
>"secret standard" approach on its own merit (which I postulate does not exist
>and agree with Ben) or keep silence.

A part of this can be found at the biometric Consortium web site:
http://www.biometrics.org/html/x_509.html

>I have no private (or, public) political
>campaigns to run and I feel harassed just by having to come here and say this
>to you.

Since you (and others) do not address the interoperability questions raised, I feel that the
design issues are obscured by too much politics.  Why not allow a design to support
different political/personal opinions instead of forcing a specific one upon everybody?
You believe that privacy is the #1 issue.  That is a personal opinion that not everybody
have to support.   MY personal opinion (which you don't have to share) is that you can
information-wise be "intimate" with a few selected parties.  And to these parties the
authentication of the subject may be of uttermost importance.  Even for the subject BTW!

So let *implementers*,  *customers*, *lawyers* and *market* decide what they feel comfortable with!
It is a free world, isn't it?

>If your point is not accepted today, there is no need to become desperate ;-)

Since a lot of knowledgeable people outside of this pretty boring list support the in-line bio-stuff,
I don't feel that desperate *anymore* :-).  Just puzzled. 


>Maybe, just maybe, you are wrong.

I won't say that you are wrong or than I am right.  I just say that my suggested solution
(user certificate selection), to the subject privacy issue (in my concept not limited to biometrics)
is well worth a comment and hopefully even could be an OPTION in QC.

>Cheers,

Well...

Anders




Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11298 for <[e-mail]>; Fri, 10 Dec 1999 00:46:25 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMIOIT00.05T for <[e-mail]>; Fri, 10 Dec 1999 08:49:41 +0000 
Received: from nma.com ([209.21.28.102]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMIOHR00.K4K; Fri, 10 Dec 1999 08:49:03 +0000 
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 1999 00:50:00 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: PKIX-List <[e-mail]>, "'Ben Laurie'" <[e-mail]>
Subject: Re: QC biometrics needs re-engineering NOW!
References: <01BF4267.0CCA6A40@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Seeing the virtually ZERO progress on the biometric part of QC, I get the feeling it may be
> a better idea (if speed counts) to keep things within a group with members that are more focused
> on solutions rather than just making "noise" or running private political campaigns (Ed & Co).

Anders:

Sometimes, an attack is the best defense. Not here. Please either defend your
"secret standard" approach on its own merit (which I postulate does not exist
and agree with Ben) or keep silence. I have no private (or, public) political
campaigns to run and I feel harassed just by having to come here and say this
to you.

If your point is not accepted today, there is no need to become desperate ;-)
Maybe, just maybe, you are wrong.

Cheers,

Ed Gerck




Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1-ext.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10175 for <[e-mail]>; Fri, 10 Dec 1999 00:40:18 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMIO8L00.4U4 for <[e-mail]>; Fri, 10 Dec 1999 08:43:33 +0000 
Received: from nma.com ([209.21.28.102]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMIO7W00.42R; Fri, 10 Dec 1999 08:43:08 +0000 
Message-ID: <[e-mail]>
Date: Fri, 10 Dec 1999 00:43:50 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus Text for key usage?
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> Ed Gerck wrote:
> > No comments.  The key usage text looks fine.
>
> Good ! (pending a small change requested by Aram which seems quite
> reasonable).

Yes.

> > > When such a
> > >     certificate is delivered, it implies that the owner of the
> > >     corresponding private key should be warned that, in the event of a
> > >     dispute, he may be held responsible of the data signed with this
> > >     key.
>
> > I am not in favor of this entire sentence.
> ....
> > Suggestion: delete the sentence.
>
>  If I re-use the example I
> used during my presenation at the last PKIX session in Washington,
> the user should really be warned, e.g. not to insert his key in an
> unknown door lock so that instead of getting the door opened he
> unknowingly signs a check of 5.000 $.

Or not. It depends on the CA's CPS, on what is disclaimed by the user
in the signed data, etc.  My objection to that text segment is that PKIX
is not the party that should "warn" the user of anything, or mandate that
the user "should be warned" -- such "warning" is outside the scope of
PKIX in the same way that the CPS is outside the scope of PKIX.

> There may be alternatives to
> the proposed wording, but the warning should be kept. Do not forget
> that this belongs to the security considerations section, where
> warnings are fully appropriate.

But not for warnings that lie outside the scope of PKIX. For example, the
user  is not warned to set the date correctly in his computer -- and yet,
setting a wrong date may make an expired certificate, valid.  The
justification/negation of user actions, or lack of actions,  lie outside the
scope of PKIX in the same way that justification of CA's actions are not
the concern of PKIX.

>
> > >     If a certificate has both the digitalSignature and the
> > >     nonRepudiation bit set, the owner of the private key should make
> > >     sure that all the environments and applications where the
> > >     corresponding private key is being used do not allow a misuse of
> > >     that private key.
> >
> > I am not in favor of this entire sequence.
> >....
> > Suggestion: A toned-down statement might be useful, such as:
> >
> >     If a certificate has both the digitalSignature and the
> >     nonRepudiation bit set, the private key owner should take
> >     justified measures to prevent a misuse of that private key.
>
> I think your sentence creates more problems than the original one.
> Some people might argument: what means a "justified measure" ? The
> original sentence should be kept.

Your point is well taken. Perhaps an even more toned-down note would
be useful, for example:

     If a certificate has both the digitalSignature and the
     nonRepudiation bit set, the private key owner should take
     measures to prevent a misuse of that private key.

where not even justification is predicated -- leaving the user
responsible for deciding "how", while PKIX clearly warns
about "what" should be protected when the NR and DS bits
are set.

> > >  If that confidence can only be obtained in some
> > >     environments, two different certificates, one with one public
> > >     key and the digitalSignature bit set and another one with a
> > >     different public key and the nonRepudiation bit set, should be used,
> > >     so that the private key corresponding to the certificate with the
> > >     nonRepudiation bit set is only used in secure environments.
> >
> > I am not in favor of this addition, which seems obvious
> ....
> > If one thinks though that saying something is necessary, I suggest, in
> > agreement with the change proposed above:
> >...
>
> Your proposed text is much more complicated to follow (and longer)
> than the original one.

Your point is well taken. I go back to my first suggestion to simply delete
the addition. Seems less confusing at this time.

Cheers,

Ed Gerck





Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08597 for <[e-mail]>; Thu, 9 Dec 1999 23:57:43 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA43534; Thu, 9 Dec 1999 16:52:02 +0100
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 1999 16:51:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Ed Gerck <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus Text for key usage?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

> Tim Polk wrote:
> 
> >  There are two pieces of proposed text; text for the key usage extension
> > and text for the security considerations section.
> >
> > 4.2.1.3  Key Usage
> >
> 
> No comments.  The key usage text looks fine.

Good ! (pending a small change requested by Aram which seems quite
reasonable).

> > --- proposed new paragraphs for Security Considerations section
> 
> Here, I have some comments.
> 
> >     A CA may include the key usage extension and assert the
> >     nonRepudiation bit when issuing a certificate.
> 
> This part is fine.
> 
> > When such a
> >     certificate is delivered, it implies that the owner of the
> >     corresponding private key should be warned that, in the event of a
> >     dispute, he may be held responsible of the data signed with this
> >     key.
 
> I am not in favor of this entire sentence.  It fixes a context for the
> NR bit which *contradicts* the key usage section (for example: "A
> signature policy identifier embedded in the signed data MAY be used to
> explicitly provide context.") and it unduly imposes upon the owner
> of the private key a duty which the signer herself (the CA, that elusive lady)
> refrains from, for example: in the case of virus, fraud, etc,. These are valid
> cases and if they would be reflected in the text, we would have a repeat of a
> CA's CPS, I am afraid.
 
> So, "when such a certificate is delivered, it implies that" is not a matter to
> be solved here. Rather it MAY be solved in a signature policy identifier
> embedded in the signed data, it MAY be solved in the CA's CPS, etc., all
> as already predicated in PKIX.
 
> Suggestion: delete the sentence.

This is the implication of that bit, as far as the user is
concerned. Your argumentation saying that "it MAY be solved in a
signature policy identifier embedded in the signed data, it MAY be
solved in the CA's CPS, etc" is not valid. If I re-use the example I
used during my presenation at the last PKIX session in Washington,
the user should really be warned, e.g. not to insert his key in an
unknown door lock so that instead of getting the door opened he
unknowingly signs a check of 5.000 $. There may be alternatives to
the proposed wording, but the warning should be kept. Do not forget
that this belongs to the security considerations section, where
warnings are fully appropriate. 

 
> >     If a certificate has both the digitalSignature and the
> >     nonRepudiation bit set, the owner of the private key should make
> >     sure that all the environments and applications where the
> >     corresponding private key is being used do not allow a misuse of
> >     that private key.
> 
> I am not in favor of this entire sequence.  It is not realistic that the
> owner of the private key "should make sure that all the
> environments and applications where the corresponding private key is
> being used" is anything.  The most we can ask is a reasonable effort,
> which may not be much in the case of virus, fraud, theft, etc.  To say
> otherwise is to put on the certificate subject's a burden which not even
> highly-qualified CAs want to shoulder.
> 
> Suggestion: A toned-down statement might be useful, such as:
> 
>     If a certificate has both the digitalSignature and the
>     nonRepudiation bit set, the private key owner should take
>     justified measures to prevent a misuse of that private key.

I think your sentence creates more problems than the original one.
Some people might argument: what means a "justified measure" ? The
original sentence should be kept.

> Of course, "justified measures" are commensurate to cost and risk,
> which means that the above statement is even more effective than
> the original to define what the keyholder's responsibilities are (for
> example, a private key used to sign money transfer justifies a
> need for more precautions than a private key used to sign email messages
> in a mailing list) -- and avoids the trap of requiring the whole world
> to be secure. An untainable goal, which could easily make the original
> clause moot by excessive requirements (not even CAs can do this).
> 
> Note: I have, on purpose, avoided the terms "reasonable measures"
> because reasonableness may be difficult to define in the technical
> sense, while a justification can be a letter from the ISP on which
> one relies upon without (usually) further checking.
> 
> >  If that confidence can only be obtained in some
> >     environments, two different certificates, one with one public
> >     key and the digitalSignature bit set and another one with a
> >     different public key and the nonRepudiation bit set, should be used,
> >     so that the private key corresponding to the certificate with the
> >     nonRepudiation bit set is only used in secure environments.
> 
> I am not in favor of this addition, which seems obvious (do not set the
> NR bit unless you want to set the NR bit), costly (two certificates) and
> unnecessary -- since I can use only one certificate with the NR bit set
> and deny NR directly in the signed data, case by case (NR opt out mode).
> Or, I can use only one certificate with the NR bit off and grant NR directly
> in the signed data, case by case (NR opt in mode).
> 
> If one thinks though that saying something is necessary, I suggest, in
> agreement with the change proposed above:
> 
>  If the private key owner can only prevent misuse in some environments,
>  then it is possible to use a certificate with the nonRepudiation bit
>  set and deny non-repudiation in the signed data, case by case (NR opt
>  out mode); or use a certificate with the nonRepudiation bit off and
>  grant non-repudiation in the signed data, case by case (NR opt in
>  mode); or use two different certificates, one with one public key and
>  the digitalSignature bit set and another one with a different public
>  key and the nonRepudiation bit set; or use another method that could
>  be justified, so that the private key corresponding to the certificate
>  with the nonRepudiation bit set is not used in environments that may
>  either not conform to a non-repudiation signature policy, or be unknown.

Your proposed text is much more complicated to follow (and longer)
than the original one. It introduces notions which are not explained
in that document e.g. "NR opt out mode" ?!?" and "NR opt in mode"
?!? is also incorrect on several aspects; e.g. you said: " If the
private key owner can only prevent misuse in some environments, then
it is possible to use a certificate with the nonRepudiation bit set
[...] case by case". I do not think that the user, in *any* case,
should use (the corresponding private key of) a certificate with the
nonRepudiation bit set, if he cannot prevent the misuse of his
private key.

Tim, the editor, could apparently live with the original proposal.
Let us keep the original text, if you can also "live with it". :-)

Regards,

Denis

> Cheers,
> 
> Ed Gerck


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08473 for <[e-mail]>; Thu, 9 Dec 1999 23:55:49 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA23760; Thu, 9 Dec 1999 16:27:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 1999 16:27:23 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus Text for key usage?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Aram,

As far as I am concerned your two proposed (small) changes seem
quite reasonable to me.

Regards,

Denis

 
> Hi Tim,
> 
> > Folks,
> >
> > With Aram and Denis back in the fray, I think we can finish this one off.
> > I have incorporated all the changes, and think we may be nearing consensus!
> >  There are two pieces of proposed text; text for the key usage extension
> > and text for the security considerations section.
> >
> > Please read it carefully.  In general, the changes were all introduced on
> > the list in the "porposed" thread, but I have tweaked a couple of other
> > paragraphs.  The only real suprise is that I capitulated and deleted the
> > word "user" under dataEncipherment.  I thought keeping it would be less
> > controversial, but that wasn't true!  I don't think it added anything, so
> > let's delete it.
> >
> > Thanks,
> >
> > Tim Polk
> >
> [snip]
> >        The digitalSignature bit is asserted when the subject public key
> >        is used with a digital signature mechanism to support security
> >        services other than non-repudiation (bit 1), certificate signing
> >        (bit 5), or revocation information signing (bit 6). Digital signa-
> >        ture mechanisms are often used for entity authentication and data
> >        origin authentication with integrity.
> >
> >        The nonRepudiation bit is asserted when the subject public key is
> >        used to verify digital signatures used to provide a non-repudiation
> >        service.  This service protects against the certificate subject falsely
> >        denying signing the data.  In the case of later conflict, a reliable
> >        third party may determine the authenticity of the signed data.
> 
> Shouldn't this last sentence read something like "a reliable third party may
> determine the non-repudiability (or repudiability) of the signed data" since
> previous paragraph states the digitalSignature is used for "entity
> authentication and data origen authentication"?
> 
> [snip]
> >
> >     This profile does not restrict the combinations of bits that may be
> >     set in an instantiation of the keyUsage extension.  However,
> >     valid combinations of bits are specified for particular algorithms
> >     in section 7.3.
> 
> Like I mentioned in a private exchange, I would add something to the effect
> of "Although there are no key restrictions, implementers should be aware
> that certain combinations do not make sense (i.e. keyAgreement for RSA keys,
> keyExchange for ECC keys) and some combinations may 'be insecure' (or
> 'lessen the security')."
> 
> [snip]
> 
> Regards,
> Aram Perez


Received: from 157.22.235.99 ([157.22.235.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA01619; Thu, 9 Dec 1999 12:14:32 -0800 (PST)
Received: from [157.22.235.84] by 157.22.235.99 (AppleShare IP Mail Server 6.2) id 30901 via TCP with SMTP; Thu, 09 Dec 1999 12:14:29 -0800
Message-id: <991209121429.3b44e7f.9d16eb63.ASIP6.2.30901@157.22.235.99>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 09 Dec 1999 12:14:29 -0800
Subject: Subscription Request
From: "Heidi Slominski" <[e-mail]>
To: Subscriptions <[e-mail]>
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

I'd greatly appreciate it if you would please forward me the appropriate 
information for subscribing to/getting the digest for your mail list.

Thank you very much!

Warm Regards,

Heidi Slominski
Marketing Coordinator
--
Mactivity, Inc.
Conference Organizers

Tel: [phone]
Fax: [phone]
www.mactivity.com



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27989 for <[e-mail]>; Thu, 9 Dec 1999 08:04:50 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA62058; Thu, 9 Dec 1999 17:10:34 +0100
Received: by HYDRA with Microsoft Mail id <01BF4267.0CCA6A40@HYDRA>; Thu, 9 Dec 1999 17:01:35 +0100
Message-ID: <01BF4267.0CCA6A40@HYDRA>
From: Anders Rundgren <[e-mail]>
To: PKIX-List <[e-mail]>, "'Ben Laurie'" <[e-mail]>
Subject: RE: QC biometrics needs re-engineering NOW!
Date: Thu, 9 Dec 1999 17:01:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ben,

Regarding "secret" standards

Seeing the virtually ZERO progress on the biometric part of QC, I get the feeling it may be
a better idea (if speed counts) to keep things within a group with members that are more focused
on solutions rather than just making "noise" or running private political campaigns (Ed & Co).

There are currently several consortiums that are competing (and sometimes
cooperating) with IEITF.  Like W3C, WAP-forum, OBI-forum, Bluetooth etc. etc.
More is in the works which I am not allowed to mention.

All these consortiums release drafts for public review when a draft has reached a
certain level of perfection.  These consortiums though keep the final decision-part internally.

Anders

PS. ZERO progress = no explanations to the raised interoperability questions, or comments to
"competing" solutions like user certificate selection  DS

----------
From:  Ben Laurie [SMTP:[e-mail]]
Sent:  Thursday, December 09, 1999 10:38
To:  PKIX-List
Subject:  Re: QC biometrics needs re-engineering NOW!

Anders Rundgren wrote:
>                              #   #   #  #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #
> But this discussion is a pure waste of time as biometrics in certificates have already
> been "standardized" by another group.  I cannot tell which one right now as I received
> this information privately.   And Steve, they of course choosed in-line bio-data!
>                              #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #
> 
> BTW, *their* draft looks real good and supports 20 different biometrics.

A secret "standard", eh? That'll be really useful.

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20099 for <[e-mail]>; Thu, 9 Dec 1999 01:35:15 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id JAA28974 for <[e-mail]>; Thu, 9 Dec 1999 09:38:12 GMT
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id JAA20802 for <[e-mail]>; Thu, 9 Dec 1999 09:38:22 GMT
Message-ID: <[e-mail]>
Date: Thu, 09 Dec 1999 09:38:13 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: PKIX-List <[e-mail]>
Subject: Re: QC biometrics needs re-engineering NOW!
References: <008b01bf41dc$82857c60$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
>                              #   #   #  #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #
> But this discussion is a pure waste of time as biometrics in certificates have already
> been "standardized" by another group.  I cannot tell which one right now as I received
> this information privately.   And Steve, they of course choosed in-line bio-data!
>                              #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #
> 
> BTW, *their* draft looks real good and supports 20 different biometrics.

A secret "standard", eh? That'll be really useful.

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA08754 for <[e-mail]>; Wed, 8 Dec 1999 15:30:08 -0800 (PST)
Received: from mega (t3o69p108.telia.com [62.20.145.108]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id AAA32063; Thu, 9 Dec 1999 00:35:57 +0100
Message-ID: <008b01bf41dc$82857c60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Ed Gerck" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Magnus (RSA)" <[e-mail]>
Subject: Re: QC biometrics needs re-engineering NOW!
Date: Thu, 9 Dec 1999 00:29:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA08755

>The largely unseen problem here is that the proponents of such unambiguous
>certificates  do not realize that privacy is at odds with security in CA systems.
>And, a bit more of security does not justify a bit less of privacy -- those that
>are willing to risk it will IMO lose both.  For further comments, also about
>reliance on biometrics to safeguard values (documents, money, etc.), please
>see http://www.mcg.org.br/faust.htm


Ed, if you do not have a single trusted party that you can allow to know your SSN,
some biometrics etc. you don't have a security problem, you have *personal* problem.

Security is also for a user to know that his/her lost keys are not only protected by PIN-codes
but optionally by biometrics.

Maybe you still believe that PUBLIC Key Certificates by default are public? 

                             #   #   #  #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   # 
But this discussion is a pure waste of time as biometrics in certificates have already
been "standardized" by another group.  I cannot tell which one right now as I received
this information privately.   And Steve, they of course choosed in-line bio-data!
                             #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #   #   #  #  

BTW, *their* draft looks real good and supports 20 different biometrics.

Anders



Received: from keeper.siac.com ([e-mail] [162.69.5.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08246 for <[e-mail]>; Wed, 8 Dec 1999 15:00:53 -0800 (PST)
Received: by keeper.siac.com; id SAA02787; Wed, 8 Dec 1999 18:04:17 -0500 (EST)
Received: from bigmouth.siac.com(162.69.5.8) by keeper.siac.com via smap (V4.2) id xma002644; Wed, 8 Dec 99 18:04:00 -0500
Received: from localhost (dfinkels@localhost) by tang01.wisdom.siac.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA12749; Wed, 8 Dec 1999 18:03:29 -0500 (EST)
X-Authentication-Warning: tang01.wisdom.siac.com: dfinkels owned process doing -bs
Date: Wed, 8 Dec 1999 18:03:28 -0500 (EST)
From: Daniel Alex Finkelstein <[e-mail]>
X-Sender: [e-mail]
To: "Todd Glassey @ GMT" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Timestamping Standards.
In-Reply-To: <04b001bf257f$40a14b90$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Nov 2, 1999 at 2:11pm,  Todd Glassey @ GMT wrote:

> They provide for a requirements to provably timestamp within three (3)
> seconds of UTC and these are of course the NASD OATS requirements. NASD for
> thos that are unaware is the NAtional Association of Securities Dealers and
> any solution that is proffered as a timestamping one for commercial purposes
> should ought to fulfill the only mandate on the books today. To get more of
> this try the OATS pages at the www.nasdr.com site.

The NASD does not specify or recommend technical matters. Member firms and
financial houses gather at our various industry groups to set technical
specs, and then turn to us (SIAC) for implementation.

-- 
Daniel Alex Finkelstein
Central Services
phone   [phone]
pager   917-427-1630
fax     [phone]
Securities Industry Automation Corporation



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02764 for <[e-mail]>; Wed, 8 Dec 1999 14:05:11 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 1060"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Wed, 8 Dec 1999 17:08:17 -0400
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <Y1RQ1P5C>; Wed, 08 Dec 1999 17:08:17 -0500
Content-return: allowed
Date: Wed, 08 Dec 1999 17:08:17 -0500
From: "Sweigert, David" <[e-mail]>
Subject: CA Audit Post
To: Hiroyuki Sakakibara <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA02765

cross-posting, apologies to those of you who have already seen this

-----Original Message-----
From: Ozgar, Gene A [mailto:[e-mail]]
Sent: Sunday, December 05, 1999 10:00 AM
To: [e-mail]
Subject: FW: NC E-Commerce Act Rules,Certificate Autho


John,

I'm a co-chair of the "audit and attestation" section of the ABA ISC working
group that you describe, and happen to be based in Charlotte.  We have
drafted a section of the ABA document which outlines in detail the
characteristics of the CA auditor.  I've been watching these NC EC
discussions with great interest, and would be glad to have a discussion
about this.  Maybe we can speak with the Secretary about this in person.

BTW, our work in the ABA is agnostic regarding the actual designation (CPA,
CISSP, etc.) but rather outlines the desired characteristics.

I believe that the auditor should possess adequate technical training with a
demonstrated proficiency in:

§ Public key infrastructure technology
§ Information security tools and techniques
§ Security auditing
§ The third-party attest function

The auditor should be organizationally independent of the CA's operation and
policy authorities.

The auditor should be accredited by a recognized professional organization
or association.  Membership in the particular organization or association
should require the possession of certain skill sets, quality assurance
measures such as peer review, standards with respect to proper assignment of
staff to engagements, and requirements for continuing professional
education.

If the above is true, then in many cases, the skills necessary to perform
the audit of a CA will not repose in a single individual.  Other important 
requirements for attestation are objectivity and credibility, and the
willingness and ability to take on the liability that may come with the
attestation.  A CA audit will be considered of great value when it is
performed by an organization that is notorious for integrity and possession
of the characteristics described above.  Also, firms who perform attestation
services and meet quality assurance requirements are likely to bring a team
of professionals (CPA, CISSP, others?) to bear that is appropriate to the
risks of the given audit engagement.

If there were one perfectly aligned professional designation I guess we
wouldn't be having this conversation.  Just some ideas.


Gene

Gene Ozgar
KPMG LLP
[e-mail]

-----Original Message-----
From: John Messing [mailto:[e-mail]]
Sent: Friday, December 03, 1999 5:59 AM
To: [e-mail]
Subject: Re: NC E-Commerce Act Rules, Certificate Autho


You may recall that we met on the podium of a speaker from Tom Smedinghoff's
law firm at the 1997 or 1998 RSA Security Conference. Your name was one that
stuck in my mind.

I find your comments very interesting. I work with the ABA's ISC, which is
currently authoring a document on audits of certification authorities and
the accreditation of auditors, similar in concept to the Digital Signature
Guidelines which it generated a number of years ago. I would like to forward
these two posts to the list serve for that group, for comment, but I would
like your permission first.

My company, Law-on-Line, does e-filings and uses PGP for its digital
signatures. I am also working with another start-up, Signauthority.com, LLC,
which uses the technology of Extensible Key Infrastructure, XKI, rather than
PKI. If you are interested, we can discuss it at some future time.

I am glad to see how your expertise in this area has developed.

Best regards.

----- Original Message -----
From: Kepa Zubeldia <[e-mail]>
To: <[e-mail]>
Sent: Thursday, December 02, 1999 4:36 PM
Subject: Re: NC E-Commerce Act Rules, Certificate Autho


> Peter,
>
> I believe it is a mistake to remove the Security Audit.  Unless the
Secretary
> wants to perform an Audit or an Accreditation/Certification of each
Licensed CA,
> the Security Audit performed by a third party is the best way to assure
> compliance with the requirements to be a CA.
>
> The problem is that a SAS70 audit is probably not the best metric.  In my
> opinion a CS2 audit using the CPS and Certificate Policies as the
"Security
> Target" for the Audit is the best way to go.  This way the auditors can
certify
> that the CA does in fact meet the terms of the CPS.  The CPS is approved
by the
> Secretary of State, and the Auditor is the one that verifies compliance
with the
> terms of the license.  Of course, the CPS will have to include the fact
that the
> CA is compliant with the Act and the Rules in N.C.
>
> As for the qualifications of the auditor, a CISSP is much better than an
> accountant, but you could require that the auditor be both a CISSP and a
CPA.
>
> As for the risk assessment, I believe that a CA should only be licensed
once
> they are in production and can be audited as being in compliance with
their own
> CPS.  Having a licensed CA that is not in production and is only under
> construction is such a moving target that any attempt to audit it would be
> meaningless in a very short time.
>
> If you want we can discuss this over the phone or on a conference call.
>
> Thanks for the opportunity to comment on these proposed changes.
>
> Kepa Zubeldia
> ARCANVS, Inc.
>
> ____________________Reply Separator____________________
> Subject:    NC E-Commerce Act Rules,                Certificate Authorit
> Author: This is the Electronic Commerce Rules Forum List
> <[e-mail]>
> Date:       11/22/99 12:44 PM
>
> Reference is made to paragraph (4) Security Audits:
>
> And what qualifications and certifications are needed for the person who
> performs the "security audit"?  Can a Certified Information Systems
Security
> Professional (CISSP) perform such an audit or must it be done by a
Chartered
> (or other) Accountant?  What, legally, constitutes an "audit" in this
> context?  Is it defined by the process that is carried out or by the
> certifications and qualifications that the person doing the audit
possesses?
>   If so what are the set of such certifications and qualifications and how
> to they relate to security and the technical knowledge and knowledge of
the
> technology?  Can NC corporations that are NOT independent NATIONALLY
> recognized security audit firm be approved by EC section?  Since there is
no
> professional organization that certifies firms to do security audits only
> the professional themselves www.isc2.org then how does a firm become
> qualified?  A security audit can only be done against a production system
to
> validate that it is in fact secure bsed on the knowledge of the security
> auditor.  Prior to production a risk assessment is perform under the
> methodology of certification and accreditation.  Dont you want a risk
> assessment (C&A) done with a report to EC Section and audits after the
> systems are in production?
>
> To be continued...
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
****************************************************************************
*
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
****************************************************************************
*

To unsubscribe send the following in the body of a message to
[e-mail]  - unsubscribe st-isc


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02258 for <[e-mail]>; Wed, 8 Dec 1999 13:45:42 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA04626; Wed, 8 Dec 1999 13:46:56 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 08 Dec 1999 16:19:29 -0500
To: Pavel Krylov <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: cert == crl
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

If the CRLIssuer GN is a DirectoryName, then the CRL can be found in the 
LDAP or X.500 Directory.  I think that all of the other cases are ambiguious.

Russ

At 08:18 PM 12/8/99 +0300, Pavel Krylov wrote:
>Hi all,
>
>I would be grateful if someone helped me with one case in CRL
>processing.
>A certificate has some information how to find appropriate CRLs
>to check revokation status of the certificate. This information includes
>certificate issuer name (DN), alternative issuer name (GN) and CRLDPs
>extension, which in its order includes distribution point (dp, i.e.
>a choice between fullName(GN) and nameRelativeToCRLIssuer (rdn) ),
>reason codes and cRLIssuer name (GN).
>
>Okay, how I understand CRL processing begins from certificate, i.e.
>getting proper information to find appropriate CRL. Suppose, we have
>a certificate with following fields ( only mentioned to CRL ):
>
>         cert
>          |_ issuer (DN)
>          |_ altIssuer (GN)
>          |_ certExtensions
>             |_ CRLDPs extension
>                |_ crldp
>                   |_ cRLIssuer (GN)
>
>i.e. dp is absent, but cRLIssuer is present in CRLDPs extension.
>In this case I have a name of issuer of needed CRL, but it is
>represented by GN type. Say, I have some CRLs to try to apply them
>for the certificate. But each CRL has issuer (DN) and altIssuer (GN).
>So my question is how cRLIssuer(GN) is supposed to be compared with
>crl.issuer(DN) and crl.altIssuer(GN)??
>
>Any ideas?
>
>Thanks a lot.
>
>Pavel Krylov



Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28270 for <[e-mail]>; Wed, 8 Dec 1999 09:15:57 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.4) id UAA20866; Wed, 8 Dec 1999 20:19:04 +0300 (MSK)
Received: from tws123(212.114.5.15) by zuka via smap (V2.0) id xma020826; Wed, 8 Dec 99 20:18:17 +0300
Message-ID: <[e-mail]>
Date: Wed, 08 Dec 1999 20:18:23 +0300
From: Pavel Krylov <[e-mail]>
Organization: TrustWorks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: cert == crl
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I would be grateful if someone helped me with one case in CRL
processing.
A certificate has some information how to find appropriate CRLs
to check revokation status of the certificate. This information includes
certificate issuer name (DN), alternative issuer name (GN) and CRLDPs
extension, which in its order includes distribution point (dp, i.e. 
a choice between fullName(GN) and nameRelativeToCRLIssuer (rdn) ),
reason codes and cRLIssuer name (GN).

Okay, how I understand CRL processing begins from certificate, i.e.
getting proper information to find appropriate CRL. Suppose, we have
a certificate with following fields ( only mentioned to CRL ):
        
        cert
         |_ issuer (DN)
         |_ altIssuer (GN)
         |_ certExtensions
            |_ CRLDPs extension
               |_ crldp
                  |_ cRLIssuer (GN)

i.e. dp is absent, but cRLIssuer is present in CRLDPs extension.
In this case I have a name of issuer of needed CRL, but it is 
represented by GN type. Say, I have some CRLs to try to apply them
for the certificate. But each CRL has issuer (DN) and altIssuer (GN).
So my question is how cRLIssuer(GN) is supposed to be compared with
crl.issuer(DN) and crl.altIssuer(GN)??

Any ideas?

Thanks a lot.

Pavel Krylov


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27286 for <[e-mail]>; Wed, 8 Dec 1999 08:16:15 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA27305; Wed, 8 Dec 1999 08:17:25 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 08 Dec 1999 11:02:23 -0500
To: [e-mail] (Terry Hayes)
From: Russ Housley <[e-mail]>
Subject: Re: Q: Are repeated OIDs allowed in the AIA extension?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Terry:

We tried to clarify AIA in the revision to RFC 2459.  Please review 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-00.txt.  If 
you still have questions, please post them in the context of the new AIA text.

Russ

At 05:14 PM 12/7/99 -0800, Terry Hayes wrote:
>All,
>
>This is a question about the constraints on the contents of the
>Authority Information Access extension as defined in RFC 2459.  This the
>data value in this extension consists of a sequence of OID/GeneralName
>pairs.  The OID portion of the pair indicates the purpose of the value,
>while the GeneralName indicates where and (in some cases) the protocol
>to use to perform other operations related to the certificate.  The
>current RFC does not specify any restriction on the values stored in the
>extension.  In particular, it doesn't seem to rule out pairs in the
>sequence that have the same OID.
>
>I can imagine certificates that are issued that make use of the
>capability to associate multiple location values (names) with a single
>OID.  For example:
>
>      OCSPResponder : http://ocsp.company.com
>      OCSPResponder : http://ocsp.default.com
>
>This set of values in the AIA extension might indicate that two OCSP
>responders are available for checking certificate status.  Also:
>
>      OCSPResponder: http://ocsp.company.com
>      OCSPResponder: tcpmsg://ocsp.company.com:1111
>
>This configuration might indicate that OCSP is available over two
>protocols (HTTP POST and a hypothetical standard TCP message protocol).
>The certificate client would be allowed to choose on that it has
>implemented.
>
>Is this sort of repeated value allowed in AIA?
>
>Terry Hayes
>[e-mail]



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27279 for <[e-mail]>; Wed, 8 Dec 1999 08:16:15 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA27309; Wed, 8 Dec 1999 08:17:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 08 Dec 1999 11:11:01 -0500
To: "Hiroyuki Sakakibara" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: certificate which has both AIA and CRL DPs
Cc: <[e-mail]>
In-Reply-To: <007601bf4126$88da3df0$78054a0a@belize>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hiroyuki:

Answer 1:  Yes, a certificate can contain both a CRL Distribution Point 
(CRLDP) extension and an Authority Information Access (AIA) extension.

Answer 2:  Precedence is not specified.  The client may either fetch the 
CRLs or use OCSP to determine whether or not the certificate is revoked.

Russ


At 11:47 AM 12/8/99 +0900, Hiroyuki Sakakibara wrote:
>Hello
>
>I would like to generate a certificate which has
>both AIA and CRL DPs.
>
>Question1 : In RFC2459 specification, is this
>                     certificate legal or illegal ?
>
>Question2 : If this certificate is legal, how does it describe the
>                      order of priority to process those extensions?
>
>For example,
>------------------------------------------------
>1st.                        OCSP server-1
>2nd.                       OCSP server-2
>3rd.                       CRL DP-1
>4th.                        CRL DP-2
>
>or
>
>1st.                        OCSP server-1
>2nd.                       CRL DP-1
>3rd.                        OCSP server-2
>4th.                        CRL DP-2
>
>etc ...
>------------------------------------------------
>
>Is a new extension(or any scheme) which describes the
>list of these priorities needed?
>
>like this
>
>LIST  {
>1st    use AIA's 1st element,
>2nd   use CRL DPs 1st element,
>3rd    use "other method",
>4th    use  AIA's 2nd element,
>5th    use  CRL DPs 2nd element,
>etc ...
>}
>
>Please, can anyone help?
>
>Hioryuki Sakakibara
>
>=========================================
>Hiroyuki Sakakibara
>Research Engineer
>Information Security Department
>Mitsubishi Electric Corporation
>Information Technology R&D Center
>5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
>PHONE: [phone]
>FAX: [phone]
>==========================================



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26794 for <[e-mail]>; Wed, 8 Dec 1999 07:53:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA26914; Wed, 8 Dec 1999 07:55:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 08 Dec 1999 10:54:34 -0500
To: "Aram Perez" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Consensus Text for key usage?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:26 PM 12/7/99 -0800, Aram Perez wrote:
> >     This profile does not restrict the combinations of bits that may be
> >     set in an instantiation of the keyUsage extension.  However,
> >     valid combinations of bits are specified for particular algorithms
> >     in section 7.3.
>
>Like I mentioned in a private exchange, I would add something to the effect
>of "Although there are no key restrictions, implementers should be aware
>that certain combinations do not make sense (i.e. keyAgreement for RSA keys,
>keyExchange for ECC keys) and some combinations may 'be insecure' (or
>'lessen the security')."

The sections that discuss each algorithm could state which bits may or may 
not be set for that algorithm.  In my view, algorithm specific information 
should not be included in the discussion of this extension.

Russ


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26343 for <[e-mail]>; Wed, 8 Dec 1999 07:31:53 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA52939; Wed, 8 Dec 1999 16:37:40 +0100
Received: by HYDRA with Microsoft Mail id <01BF4199.48A50800@HYDRA>; Wed, 8 Dec 1999 16:28:39 +0100
Message-ID: <01BF4199.48A50800@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: Tony Bartoletti <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: No, was Re: QC biometrics needs re-engineering NOW!
Date: Wed, 8 Dec 1999 16:28:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

>No real problems with interoperability with the current solution has ben presented

I do not agree with your conclusion regarding interoperability.
Neither did Tony B regarding the hash-bio solution.  Try to build a system and you will see...

Absolutely nothing has been presented by anybody giving any clues on how to achieve interoperability.

>This is not a complete biometric solution.

No, I think that it is so inferior that it should be left out from the draft.

Don't worry, I will soon write a QC addendum that supports both interoperability,
privacy, additional biometric types, and does not require any new protocols.  It
will be developed together with the leading biometrics companies.

Anders



Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25353 for <[e-mail]>; Wed, 8 Dec 1999 06:30:02 -0800 (PST)
Received: from best-laptop (par-c45-005-vty141.as.wcom.net [195.232.69.141]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id QAA26886 for <[e-mail]>; Wed, 8 Dec 1999 16:48:36 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 08 Dec 1999 09:34:57 -0500
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: No, was Re: QC biometrics needs re-engineering NOW!
In-Reply-To: <002501bf4149$bc731560$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

My conclusion from this discussion is that our consensus from last time
this was up for debate still stands.

1) We don't want to involve us in the complex issue of machine verified
bio-metrics and they serve no meaningful purpose in remote authentication.

2) We don't want to encourage inclusion of the actual bio metric data in
certificates. It is OK to include a hash but not the actual data. I would
personally sleep better if we keep this limitation.

No real problems with interoperability with the current solution has ben
presented .

This is not a complete general bio-metrics solution. It never was and it
never will be. But it serves a particular relevant issue. For expanded
solutions I would suggest a separate work item.

I hope we all can live with this.

/Stefan


At 06:59 1999-12-08 +0000, Anders Rundgren wrote:
>>> >as you should be able to see from
>>> >the archive (but its so long ago I forget, maybe it was
>>> >a private posting). I think Steve K. addressed the issue
>>> >when he said that handing over a URL says nothing about
>>> >who can gets a 404 vs. a 200 when they ask for the content.
>>>
>>> That is REALLY silly!
>>
>>No, it is not. It means that the biometric data can be denied to
>>you, even though it is available.  You may need a client certificate
>>to get it, or a password, or be in an IP range  You don't get it just
>>because it is in the certificate.
>>
>>BTW, I may suggest that including identifying biometric data in
>>certificates is unconstitutional in the entire EC, where countries
>>have harmonized their constitutions to directly *forbid* any
>>initiative which may allow the creation of a unique indentifier,
>>a national ID.  Please verify in the current Swedish Carta Magna,
>>or German, etc.
>
>
>Ed, I think that your answer verifies what I have suspected all the time: 
>The authors
>of the two variants of bio-metrics linked to certs are not really such lousy 
>engineers,
>but are so against the idea of biometrics and PKI that they push solutions
that
>have no chance to suceed on a wider scale since they are by design 100%
>not interoperable.  QCs are unconstitutional?  Stefan, where you?
>
>Anders



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA09120 for <[e-mail]>; Tue, 7 Dec 1999 21:59:51 -0800 (PST)
Received: from mega (t2o69p42.telia.com [62.20.144.162]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA42956; Wed, 8 Dec 1999 07:05:20 +0100
Message-ID: <002501bf4149$bc731560$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Ilan Shacham" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: No, was Re: QC biometrics needs re-engineering NOW!
Date: Wed, 8 Dec 1999 06:59:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA09121

>> >as you should be able to see from
>> >the archive (but its so long ago I forget, maybe it was
>> >a private posting). I think Steve K. addressed the issue
>> >when he said that handing over a URL says nothing about
>> >who can gets a 404 vs. a 200 when they ask for the content.
>>
>> That is REALLY silly!
>
>No, it is not. It means that the biometric data can be denied to
>you, even though it is available.  You may need a client certificate
>to get it, or a password, or be in an IP range  You don't get it just
>because it is in the certificate.
>
>BTW, I may suggest that including identifying biometric data in
>certificates is unconstitutional in the entire EC, where countries
>have harmonized their constitutions to directly *forbid* any
>initiative which may allow the creation of a unique indentifier,
>a national ID.  Please verify in the current Swedish Carta Magna,
>or German, etc.


Ed, I think that your answer verifies what I have suspected all the time: The authors
of the two variants of bio-metrics linked to certs are not really such lousy engineers,
but are so against the idea of biometrics and PKI that they push solutions that
have no chance to suceed on a wider scale since they are by design 100%
not interoperable.  QCs are unconstitutional?  Stefan, where you?

Anders



Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18232 for <[e-mail]>; Tue, 7 Dec 1999 18:46:06 -0800 (PST)
Received: by florida.melco.co.jp (3.7W-florida) id LAA06863; Wed, 8 Dec 1999 11:48:57 +0900 (JST)
Received: by mailgw.melco.co.jp (3.7W-mailgw) id LAA05034; Wed, 8 Dec 1999 11:49:19 +0900 (JST)
Received: by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.7W-inetgw) id LAA10171; Wed, 8 Dec 1999 11:49:34 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id LAA14517; Wed, 8 Dec 1999 11:49:36 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id LAA11950; Wed, 8 Dec 1999 11:53:04 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id LAA05654; Wed, 8 Dec 1999 11:48:59 +0900 (JST)
Message-ID: <007601bf4126$88da3df0$78054a0a@belize>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: certificate which has both AIA and CRL DPs
Date: Wed, 8 Dec 1999 11:47:14 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700

Hello

I would like to generate a certificate which has
both AIA and CRL DPs.

Question1 : In RFC2459 specification, is this 
                    certificate legal or illegal ?

Question2 : If this certificate is legal, how does it describe the
                     order of priority to process those extensions?

For example, 
------------------------------------------------
1st.                        OCSP server-1
2nd.                       OCSP server-2
3rd.                       CRL DP-1
4th.                        CRL DP-2

or

1st.                        OCSP server-1
2nd.                       CRL DP-1
3rd.                        OCSP server-2
4th.                        CRL DP-2

etc ...
------------------------------------------------

Is a new extension(or any scheme) which describes the
list of these priorities needed?

like this

LIST  {
1st    use AIA's 1st element,
2nd   use CRL DPs 1st element,
3rd    use "other method",
4th    use  AIA's 2nd element,
5th    use  CRL DPs 2nd element,
etc ...
}

Please, can anyone help? 

Hioryuki Sakakibara

=========================================
Hiroyuki Sakakibara
Research Engineer
Information Security Department
Mitsubishi Electric Corporation
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
PHONE: [phone]
FAX: [phone]
==========================================



Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09258 for <[e-mail]>; Tue, 7 Dec 1999 17:12:18 -0800 (PST)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA25430 for <[e-mail]>; Tue, 7 Dec 1999 17:14:18 -0800 (PST)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FMEE4T00.JD4 for <[e-mail]>; Tue, 7 Dec 1999 17:14:53 -0800 
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 17:14:44 -0800
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Q: Are repeated OIDs allowed in the AIA extension?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

This is a question about the constraints on the contents of the
Authority Information Access extension as defined in RFC 2459.  This the
data value in this extension consists of a sequence of OID/GeneralName
pairs.  The OID portion of the pair indicates the purpose of the value,
while the GeneralName indicates where and (in some cases) the protocol
to use to perform other operations related to the certificate.  The
current RFC does not specify any restriction on the values stored in the
extension.  In particular, it doesn't seem to rule out pairs in the
sequence that have the same OID.

I can imagine certificates that are issued that make use of the
capability to associate multiple location values (names) with a single
OID.  For example:

     OCSPResponder : http://ocsp.company.com
     OCSPResponder : http://ocsp.default.com

This set of values in the AIA extension might indicate that two OCSP
responders are available for checking certificate status.  Also:

     OCSPResponder: http://ocsp.company.com
     OCSPResponder: tcpmsg://ocsp.company.com:1111

This configuration might indicate that OCSP is available over two
protocols (HTTP POST and a hypothetical standard TCP message protocol).
The certificate client would be allowed to choose on that it has
implemented.

Is this sort of repeated value allowed in AIA?

Terry Hayes
[e-mail]



Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06884 for <[e-mail]>; Tue, 7 Dec 1999 15:29:19 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FME87200.7G3 for <[e-mail]>; Tue, 7 Dec 1999 23:06:38 +0000 
Received: from nma.com ([209.21.28.80]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FME6MJ00.E29; Tue, 7 Dec 1999 22:32:43 +0000 
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 14:29:08 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Stefan Santesson <[e-mail]>, Ilan Shacham <[e-mail]>, Tony Bartoletti <[e-mail]>, [e-mail], [e-mail]
Subject: No, was Re: QC biometrics needs re-engineering NOW!
References: <007501bf4105$21c34330$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> Stephen,
> ...
> >as you should be able to see from
> >the archive (but its so long ago I forget, maybe it was
> >a private posting). I think Steve K. addressed the issue
> >when he said that handing over a URL says nothing about
> >who can gets a 404 vs. a 200 when they ask for the content.
>
> That is REALLY silly!

No, it is not. It means that the biometric data can be denied to
you, even though it is available.  You may need a client certificate
to get it, or a password, or be in an IP range  You don't get it just
because it is in the certificate.

BTW, I may suggest that including identifying biometric data in
certificates is unconstitutional in the entire EC, where countries
have harmonized their constitutions to directly *forbid* any
initiative which may allow the creation of a unique indentifier,
a national ID.  Please verify in the current Swedish Carta Magna,
or German, etc.

Cheers,

Ed Gerck




Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06197 for <[e-mail]>; Tue, 7 Dec 1999 15:05:24 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF044VM>; Tue, 7 Dec 1999 15:04:00 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Stephen Kent '" <[e-mail]>
Cc: "'PKIX-List '" <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Date: Tue, 7 Dec 1999 15:04:00 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="iso-8859-1"

 
Steve's argument really does not make sense, in a wider context.

NSA defines, in SDN706, clearance and privilege attributes to
instrument authorization regimes including NOFORN,
RELUK, etc, and PKIX faciliates their transport & carriage in 
the PKIX flexible, subjectDirectoryAttributes field. 

If PKIX id-certs transport such authorization info, they
can transport similar bio-info, in other subjectDirectoryAttributes
fields.

The privacy argument concerning bio info is mostly the same 
as authorization info. A 100 byte compressed picture of me
is no more sensitive than the level of my (non-existing) US 
security clearance.

Given the seeming synchronization of PKIX work and NSA work, I 
have no doubt that knowledge of this authorization case is
well known to all those who decide what goes into PKIX
draft standards.

If my argument does not hold, then authorization info
in PKIX-compliant certs should be restricted to a hash-reference,
so it is aligned with the bio-data rationale.

This would of course make a large swath of NSA certs
today PKIX non-complying. I doubt PKIX WG would make that
decision, somehow: so PKIX stds should allow the same logic as 
enabled 100 bytes of authorization information to now
also hold for embeddeding 100 bytes of bio-data.

-----Original Message-----
From: Stephen Kent
To: Anders Rundgren
Cc: 'SEIS-List'; PKIX-List; Tony Bartoletti
Sent: 12/7/99 5:47 AM
Subject: Re: Accessing/selecting biometrics was: Stray Poll: Finger-prints
in QCs

Anders,

>Tony,
>
>Slight comment on a thing of importance that you mention
>
><snip>
>
>  >Someone mentioned that the hash is sufficient, since the actual
>  >data could just "tag along" with the cert, if required. But there
>  >needs to be a standard even for this kind of operation. Is there?
>
>
>This was the original QC solution. As you noted (and I have told the
>authors several times) this is a half-made solution. A genuine example
>of poor engineering!

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.  For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications; we just 
define the certificate and CRL formats.  The same principle applies 
here. Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.

What aspect of this argument do you not understand?

Steve


Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05802 for <[e-mail]>; Tue, 7 Dec 1999 14:50:16 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA16403 for <[e-mail]>; Tue, 7 Dec 1999 14:53:20 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 07 Dec 1999 14:26:59 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id OAA03458 for <[e-mail]>; Tue, 7 Dec 1999 14:26:59 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 07 Dec 1999 14:26:58 -0800
Subject: Re: Consensus Text for key usage?
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Tim,

> Folks,
> 
> With Aram and Denis back in the fray, I think we can finish this one off.
> I have incorporated all the changes, and think we may be nearing consensus!
>  There are two pieces of proposed text; text for the key usage extension
> and text for the security considerations section.
>
> Please read it carefully.  In general, the changes were all introduced on
> the list in the "porposed" thread, but I have tweaked a couple of other
> paragraphs.  The only real suprise is that I capitulated and deleted the
> word "user" under dataEncipherment.  I thought keeping it would be less
> controversial, but that wasn't true!  I don't think it added anything, so
> let's delete it.
>
> Thanks,
>
> Tim Polk
>
[snip]
>        The digitalSignature bit is asserted when the subject public key
>        is used with a digital signature mechanism to support security
>        services other than non-repudiation (bit 1), certificate signing
>        (bit 5), or revocation information signing (bit 6). Digital signa-
>        ture mechanisms are often used for entity authentication and data
>        origin authentication with integrity.
>
>        The nonRepudiation bit is asserted when the subject public key is
>        used to verify digital signatures used to provide a non-repudiation
>        service.  This service protects against the certificate subject falsely
>        denying signing the data.  In the case of later conflict, a reliable
>        third party may determine the authenticity of the signed data.

Shouldn't this last sentence read something like "a reliable third party may
determine the non-repudiability (or repudiability) of the signed data" since
previous paragraph states the digitalSignature is used for "entity
authentication and data origen authentication"?

[snip]
>
>     This profile does not restrict the combinations of bits that may be
>     set in an instantiation of the keyUsage extension.  However,
>     valid combinations of bits are specified for particular algorithms
>     in section 7.3.

Like I mentioned in a private exchange, I would add something to the effect
of "Although there are no key restrictions, implementers should be aware
that certain combinations do not make sense (i.e. keyAgreement for RSA keys,
keyExchange for ECC keys) and some combinations may 'be insecure' (or
'lessen the security')."

[snip]

Regards,
Aram Perez


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05617 for <[e-mail]>; Tue, 7 Dec 1999 14:47:47 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FME7DB00.QP2 for <[e-mail]>; Tue, 7 Dec 1999 22:48:47 +0000 
Received: from nma.com ([209.21.28.97]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FME5F800.Q2J; Tue, 7 Dec 1999 22:06:44 +0000 
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 13:46:04 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus Text for key usage?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim Polk wrote:

>  There are two pieces of proposed text; text for the key usage extension
> and text for the security considerations section.
>
> 4.2.1.3  Key Usage
>

No comments.  The key usage text looks fine.

> --- proposed new paragraphs for Security Considerations section

Here, I have some comments.

>     A CA may include the key usage extension and assert the
>     nonRepudiation bit when issuing a certificate.

This part is fine.

> When such a
>     certificate is delivered, it implies that the owner of the
>     corresponding private key should be warned that, in the event of a
>     dispute, he may be held responsible of the data signed with this
>     key.

I am not in favor of this entire sentence.  It fixes a context for the
NR bit which *contradicts* the key usage section (for example: "A
signature policy identifier embedded in the signed data MAY be used to
explicitly provide context.") and it unduly imposes upon the owner
of the private key a duty which the signer herself (the CA, that elusive lady)
refrains from, for example: in the case of virus, fraud, etc,. These are valid
cases and if they would be reflected in the text, we would have a repeat of a
CA's CPS, I am afraid.

So, "when such a certificate is delivered, it implies that" is not a matter to
be solved here. Rather it MAY be solved in a signature policy identifier
embedded in the signed data, it MAY be solved in the CA's CPS, etc., all
as already predicated in PKIX.

Suggestion: delete the sentence.

>     If a certificate has both the digitalSignature and the
>     nonRepudiation bit set, the owner of the private key should make
>     sure that all the environments and applications where the
>     corresponding private key is being used do not allow a misuse of
>     that private key.

I am not in favor of this entire sequence.  It is not realistic that the
owner of the private key "should make sure that all the
environments and applications where the corresponding private key is
being used" is anything.  The most we can ask is a reasonable effort,
which may not be much in the case of virus, fraud, theft, etc.  To say
otherwise is to put on the certificate subject's a burden which not even
highly-qualified CAs want to shoulder.

Suggestion: A toned-down statement might be useful, such as:

    If a certificate has both the digitalSignature and the
    nonRepudiation bit set, the private key owner should take
    justified measures to prevent a misuse of that private key.

Of course, "justified measures" are commensurate to cost and risk,
which means that the above statement is even more effective than
the original to define what the keyholder's responsibilities are (for
example, a private key used to sign money transfer justifies a
need for more precautions than a private key used to sign email messages
in a mailing list) -- and avoids the trap of requiring the whole world
to be secure. An untainable goal, which could easily make the original
clause moot by excessive requirements (not even CAs can do this).

Note: I have, on purpose, avoided the terms "reasonable measures"
because reasonableness may be difficult to define in the technical
sense, while a justification can be a letter from the ISP on which
one relies upon without (usually) further checking.

>  If that confidence can only be obtained in some
>     environments, two different certificates, one with one public
>     key and the digitalSignature bit set and another one with a
>     different public key and the nonRepudiation bit set, should be used,
>     so that the private key corresponding to the certificate with the
>     nonRepudiation bit set is only used in secure environments.

I am not in favor of this addition, which seems obvious (do not set the
NR bit unless you want to set the NR bit), costly (two certificates) and
unnecessary -- since I can use only one certificate with the NR bit set
and deny NR directly in the signed data, case by case (NR opt out mode).
Or, I can use only one certificate with the NR bit off and grant NR directly
in the signed data, case by case (NR opt in mode).

If one thinks though that saying something is necessary, I suggest, in
agreement with the change proposed above:

 If the private key owner can only prevent misuse in some environments, 
 then it is possible to use a certificate with the nonRepudiation bit 
 set and deny non-repudiation in the signed data, case by case (NR opt
 out mode); or use a certificate with the nonRepudiation bit off and
 grant non-repudiation in the signed data, case by case (NR opt in
 mode); or use two different certificates, one with one public key and
 the digitalSignature bit set and another one with a different public
 key and the nonRepudiation bit set; or use another method that could
 be justified, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is not used in environments that may 
 either not conform to a non-repudiation signature policy, or be unknown.


Cheers,

Ed Gerck



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA04396 for <[e-mail]>; Tue, 7 Dec 1999 13:48:44 -0800 (PST)
Received: from mega (t2o69p18.telia.com [62.20.144.138]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA33001; Tue, 7 Dec 1999 22:54:16 +0100
Message-ID: <007501bf4105$21c34330$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Ilan Shacham" <[e-mail]>, "Tony Bartoletti" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: QC biometrics needs re-engineering NOW!
Date: Tue, 7 Dec 1999 22:48:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA04398

Stephen,

>I suggested that it was silly to present a digest
>without being able to point at something that allows you 
>to verify the digest

It sure is silly!  Interoperability=ZERO

>as you should be able to see from 
>the archive (but its so long ago I forget, maybe it was
>a private posting). I think Steve K. addressed the issue
>when he said that handing over a URL says nothing about
>who can gets a 404 vs. a 200 when they ask for the content.

That is REALLY silly!  The RP is authenticating to the CA-server.......
I.e. all RPs must be "known" in advance by the CA?  Should I laugh  :-) :-) :-) . Or should I cry? :-( :-(

Compare that to the simple, interoperable, universal trick invented by Netscape(?)
some 3-4 years ago called user certificate selection.  Like getting a list like:

    - Standard QC
    - Photo ID
    - e-mail cert
    - SSN cert

Anders



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02273 for <[e-mail]>; Tue, 7 Dec 1999 12:35:24 -0800 (PST)
Received: by balinese.baltimore.ie; id UAA20663; Tue, 7 Dec 1999 20:38:28 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020655; Tue, 7 Dec 99 20:38:25 GMT
Received: from baltimore.ie ([192.168.20.113]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA27338; Tue, 7 Dec 1999 20:38:22 GMT
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 20:44:22 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: Back to nothing: URI solution works?
References: <005201bf40fa$1c256e40$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(I thought the "back to nothing" thread was about keyUsage,
not biometrics, but since I've been dumb enough to stick
my head up...)

I suggested that it was silly to present a digest
without being able to point at something that allows you 
to verify the digest, as you should be able to see from 
the archive (but its so long ago I forget, maybe it was
a private posting). I think Steve K. addressed the issue
when he said that handing over a URL says nothing about
who can gets a 404 vs. a 200 when they ask for the content.

Stephen.

Anders Rundgren wrote:
> 
> Hi Stephen,
> 
> As it was you who suggested the URI+hash solution for biometrics, you could maybe
> elaborate on how this solution is information-wise (not certificate-size-wise) different from
> in-line biometric data.
> 
> Anders

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA02014 for <[e-mail]>; Tue, 7 Dec 1999 12:29:38 -0800 (PST)
Received: from mega (t4o69p29.telia.com [62.20.145.149]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA55597; Tue, 7 Dec 1999 21:35:23 +0100
Message-ID: <005201bf40fa$1c256e40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Back to nothing: URI solution works?
Date: Tue, 7 Dec 1999 21:29:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02015

Hi Stephen,

As it was you who suggested the URI+hash solution for biometrics, you could maybe
elaborate on how this solution is information-wise (not certificate-size-wise) different from
in-line biometric data.

Anders





Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01710 for <[e-mail]>; Tue, 7 Dec 1999 12:23:59 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id PAA19797; Tue, 7 Dec 1999 15:26:19 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Tue, 07 Dec 1999 15:30:50 -0500
To: "Aram Perez" <[e-mail]>, Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Consensus Text for key usage?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Folks,

With Aram and Denis back in the fray, I think we can finish this one off.
I have incorporated all the changes, and think we may be nearing consensus!
 There are two pieces of proposed text; text for the key usage extension
and text for the security considerations section.

Please read it carefully.  In general, the changes were all introduced on
the list in the "porposed" thread, but I have tweaked a couple of other
paragraphs.  The only real suprise is that I capitulated and deleted the
word "user" under dataEncipherment.  I thought keeping it would be less
controversial, but that wasn't true!  I don't think it added anything, so
let's delete it.

Thanks,

Tim Polk


 parties.---- Proposed text for 4.2.1.3 Key Usage


4.2.1.3  Key Usage

    The key usage extension defines the purpose (e.g., encipherment, sig-
    nature, certificate signing) of the key contained in the certificate.
    The usage restriction might be employed when a key that could be used
    for more than one operation is to be restricted.  For example, when
    an RSA key should be used only for signing, the digitalSignature
    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
    key should be used only for key management, the keyEncipherment bit
    would be asserted. When used, this extension SHOULD be marked criti-
    cal.

       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

       KeyUsage ::= BIT STRING {
            digitalSignature        (0),
            nonRepudiation          (1),
            keyEncipherment         (2),
            dataEncipherment        (3),
            keyAgreement            (4),
            keyCertSign             (5),
            cRLSign                 (6),
            encipherOnly            (7),
            decipherOnly            (8) }


    Bits in the KeyUsage type are used as follows:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or revocation information signing (bit 6). Digital signa-
       ture mechanisms are often used for entity authentication and data
       origin authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-repudiation
       service.  This service protects against the certificate subject falsely
       denying signing the data.  In the case of later conflict, a reliable
       third party may determine the authenticity of the signed data.

       The values of the digitalSignature and nonRepudiation bits are not
       considered when validating the signature on certificates or certificate
       status information.  Further distinctions between the digitalSignature
       and nonRepudiation bits may be provided in specific certificate
       policies.  The values of the digitalSignature and nonRepudiation bits
       is insufficient to determine the intentions of the certificate subject.
       The context in which the data was signed MUST also be considered.  A
       signature policy identifier embedded in the signed data MAY be used to
       explicitly provide context.

       The keyEncipherment bit is asserted when the subject public key is
       used for key transport.  For example, when an RSA key is to be
       used for key management, then this bit shall be asserted.

       The dataEncipherment bit is asserted when the subject public key
       is used for enciphering data other than cryptographic keys.

       The keyAgreement bit is asserted when the subject public key is
       used for key agreement.  For example, when a Diffie-Hellman key is
       to be used for key management, then this bit shall be asserted.

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on certificates.  This bit may only
       be asserted in CA certificates.  If the keyCertSign bit is
       asserted, then the cA bit in the basic constraints extension (see
       4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
       asserted, then the cA bit in the basic constraints extension MUST
       NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on revocation information (e.g., a CRL).
       Note: Unlike the keyCertSign bit, there is no relationship
       between the value of cRLSign and the basic constraints extension.

       The meaning of the encipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the encipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for enciphering data while performing key agreement.

       The meaning of the decipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the decipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for deciphering data while performing key agreement.

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    valid combinations of bits are specified for particular algorithms
    in section 7.3.



--- proposed new paragraphs for Security Considerations section

    A CA may include the key usage extension and assert the
    nonRepudiation bit when issuing a certificate. When such a
    certificate is delivered, it implies that the owner of the
    corresponding private key should be warned that, in the event of a
    dispute, he may be held responsible of the data signed with this
    key.
    
    If a certificate has both the digitalSignature and the
    nonRepudiation bit set, the owner of the private key should make
    sure that all the environments and applications where the
    corresponding private key is being used do not allow a misuse of
    that private key. If that confidence can only be obtained in some
    environments, two different certificates, one with one public
    key and the digitalSignature bit set and another one with a
    different public key and the nonRepudiation bit set, should be used,
    so that the private key corresponding to the certificate with the
    nonRepudiation bit set is only used in secure environments.




Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01372 for <[e-mail]>; Tue, 7 Dec 1999 12:12:22 -0800 (PST)
Received: by balinese.baltimore.ie; id UAA20167; Tue, 7 Dec 1999 20:15:25 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma020157; Tue, 7 Dec 99 20:15:01 GMT
Received: from baltimore.ie ([192.168.20.113]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA25935 for <[e-mail]>; Tue, 7 Dec 1999 20:14:56 GMT
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 20:20:54 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: back to nothing, was Re: proposed key usaged text -- the final round
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

...some 100s of messages later...

> If you want to deprecate the NR bit, please say so.

YES!!! More and more everytime I see this discussion.

Actually, I did have the idea that we mandate that CAs
MUST set this bit randomly whenever a keyUsage extension
is present, just to stop people who argue that its absence 
has a meaning.

Stpehen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00823 for <[e-mail]>; Tue, 7 Dec 1999 11:45:11 -0800 (PST)
Received: from dfw-mmp4.email.verio.net ([129.250.38.64]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMDYZ000.VDZ for <[e-mail]>; Tue, 7 Dec 1999 19:47:24 +0000 
Received: from nma.com ([209.21.28.104]) by dfw-mmp4.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMDWCA00.CDW; Tue, 7 Dec 1999 18:50:34 +0000 
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 10:50:26 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail]
Subject: back to nothing, was Re: proposed key usaged text -- the final round
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> I would like first to summarize where we are. Keeping the first
> sentence unchanged and adding the text you proposed to solve both my
> issue and John Linn issue we come to the following normative text:
>
> The nonRepudiation bit is asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service. The values of the digitalSignature and nonRepudiation bits
> are not considered when validating the signature on certificates or
> certificate status information (see keyCertSign and cRLSigning,
> below, for values that are considered when validating such
> signatures.)

Should I understand this suggestion as a substituion for the first
sentence or for the entire paragraph?  Either way, the suggestion
seems to cut the part where the *meaning* of the NR bit is
given.  The original text was:

 The nonRepudiation bit is asserted when the subject public key is
 used to verify digital signatures used to provide a non-repudiation
 service.  This service protects against the certificate subject
 falsely denying signing the data, excluding certificate or CRL
 signing. In the case of later conflict, a reliable third party may
 determine the authenticity of the signed data.

So, I fail to see how the suggested text is better. In fact, I think it
turns back the clock some six months and we are again back
to nothing.

If you want to deprecate the NR bit, please say so.

> Thenafter I agree that warnings should be moved in the security
> consideration section. So the only remaining point should be to
> agree on that text. You proposal was missing the case of the two
> bits set. Here is a new attempt:
>
> "A CA may include the key usage extension and assert the
> nonRepudiation bit when issuing a certificate. When such a
> certificate is delivered, it implies that the owner of the
> corresponding private key should be warned that, in the event of a
> dispute, he may be held responsible of the data signed with this
> key.

"The owner of the private key should be warned" -- we are again back
some six months ago.  Non-repudiation cannot be imposed,
it has to be voluntary.  Why should the CA tell me that I may be
held responsible when the CA themselves says that they are never
responsible, provide no warranty, no assurances, yada yada?

> If a certificate has both the digitalSignature and the
> nonRepudiation bit set, the owner of the private key should make
> sure that all the environments and applications where the
> corresponding private key is being used do not allow a misuse of
> that private key.

*All the enviroments and the applications" -- can we be more less
assuming?  If even the CA refuses to accept responsibility for their
environment, I presume that the above text is fictional to the extreme
and unfair.  Besides, it is outdated by six months.

Again, the lack of a real-world model is apparent in the previous
work and percolates here.

> If that condidence can only be obtained in some
> environments, two different certificates, one with one public public
> key and the digitalSignature bit set and another one with a
> different public key and the nonRepudiation bit set, should be used,
> so that the private key corresponding to the certificate with the
> nonRepudiation bit set is only used in secure environments."

Dennis:

I see that we are back to nothing if we follow your suggestions.

Again, if you want to deprecate the NR bit, please say so.  This is
what the market, if not this list, will do if your suggestion is accepted
*over all the discussions here*.  Those issues that you want to
"introduce" now at the final round were already discussed and
rejected. Why discuss them to death over and over and over?

Cheers,

Ed Gerck




Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29708 for <[e-mail]>; Tue, 7 Dec 1999 10:36:26 -0800 (PST)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id KAA28075 for <[e-mail]>; Tue, 7 Dec 1999 10:39:28 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 07 Dec 1999 10:39:20 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id KAA17247; Tue, 7 Dec 1999 10:39:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Tue, 07 Dec 1999 10:38:54 -0800
Subject: Re: proposed key usaged text -- the final round
From: "Aram Perez" <[e-mail]>
To: Denis Pinkas <[e-mail]>, Tim Polk <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:

> Tim,
> 
> I did not realized that the ball was rolling in my camp and thus I
> needed to send you a response.
> I would like first to summarize where we are. Keeping the first
> sentence unchanged and adding the text you proposed to solve both my
> issue and John Linn issue we come to the following normative text:
>
> The nonRepudiation bit is asserted when the subject public key is
> used to verify digital signatures used to provide a non-repudiation
> service. The values of the digitalSignature and nonRepudiation bits
> are not considered when validating the signature on certificates or
> certificate status information (see keyCertSign and cRLSigning,
> below, for values that are considered when validating such
> signatures.)
>
> Thenafter I agree that warnings should be moved in the security
> consideration section. So the only remaining point should be to
> agree on that text. You proposal was missing the case of the two
> bits set. Here is a new attempt:
>
> "A CA may include the key usage extension and assert the
> nonRepudiation bit when issuing a certificate. When such a
> certificate is delivered, it implies that the owner of the
> corresponding private key should be warned that, in the event of a
> dispute, he may be held responsible of the data signed with this
> key.
>
> If a certificate has both the digitalSignature and the
> nonRepudiation bit set, the owner of the private key should make
> sure that all the environments and applications where the
> corresponding private key is being used do not allow a misuse of
> that private key. If that condidence can only be obtained in some
> environments, two different certificates, one with one public public
> key and the digitalSignature bit set and another one with a
> different public key and the nonRepudiation bit set, should be used,
> so that the private key corresponding to the certificate with the
> nonRepudiation bit set is only used in secure environments."
>
> Regards,
>
> Denis

I like Denis' suggestions and I agree that "warnings should be moved in the
security consideration section".

Regards,
Aram Perez

[snip]


Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28512 for <[e-mail]>; Tue, 7 Dec 1999 09:45:27 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id SAA20132; Tue, 7 Dec 1999 18:48:04 +0100
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 18:47:55 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: proposed key usaged text -- the final round
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tim,

I did not realized that the ball was rolling in my camp and thus I
needed to send you a response.
I would like first to summarize where we are. Keeping the first
sentence unchanged and adding the text you proposed to solve both my
issue and John Linn issue we come to the following normative text:

The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-repudiation
service. The values of the digitalSignature and nonRepudiation bits
are not considered when validating the signature on certificates or
certificate status information (see keyCertSign and cRLSigning,
below, for values that are considered when validating such
signatures.)

Thenafter I agree that warnings should be moved in the security
consideration section. So the only remaining point should be to
agree on that text. You proposal was missing the case of the two
bits set. Here is a new attempt:

"A CA may include the key usage extension and assert the
nonRepudiation bit when issuing a certificate. When such a
certificate is delivered, it implies that the owner of the
corresponding private key should be warned that, in the event of a
dispute, he may be held responsible of the data signed with this
key. 

If a certificate has both the digitalSignature and the
nonRepudiation bit set, the owner of the private key should make
sure that all the environments and applications where the
corresponding private key is being used do not allow a misuse of
that private key. If that condidence can only be obtained in some
environments, two different certificates, one with one public public
key and the digitalSignature bit set and another one with a
different public key and the nonRepudiation bit set, should be used,
so that the private key corresponding to the certificate with the
nonRepudiation bit set is only used in secure environments."

Regards,

Denis

=======================================
 
> Denis,
> 
> At 11:52 AM 11/25/1999 +0100, Denis Pinkas wrote:
> >Tim and Russ,
> >
> >> To people who still care about NR:
> >
> >I care.
> >
> 
> We thought you might. :-)
> 
> I've cut and pasted a bit to asssist those reading along at home... I trust I haven't altered your intent.
> 
> Our proposed text:
> > The nonRepudiation bit is asserted when the subject public key is
> > used to verify digital signatures used to provide a non-repudiation
> > service. This service protects against the certificate subject
> > falsely denying signing the data, excluding certificate or CRL
> > signing. In the case of later conflict, a reliable third party may
> > determine the authenticity of the signed data.
> 
> Your proposed text:
> 
> >" The nonRepudiation bit is asserted when the subject public key is
> >used to verify digital signatures used to provide a non-repudiation
> >service. When present, the nonRepudiation bit indicates that the
> >private key corresponding to the subject public key present in that
> >certificate may be used to indicate the user's conscious and willing
> >intent to endorse what is being signed."
> >
> 
> I prefer our text, since it sticks to the definition of the service. The certificate subject can use their private key for anything they'd like. The question for the key usage extension is, "Should I use this public key to implement this service?". I believe our text describes the general case, yours an important specific case.
> 
> Russ and I worked very hard to remove the word "intent" in our latest proposal. Intent can only be indicated through context, such as the signing policy that ETSI has proposed. This specification cannot do a thing to ensure that any particular signature was generated conciously and willingly.
> 
> Since our text includes your case, and ETSI is already working on the mechanisms to describe the signing context, I think our text is a good middle ground.
> 
> You also wrote:
> >I would also propose to add a note that explains the case of a
> >certificate having both the DS and the NR bits set and to place this
> >addition at the end of the whole section 4.2.1.3:
> >
> >" Note: A certificate with the nonRepudiation bit set should only be
> >used when it is possible to get full confidence of the environments
> >where the private key will be used. If a certificate has both the
> >digitalSignature and the nonRepudiation bit set, the entity owning
> >the private key should have full confidence of all the various
> >environments and applications where the private key will being used.
> >For the cases where that condidence cannot be obtained, two
> >different certificates, one with one public public key and the
> >digitalSignature bit set and another one with a different public key
> >and the nonRepudiation bit set, should be used."
> >
> >
> 
> I substituted "issued" for "used" in this paragraph. I'm assuming you are talking about how a CA determines *which* bits should be asserted. Is that right? On that assumption, I think it is a policy issue or a security consideration. [Side note: What do you mean by "full confidence"?] The next paragraph points to the policy for additional information.
> 
> The other possibility would be the security considerations section. It could build on the current text, which includes the folowing:
> 
> The protection afforded private keys is a critical factor in main-
> taining security. On a small scale, failure of users to protect
> their private keys will permit an attacker to masquerade as them, or
> decrypt their personal information. [stuff about CA keys deleted]
> 
> Adding the following paragraph might address your concern:
> 
> A CA may include the key usage extension and assert the nonRepudiation bit
> when issuing a certificate. This implies that a reliable third party will
> be able to determine the authenticity of signed data in the event of a dispute.
> If the certificate subject uses the private key in an insecure environment,
> it may be difficult to detect or prevent key compromise. This could prevent a
> reliable third party from determining the authenticity of signed data. A CA
> should consider the environment of the private key before asserting the
> nonRepudiation bit.
> 
> I know this text is very rough, but would this serve your purpose?
> 
> Thanks,
> 
> Tim


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA26207 for <[e-mail]>; Tue, 7 Dec 1999 07:28:35 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA62362; Tue, 7 Dec 1999 16:34:13 +0100
Received: by HYDRA with Microsoft Mail id <01BF40CF.A1904DA0@HYDRA>; Tue, 7 Dec 1999 16:25:10 +0100
Message-ID: <01BF40CF.A1904DA0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, PKIX-List <[e-mail]>, Tony Bartoletti <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: RE: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs
Date: Tue, 7 Dec 1999 16:25:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Well Steve,
This was the question.  And it was not only raised by me:

>  >Someone mentioned that the hash is sufficient, since the actual
>  >data could just "tag along" with the cert, if required. But there
>  >needs to be a standard even for this kind of operation. Is there?
>
>
>This was the original QC solution. As you noted (and I have told the
>authors several times) this is a half-made solution. A genuine example
>of poor engineering!

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.

I would say that this sloppy definition requires that the maker of the smart-card and
the authenticating application are identical.  Interoperability=ZERO.


 For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications;

Odd examples.  AFAIK SSL/TLS specify exactly how and when client and
server certificates are transmitted between client and server.


Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.


As noted by others, the URI+hash thing does not do the privacy job the way you describe it and then
the whole foundation is flawed.  I.e. we are back to "file-size" discussions which are pretty trivial.

User certificate selection is (so far) the only documented, interoperable, general-purpose solution to privacy
problems of the kind introduced by certificates containing "sensitive" information like SSNs, biometrics etc.

Anders




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25055 for <[e-mail]>; Tue, 7 Dec 1999 06:22:14 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA29058; Tue, 7 Dec 1999 15:24:49 +0100
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 1999 15:24:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: Re: Repeated: QC biometric selection/protocol
References: <01BF40B8.F863BF70@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

> Stefan,
> 
> I look forward to consensus but without any comments on this
> 
> http://www.imc.org/ietf-pkix/mail-archive/msg03203.html
> 
> which is directed to the QC-designers rather than the list, it is very hard
> to have an opinion about the current concept for handling biometrics.
> 
> I think it was Denis Pinkas who originally suggested the hash-bio and Stephen Farrel
> who added the URI part.  Maybe they care to elaborate on this?

Your historic is correct. However, I said yesterday: "We should not
re-open that discussion". Thus, I do not want to elaborate more on
this at this time.

Regards,

Denis

> Note that several others in this list seem to agree with me that the hash+URI is
> equally privacy-depriving as the bio-in-cert solution.  So is the big question really
> only a matter of "file-size"?
> 
> Anders


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24403 for <[e-mail]>; Tue, 7 Dec 1999 05:53:27 -0800 (PST)
Received: from [128.33.238.59] (TC059.BBN.COM [128.33.238.59]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id IAA28082; Tue, 7 Dec 1999 08:55:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b472bf2de48d@[128.33.238.12]>
In-Reply-To: <001001bf407c$81fda7b0$[e-mail]>
References: <001001bf407c$81fda7b0$[e-mail]>
Date: Tue, 7 Dec 1999 08:47:18 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Cc: "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Tony,
>
>Slight comment on a thing of importance that you mention
>
><snip>
>
>  >Someone mentioned that the hash is sufficient, since the actual
>  >data could just "tag along" with the cert, if required. But there
>  >needs to be a standard even for this kind of operation. Is there?
>
>
>This was the original QC solution. As you noted (and I have told the
>authors several times) this is a half-made solution. A genuine example
>of poor engineering!

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.  For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications; we just 
define the certificate and CRL formats.  The same principle applies 
here. Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.

What aspect of this argument do you not understand?

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24297 for <[e-mail]>; Tue, 7 Dec 1999 05:53:12 -0800 (PST)
Received: from [128.33.238.59] (TC059.BBN.COM [128.33.238.59]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id IAA28130; Tue, 7 Dec 1999 08:56:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b472c1365f75@[128.33.238.12]>
In-Reply-To: <01BF408F.23151B30@HYDRA>
References: <01BF408F.23151B30@HYDRA>
Date: Tue, 7 Dec 1999 08:56:26 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC's - for human eyes only?
Cc: "[e-mail]" 	 <[e-mail]>, "'SEIS-List'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Ilan,
>
>  >It seems to me that most postings here with privacy concerns are
>  >actually against the whole concept of the QC and the linking of
>  >biometric data to individuals. Once QC's have been agreed upon it
>  >looks like both options - hash+URI and Biometrics on the QC, are
>  >conceptualy identical.
>
>Your observation is unfortunately completely correct!
>
>This IMO where you get by starting with ASN.1 instead of an old-fashioned
>"requirement specification".   A the requirement specification should be on
>a level that can be (more or less) interpreted by parties that may not have a
>degree in cryptography.  Why?  Unlike TLS and OCSP, QC is very close to
>an "application" and when applications are designed, "users" should be
>able to participate.  But that's too late now.   And many valuable months have
>simply passed without any progress and soon the last call is over and things
>are still in a partial shape.

QC is not an application. It is a certificate profile. Multiple ways 
of making use of QCs are possible, and that is one of the reasons why 
we have deferred the question of how to present the biometric 
template that is bound to a certificate.

Steve

P.S.  OCSP is a PKI management application protocol, and TLS is an 
application  layer protocol, so your comparison above is as flawed as 
the rest of your arguments.



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24265 for <[e-mail]>; Tue, 7 Dec 1999 05:53:06 -0800 (PST)
Received: from [128.33.238.59] (TC059.BBN.COM [128.33.238.59]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id IAA28097; Tue, 7 Dec 1999 08:55:49 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b472c08435aa@[128.33.238.12]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 7 Dec 1999 08:50:25 -0500
To: Ilan Shacham <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC's - for human eyes only?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ilan,

If one were to provide no protection for the URI-based access, I 
agree that the argument of added confidentiality would be 
questionable.  That's why the proposal I put forth some time ago left 
open the issue of how and under what circumstances the biometric 
template data would be provided.

Steve


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA22649 for <[e-mail]>; Tue, 7 Dec 1999 04:46:14 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA12684; Tue, 7 Dec 1999 13:52:01 +0100
Received: by HYDRA with Microsoft Mail id <01BF40B8.F863BF70@HYDRA>; Tue, 7 Dec 1999 13:42:57 +0100
Message-ID: <01BF40B8.F863BF70@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: Repeated: QC biometric selection/protocol
Date: Tue, 7 Dec 1999 13:42:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

I look forward to consensus but without any comments on this

http://www.imc.org/ietf-pkix/mail-archive/msg03203.html

which is directed to the QC-designers rather than the list, it is very hard
to have an opinion about the current concept for handling biometrics.

I think it was Denis Pinkas who originally suggested the hash-bio and Stephen Farrel
who added the URI part.  Maybe they care to elaborate on this?

Note that several others in this list seem to agree with me that the hash+URI is
equally privacy-depriving as the bio-in-cert solution.  So is the big question really
only a matter of "file-size"?

Anders



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA22066 for <[e-mail]>; Tue, 7 Dec 1999 04:10:37 -0800 (PST)
Received: (qmail 32892 invoked from network); 7 Dec 1999 12:13:30 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Dec 1999 12:13:30 -0000
Received: (qmail 15447 invoked from network); 7 Dec 1999 12:13:29 -0000
Received: from mnystrom-lap.nordic-dhcp.dynas.se (10.129.12.111) by spirit.dynas.se with SMTP; 7 Dec 1999 12:13:29 -0000
Date: Tue, 7 Dec 1999 13:12:55 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
To: Tom Biskupic <[e-mail]>
cc: [e-mail]
Subject: Re: The definition of OTHER-NAME
In-Reply-To: <000001bf40aa$f45e9340$[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Tom,

Note that the 'otherName' choice in the definition of 'GeneralName' in
X.509:1997 is:

otherName INSTANCE OF OTHER-NAME,

and 'INSTANCE OF' is defined in Annex C of X.681 as precisely the
'OtherName' type defined in RFC 2459.

Hope this helps,
-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories

On Tue, 7 Dec 1999, Tom Biskupic wrote:

> Hello,
> 
> I'm sure this must have been discussed previously, but not having found an
> answer in the first 12Mb archive of this mailing list I thought I'd float it
> anyhow.
> 
> There seems to be a discrepancy in the definition of Othername in RFC2459
> and X509V3
> 
> The definition of OtherName in RFC2459 is as follows :-
> 
>      OtherName ::= SEQUENCE {
>            type-id    OBJECT IDENTIFIER,
>            value      [0] EXPLICIT ANY DEFINED BY type-id }
> 
> where as X509.V3 defines it as
> 
> OTHER-NAME ::= TYPE-IDENTIFIER
> 
> Which does not have the [0] tag on the value (see X.681 Annex A)
> 
> The draft-ietf-pkix-new-part1-00.txt even says
> 	-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
> 	-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
> 
> But then goes on to define AnotherName to include the [0] tag.
> 
> Why is the [0] tag there? I don't see any ambiguity in the encoding that
> would require a context specific tag.



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21789 for <[e-mail]>; Tue, 7 Dec 1999 03:59:21 -0800 (PST)
Received: by balinese.baltimore.ie; id MAA00128; Tue, 7 Dec 1999 12:02:22 GMT
Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma000112; Tue, 7 Dec 99 12:01:48 GMT
Received: from crown (crown.baltimore.ie [192.168.21.124]) by bobcat.baltimore.ie (8.9.3/8.9.3) with SMTP id MAA22364 for <[e-mail]>; Tue, 7 Dec 1999 12:01:47 GMT
From: "Tom Biskupic" <[e-mail]>
To: <[e-mail]>
Subject: The definition of OTHER-NAME
Date: Tue, 7 Dec 1999 12:02:36 -0000
Message-ID: <000001bf40aa$f45e9340$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal

Hello,

I'm sure this must have been discussed previously, but not having found an
answer in the first 12Mb archive of this mailing list I thought I'd float it
anyhow.

There seems to be a discrepancy in the definition of Othername in RFC2459
and X509V3

The definition of OtherName in RFC2459 is as follows :-

     OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

where as X509.V3 defines it as

OTHER-NAME ::= TYPE-IDENTIFIER

Which does not have the [0] tag on the value (see X.681 Annex A)

The draft-ietf-pkix-new-part1-00.txt even says
	-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
	-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

But then goes on to define AnotherName to include the [0] tag.

Why is the [0] tag there? I don't see any ambiguity in the encoding that
would require a context specific tag.

Thanks,

Tom Biskupic,
Software Engineer
----------------------------------------------------------------------------
--------------
Baltimore Technologies
Tel. [phone]   Fax. [phone]
Baltimore - Global e-Security
----------------------------------------------------------------------------
--------------




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18461 for <[e-mail]>; Tue, 7 Dec 1999 02:21:22 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA05890 for <[e-mail]>; Tue, 7 Dec 1999 12:39:54 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 07 Dec 1999 11:24:51 +0100
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC's - for human eyes only?
In-Reply-To: <003d01bf4026$fc7600b0$5b116a0a@cylink>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA18462

This is fairly much a repetition of the previous discussion about biometrics.

I would avoid discussions regarding the privacy issues, but would like to
say that any system that relies on the secrecy of biometrics are likely to
fail. The unique identification capability of biometrics does not come from
keeping it secret, but rather your unique capability to represent these
bio-metric values with your physical body. The wrong body can't represent
these values regardless of wether they are secret or not.

The second general issue is about the value of bio-metrics in long distance
communication. This is where human verification comes in. Schemes aimed for
human verification works well on distance (i.e. my certified photo may help
convince you who I am, because you may have seen me before and recognize
me), while schemes for machine verification doesn't (i.e. finger print
verification must be performed with physical control over the bio-measure
device, and this device must be where you are). 

Anyway. I still think that the current solution is good.... On the other
hand it would be very easy so expand the scheme. Personally I'm not sure
what the best solution is.

The only thing I'm really sure about, is that I believe that the predefined
bio-metric types shall remain as they are (photo and written signature
image) aimed for human verification.

The current scheme allows definition of other bio-metric types with an OID
and I would personally not object if such OID may be allowed to define a
finger print scheme.

I would hope to avoid the actual bio-data in certificates, but I don't have
a strong opinion here. So please continue top argue and find a consensus here.

/Stefan






-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA13568 for <[e-mail]>; Mon, 6 Dec 1999 23:46:51 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA62390; Tue, 7 Dec 1999 08:44:35 +0100
Received: by HYDRA with Microsoft Mail id <01BF408F.23151B30@HYDRA>; Tue, 7 Dec 1999 08:43:30 +0100
Message-ID: <01BF408F.23151B30@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Ilan Shacham'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: QC's - for human eyes only?
Date: Tue, 7 Dec 1999 08:43:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ilan,

>It seems to me that most postings here with privacy concerns are
>actually against the whole concept of the QC and the linking of
>biometric data to individuals. Once QC's have been agreed upon it
>looks like both options - hash+URI and Biometrics on the QC, are
>conceptualy identical.

Your observation is unfortunately completely correct!

This IMO where you get by starting with ASN.1 instead of an old-fashioned 
"requirement specification".   A the requirement specification should be on
a level that can be (more or less) interpreted by parties that may not have a
degree in cryptography.  Why?  Unlike TLS and OCSP, QC is very close to
an "application" and when applications are designed, "users" should be
able to participate.  But that's too late now.   And many valuable months have
simply passed without any progress and soon the last call is over and things
are still in a partial shape.

Anders Rundgren
Senior Internet e-commerce Architect
 



Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12175 for <[e-mail]>; Mon, 6 Dec 1999 23:09:15 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <YJWJFWG9>; Tue, 7 Dec 1999 09:09:35 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: QC's - for human eyes only?
Date: Tue, 7 Dec 1999 09:09:33 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

It looks like there is a consensus on the fact that Biometric data
is no good for remote authentication, therefore there would be no need
for putting QC's in directories. Instead, the QC owner would hold it in
a smartcard, or something similiar.

Consider the following Scenerio:
Alice runs some service which requires authentication through biometrics.
Bob comes to Alice and presents his smartcard with his QC on it. Alice
takes Biometric measurements of Bob and checks his QC to authenticate
him. Now there are two possibilities:
1. The QC includes a hash and URI of the biometrics - Alice securely
accesses the URI and retrieves Bob's biometrics.
2. The QC includes Bobs biometrics - Alice gets the biometrics from the
QC.
In both cases Alice, and only Alice, is given Bob's biometrics. If Bob
trusts Alice to keep this data secret then there is no problem. If he
doesn't trust her then he shouldn't have given her the smartcard in the
first case.

Currently there are no definitions of the secure access of the URI, so
this might be an opening for malicious people to fraudulantly retrieve
the biometrics from the URI. Therefore, as I see it, the URI option is
the one where privacy is more breachable.

It seems to me that most postings here with privacy concerns are
actually against the whole concept of the QC and the linking of
biometric data to individuals. Once QC's have been agreed upon it
looks like both options - hash+URI and Biometrics on the QC, are
conceptualy identical.

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, December 07, 1999 12:55 AM
> To: [e-mail]
> Subject: Re: QC's - for human eyes only?
> 
> 
> 
> 
> Consider the distinction between *identification* and 
> *authentication*.
> Something makes a good identifier if it points uniquely to 
> what it identifies.
> Something makes a good authenticator if it is hard for the 
> wrong entity to
> generate it.   If a "secret" authenticator is shared between 
> too many parties
> (e.g., SSN, mother's maiden name) it no longer makes a very 
> good authenticator.
> 
> What is the nature of a biometric?  A problem for biometrics 
> is that if multiple
> systems know and authenticate me by a my fingerprint data, is 
> that data still a
> good authenticator?  If the comparison is static, the answer 
> would be "no" for
> the same reason as SSNs, etc. are poor.  But if they also use 
> an effective
> "liveness" test against static reference data, then the 
> reference fingerprint
> data really serves as an identifier and the "liveness" test 
> mechanism really
> serves as the authenticator.  In that case what's the problem 
> with including my
> fingerprint data in a certificate?
> 
> I think the real worry about including a biometric in a 
> certificate is the
> potential for privacy invasion, because the biometric in 
> effect becomes an
> unchangeable universal identifier - exactly the same concern 
> now about SSNs
> being attached to all your records, permitting easy dossier 
> compilation.
> 
> A static hash doesn't solve the privacy problem because that 
> hash itself just
> serves as the universal identifier.
> 
> IMO, the best thing to do with a biometric in connection with 
> PKI is to put it
> into a hardware token that protects one's private key 
> corresponding to the
> public key in a certificate.  Then it serves as a private 
> user-to-key-device
> authenticator which is not shared outside that environment.  
> No reference to the
> biometric content is needed in the certificate for this use.  
> This use of
> biometrics is (1)highly secure (assuming a trusted channel 
> between biometrics
> reader and key device) and (2) not a threat to privacy.
> 
> -Gene Hilborn
> 
> 
> 
> 
> [e-mail] on 12/06/99 03:17:57 PM
> 
> To:   [e-mail]
> cc:    (bcc: Gene Hilborn/DEF/CSC)
> Subject:  Re: QC's - for human eyes only?
> 
> 
> 
> If putting biometric data in a certificate is "bad," what 
> about putting a
> hash of it?
> 
> Or should this type of information be more appropriately stored in a
> directory?
> ----- Original Message -----
> From: Tony Bartoletti <[e-mail]>
> To: Eric Murray <[e-mail]>; Ilan Shacham <[e-mail]>
> Cc: Ietf-Pkix (E-mail) <[e-mail]>
> Sent: Monday, December 06, 1999 11:05 AM
> Subject: Re: QC's - for human eyes only?
> 
> 
> > At 09:00 AM 12/05/1999 -0800, Eric Murray wrote:
> >
> > >However putting a biometric in a certificate is like 
> putting your Social
> > >Security Number and mother's maiden name in a certificate- it would
> > >allow anyone who receives the certificate to be able to use those
> > >irrevocable identifiers to impersonate you.  So biometric 
> data should
> > >only be sent encrypted in a session key, if it's ever sent at all.
> >
> > This is why "irrevocables" should never be relied upon as 
> identifiers.
> >
> > I intend to publish my own photographs, fingerprints, 
> retinal scans and
> > DNA traces to public fora, precisely to diminish reliance 
> upon them as
> > evidence of "me"!  I hope to start a global movement...
> >
> > Seriously, my philosophic problem with biometrics is that, while the
> > "body" is somewhat of a constant, the "person" is not, 
> especially with
> > respect to time and circumstance.  Yet (undo) reliance upon 
> biometrics
> > tends to reinforce the notion of "once an X, always an X".  That is,
> > it will encourage the limitation of "trust" calculations to 
> constants.
> >
> > ___tony___
> >
> > Tony Bartoletti                                             LL
> > IOWA Center                                              LL LL
> > Lawrence Livermore National Laboratory                LL LL LL
> > PO Box 808, L - 089                                   LL LL LL
> > Livermore, CA 94551-9900                              LL LL LLLLLLLL
> > phone: [phone]   fax: [phone]               LL LLLLLLLL
> > email: [e-mail]                                   LLLLLLLL
> >
> 
> 
> 
> 
> 


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA05835 for <[e-mail]>; Mon, 6 Dec 1999 21:31:38 -0800 (PST)
Received: from mega (t1o69p59.telia.com [62.20.144.59]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id GAA33014; Tue, 7 Dec 1999 06:28:20 +0100
Message-ID: <001001bf407c$81fda7b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "'SEIS-List'" <[e-mail]>, "PKIX-List" <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Cc: "Magnus (RSA)" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Subject: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs
Date: Tue, 7 Dec 1999 06:30:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id VAA05947

Tony, 

Slight comment on a thing of importance that you mention 

<snip> 

>Someone mentioned that the hash is sufficient, since the actual
>data could just "tag along" with the cert, if required. But there
>needs to be a standard even for this kind of operation. Is there?


This was the original QC solution. As you noted (and I have told the 
authors several times) this is a half-made solution. A genuine example 
of poor engineering! 


Then somebody sad: Why not add an URI (option) to hold the actual data. 
Hooray!  Problem solved!   Is it? The idea behind this and the first suggestion 
is probably that the user in some mysterious way is supposed to select 
if he/she is going to give his/her biometrics away. Q: How do you do that 
with the URI-solution? I have never received an answer this! 


So I proposed that you include biometrics in a "biometric cert" and use the 
mechanism already featured in browsers (although biometrics will seldom be used 
in that environment) - certificate selection. The same solution can be applied 
to any "privacy-depriving" certificate. 

         http://www.mobilephones-tng.com/papers/idcards.html 


My bet is: Only really stupid QC implementers will use the current QC scheme for 
biometrics as they are unlikely to be supported by the large SW manufacturers 
as this part is currently simply not ready for use. But of course there is a market 
for proprietary solutions where this fits very nicely... 

Anders 




Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2-ext.email.verio.net [129.250.36.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00626 for <[e-mail]>; Mon, 6 Dec 1999 20:17:15 -0800 (PST)
Received: from dfw-mmp1.email.verio.net ([129.250.38.61]) by dfw-smtpout2.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMCS1R00.SFJ for <[e-mail]>; Tue, 7 Dec 1999 04:20:15 +0000 
Received: from nma.com ([209.21.28.123]) by dfw-mmp1.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FMCS1200.Q5G; Tue, 7 Dec 1999 04:19:50 +0000 
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 1999 20:20:24 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter:

First, excuse me for resetting the messages but your
last post in forward format with mixed text, mine and
yours, but without any ">" reply level indicator might
be even more confusing if replied ;-)

You point out that the proposed NR text in PKIX is not
"technologically-neutral" because it relies on asymmetric
signatures in order to specify the NR services.

I agreed -- however I observed:

1.  this WG is NOT binding NR to asymmetric signatures,
but just specifying  the least requirements for  NR *when*
it is based on asymmetric signatures.

2.  some posters in this WG (myself included) have already
pointed out that NR *can* be based on symmetric signatures
(see archives).

3. nowhere in X.509 it is specified that NR can NOT be based
on symmetric signatures.

4.  X.509 does specify however that authentication can NOT
be based on symmetric signatures, as given in the segment:
"The strong authentication method specified in this
Recommendation | International Standard is based upon
public-key cryptosystems."

5. I do not feel it is necessary *now* to additionally require PKIX
to be "technologically-neutral" for non-repudiation  and additionally
specify a symmetric signature method for NR -- since PKIX  is not
technologically-neutral for authentication, by definition.

However, please note that other authentication techniques besides
public-key digital signatures are clearly positively allowed (as you
argue for) in the provision of NR services, as already written in the
proposed PKIX key usage text.  This occurs when the text specifies
that "[a] signature policy identifier embedded in the signed data MAY
be used to explicitly provide context." -- e.g., I can embed a symmetric
NR signature in the asymmetrically signed data, according to a policy
identifier that I am allowed to embed in the asymmetrically signed data,
which policy identifier provides the context for the NR services ... based
on the embedded symmetric signature.

Thus, by explictly allowing the signed data itself to provide for NR context,
the current key usage text already says what you (correctly, IMO) miss:
PKIX does not require that one uses only the fixed context of  public-key
digital signatures in order to obtain a NR  service.  In a universal
Turing machine analogy, the signed data provides a secure channel both
for "code" (the to-be-interpreted bytes that denote context for a NR
service) as well as for "data" (the uninterpreted bytes that support
the NR service).  You define what is "code" and what is "data" -- but, if
you do not, the default is NR based on the context of asymmetric keys.

Cheers,

Ed Gerck



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11446 for <[e-mail]>; Mon, 6 Dec 1999 17:45:41 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF04S9J>; Mon, 6 Dec 1999 17:44:13 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Ed Gerck '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Mon, 6 Dec 1999 17:44:12 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe
Content-Type: text/plain; charset="iso-8859-1"

 

-----Original Message-----
From: Ed Gerck
To: Peter Williams
Cc: [e-mail]
Sent: 12/3/99 8:31 PM
Subject: Re: non-repudiation, was Re: proposed key usage text



Peter Williams wrote:

> <snip, snip>
>
> Perhaps, what we need is the "durable communications"
> assertion bit.
>
> Binding NR to asymmetric signatures is just a bad idea, in
> my view. Its pretty clear to me that the EC directive will
> accept a SSL server-generated, certificate-supported,
> key exchange blob-set as one or more admissable and effective
> electronic signature(s), just as it would an asymmetric
> signature blob.
>
> You may have got the NR defn off of the NSA-aberism of
> time-dependent, not evidence-dependent semantics, but its
> still linked to asymmetric signatures, and thus
> at odds with the technology-neutral regulatory
> frameworks.

Peter:

I have no doubt that non-repudiation can be based on
symmetric signatures.  This is also mentioned in this
list's archives, and by more than one poster.  I may say
thus this WG is NOT binding NR to asymmetric signatures,
but just specifying the least requirements for NR *when* it
is based on asymmetric signatures.  I think your comment
helps make this clear.

Ed:



Let me be even more clear then, based on what
you seem to assert. Its easier to specify in the positive,
to remove interpretability:-

"Use of the NR bit, as to be defined in the PKIX son
of 2459, does not require that one use a digital signature 
verification key in order to obtain that service."

If this is true, for PKIX, then I recommed we
add a statement along the lines of the above
quoted assertion to the text on NR key usage.



Now, I must also say that nowhere in X.509 it is specified
that NR can NOT be based on symmetric signatures.  It
only so restricts *authentication*, to wit:

"The strong authentication method specified in this
Recommendation | International Standard is based upon
public-key cryptosystems."

Thus, since we did manage to more clearly differentiate
between authentication and non-repudiation functions
in PKIX, which separation X.509 also predicates as quoted
in the archives, it is IMO clear that yours is a valid
question to ask -- "Why stop the NR  discussion at
asymmetric signatures in PKIX? Why not be more
technologically-neutral?"

Well, PKIX itself is NOT technologically-neutral
for authentication (see above) --  which may already
preempt the "technology-neutral" argument for
PKIX in the eyes of many.  So, this may be one
answer to your question -- it is not required.

However, in time and again, I believe facts will show
that unless we enlarge our models (e.g., with symmetric
NR) we will not be able to represent the real-world as
we ourselves enlarge it.  Then, IMO your question will
be rediscovered and a solution will be more clearly
needed.  But, right now, I believe we should try to
achieve closure on the current (limited, but useful)
definition of NR in PKIX.  It will be always fun
though to investigate the next issues.

Cheers,

Ed Gerck


Received: from oberon.dnai.com (oberon.dnai.com [207.181.194.97]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10883 for <[e-mail]>; Mon, 6 Dec 1999 17:08:33 -0800 (PST)
Received: from dnai.com (dnai-216-15-121-230.cust.dnai.com [216.15.121.230]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id RAA23987; Mon, 6 Dec 1999 17:10:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 1999 17:10:22 -0800
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: PKIX-List <[e-mail]>
Subject: Re: Stray Poll: Finger-prints in QCs
References: <005101bf4039$801e82e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:

> This discussion can continue forever without getting anywhere so I
> propose a short-cut.  The alternatives are:
> 
> 1.  Support it as an option

see final comments below.

> 2.  PKIX should limit direct support of information that could deprive privacy regardless if some parties want it

Definitely. 

> 3.  Finger-prints have no proved value or are still technically immature

A substantial percentage of the population in the (ethnically diverse) US
have no readable fingerprints.  No encoding of biometric data
exists which would represent an invariant reference -- all biometric
data are subject not only to variances in the metric apparatus, but
also in the subject.  Therefore,  biometric data could only reasonably
accomodated by reference.  Which raises the question of whether there
can be a trusted repository of such data.  I suggest not.

There are undoubtedly applications in which reference to biometric data
for the purposes of authentication might be desireable,  and in which
privacy concerns are not relevant (military installations, etc.).  I
cannot comprehend why anyone thinks that the binding of biometric data
to a unique person should be embedded in a certificate.  

-- 
QUI ME AMET, CANEM MEUM ETIAM AMET


Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02613 for <[e-mail]>; Mon, 6 Dec 1999 15:04:50 -0800 (PST)
Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA15138 for <[e-mail]>; Mon, 6 Dec 1999 15:07:49 -0800 (PST)
Received: from scv1.apple.com (scv1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Mon, 06 Dec 1999 15:07:06 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id PAA09537 for <[e-mail]>; Mon, 6 Dec 1999 15:06:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Mon, 06 Dec 1999 15:06:49 -0800
Subject: Re: proposed key usaged text -- the final round
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Tim Polk wrote:

> Hi Aram,
> 
> I At 01:35 PM 11/24/1999 -0800, Aram Perez wrote:
>>Hi Tim and Russ,
>>
>>Thanks for taking the effort to clarify and settling the key usage debate.
>>Below are a few comments...
>>
> [snip]
>>>
>>>        The dataEncipherment bit is asserted when the subject public key
>>>        is used for enciphering user data, other than cryptographic keys.
>>
>>I'd would change "enciphering user data" to "enciphering data".
>>
>
> At the moment, I can't think of a technical reason to retain "user" in that
> phrase.  However, that bit of text has been stable since at least draft 5
> (July '97).  The word user doesn't add much, but is it *really* a problem?
>
> My inclination is to leave it alone unless it is really broken.

I believe a few other folks agree that it should be dropped. It does not add
anything and it raises the question "What's the difference between 'user
data' and just plain 'data'?"

>
>>>
>>>        The keyAgreement bit is asserted when the subject public key is
>>>        used for key agreement.  For example, when a Diffie-Hellman key is
>>>        to be used for key management, then this bit shall asserted.
>>>
>>>        The keyCertSign bit is asserted when the subject public key is
>>>        used for verifying a signature on certificates.  This bit may only
>>>        be asserted in CA certificates.  If the keyCertSign bit is
>>>        asserted, then the cA bit in the basic constraints extension (see
>>>        4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
>>>        asserted, then the cA bit in the basic constraints extension MUST
>>>        NOT be asserted.
>>>
>>>        The cRLSign bit is asserted when the subject public key is used
>>>        for verifying a signature on revocation information (e.g., a CRL).
>>
>>Neither of you responded to my previous comment on this bit. If cRLSign bit
>>is asserted, must the cA bit in the basic constraints extension also be
>>asserted? And vice-versa?
>>
>
> My apologies for the lack of a response.  I have been swamped since we
> posted the text.
>
> There is no direct relationship between the cA bit in basic constraints and
> the cRLSign bit in key usage.  Consider a subject that issues indirect CRLs
> but does not generate certificates.  In this case, the cRLSign bit would be
> set, but the cA bit in basic constraints and the keyCertSign bit in key
> usage would not be set.
>
> Alternatively, CAs may not issue CRLs; they may rely on indirect CRLs or
> OCSP for example.  In that case, the cA bit in basic constraints and the
> keyCertSign bit in key usage would be set; the cRLSign bit would not.
>
> Would a brief note stating that no relationship exists clarify matters?
> Perhaps the following would do?
>
>         The cRLSign bit is asserted when the subject public key is used
>         for verifying a signature on revocation information (e.g., a CRL).
>         [Note: Unlike the keyCertSign bit, there is no relationship
>         between the value of cRLSign and the basic constraints extension.]

Yes, I think this would clarify the description.

>
>
>>>     This profile does not restrict the combinations of bits that may be
>>>     set in an instantiation of the keyUsage extension.  However,
>>>     appropriate values for keyUsage extensions for particular algorithms
>>>     are specified in section 7.3.
>>
>>Again, neither of you responded to my previous comment on at least
>>recommending against certain combinations.
>>
>
> See apology above.  From your email on 11/17:
>>I think this is a mistake and causes confusion. In an extreme example, since
>>there is no restrictions, I could have a certificate that has all the bits
>>set. This means that I can do the following with my asymmetric key pair:
>>
>>1) sign for entity authentication and data origin authentication with
>>integrity,
>>2) sign with a non-repudiation service,
>>3) encrypt keys for transport using RSA like algorithms,
>>4) encrypt data,
>>5) exchange keys using D-H like algorithms,
>>6) sign certificates,
>>7) sign CRLs,
>>8) encrypt data using D-H like algorithms, and
>>9) decrypt data using D-H like algorithms.
>>
>>
> That's true.  That is also the case if the key usage extension isn't
> included in the certificate.
>
> We rely on the algorithm text (section 7.3) to recommend against
> combinations that don't make sense cryptographically.  (That is, if the
> public key is a DSA key, don't asssert keyEncipherment or
> dataEncipherment.) I expect that is all this group can do.

I still believe that stating the profile "does not restrict the combinations
of bits" is a mistake. This means that there will be compliant software that
has invalid keyUsage bit combinations.

>
> More from 11/17:
>>At a minimum, the profile should list the combination of bits which are not
>>allowed. A few examples:
>>
>>1) If keyCertSign is asserted, then the only other bit that can be asserted
>>is the cRLSign bit.
>>2) If cRLSign is asserted, then the only other bit that can be asserted is
>>the keyCertSign bit.
>>3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.
>>
>>
> There has been a lot of debate here, and in other groups, about which
> combinations should be permitted or forbidden.  There are lots of different
> opinions.  For example, I personally could accept 1) and 2) but not 3).
> There are algorithms that would let me use my RSA key for key agreement or
> my elliptic curve key for key transport. I don't think I should need two
> certificates to support that.

You lost me here Tim. I've never seen an X.509 certificate for both an RSA
key and an elliptic curve key. Unless I've completed missed something, you
MUST have certificate for your RSA key and another certificate for your
elliptic curve key.

>  Others have rational arguments with 1) and 2).

Just because there are rational arguments does not mean that they are
"secure arguments". I've asked the question and I will ask it again: "If we,
who claim to be the security experts, can't agree on these issues, how is
the general population going to know what to do?

>
> IMHO, there is absolutely no chance that this group would ever reach
> consensus on which combinations should be restricted.  It is rathole as
> dark and deep as the NR bit!
>
> Besides, PKIX client systems need to handle any combinations of key usage
> bits for the sake of interoperability.  As long as path building is "hard",
> people will try to limit the number of certificates they generate by
> asserting all (cryptographically) reasonable bits.

But they should be asserting all (cryptographically and security-wise)
reasonable bits.

Regards,
Aram Perez


Received: from ponyexpress6.csc.com (ponyexpress6.csc.com [208.219.64.207]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02244 for <[e-mail]>; Mon, 6 Dec 1999 14:52:33 -0800 (PST)
From: [e-mail]
Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress6.csc.com with smtp (Exim 2.12 #1) id 11v726-0002Uq-00 for [e-mail]; Mon, 6 Dec 1999 17:55:02 -0500
Received: by csc.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525683F.007DEA98 ; Mon, 6 Dec 1999 17:55:20 -0500
X-Lotus-FromDomain: CSC
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 6 Dec 1999 17:54:51 -0500
Subject: Re: QC's - for human eyes only?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Consider the distinction between *identification* and *authentication*.
Something makes a good identifier if it points uniquely to what it identifies.
Something makes a good authenticator if it is hard for the wrong entity to
generate it.   If a "secret" authenticator is shared between too many parties
(e.g., SSN, mother's maiden name) it no longer makes a very good authenticator.

What is the nature of a biometric?  A problem for biometrics is that if multiple
systems know and authenticate me by a my fingerprint data, is that data still a
good authenticator?  If the comparison is static, the answer would be "no" for
the same reason as SSNs, etc. are poor.  But if they also use an effective
"liveness" test against static reference data, then the reference fingerprint
data really serves as an identifier and the "liveness" test mechanism really
serves as the authenticator.  In that case what's the problem with including my
fingerprint data in a certificate?

I think the real worry about including a biometric in a certificate is the
potential for privacy invasion, because the biometric in effect becomes an
unchangeable universal identifier - exactly the same concern now about SSNs
being attached to all your records, permitting easy dossier compilation.

A static hash doesn't solve the privacy problem because that hash itself just
serves as the universal identifier.

IMO, the best thing to do with a biometric in connection with PKI is to put it
into a hardware token that protects one's private key corresponding to the
public key in a certificate.  Then it serves as a private user-to-key-device
authenticator which is not shared outside that environment.  No reference to the
biometric content is needed in the certificate for this use.  This use of
biometrics is (1)highly secure (assuming a trusted channel between biometrics
reader and key device) and (2) not a threat to privacy.

-Gene Hilborn




[e-mail] on 12/06/99 03:17:57 PM

To:   [e-mail]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: QC's - for human eyes only?



If putting biometric data in a certificate is "bad," what about putting a
hash of it?

Or should this type of information be more appropriately stored in a
directory?
----- Original Message -----
From: Tony Bartoletti <[e-mail]>
To: Eric Murray <[e-mail]>; Ilan Shacham <[e-mail]>
Cc: Ietf-Pkix (E-mail) <[e-mail]>
Sent: Monday, December 06, 1999 11:05 AM
Subject: Re: QC's - for human eyes only?


> At 09:00 AM 12/05/1999 -0800, Eric Murray wrote:
>
> >However putting a biometric in a certificate is like putting your Social
> >Security Number and mother's maiden name in a certificate- it would
> >allow anyone who receives the certificate to be able to use those
> >irrevocable identifiers to impersonate you.  So biometric data should
> >only be sent encrypted in a session key, if it's ever sent at all.
>
> This is why "irrevocables" should never be relied upon as identifiers.
>
> I intend to publish my own photographs, fingerprints, retinal scans and
> DNA traces to public fora, precisely to diminish reliance upon them as
> evidence of "me"!  I hope to start a global movement...
>
> Seriously, my philosophic problem with biometrics is that, while the
> "body" is somewhat of a constant, the "person" is not, especially with
> respect to time and circumstance.  Yet (undo) reliance upon biometrics
> tends to reinforce the notion of "once an X, always an X".  That is,
> it will encourage the limitation of "trust" calculations to constants.
>
> ___tony___
>
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL
>







Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01916 for <[e-mail]>; Mon, 6 Dec 1999 14:36:11 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id OAA14621; Mon, 6 Dec 1999 14:39:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 06 Dec 1999 14:38:40 -0800
To: "Anders Rundgren" <[e-mail]>, "PKIX-List" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Stray Poll: Finger-prints in QCs
In-Reply-To: <005101bf4039$801e82e0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Anders,

Putting philosophy aside, I am not against the inclusion of any
option, technically.  But I confess to being behind the curve on
the distinctions made regarding "options" and "future extensibility".

Ilam asked why the profile limits discussion to "human-on-hand"
biometric authentication.  This makes sense, as Steven Kent noted.
That is, in remote authentication, biometric data is only useful
if it is absolutely secret.  But then, ANYTHING absolutely secret
would do just as well, and biometric data would certainly NOT be
the best choice.  I might pick up your fingerprints or DNA trace
from an unwashed drinking glass.  But you take better care with
your secret keys, I suppose.

Ilam also asked why the limitation to a hash.  Here, I agree that
size limitations seem short-sighted.  Bob Jueneman's "JPG of my cat"
comes to mind.  Why not allow for unlimited size, given systems that
can handle it.

Denis Pinkas states that X509V3 allows extensions that can be
"defined later, when it becomes appropriate".  So, when does it
become appropriate?  And can such extensions be added unilaterally
by the parties that would use them?  Are we arguing that they need
to be profiled now, to provide a consistent groundwork?

Someone mentioned that the hash is sufficient, since the actual
data could just "tag along" with the cert, if required.  But there
needs to be a standard even for this kind of operation.  Is there?

It may be marginally outside the PKIX charter to show concern
beyond the keys/certificates themselves.  Is s/mime a more
appropriate forum for this concern?

Have I posed enough questions? ;)

___tony___


At 10:30 PM 12/06/1999 -0000, Anders Rundgren wrote:
>All,
>This discussion can continue forever without getting anywhere so I
>propose a short-cut.  The alternatives are:
>
>1.  Support it as an option
>
>2.  PKIX should limit direct support of information that could deprive privacy regardless if some parties want it
>
>3.  Finger-prints have no proved value or are still technically immature
>
>Anders 
>
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA00979 for <[e-mail]>; Mon, 6 Dec 1999 13:30:55 -0800 (PST)
Received: from mega (t2o69p13.telia.com [62.20.144.133]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA31423 for <[e-mail]>; Mon, 6 Dec 1999 22:28:42 +0100
Message-ID: <005101bf4039$801e82e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: Stray Poll: Finger-prints in QCs
Date: Mon, 6 Dec 1999 22:30:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA00980

All,
This discussion can continue forever without getting anywhere so I
propose a short-cut.  The alternatives are:

1.  Support it as an option

2.  PKIX should limit direct support of information that could deprive privacy regardless if some parties want it

3.  Finger-prints have no proved value or are still technically immature

Anders 



Received: from cymail.cylink.com ([192.43.161.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29073 for <[e-mail]>; Mon, 6 Dec 1999 12:17:12 -0800 (PST)
Received: from lmartin ([10.106.17.91]) by cymail.cylink.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41860U500L2S100) with SMTP id AAA14295 for <[e-mail]>; Mon, 6 Dec 1999 12:16:10 -0800
Message-ID: <003d01bf4026$fc7600b0$5b116a0a@cylink>
From: [e-mail] (Luther Martin)
To: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: QC's - for human eyes only?
Date: Mon, 6 Dec 1999 12:17:57 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

If putting biometric data in a certificate is "bad," what about putting a
hash of it?

Or should this type of information be more appropriately stored in a
directory?
----- Original Message -----
From: Tony Bartoletti <[e-mail]>
To: Eric Murray <[e-mail]>; Ilan Shacham <[e-mail]>
Cc: Ietf-Pkix (E-mail) <[e-mail]>
Sent: Monday, December 06, 1999 11:05 AM
Subject: Re: QC's - for human eyes only?


> At 09:00 AM 12/05/1999 -0800, Eric Murray wrote:
>
> >However putting a biometric in a certificate is like putting your Social
> >Security Number and mother's maiden name in a certificate- it would
> >allow anyone who receives the certificate to be able to use those
> >irrevocable identifiers to impersonate you.  So biometric data should
> >only be sent encrypted in a session key, if it's ever sent at all.
>
> This is why "irrevocables" should never be relied upon as identifiers.
>
> I intend to publish my own photographs, fingerprints, retinal scans and
> DNA traces to public fora, precisely to diminish reliance upon them as
> evidence of "me"!  I hope to start a global movement...
>
> Seriously, my philosophic problem with biometrics is that, while the
> "body" is somewhat of a constant, the "person" is not, especially with
> respect to time and circumstance.  Yet (undo) reliance upon biometrics
> tends to reinforce the notion of "once an X, always an X".  That is,
> it will encourage the limitation of "trust" calculations to constants.
>
> ___tony___
>
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL
>



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21404 for <[e-mail]>; Mon, 6 Dec 1999 11:03:08 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA11765; Mon, 6 Dec 1999 11:05:49 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 06 Dec 1999 11:05:22 -0800
To: Eric Murray <[e-mail]>, Ilan Shacham <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: QC's - for human eyes only?
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:00 AM 12/05/1999 -0800, Eric Murray wrote:

>However putting a biometric in a certificate is like putting your Social
>Security Number and mother's maiden name in a certificate- it would
>allow anyone who receives the certificate to be able to use those
>irrevocable identifiers to impersonate you.  So biometric data should
>only be sent encrypted in a session key, if it's ever sent at all.

This is why "irrevocables" should never be relied upon as identifiers.

I intend to publish my own photographs, fingerprints, retinal scans and
DNA traces to public fora, precisely to diminish reliance upon them as
evidence of "me"!  I hope to start a global movement...

Seriously, my philosophic problem with biometrics is that, while the
"body" is somewhat of a constant, the "person" is not, especially with
respect to time and circumstance.  Yet (undo) reliance upon biometrics
tends to reinforce the notion of "once an X, always an X".  That is,
it will encourage the limitation of "trust" calculations to constants.

___tony___  

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from hotmail.com (f186.law4.hotmail.com [216.33.149.186]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA14813 for <[e-mail]>; Mon, 6 Dec 1999 05:05:54 -0800 (PST)
Received: (qmail 93197 invoked by uid 0); 6 Dec 1999 13:08:21 -0000
Message-ID: <[e-mail]>
Received: from 202.84.254.4 by www.hotmail.com with HTTP; Mon, 06 Dec 1999 05:08:21 PST
X-Originating-IP: [202.84.254.4]
From: "Franklin Lee" <[e-mail]>
To: [e-mail]
Subject: Re: CRL Distribution Mechanism Evaluation and Considerations
Date: Mon, 06 Dec 1999 13:08:21 GMT
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_4918659b_a2cb209$754862cf"

This is a multi-part message in MIME format.

------=_NextPart_000_4918659b_a2cb209$754862cf
Content-Type: text/plain; format=flowed

Dear all,
Today, I have consolidated some data as researched from the web. Please see 
the attached.  Though are very priliminary, would greatly be appreicated for 
any comments regarding:

- security considerations (whether there issues to distribute the CRL with 
either protocol?)
- performance (which would be more suitable? which would be faster in terms 
of the speed of retrieval/processing)
- compatibility (any considerations regarding the transfer of the CRL)
- interoperability
- market trend/practice ( which is more popular

Again, thanks a lot.

Rgds,
Franklin

>From: "Franklin Lee" <[e-mail]>
>To: [e-mail]
>Subject: Re: CRL Distribution Mechanism Evaluation and Considerations
>Date: Mon, 06 Dec 1999 02:09:00 GMT
>
>Dear all,
>
>Actually, I'm a student in the Mainland China having a reserach on the
>"Digital Certificate" applications and limitations --- e-commerce and
>cryptograhpy are still relatively new to our region.
>
>Regarding the CRL distribution mechanism, I have found few topics yet there
>are of 98 versions:
>
>a) Phillip Hallum-Baker
>http://csrc.nist.gov/pki/twg/papers/hallum-baker.htm
>
>b) Mike Myers
>http://csrc.nist.gov/pki/twg/twg98_6.htm
>
>Therefore, would be greatly appreciated for the comments and advice from 
>the
>corresponding knowledge leads.
>
>Again, thanks a lot and all comments are very welcomed.
>
>>From: "Franklin Lee" <[e-mail]>
>>To: [e-mail]
>>Subject: CRL Distribution Mechanism Evaluation and Considerations
>>Date: Sun, 05 Dec 1999 04:18:45 GMT
>>
>>Dear all,
>>
>>I'm interested in all experts' views on evaulating the distribution of the
>>CRL(Certificate Revocation List) -
>>
>>LADP over SSL vs. HTTPS (HTTP over SSL)
>>
>>e.g,
>>- what are the key considerations (e.g, performance, infrastructure) for
>>choosing either protocol?
>>- what are the current preferred practice as performed by the various CAs?
>>(e.g. Thawte, Verisign)?
>>
>>
>>Thanks a lot and any comments (e.g., links to any relevant docu") are
>>greatly appreciated.
>>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
------=_NextPart_000_4918659b_a2cb209$754862cf
Content-Type: application/octet-stream; name="LDAP_HTTPS1.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="LDAP_HTTPS1.xls"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB
AAAANQAAAAAAAAAAEAAA/v///wAAAAD+////AAAAADQAAAD/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////8JCBAAAAYFANMQzAdJAAAABgAAAOEAAgCwBMEA
AgAAAOIAAABcAHAAGwAAUmlja3kgTGkgKE1hcmtldCBSZWFkaW5lc3MpICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAA
AD0BAgABAJwAAgAOABkAAgAAABIAAgAAABMAAgAAAK8BAgAAALwBAgAAAD0A
EgBYAv8AXCvLFjgAAAAAAAEAWAJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3
AQIAAADaAAIAAAAxACgAyAAAAP9/kAEAAAAAAAAMAUIAbwBvAGsAIABBAG4A
dABpAHEAdQBhADEAKADIAAAA/3+QAQAAAAAAAAwBQgBvAG8AawAgAEEAbgB0
AGkAcQB1AGEAMQAoAMgAAAD/f5ABAAAAAAAADAFCAG8AbwBrACAAQQBuAHQA
aQBxAHUAYQAxACgAyAAAAP9/kAEAAAAAAAAMAUIAbwBvAGsAIABBAG4AdABp
AHEAdQBhADEAKADIAAEA/3+8AgAAAAEAAAwBQgBvAG8AawAgAEEAbgB0AGkA
cQB1AGEAMQAoAMgABAAMAJABAAABAAAADAFCAG8AbwBrACAAQQBuAHQAaQBx
AHUAYQAxACgAyAAAAP9/kAEAAAABAAAMAUIAbwBvAGsAIABBAG4AdABpAHEA
dQBhAB4EHAAFABcAACIkIiMsIyMwXyk7XCgiJCIjLCMjMFwpHgQhAAYAHAAA
IiQiIywjIzBfKTtbUmVkXVwoIiQiIywjIzBcKR4EIgAHAB0AACIkIiMsIyMw
LjAwXyk7XCgiJCIjLCMjMC4wMFwpHgQnAAgAIgAAIiQiIywjIzAuMDBfKTtb
UmVkXVwoIiQiIywjIzAuMDBcKR4ENwAqADIAAF8oIiQiKiAjLCMjMF8pO18o
IiQiKiBcKCMsIyMwXCk7XygiJCIqICItIl8pO18oQF8pHgQuACkAKQAAXygq
ICMsIyMwXyk7XygqIFwoIywjIzBcKTtfKCogIi0iXyk7XyhAXykeBD8ALAA6
AABfKCIkIiogIywjIzAuMDBfKTtfKCIkIiogXCgjLCMjMC4wMFwpO18oIiQi
KiAiLSI/P18pO18oQF8pHgQ2ACsAMQAAXygqICMsIyMwLjAwXyk7XygqIFwo
IywjIzAuMDBcKTtfKCogIi0iPz9fKTtfKEBfKeAAFAAAAAAA9f8gAAAAAAAA
AAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0
AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8g
AAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA
9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAA
AAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA
FAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADA
IOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAA
AADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAAAQAgAAAAAAAA
AAAAAADAIOAAFAABACsA9f8gAAD4AAAAAAAAAADAIOAAFAABACkA9f8gAAD4
AAAAAAAAAADAIOAAFAABACwA9f8gAAD4AAAAAAAAAADAIOAAFAABACoA9f8g
AAD4AAAAAAAAAADAIOAAFAAGAAAA9P8AAAD0AAAAAAAAAADAIOAAFAABAAkA
9f8gAAD4AAAAAAAAAADAIOAAFAAFAAAAAQAIAAB4ERFAIEAgAAQqIOAAFAAF
AAAAAQAIAAA4ERFAIEAgAADAIOAAFAAFAAAAAQAIAAB4ERFAIEAgAADAIOAA
FAAHAAAAAQAIAAB4ERFAIEAgAADAIOAAFAAHAAAAAQAIAAAYAAAAAAAAAADA
IOAAFAAHAAAAAQAIAAA4ERFAIEAgAADAIOAAFAAHAAAAAQAJAAA4ERFAIEAg
AADAIOAAFAAHAAAAAQALAAA4ERFAIEAgAADAIOAAFAAFAAAAAQALAAB4ERFA
IEAgAAQNIOAAFAAFAAAAAQAIAAB4ERFAIEAgAAQpIOAAFAAFAAAAAQAAAAB4
ERFAIEAgAAQpIJMCBAAQgAP/kwIEABGABv+TAgQAEoAE/5MCBAATgAf/kwIE
ABSACP+TAgQAAIAA/5MCBAAVgAX/YAECAAEAhQAQABA2AAAAAAgARmluZGlu
Z3OMAAQAAQABAK4BBAABAAEEFwAIAAEAAAAAAAAAGAAiAAAAAAgLAAAAAQAA
AAAAAF8xMDY5NTM3OwAAJAAkAAMAAwAYABsAIAAAAQsAAAABAAAAAAAABzsA
AAAAAAAAAP8AGAAfAAAAAAULAAAAAQAAAAAAAFRBQkxFOwAADQAOAAEAAQAY
ACEAAAAABwsAAAABAAAAAAAAVEFCTEVfMjsAAB0AHQACAAQAGAAhAAAAAAcL
AAAAAQAAAAAAAFRBQkxFXzM7AAAdAB0AAgAEABgAIQAAAAAHCwAAAAEAAAAA
AABUQUJMRV80OwAAJAAkAAMAAwD8ACAgXwAAAFYAAADeAQBMREFQIGRlZmlu
ZXMgYSBjb21tdW5pY2F0aW9uIHByb3RvY29sLiBUaGF0IGlzLCBpdCBkZWZp
bmVzIHRoZSB0cmFuc3BvcnQgYW5kIGZvcm1hdCBvZiBtZXNzYWdlcyB1c2Vk
IGJ5IGEgY2xpZW50IHRvIGFjY2VzcyBkYXRhIGluIGFuIFguNTAwLWxpa2Ug
ZGlyZWN0b3J5LiBMREFQIGRvZXMgbm90IGRlZmluZSB0aGUgZGlyZWN0b3J5
IHNlcnZpY2UgaXRzZWxmLiBIb3dldmVyLCB3aGVuIHJlZmVycmluZyB0byBh
IGRpcmVjdG9yeSB0aGF0IGNhbiBiZSBhY2Nlc3NlZCB1c2luZyBMREFQLCB0
aGUgZGlyZWN0b3J5IGlzIHVzdWFsbHkgY2FsbGVkIGFuIExEQVAgZGlyZWN0
b3J5LiBUaGVyZWZvcmUsIExEQVAgZGlyZWN0b3JpZXMgY2FuIGJlIGltcGxl
bWVudGVkIGluIG1hbnkgZGlmZmVyZW50IHdheXMuIElCTSBpbXBsZW1lbnRz
IGNyb3NzIHBsYXRmb3JtIExEQVAgZGlyZWN0b3JpZXMgdXNpbmcgREIyIGFu
ZCBMb3R1cyBEb21pbm8uIAoK6gAATERBUCwgd2hpY2ggaGFzIGJlY29tZSB0
aGUgSW50ZXJuZXQgc3RhbmRhcmQgZm9yIGRpcmVjdG9yeSBvcGVyYXRpb25z
LCBpcyBzdGFydGluZyB0byByZXBsYWNlIHRoZSBtb3JlIGZhbWlsaWFyIEhU
VFAgaW4gc29tZSBJbnRlcm5ldCBhcHBsaWNhdGlvbnMuIEFuIEludGVybmV0
IFVSTCBtYXkgc3BlY2lmeSB0aGUgYWRkcmVzcyBvZiBhbiBMREFQIHNlcnZl
ciwgaW5zdGVhZCBvZiBhbiBIVFRQIHNlcnZlcgoKFAEARGlzdHJpYnV0aW9u
IG9mIGNlcnRpZmljYXRlcyBpcyBhbHNvIGRvbmUgdGhyb3VnaCBvcGVuIHN0
YW5kYXJkcy4gQmVjYXVzZSBOZXRzY2FwZSBDZXJ0aWZpY2F0ZSBTZXJ2ZXIg
dXNlcyBMREFQIChMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzIFByb3Rv
Y29sKSB0byBwdWJsaXNoIGNlcnRpZmljYXRlcyBhbmQgY2VydGlmaWNhdGUg
cmV2b2NhdGlvbiBsaXN0cywgdGhlc2Ugb2JqZWN0cyBjYW4gYmUgcHVibGlz
aGVkIHRvIGFueSBMREFQLWNvbXBsaWFudCBkaXJlY3RvcnkuIAoKEAEATERB
UCB2MiBvbmx5IG9mZmVycyBhIHNpbXBsZSBjbGVhciB0ZXh0IHBhc3N3b3Jk
IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbS4gCkxEQVAgdjMgaXMgZXhwZWN0
ZWQgdG8gZGVzY3JpYmUgYSBzZWN1cml0eSBtb2RlbCBiYXNlZCB1cG9uIHRo
ZSBTZWN1cmUgU29ja2V0cyBMYXllciAoU1NMKSB0ZWNobm9sb2d5IHVzZWQg
d2l0aGluIHRoZSBJRVRGLiBUaGlzIHNlY3VyZXMgYWNjZXNzIGJldHdlZW4g
dGhlIExEQVAgY2xpZW50IGFuZCB0aGUgbG9jYWwgTERBUCBzZXJ2ZXIuIAoq
AQBMREFQIG92ZXIgU1NMIChMREFQUykgYWxsb3dzIHNlY3VyZSBMREFQIGNs
aWVudCBhY2Nlc3MgYW5kIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmYWNpbGl0
aWVzIHRvZGF5LiBJbiB0aGUgZnV0dXJlLCBMREFQdjMgY2xpZW50cyBjYW4g
dXNlIHRoZSBzdGFydFRMUyBleHRlbmRlZCBvcGVyYXRpb24gdG8gYmVnaW4g
ZW5jcnlwdGluZyBhbiBMREFQIGNvbm5lY3Rpb24sIGFuZCBUTFMgdG8gcHJv
dmUgdGhlaXIgaWRlbnRpdHkgdG8gdGhlIHNlcnZlciwgYXMgd2VsbCBhcyB2
ZXJpZnkgdGhlIHNlcnZlcidzIGlkZW50aXR5LiAKrgAAQmVpbmcgZGVzaWdu
ZWQgZm9yIHRoaXMgdXNhZ2UgcGF0dGVybiwgY3VycmVudCBkaXJlY3Rvcnkg
c2VydmVycyB3aXRoIGEgbWlsbGlvbiBvciBtb3JlIGVudHJpZXMgY2FuIHJl
c3BvbmQgdG8gaHVuZHJlZHMgb2Ygc2VhcmNoIHJlcXVlc3RzIHBlciBzZWNv
bmQgZnJvbSBhIHNpbmdsZSBzZXJ2ZXIuIAoKFgAASW50ZXJuYXRpb25hbCBT
dGFuZGFyZBcAAFNlY3VyaXR5IENvbnNpZGVyYXRpb25zlQQATERBUCBhbmQg
SFRUUCBoYXZlIGJvdGggYmVlbiBwcm9wb3NlZCBhcyBtZWNoYW5pc21zIGZv
ciBkaXN0cmlidXRpbmcgc3RhdHVzIGluZm9ybWF0aW9uLiBJbiBib3RoIGNh
c2VzIGhvd2V2ZXIgaXQgaXMgbmVjZXNzYXJ5IHRvIGNhcmVmdWxseSBjb25z
aWRlciB0aGUgaXNzdWVzIHJhaXNlZCBieSBjb3Jwb3JhdGUgZmlyZXdhbGxz
LiAKSW5zaWRlIGFuIGVudGVycHJpc2UgYm90aCBMREFQIGFuZCBIVFRQIGFy
ZSBhbiBhZGVxdWF0ZSBiYXNpcyBmb3IgYSBzb2x1dGlvbi4gTERBUCBvZmZl
cnMgY2xvc2VyIGludGVncmF0aW9uIHdpdGggdGhlIFguNTAwIGRhdGEgbW9k
ZWwsIEhUVFAgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGRhdGEgbW9kZWwuIFRo
ZSBiZW5lZml0cyBvZiBib3RoIHN0cmF0ZWdpZXMgbWF5IGJlIGFyZ3VlZC4g
ClVubGlrZSBIVFRQLCBpdCByZW1haW5zIHRvIGJlIHNlZW4gaWYgTERBUCBi
ZWNvbWVzIGEgY29udGVuZGVyIGluIHRoZSBpbnRlci1uZXR3b3JraW5nIGNv
bnRleHQuIFRoZSBncmVhdGVyIHRoZSBkZXBlbmRlbmNlIG9mIHRoZSBlbnRl
cnByaXNlIGluZnJhc3RydWN0dXJlIG9uIGEgZGlyZWN0b3J5LCB0aGUgbW9y
ZSByZWx1Y3RhbnQgZW50ZXJwcmlzZXMgYXJlIHRvIG1ha2UgdGhlbSBleHRl
cm5hbGx5IGFjY2Vzc2libGUuIExEQVAgcmVwcmVzZW50cyBhIHJpY2ggdmVp
biBvZiBwcmVjaXNlbHkgdGhlIHR5cGUgb2YgbWF0ZXJpYWwgY29ycG9yYXRp
b25zIGFyZSBrZWVuIHRvIHByZXZlbnQgZXh0ZXJuYWwgYWNjZXNzIHRvLCBw
ZXJzb25uZWwgaW5mb3JtYXRpb24sIGRlcGFydG1lbnQgc3RydWN0dXJlLCBl
dGMuIApCb3RoIHRyYW5zcG9ydHMgYXJlIHJlbGV2YW50IGluIGRpZmZlcmVu
dCBzY2VuYXJpb3MuIEVudGVycHJpc2UgUy9NSU1FIGFuZCBwb2xpY3kgZW5m
b3JjZW1lbnQgZ2VuZXJhbGx5IGZhdm9ycyBMREFQJ3MgYWJpbGl0eSB0byBw
cm92aWRlIGEgcmljaCBjb250ZXh0IGFjcm9zcyBpbnRlcm5hbCBuZXR3b3Jr
cy4gIEV4dHJhbmV0IGludGVyb3BlcmFiaWxpdHkgY29uY2VybnMsIHN1Y2gg
YXMgdGhvc2UgbGlrZWx5IHRvIGJlIGVuY291bnRlcmVkIGJ5IHJlcGx5aW5n
IHBhcnRpZXMnIGFjY2VzcyB0byByZXZvY2F0aW9uIGluZm9ybWF0aW9uLCBt
YXkgYmUgbW9yZSBxdWlja2x5IG1ldCB1c2luZyBIVFRQLiAKCgoKWgAAQm90
aCBhcmUgcmVjb21tZW5kZWQgYXMgdGhlIEludGVybmV0IFguNTA5IFB1Ymxp
YyBLZXkgSW5mcmFzdHJ1Y3R1cmUgT3BlcmF0aW9uYWwgUHJvdG9jb2xzMQAA
Qm90aCB3aWxsIGJlIGNvbnNpZGVyZWQgc2VjdXJlIGFzIHByb3ZpZGVkIGJ5
IFNTTEIAAEJvdGggYXJlIHBycG9zZWQgYXMgbWVjaGFuaXNtcyBmb3IgZGlz
dHJpYnV0aW5nIHN0YXR1cyBpbmZvcm1hdGlvbhQAAE5vIGdyb3VuZCB0byBj
b21wYXJlNgAAQm90aCBhcmUgc3VwcG9ydGVkIGJ5IEZpcmV3YWxsLTEgKENo
ZWNrcG9pbnQgU29mdHdhcmUp0gAAWWVzLCB3ZSBkbyBzdXBwb3J0IEhUVFBT
LiAgV2UgZG9uJ3Qgc3VwcG9ydCBMREFQIG92ZXIgU1NMLiAgV2UgZG8KbWFr
ZSB0aGUgQ1JMJ3MgYXZhaWxhYmxlIG9uIG91ciB3ZWIgc2l0ZSBhbmQgd2Ug
YWxzbyBzZW5kIHRoZW0gdG8KVmFsaWNlcnQsIGEgdmFsaWRhdGlvbiBhdXRo
b3JpdHkuICBWYWxpY2VydCBzdXBwb3J0cyBPQ1NQIChyZWFsdGltZSBsb29r
IHVwKS4KAgAAPz8EAABMREFQBQAASFRUUFMPAABNYXJrZXQgUHJhY3RpY2UU
AABUaGF3dGUgQ2VydGlmaWNhdGlvbgIAAE5vTAAATERBUCBvbmx5IHN1cHBv
cnRzIG5vIGF1dGhlbnRpY2F0aW9uIG9yIHNpbXBsZSBwYXNzd29yZCBiYXNl
ZCBhdXRoZW50aWNhdGlvbgUAAFgtcmVmNgAAaHR0cDovL3d3dy51bWljaC5l
ZHUvfmRpcnN2Y3MvbGRhcC9pbmRleC5odG1sI292ZXJ2aWV3CwAAUGVyZm9y
bWFuY2UrAABodHRwOi8vcGVvcGxlLm5ldHNjYXBlLmNvbS9iam0vd2h5TERB
UC5odG1sbAAATERBUCBjb25uZWN0aW9ucyBjYW4gYmUgYXV0aGVudGljYXRl
ZCAocmVxdWlyaW5nIGEgcGFzc3dvcmQgb3Igb3RoZXIgY3JlZGVudGlhbHMp
IGFuZCBzZWN1cmVkIHRocm91Z2ggU1NMLiAKNwAAaHR0cDovL2RldmVsb3Bl
ci5uZXRzY2FwZS5jb20vdmlld3NvdXJjZS9yb3NlX2xkYXAuaHRtbAUAAEFy
ZWFzwAAATERBUCBpcyBhIGNsaWVudC1zZXJ2ZXIgcHJvdG9jb2wgZm9yIGFj
Y2Vzc2luZyBhIGRpcmVjdG9yeSBzZXJ2aWNlLiBJdCB3YXMgaW5pdGlhbGx5
IHVzZWQgYXMgYSBmcm9udC1lbmQgdG8gWC41MDAsIGJ1dCBjYW4gYWxzbyBi
ZSB1c2VkIHdpdGggc3RhbmQtYWxvbmUgYW5kIG90aGVyIGtpbmRzIG9mIGRp
cmVjdG9yeSBzZXJ2ZXJzLgoKNAAAaHR0cDovL3d3dy5jcml0aWNhbC1hbmds
ZS5jb20vbGRhcHdvcmxkL2xkYXBmYXEuaHRtbBcAAEZpcmV3YWxsIENvbnNp
ZGVyYXRpb25zJgAAaHR0cDovL3d3dzMuaW5ub3NvZnQuY29tL2Rpci9saXBu
Lmh0bWwqAABNYWlsIGZyb20gVmlja2kgU21pdGggPHZpY2tpc0B0aGF3dGUu
Y29tPiBiAABNYWlsIGZyb20gOiBNaWNoYWVsIFN0cvZkZXIgPG1pY2hhZWwu
c3Ryb2VkZXJAaW5rYS5kZT4gYXMgcG9zdGVkIG9uIG9wZW5sZGFwLWdlbmVy
YWxAT3BlbkxEQVAub3JnIKcAAExEQVAgaXMsIGxpa2UgWC41MDAsIGJvdGgg
YW4gaW5mb3JtYXRpb24gbW9kZWwgYW5kIGEgcHJvdG9jb2wgZm9yIHF1ZXJ5
aW5nIGFuZCBtYW5pcHVsYXRpbmcgaXQuIExEQVAncyBvdmVyYWxsIGRhdGEg
YW5kIG5hbWVzYXBjZSBtb2RlbCBpcyBlc3NlbnRpYWxseSB0aGF0IG9mIFgu
NTAwLiAKLgAAaHR0cDovL3d3dy5raW5nc21vdW50YWluLmNvbS9sZGFwUm9h
ZG1hcC5zaHRtbBAAAEludGVyb3BlcmFiaWxpdHkrAABodHRwOi8vd3d3LmVl
bWEub3JnL3VuZGVyc3RhbmRpbmdfbGRhcC5odG1sDAAAQ29tcGF0aWJsaXR5
VwAAVGhlIEhUVFAgU2VydmVyIGFsbG93cyBhY2Nlc3MgdG8gTERBUCBpbmZv
cm1hdGlvbiB0aHJvdWdoIHRoZSB1c2Ugb2YgYSBwbHVnLWluIG9yIEFQSS4g
SgAAaHR0cDovL3d3dy00LmlibS5jb20vc29mdHdhcmUvd2Vic2VydmVycy9o
dHRwc2VydmVycy9kb2MvdjUyL2ljc3dnMDE0Lmh0bWwqAABodHRwOi8vd3d3
LmFzNDAwLmlibS5jb20vbGRhcC9sZGFwc29sbi5odG1LAABodHRwOi8vd3d3
LTQuaWJtLmNvbS9zb2Z0d2FyZS93ZWJzZXJ2ZXJzL2h0dHBzZXJ2ZXJzL2Rv
Yy92NTIvaWNzd2cwMTQuaHRtbAo6AABodHRwOi8vaG9tZS5uZXRzY2FwZS5j
b20vZGlyZWN0b3J5c2VjdXJpdHkvd2hpdGVwYXBlci5odG1sNQAAaHR0cDov
L3d3dy5pbWMub3JnL2lldGYtcGtpeC9vbGQtYXJjaGl2ZS05Ny8wNTg1Lmh0
bWwmAQBJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJl
IE9wZXJhdGlvbmFsIFByb3RvY29scyAtIExEQVB2MiAKVGhpcyBzcGVjaWZp
Y2F0aW9uIGFkZHJlc3MgcmVxdWlyZW1lbnRzIHRvIHByb3ZpZGUgYWNjZXNz
IHRvIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgcmVwb3NpdG9yaWVzIGZv
ciByZXRyaWV2aW5nIGFuZCBtYW5hZ2luZyBQS0kgaW5mb3JtYXRpb24uIEl0
IGlzIGJhc2Vkb24gdGhlIExpZ2h0d2VpZ2h0IERpcmVjdG9yeSBBY2NlcyBQ
cm90b2NvbCAoTERBUCkgdjIgKFJGQyAxNzc3KS5HAABodHRwOi8vd3d3LmZy
ZWVuaWMubmV0L2RyYWZ0cy9kcmFmdHMtcy10L2RyYWZ0LXNha3VyYWktcGtp
eC1pY2FwLTAwLnR4dDoAAGh0dHA6Ly93d3cuZmlzLnVuaXByLml0L2xjYS90
dXRvcmlhbC9zZWN1ZGUvaHRtL2FmbGRhcC5odG0fAABOZXRzY2FwZSBEaXJl
Y3RvcnkgU2VydmVyIDMuMCAgFgAATWljcm9zb2Z0IEV4Y2hhbmdlIDUuMA0A
AExEQVAgb3ZlciBTU0yEAABQdWJsaXNoZXMgY2VydGlmaWNhdGVzIGFuZCBj
ZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3RzIChDUkxzKSB0byBhbnkgTERB
UC1jb21wbGlhbnQgZGlyZWN0b3J5IG92ZXIgTERBUCBhbmQgSFRUUC9IVFRQ
UyBjb25uZWN0aW9ucy5DAABwdWJsaXNoaW5nIENSTHMgaW4gdGhlIExEQVAg
ZGlyZWN0b3J5IGFuZCByZXRyaWV2aW5nIENSTHMgb3ZlciBIVFRQSAAAaHR0
cDovL2hvbWUubmV0c2NhcGUuY29tL2VuZy9zZXJ2ZXIvY21zLzQxL2FkbV9n
aWRlL2xkYXBfY3JsLmh0bSMxMDAyNjU1DgAAQmVsU2lnbiBOVi9TQSAfAABo
dHRwOi8vd3d3LndoYXRpcy5jb20vaHR0cHMuaHRtRQAAaHR0cDovL2RldmVs
b3Blci5uZXRzY2FwZS5jb20vdmlld3NvdXJjZS9sZGFwX21vZGVscy9sZGFw
X21vZGVscy5odG1sQAAAaHR0cDovL3d3dy5qcC5uZXRzY2FwZS5jb20vY2Vy
dGlmaWNhdGUvdjEuMC9ldmFsZ3VpZGUvaW5kZXguaHRtbEUAAE1pbmltdW0g
SW50ZXJvcGVyYWJpbGl0eSBTcGVjaWZpY2F0aW9uIGZvciBQS0kgQ29tcG9u
ZW50cywgVmVyc2lvbiAxCvEAAFlvdSBkb24ndCBoYXZlIHRvIHNlY3VyZSB0
aGUgdHJhbnNwb3J0IG9mIENSTHMgd2l0aCBlLmcuIFNTTGJlY2F1c2UgdGhl
IENSTAoxLiBjb250YWlucyBwdWJsaWMgZGF0YSAoc2VyaWFsIG51bWJlcnMg
b2YgcmV2b2tlZCBjZXJ0cykuCjIuIGlzIGFsc28gYSBjZXJ0aWZpY2F0ZSBp
c3N1ZWQgYnkgdGhlIENBID0+IG5vbiByZXB1ZGlhdGlvbiBpcyBhbHJlYWR5
CmdhcmFudGVlZCBieSB0aGUgQ0EncyBzaWduYXR1cmUuCgo7AABodHRwOi8v
d3d3LmNoZWNrcG9pbnQuY28uanAvcHJvZHVjdHMvdGVjaG5vbG9neS9pbmRl
eC5odG1sCisAAE1haWwgZnJvbSBWaWNraSBTbWl0aCA8dmlja2lzQHRoYXd0
ZS5jb20+IApMAABMREFQIG92ZXIgU1NMIGFuZCBYLjUwMCBmb3IgRGlyZWN0
b3J5IGFjY2VzcywgdXNpbmcgc3RhbmRhcmQgQVNOLjEgZW5jb2RpbmcKUgAA
TERBUCBhbmQgU1NMIGFyZSB1c2VkIGFzIERpcmVjdG9yeSBhY2Nlc3MgYW5k
IHVuZGVybHlpbmcgc2VjdXJlIHNlc3Npb24gcHJvdG9jb2xzChEAAE5vIExE
QVAgb3ZlciBTU0wKhQAAUHVibGlzaGVzIGNlcnRpZmljYXRlcyBhbmQgY2Vy
dGlmaWNhdGUgcmV2b2NhdGlvbiBsaXN0cyAoQ1JMcykgdG8gYW55IExEQVAt
Y29tcGxpYW50IGRpcmVjdG9yeSBvdmVyIExEQVAgYW5kIEhUVFAvSFRUUFMg
Y29ubmVjdGlvbnMuCk4AAGh0dHA6Ly9jZ2kuanAubmV0c2NhcGUuY29tL3By
b2R1Y3RzL3NlY3VyaXR5L3Jlc291cmNlcy9ldmFsZ3VpZGUvY29tcGFyZS5o
dG1sCv8AAFRoZSBMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzIFByb3Rv
Y29sIChMREFQKSBpcyBhIHByb3RvY29sIGZvciBhY2Nlc3Npbmcgb25saW5l
IGRpcmVjdG9yeSBzZXJ2aWNlcy4gSXQgcnVucyBkaXJlY3RseSBvdmVyIFRD
UCwgYW5kIGNhbiBiZSB1c2VkIHRvIGFjY2VzcyBhIHN0YW5kYWxvbmUgTERB
UCBkaXJlY3Rvcnkgc2VydmljZSBvciB0byBhY2Nlc3MgYSBkaXJlY3Rvcnkg
c2VydmljZSB0aGF0IGlzIGJhY2stZW5kZWQgYnkgWC41MDAuCv4AAEludGVy
bmV0IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgT3BlcmF0aW9u
YWwgUHJvdG9jb2xzOiBGVFAgYW5kIEhUVFAgOgpUaGlzIHNwZWNpZmljYXRp
b24gY292ZXJzIHRoZSBjb252ZW50aW9uIHMgZm9yIHVzaW5nIEZpbGUgVHJh
bnNlciBQcm90b2NvbCAoRlRQKSBhbmQgSHlwZXJ0ZXh0IFRyYW5zZmVyIFBy
b3RvY29sIChIVFRQKSB0byBvYnRhaW4gY2VydGlmaWNhdGVzIGFuZCBDUkxz
IGZyb20gUEtJIHJlcG9zaXRvcmllcwoKPgEAV0VCIGJhc2VkIENlcnRpZmlj
YXRlIEFjY2VzcyBQcm90b2NvbC0tIFdlYkNBUC8xLjAgClRoaXMgc3BlY2lm
aWNhdGlvbiBkZWZpbmVzIGEgc2V0IG9mIG1ldGhvZHMsIGhlYWRlcnMsIGFu
ZCBjb250ZW50LXR5cGVzIGZvciBIVFRQLzEuMSB0byBwdWJsaXNoLCByZXRy
aWV2ZSBYLjUwOSBjZXJ0aWZpY2F0ZXMgYW5kIENlcnRpZmljYXRlIFJldm9j
YXRpb24gTGlzdHMuIFRoaXMgcHJvdG9jb2wgYWxzbyBmYWNpbGl0YXRlcyBk
ZXRlcm1pbmluZyBjdXJyZW50IHN0YXR1cyBvZiBhIGRpZ2l0YWwgY2VydGlm
aWNhdGUgd2l0aG91dCB0aGUgdXNlIG9mIENSTHMK1gAASFRUUFMgKFNlY3Vy
ZSBIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wpIGlzIGEgV2ViIHByb3Rv
Y29sIGRldmVsb3BlZCBieSBOZXRzY2FwZSBhbmQgYnVpbHQgaW50byBpdHMg
YnJvd3NlciB0aGF0IGVuY3J5cHRzIGFuZCBkZWNyeXB0cyB1c2VyIHBhZ2Ug
cmVxdWVzdHMgYXMgd2VsbCBhcyB0aGUgcGFnZXMgdGhhdCBhcmUgcmV0dXJu
ZWQgYnkgdGhlIFdlYiBzZXJ2ZXIuCkEBAEhvd2V2ZXIsIERpcmVjdG9yeSBT
ZXJ2aWNlcyBhcmUgbm90IGF2YWlsYWJsZSBpbgptYW55IHBhcnRzIG9mIHRo
ZSBJbnRlcm5ldCB0b2RheSwgYW5kIHRoZSBIeXBlcnRleHQgVHJhbnNmZXIg
UHJvdG9jb2wKKEhUVFApLCBkZWZpbmVkIGluIFJGQyAyMDY4LCAgb2ZmZXJz
IGFuIGFsdGVybmF0ZSBtZXRob2QgZm9yCmNlcnRpZmljYXRlIGFuZCBDUkwg
ZGlzdHJpYnV0aW9uLgouLi4KSFRUUCBpcyBhbiBhdHRyYWN0aXZlIGFsdGVy
bmF0aXZlIHRvIERpcjwAdQkAZWN0b3J5CmFjY2VzcyBwcm90b2NvbHMgZm9y
IGNlcnRpZmljYXRlIGFuZCBDUkwgZGlzdHJpYnV0aW9uLgoKEAAARGVmaW5p
dGlvbi9Vc2FnZTQAAGh0dHA6Ly9jc3JjLm5pc3QuZ292L3BraS90d2cvcGFw
ZXJzL2hhbGx1bS1iYWtlci5odG0yAABTdXBwb3J0ZWQgYnkgRmlyZXdhbGwt
MSAoQ2hlY2tQb2ludCBTb2Z0d2FyZSBMdGQpIFYBAFRoZSBOZXRzY2FwZSBE
aXJlY3RvcnkgU29mdHdhcmUgRGV2ZWxvcG1lbnQgS2l0IGluY2x1ZGVzIHV0
aWxpdHkgYW5kIGRhdGEtYWNjZXNzIFNES3MgdG8gZmFjaWxpdGF0ZSBjb21t
dW5pY2F0aW9uIHdpdGggdGhlIExEQVAtYmFzZWQgZGlyZWN0b3JpZXMgYW5k
IGFkbWluaXN0cmF0aW9uIHNlcnZlcnMgZm9yIG1hbmFnaW5nIHNlcnZlciBj
b25maWd1cmF0aW9uIGluZm9ybWF0aW9uLiBUaGVzZSBpbmNsdWRlIExEQVAg
Y2xpZW50IGFuZCBTREtzIGNyb3NzLXBsYXRmb3JtIGluc3RhbGxhdGlvbiBI
VFRQIGNvbm5lY3Rpb24gbWFuYWdlbWVudCBhbmQgQ0dJIHNlcnZpY2UgcmVx
dWVzdCBBUElzIAoKCvoCAFRoZSBoYW5kbGluZyBvZiB0aGUgWC41MDkgYXR0
cmlidXRlICJ1c2VyQ2VydGlmaWNhdGUiIGlzIGJhc2VkIHVwb24gYSBzdHJp
bmcgZm9ybWF0LCBhbmQgWC41MDAgKDg4KSB2ZXJzaW9uIDEgY2VydGlmaWNh
dGVzLiBIb3dldmVyLCB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHdvcmsgd2l0
aCB0aGUgWC41MDAgKDkzKSB2ZXJzaW9uIDMgY2VydGlmaWNhdGVzIHdoaWNo
IGFyZSB0aGUgYmFzaXMgb2YgbW9zdCBzZWN1cml0eSBzeXN0ZW1zIGxpa2Ug
RW50cnVzdCwgYXMgdGhlIHN0cmluZyBlbmNvZGluZyBkb2VzIG5vdCBoYXZl
IHNwZWNpZmljIGZpZWxkcyBmb3IgdGhlIG5ldyBwcm90b2NvbCBlbGVtZW50
cy4gVGhpcyBtZWFucyB0aGVzZSBuZXcgc2VjdXJpdHkgZmllbGRzIGRvIG5v
dCBnZXQgY2FycmllZCB3aXRoaW4gdGhlIExEQVAgcHJvdG9jb2wsIGFuZCBj
b25zZXF1ZW50bHkgdGhlIGZ1bGwgdmVyc2lvbiAzIGNlcnRpZmljYXRlIGNh
bm5vdCBiZSByZWJ1aWx0IGluIHRoZSBjbGllbnQKTERBUCB2MyByZXZlcnRz
IHRvIGEgYmluYXJ5IGVuY29kaW5nIGZvciB1c2VyQ2VydGlmaWNhdGUgYXR0
cmlidXRlcy4gVGhpcyBtZWFucyB0aGUgY2VydGlmaWNhdGUgaXMgZXhjaGFu
Z2VkIGluIGl0cyByYXcgQVNOLjEgZm9ybSwgcmF0aGVyIHRoYW4gdXNpbmcg
YSBzdHJpbmcgZW5jb2RpbmcuIENvbnNlcXVlbnRseSB0aGUgb3JpZ2luYWws
IHVubW9kaWZpZWQgY2VydGlmaWNhdGUgaXMgY2FycmllZCB3aXRoaW4gdGhl
IHByb3RvY29sLiAKCq0CAFRoZSBNSVNQQyBhc3N1bWVzIHRoYXQgY2VydGlm
aWNhdGVzIGFuZCBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3RzIChDUkxz
KSB3aWxsIGJlIGF2YWlsYWJsZSBpbiBhIHJlcG9zaXRvcnkgZm9yIHJldHJp
ZXZhbCB3aXRob3V0IGF1dGhlbnRpY2F0aW9uLiAgTUlTUEMgY2xpZW50cyB3
aWxsIHBlcmZvcm0gcGF0aCB2YWxpZGF0aW9uIGJ5IG9idGFpbmluZyB0aGUg
bmVjZXNzYXJ5IGNlcnRpZmljYXRlcyBhbmQgQ1JMcyBmcm9tIHRoZSBhcHBy
b3ByaWF0ZSByZXBvc2l0b3JpZXMuICBUaGUgcmVwb3NpdG9yeSBtYXkgYmUg
YW4gWC41MDAgZGlyZWN0b3J5IG9yIHNvbWUgb3RoZXIgdHlwZSBhY2Nlc3Np
YmxlIGJ5IHVzaW5nIFVuaXZlcnNhbCBSZXNvdXJjZSBJZGVudGlmaWVyIChV
UkkpIG5vdGF0aW9uLiAgUmVwb3NpdG9yaWVzIGFyZSBleHBlY3RlZCB0byBz
dXBwb3J0IHRoZSBMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzIFByb3Rv
Y29sIChMREFQKSBbUkZDIDE3NzddLCB0aGVyZWZvcmUgY29tcGxpYW50IHBy
b2R1Y3RzIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IHRoaXMgcHJvdG9jb2wu
ClRoZXNlIHJlcG9zaXRvcmllcyBuZWVkIG5vdCBiZSBsaW5rZWQgdG9nZXRo
ZXIgYW5kIG90aGVyIHByb3RvY29scyBtYXkgYmUgdXNlZCB0byByZXRyaWV2
ZSBjZXJ0aWZpY2F0ZXMgYW5kIENSTHMuCgpAAABodHRwOi8vaG9tZS5uZXRz
Y2FwZS5jb20vZW5nL3NlcnZlci9jbXMvNDEvYWRtX2dpZGUvY3M0MF9pbnQu
aHRtJQAAaHR0cDovLzE5NS4xNzAuMTYuMzMvZDNfMS9kb2MwMDA5Lmh0bQgA
AFJvb3QgQ0FzBwAAVmVuZG9ycyUAAGh0dHA6Ly93d3cuZmFxcy5vcmcvcmZj
cy9yZmMxNzc3Lmh0bWwlAABodHRwOi8vd3d3LmZhcXMub3JnL3JmY3MvcmZj
MjU4NS5odG1s3QAATERBUCBpcyBkZWZpbmVkIGJ5IHRoZSBJbnRlcm5ldCBj
b21tdW5pdHksIGFuZCBpbiBwYXJ0aWN1bGFyIHRoZSBBU0lEIHdvcmtpbmcg
Z3JvdXAuIFRoZSBwcm90b2NvbCBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3Ig
cGFzc2luZyB0ZXh0LWJhc2VkIHF1ZXJpZXMgZnJvbSBhbiBMREFQIGNsaWVu
dCB0byBhbiBMREFQIHNlcnZlciBvdmVyIHRoZSBUQ1AvSVAgbmV0d29yayBw
cm90b2NvbAr/AFIECAAlCAAADABIti4PAAAVBwEAxhUAAK0NaACTFgAAeg5f
AJQYAAB7EGwAehoAAGEScgCEHQAAaxUAADUfAAAcFyMA2SEAAMAZAAA4JwAA
Hx8kAEkwAAAMCAAAYgAAAfOPJQAAAAUAHAIEAAAABAAAAAkEAAABAAAAvlCe
AJrFYgAAAAAAAAAAAAAAYgAAAWIACAAAAAUARgUAAAAAAAGJAAkAAAAFAIwK
AAAAAAABAAAKAAAABQBUBgAAAAAAAQAAKNCdMAUAYgcAAAAAAAEAAAwAAAAF
ACwBAAAAAAABAAANAAAABQBUBgAAtwBAAQAADgAAAAUAKgMAAAAAAAEAAA8A
AAAFAHAIAAAAAAABAAAQAAAABQBiBwAAYgAAAQAAAAAAAGF6cDC2UJ4ABAAA
AJLFYgAEAAAAAQAAAAQAAACSxWIAtlCeAAQAAAAAAQAAFAAAAAUALAEAAGIA
AAFiABUAAAAFAOAQAABiAAABAgABAAAAeOhiAAAAAADAUJ4AhPZTMEDFYgB0
AAAAAAAAAAIAxzAAAMUwAAAgAAABbgAZAAAABQDEDgAAAADhPG0wDgDHMNEA
AACCxWIA/AAAAAkAAADNFQQwAADFMOyjxzDRAAAAgsViAP0AAACCxWIAhMdi
AOzqAjCCxWIAwFCeAAAAAACEx2IAdAAAAAAAAACOjw8wAAAAAIDFYgAHAAAA
/////1QAQQBCAEwARQBfADQANwBlAHIAYwBlAG4AdAAAAAAAAAAwAF0AAAB9
pfi/AAgAAIQ4QAAAAAAAAAgAAAAAAADfAwAAAQAAAEhKngABAAAAFMdiAAAA
AAAEAAAAAQAAACDvnTAAAAAAXACHABDHYgABAAAA2RAAMJZqVDBScFQwwsgQ
MLUaiQBUAIcAZRAAMFQAhwC1GokAAgAAAN2IDzC1GokAVACHAAEAAAB8GokA
AAAAAAgAhwD8AYcAAAAAAAAAAADDGokAAAAAAAAAAAAAAAAAPwAAAAAAAACU
xmIAOYYPMAYAAAB8GokAKQAAAAcAAAAGAocAwsdiAMDHYgAIAIcABwAAAEAA
AADOWlQwAAAAAGUQADBwalQw7ASJAEwAAADZEAAw7ASJAHBqVDBMAAAAzlpU
MJ7HYgCkx2IAAAAAAAAAAAAAAAAAoscQMAkEAAAAAAAAAAAAACQAAADg52IA
84MPMDDHYgABAAAAw5/3v7wBc4EBAAAAZk5wMEjXnTAnTnAwcRUAMBDHYgAE
AAAASEqeAGBnngBEUe8ASEqeAGBnngCoaA8wSEqeAMRTngAIAIcAAAAAAHzH
YgAIAAAAFwAAAJzHYgB8Z54AyMdiALq/EDDAx2IACAAAAAgAAADAx2IA62wP
MBcAAAAIAAAALP+fAAgAhwBNAAAAvsNiAP////8AAKAAAAAAAFYAAAALAAAA
AAAAAP/////g52IA3QAAAAkAAAAAAAAAPAAAAJToYgBueA8wPSgKAAAACQgQ
AAAGEADTEMwHSQAAAAYAAAALAhgAAAAAAAAAAAAmAAAAeDoAAOJDAADiRQAA
DQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgAC
AAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAADgGBAAIAwQUUAAAA
FQAWABMAACZMJkYmQ1BhZ2UgJlAgb2YgJk6DAAIAAACEAAIAAABNAI4DAABI
AFAAIABMAGEAcwBlAHIASgBlAHQAIAA0ADAAMAAwACAAUwBlAHIAaQBlAHMA
IABQAFMAAAAAAAAAAAAAAAAAAAQDBNQAuAIfdwAAAgAJAJoLMwhNAAEABwBY
AgEAAQBYAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAyBkAAMASAAAB
AAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAABC+91hAFwwYKScjAAEA
AQAAAAEAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD/
/wAA//8AAP//AQD//wAA//8AAP//AAD//wEA//8BAP//AQD//wEA//8BAP//
AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9DdXN0b20gcGFn
ZSAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABYQwAAtEMAAAAAAABDdXN0b20gcGFnZSAyAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY
QwAAtEMAAAAAAABDdXN0b20gcGFnZSAzAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAA
AAAAAAAAAKEAIgAJAE0AAQABAAAAAABYAlgCAAAAAAAA4D8AAAAAAADgPwEA
VQACAAgAfQAMAAAAAADbGBoABgAAAH0ADAABAAEAJDEaAAIAAAB9AAwAAgAC
AEkfGgAGAAAAfQAMAAMAAwAkKBoABgAAAH0ADAAEAAQAJCgaAAIAAAB9AAwA
BQAAASQJGgAAAAAAAAIOAAAAAAAmAAAAAAAFAAAACAIQAAAAAAAFACwBAAAr
WwAByIMIAhAAAQAAAAUALAEAAAAAAAEAAAgCEAACAAAABQBwCAAAAAAAAWIA
CAIQAAMAAAAFAH4JAABiAAABAAAIAhAABAAAAAUALAEAAGIAAAHzjwgCEAAF
AAAABQBUBgAAYgAAAQAACAIQAAYAAAAFAFQGAABiAAABYgAIAhAABwAAAAUA
qAwAAGIAAAFiAAgCEAAIAAAABQBGBQAAAAAAAYkACAIQAAkAAAAFAIwKAAAA
AAABAAAIAhAACgAAAAUAVAYAAAAAAAEAAAgCEAALAAAABQBiBwAAAAAAAQAA
CAIQAAwAAAAFACwBAAAAAAABAAAIAhAADQAAAAUAVAYAALcAQAEAAAgCEAAO
AAAABQAqAwAAAAAAAQAACAIQAA8AAAAFAHAIAAAAAAABAAAIAhAAEAAAAAUA
YgcAAGIAAAEAAAgCEAARAAAABQBUBgAAATAAAQAACAIQABIAAAAFACwBAAAA
AAABAAAIAhAAEwAAAAUAChQAAAAAAAEAAAgCEAAUAAAABQAsAQAAYgAAAWIA
CAIQABUAAAAFAOAQAABiAAABAgAIAhAAFgAAAAUAOAQAAAAAAAEAAAgCEAAX
AAAABQAsAQAAtwAAAQAACAIQABgAAAAFAEYFAAAgAAABbgAIAhAAGQAAAAUA
xA4AAAAAAAEAAAgCEAAaAAAABQAsAQAAAAAAAQAACAIQABsAAAAFACoDAAAA
AAABAAAIAhAAHAAAAAUAKgMAAAAAAAEAAAgCEAAdAAAABQAsAQAAAAAAAWIA
CAIQAB4AAAAFACwBAABUMAABAAAIAhAAHwAAAAUAYgcAAAAAAAEAAP0ACgAA
AAAAFgAcAAAA/QAKAAAAAQAWABAAAAD9AAoAAAACABYAFgAAAP0ACgAAAAMA
FgARAAAA/QAKAAAABAAWABYAAAD9AAoAAQAAAB8ABgAAAP0ACgABAAEAIAAJ
AAAAvgAMAAEAAgAfAB8AHwAEAAECBgACAAAAGAD9AAoAAgABABkALgAAAP0A
CgACAAIAGQBTAAAA/QAKAAIAAwAZAEUAAAD9AAoAAgAEABkAVAAAAL4ADAAD
AAAAGAAZABgAAgD9AAoAAwADABkARgAAAP0ACgADAAQAGQAvAAAA/QAKAAQA
AAAfAEkAAAC+AA4ABAABACAAHwAfAB8ABAABAgYABQAAABcA/QAKAAUAAQAb
AEQAAAD9AAoABQACABsAFwAAAP0ACgAFAAMAGwBHAAAA/QAKAAUABAAbADgA
AAABAgYABgAAABsA/QAKAAYAAQAbAB0AAAD9AAoABgACABsAHgAAAP0ACgAG
AAMAGwAoAAAA/QAKAAYABAAbACkAAAABAgYABwAAABsA/QAKAAcAAQAbACMA
AAD9AAoABwACABsAJAAAAP0ACgAHAAMAGwBIAAAA/QAKAAcABAAbAC0AAAAB
AgYACAAAABsA/QAKAAgAAQAbAFUAAAD9AAoACAACABsAJgAAAL4ACgAIAAMA
GwAbAAQAAQIGAAkAAAAbAP0ACgAJAAEAGwAAAAAA/QAKAAkAAgAbACoAAAC+
AAoACQADABsAGwAEAAECBgAKAAAAGwD9AAoACgABABsAAQAAAP0ACgAKAAIA
GwAqAAAAvgAKAAoAAwAbABsABAABAgYACwAAABsA/QAKAAsAAQAbAAIAAAD9
AAoACwACABsAOgAAAL4ACgALAAMAGwAbAAQA/QAKAAwAAAAfAAcAAAD9AAoA
DAABACAACgAAAL4ADAAMAAIAHwAfAB8ABAABAgYADQAAABcA/QAKAA0AAQAb
ABUAAAD9AAoADQACABsAMAAAAL4ACgANAAMAGwAbAAQAAQIGAA4AAAAbAP0A
CgAOAAEAGwAaAAAA/QAKAA4AAgAbABsAAAC+AAoADgADABsAGwAEAAECBgAP
AAAAGwD9AAoADwABABsAPAAAAP0ACgAPAAIAGwAiAAAAvgAKAA8AAwAbABsA
BAABAgYAEAAAABsA/QAKABAAAQAbAAMAAAD9AAoAEAACABsAJgAAAL4ACgAQ
AAMAGwAbAAQAAQIGABEAAAAbAP0ACgARAAEAGwAEAAAA/QAKABEAAgAbADkA
AAC+AAoAEQADABsAGwAEAP0ACgASAAAAHwAlAAAA/QAKABIAAQAgAAsAAAC+
AAwAEgACAB8AHwAfAAQAAQIGABMAAAAXAP0ACgATAAEAGwAIAAAA/QAKABMA
AgAbAEoAAAC+AAoAEwADABsAGwAEAP0ACgAUAAAAHwAnAAAAvgAOABQAAQAf
AB8AHwAfAAQAAQIGABUAAAAXAP0ACgAVAAEAGwBNAAAA/QAKABUAAgAbACYA
AAD9AAoAFQADABwATAAAAP0ACgAVAAQAGwAsAAAAvgAMABYAAAAXABsAGwAC
AP0ACgAWAAMAGwAoAAAA/QAKABYABAAbACsAAAD9AAoAFwAAAB8AGAAAAP0A
CgAXAAEAHwAMAAAAvgAMABcAAgAfAB8AHwAEAAECBgAYAAAAFwD9AAoAGAAB
ABsABQAAAP0ACgAYAAIAGwAZAAAAvgAKABgAAwAbABsABAABAgYAGQAAABcA
/QAKABkAAQAbAE4AAAD9AAoAGQACABsAOwAAAL4ACgAZAAMAGwAbAAQA/QAK
ABoAAAAfAB8AAAD9AAoAGgABACAADQAAAL4ADAAaAAIAHwAfAB8ABAABAgYA
GwAAABcA/QAKABsAAQAbAEsAAAD9AAoAGwACABsAIAAAAP0ACgAbAAMAGwBL
AAAA/QAKABsABAAbAD0AAAC+AAoAHAAAABcAGwABAP0ACgAcAAIAGwA9AAAA
vgAKABwAAwAbABsABAD9AAoAHQAAAB8AEgAAAP0ACgAdAAEAHwAPAAAAvgAM
AB0AAgAfAB8AHwAEAP0ACgAeAAAAHgBRAAAAvgAOAB4AAQAbABwAGwAbAAQA
/QAKAB8AAAAdABMAAAD9AAoAHwABABsADgAAAP0ACgAfAAIAGwA+AAAA/QAK
AB8AAwAbABQAAAD9AAoAHwAEABsAIQAAANcARADyCAAAbAJGACwAQgAsACAA
QgBCAEIANAA0ADQANAAsADQANAA0ADQANAAsADQAIABCACwALAA0ADQALABC
ACoALAAgAAgCEAAgAAAABQAqAwAAK1sAAciDCAIQACEAAAAFACoDAAAAAAAB
AAAIAhAAIgAAAAUALAEAAAAAAAFiAAgCEAAjAAAABQAqAwAAYgAAAQAACAIQ
ACQAAAAFADgEAABiAAAB848IAhAAJQAAAAUAHAIAAGIAAAEAAP0ACgAgAAAA
HQA3AAAA/QAKACAAAQAbAD8AAAD9AAoAIAACABsAUAAAAL4ACgAgAAMAGwAb
AAQAAQIGACEAAAAdAP0ACgAhAAEAGwBAAAAA/QAKACEAAgAbAFAAAAC+AAoA
IQADABsAGwAEAP0ACgAiAAAAHgBSAAAAvgAOACIAAQAbABsAGwAbAAQA/QAK
ACMAAAAdADEAAAD9AAoAIwABABsAMwAAAP0ACgAjAAIAGwBDAAAA/QAKACMA
AwAbADUAAAD9AAoAIwAEABsANgAAAAECBgAkAAAAHQD9AAoAJAABABsAQgAA
AP0ACgAkAAIAGwBPAAAA/QAKACQAAwAcADQAAAD9AAoAJAAEABsATwAAAP0A
CgAlAAAAHQAyAAAA/QAKACUAAQAbAEEAAAC+AAwAJQACABsAGwAbAAQA1wAQ
ALgBAABkADgANAAgAEYAQgA+AhIAtgYUAAAAQAAAAAAAAAAAAAAAoAAEAAMA
BAAdAA8AAxcAAAAAAAEAFwAXAAAA5QACAAAACgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+
/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA
AADoAAAACAAAAAEAAABIAAAAAgAAAFAAAAAEAAAAaAAAAAgAAACMAAAAEgAA
ALAAAAALAAAAyAAAAAwAAADUAAAAEwAAAOAAAAACAAAA5AQAAB4AAAAOAAAA
SG90bWFpbCBJbmJveAB4AB4AAAAcAAAAUmlja3kgTGkgKE1hcmtldCBSZWFk
aW5lc3MpAB4AAAAcAAAAUmlja3kgTGkgKE1hcmtldCBSZWFkaW5lc3MpAB4A
AAAQAAAATWljcm9zb2Z0IEV4Y2VsAEAAAACAmnm75j+/AUAAAACAyy/IsT+/
AQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E
AAAABdXN1ZwuGxCTlwgAKyz5rgwBAADIAAAACQAAAAEAAABQAAAADwAAAFgA
AAAXAAAAaAAAAAsAAABwAAAAEAAAAHgAAAATAAAAgAAAABYAAACIAAAADQAA
AJAAAAAMAAAApQAAAAIAAADkBAAAHgAAAAUAAABzZWhrAABzAAMAAABqEAgA
CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAkAAABG
aW5kaW5ncwAMEAAAAgAAAB4AAAALAAAAV29ya3NoZWV0cwADAAAAAQAAAJgA
AAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJ
RF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADEANwA0AEQAOQAxADIAMAAtAEEA
QgBFAEIALQAxADEARAAzAC0AQgA1ADEAMgAtADAAMAAxADAANABCADAANQA4
AEMAMwBBAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAA
DAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAX
AAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA
AAAjAAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAD+////LQAA
AC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAAP7////9/////v//////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAA////
/wEAAACK1GIAAAAAAAEAAAD/////AQAAAIbUYgAAAAAAAQAAABYABQH/////
/////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAEAAAD/////AQAAAAQAYgD+
////AAAAAP////9XAG8AcgBrAGIAbwBvAGsAAAD//wEAAAAFAGIAAAAAAAEA
AAD/////AQAAAA0AYgAAAAAAAQAAAP////8BAAAAEgACAf//////////////
/wEAAACS1GIAAAAAAAEAAAD/////AQAAAMzUYgAAAAAAAQAAAAAAAAAxRgAA
a81iAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA
AAAAAQAAAP////8BAAAAN8piAAAAAAAoAAIBAQAAAAMAAAD/////AAAAAAEA
AAD/////AQAAAH7UYgAAAAAAAQAAAP////8BAAAAJAAAAAAQAAABAAAABQBE
AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAAAkDwAAAAAAADgAAgH///////////////8AAAAA////ADUAAAAA
AAAANQAAAAAAAAAAAAAAAAAAAAQAAAAsAAAAABAAAAAAAAA=

------=_NextPart_000_4918659b_a2cb209$754862cf--



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA14425 for <[e-mail]>; Mon, 6 Dec 1999 04:48:20 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA26539; Mon, 6 Dec 1999 13:46:04 +0100
Received: by HYDRA with Microsoft Mail id <01BF3FF0.157E6890@HYDRA>; Mon, 6 Dec 1999 13:44:57 +0100
Message-ID: <01BF3FF0.157E6890@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "Ietf-Pkix (E-mail)" <[e-mail]>, SEIS-listan <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>
Subject: Re: QC's - for human eyes only?
Date: Mon, 6 Dec 1999 13:44:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis

>Stephen gave the right answer. We should not re-open that
>discussion. We are not "shutting the door on options that technology
>will soon make available". The Version 3 of X.509 certificates
>allows to define other extensions. The one you are requesting could
>be defined later, when it becomes appropriate.

It was appropriate already a year ago.  I don't think it has gotten less interesting.
The problem was (and probably is) that information in certificates cause
self-made "politicians" to destroy a debate that really only concerns a "file-format".

If you look on ID2's home-page you can see that they brag about being number
one in PKI and that they DO combine PKI and finger-prints.  So it is HERE TODAY!

And regarding file-sizes: Extremely depending on the implementation environment
(global Internet consumer, vs corporate intranets) so it is inappropriate of PKIX to decide
here and now what is suitable.

I.e. QC does not and should not recommend any particular solution.  It
should offer a "smorgasbord" of generally useful options in a standardized way.

The suggested items are known and using the MIME-type of definition that
I proposed earlier, they can proliferate on their own merits and pace .

How, when and why certificate information is to be used can surely be discussed forever,
but if we need consensus on that part as well, we can simply terminate the whole thing.

BTW, we just seem to have finally gotten the unique identifier concept through the door
although there were originally many, many opponents to such things...

Anders




Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA10478 for <[e-mail]>; Mon, 6 Dec 1999 02:49:57 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA57347 for <[e-mail]>; Mon, 6 Dec 1999 11:47:42 +0100
Received: by HYDRA with Microsoft Mail id <01BF3FDF.8C5EC060@HYDRA>; Mon, 6 Dec 1999 11:46:35 +0100
Message-ID: <01BF3FDF.8C5EC060@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: QC's - for human eyes only?
Date: Mon, 6 Dec 1999 11:46:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA10479

Just some more info for those who still believe finger-prints is marginal technology

----------
From:  Calum Bunney [SMTP:[e-mail]]
Sent:  Monday, December 06, 1999 10:47
To:  'SEIS-List'
Subject:  SEIS: Re: QC's - for human eyes only?

--- Message on the SEIS mailing list ([e-mail])
Can I add to the comments below?
The biometric industry community is moving towards some sort of standardisation in this area, albeit in a piecemeal way.
The National Security Agency in the USA has long been investigating the use of X509 v3 certification for storage of biometric data.  The ANSI X9F4 standards working group is developing a certificate based standard for the secure and responsible management of biometric data, initially for the financial services community.  The Biometric Consortium (www.biometrics.org) is sponsoring a Biometric Common File Exchange Format to find a way of storing biometric data that can invite different biometrics (iris, finger, face etc) and different vendors' solutions to participate in a quasi-universal storage mechanism such as certificates.
There is some recognition of the overlap in biometric standardisation with certificate operation, and this is increasingly recognised as a future technical issue for the emerging biometric standard (www.bioapi.org)
There are indeed at least ten vendors with selling fingerprint technologies.  There are more than fify actual technologies on the market. Among these there are a good number with fingerprint data stored in files between 100 and 400 bytes. Is the general opinion that this is still too large for feasible verification off the certificate, without reliance on a network? I am interested to know the general view on this?
with all good wishes
Calum Bunney
International Biometric & Authentication Consulting




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10282 for <[e-mail]>; Mon, 6 Dec 1999 02:43:34 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA57334; Mon, 6 Dec 1999 11:45:44 +0100
Message-ID: <[e-mail]>
Date: Mon, 06 Dec 1999 11:45:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Ilan Shacham <[e-mail]>
CC: "Ietf-Pkix (E-mail)" <[e-mail]>, SEIS-listan <[e-mail]>
Subject: Re: QC's - for human eyes only?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ilan,

Stephen gave the right answer. We should not re-open that
discussion. We are not "shutting the door on options that technology
will soon make available". The Version 3 of X.509 certificates
allows to define other extensions. The one you are requesting could
be defined later, when it becomes appropriate.

Denis
 
> Stephen,
> Comments inline.
> 
> > Ian & Anders,
> That's Ilan... :-)
> >
> > We had this discussion a year ago, as Anders noted.  We did not
> > choose to put biometric data in certs because such data is large,
> > because its inclusion in a cert potentially exposes it to
> > unauthorized acquisition, and because it is not generally required.
> 
> All of these arguments may be true today, but will probably not be
> true tomorrow, and are certainly application specific. Therefore
> I think we should leave the option to include the biometric data
> inside the certificate, and let the application engineers make
> storage and security considerations, considering the biometry type,
> technologies involved and the specific application.
> If we are looking at the security side, I can see network access to
> biometric data as an opening to denial of service attacks.
> 
> > In general, biometric user authentication is NOT a good idea for
> > remote authentication.  Anders made a persuasive argument for
> > inclusion of a reference to such data in the case when a person will
> > evlauate a human supplied biometric.  His arguments were not
> > persuasive enough to warrant inclusion of the biometric data in the
> > cert per se, nor in more general biometric contexts.  This is not a
> > function of the quality of the biometrics involved, but a fundamental
> > issue with any biometric.
> 
> True, Biometric data has no meaning remotely, that's why I don't see
> why a in order to verify a person carrying a digital ID card I should
> need anything but the information on the card itself. I also don't
> see why, if technology permits it, I shouldn't be able to be machine
> authenticated.
> 
> > Steve
> >
> 
> My main point is that it seems that we are shutting the door on options
> that technology will soon make available. Standards we are etching here
> take a long time until they are well accepted in the market, our job is
> to look forward at the needs of the market for today and for the
> following years. We don't have to do the specifics of stuff we can't
> yet work out, but at least leave a good opening for those specifics.
> 
> Ilan


Received: from isak.online.no (isak.online.no [193.212.240.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09648 for <[e-mail]>; Mon, 6 Dec 1999 02:11:21 -0800 (PST)
From: [e-mail]
Received: from gw.telemax.no by isak.telepost.no (X.400 to RFC822 Gateway); Mon, 6 Dec 1999 11:15:26 +0100
X400-Received: by mta MHNORWAY in /c=no/admd=telemax/prmd=internet/; converted ( Undefined);  Relayed; 06 Dec 1999 11:15:23 +0100
X400-Received: by /c=no/admd=telemax/prmd=internet/; converted ( Undefined);  Relayed; 06 Dec 1999 11:15:23 +0100
X400-Received: by /c=no/admd=telemax/prmd=dep/; Relayed; 06 Dec 1999 10:13:55 Z
X400-MTS-Identifier: [/c=no/admd=telemax/prmd=dep/; 10159 99/12/06 11:13]
Content-Identifier: 10159 99/12/06
Content-Return: Prohibited
X400-Content-Type: P2-1988 ( 22 )
Conversion: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [e-mail]
X400-Recipients: non-disclosure;
Message-Id:  <"10159 99/12/06 11:13*/c=no/admd=telemax/prmd=dep/o=aad/s=de-brisis/g=katarina/"@MHS>
In-Reply-To: <01BF3FC7.68A9BF20@HYDRA>
Date: 06 Dec 1999 10:13:55 Z
cc: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: SEIS:  RE: QC's - for human eyes only?
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA09649

Hi!
I've been a "listener" on the SEIS mailing list for some time now, but as I am not a specialist 
in certificate design, I did not write to it.
However, the work you do in PKIX on QC, warrants some comment from potential "market". I 
represent a part of this market - the public sector in Norway. I've been responsible for 
establishing  naming rules for certificates for the Norwegian public sector.
I have two comments in connection with the QC-debates on unique identity and biometrics:
1. Using "serialnumber" for unique identifier seems to be a strange idea for denominating 
humans and organizations (we have unique numbers for both in Norway, but we put them in 
dnQualifier or in the O-field following the name itself); dnQualifier makes much more sense 
for a "common user" than "serialnumber" (this is more appropriate for devices)
2. Inserting biometrics in certificates is NOT a very good idea in terms of personal data 
protection - no matter how "secure" it might be made, the users won't have it (I would never 
accept this as a user - I want my biometrics on the smartcard!).
I don't know whom do you refer to when you speak about "the market", but it might be more 
complex than you seem to think.
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [e-mail]


Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08462 for <[e-mail]>; Mon, 6 Dec 1999 00:58:01 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <YJWJFVR8>; Mon, 6 Dec 1999 10:58:07 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "'Magnus Nystrom'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Internal conflict in QC profile?
Date: Mon, 6 Dec 1999 10:58:06 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Hi Magnus,
I see...
If I'm the only one who mis-read that then I guess it's ok...

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864


> -----Original Message-----
> From: Magnus Nystrom [mailto:[e-mail]]
> Sent: Monday, December 06, 1999 10:51 AM
> To: Ilan Shacham
> Cc: [e-mail]
> Subject: Re: Internal conflict in QC profile?
> 
> 
> 
> Hi Ilan,
> 
> And thanks for your feedback.
> 
> With regards to your question, please note that the paragraph 
> after the
> three choices below refers not only to them but also to all 
> the attributes
> in the list just before your 'snippet'. That is, the dnQualifier (and
> whatever attribute that functionally will replace it) is 
> already included.
> 
> Best regards,
> -- Magnus
> Magnus Nystrom		Email: [e-mail]
> RSA Laboratories
> 
> On Sun, 5 Dec 1999, Ilan Shacham wrote:
> 
> > Hi all,
> > The QC profile, in section 3.1.2 states:
> > 
> >  "  ...Of these attributes, the subject field SHALL include 
> at least one of
> >    the following:
> > 
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> > 
> >    Other attributes may be present but MUST NOT be necessary to
> >    distinguish the subject name from other subject names within the
> >    issuer domain.
> > ...
> > ...
> >    The dnQualifier attribute type SHALL, when present, be used to
> >    differentiate between names where the subject field 
> would otherwise
> >    be identical.  This qualifier has no defined semantics beyond
> >    ensuring uniqueness of subject names.  It MAY contain a number or
> >    code assigned by the CA or an identifier assigned by a 
> government or
> >    civil authority.  It is the CA's responsibility to 
> ensure that the
> >    dnQualifier is sufficient to resolve any subject name 
> collisions..."
> > 
> > It looks to me that the first of these paragraphs should be 
> changed to
> > something like:
> > 
> >    Other attributes may be present but MUST NOT be necessary to
> >    distinguish the subject name from other subject names within the
> >    issuer domain, except for the dnQualifier attribute which may be
> >    used as described below.
> 


Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA08220 for <[e-mail]>; Mon, 6 Dec 1999 00:48:52 -0800 (PST)
Received: (qmail 19835 invoked from network); 6 Dec 1999 08:51:47 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 6 Dec 1999 08:51:47 -0000
Received: (qmail 2491 invoked from network); 6 Dec 1999 08:51:46 -0000
Received: from mnystrom-lap.nordic-dhcp.dynas.se (10.129.12.111) by spirit.dynas.se with SMTP; 6 Dec 1999 08:51:46 -0000
Date: Mon, 6 Dec 1999 09:51:14 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
To: Ilan Shacham <[e-mail]>
cc: [e-mail]
Subject: Re: Internal conflict in QC profile?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Ilan,

And thanks for your feedback.

With regards to your question, please note that the paragraph after the
three choices below refers not only to them but also to all the attributes
in the list just before your 'snippet'. That is, the dnQualifier (and
whatever attribute that functionally will replace it) is already included.

Best regards,
-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories

On Sun, 5 Dec 1999, Ilan Shacham wrote:

> Hi all,
> The QC profile, in section 3.1.2 states:
> 
>  "  ...Of these attributes, the subject field SHALL include at least one of
>    the following:
> 
>       Choice   I:  commonName
>       Choice  II:  givenName
>       Choice III:  pseudonym
> 
>    Other attributes may be present but MUST NOT be necessary to
>    distinguish the subject name from other subject names within the
>    issuer domain.
> ...
> ...
>    The dnQualifier attribute type SHALL, when present, be used to
>    differentiate between names where the subject field would otherwise
>    be identical.  This qualifier has no defined semantics beyond
>    ensuring uniqueness of subject names.  It MAY contain a number or
>    code assigned by the CA or an identifier assigned by a government or
>    civil authority.  It is the CA's responsibility to ensure that the
>    dnQualifier is sufficient to resolve any subject name collisions..."
> 
> It looks to me that the first of these paragraphs should be changed to
> something like:
> 
>    Other attributes may be present but MUST NOT be necessary to
>    distinguish the subject name from other subject names within the
>    issuer domain, except for the dnQualifier attribute which may be
>    used as described below.



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA07451 for <[e-mail]>; Sun, 5 Dec 1999 23:57:20 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA33990; Mon, 6 Dec 1999 08:55:04 +0100
Received: by HYDRA with Microsoft Mail id <01BF3FC7.68A9BF20@HYDRA>; Mon, 6 Dec 1999 08:53:47 +0100
Message-ID: <01BF3FC7.68A9BF20@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>, SEIS-listan <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: QC's - for human eyes only?
Date: Mon, 6 Dec 1999 08:53:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve,

The URI biometric solution does the same thing (information-wise) as in-line biometric data, but
in a "crummy" way.  If there is any defined way to discriminate access to the URI, this
information is surely not possible to find in the QC draft.  Note that such information have
been requested by me several times.  No answer - or "implementation defined".

In-line biomterics and finger-prints are just another implementor's option.  If it is
good or bad is outside of the scope of the standard.

If someone really needs "DiameterOfRectum" [he surely must be an A** H**E :-) :-) ] and can prove
that there is an entire industry (in analogy with finger-prints) interested in this.  Why not add it?

The solution in the commercial world will be that this is solved by extensions.
Is this what you/we/all want?

Anders

----------
From:  Stephen Kent [SMTP:[e-mail]]
Sent:  Sunday, December 05, 1999 22:52
To:  Anders Rundgren
Cc:  Ietf-Pkix (E-mail); SEIS-listan
Subject:  RE: QC's - for human eyes only?

Ian & Anders,

We had this discussion a year ago, as Anders noted.  We did not 
choose to put biometric data in certs because such data is large, 
because its inclusion in a cert potentially exposes it to 
unauthorized acquisition, and because it is not generally required.

In general, biometric user authentication is NOT a good idea for 
remote authentication.  Anders made a persuasive argument for 
inclusion of a reference to such data in the case when a person will 
evlauate a human supplied biometric.  His arguments were not 
persuasive enough to warrant inclusion of the biometric data in the 
cert per se, nor in more general biometric contexts.  This is not a 
function of the quality of the biometrics involved, but a fundamental 
issue with any biometric.

Steve



Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA07197 for <[e-mail]>; Sun, 5 Dec 1999 23:43:48 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <YJWJFVP0>; Mon, 6 Dec 1999 09:43:46 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>, SEIS-listan <[e-mail]>
Subject: RE: QC's - for human eyes only?
Date: Mon, 6 Dec 1999 09:43:45 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Stephen,
Comments inline.

> Ian & Anders,
That's Ilan... :-)
> 
> We had this discussion a year ago, as Anders noted.  We did not 
> choose to put biometric data in certs because such data is large, 
> because its inclusion in a cert potentially exposes it to 
> unauthorized acquisition, and because it is not generally required.

All of these arguments may be true today, but will probably not be
true tomorrow, and are certainly application specific. Therefore
I think we should leave the option to include the biometric data
inside the certificate, and let the application engineers make
storage and security considerations, considering the biometry type,
technologies involved and the specific application.
If we are looking at the security side, I can see network access to 
biometric data as an opening to denial of service attacks.

> In general, biometric user authentication is NOT a good idea for 
> remote authentication.  Anders made a persuasive argument for 
> inclusion of a reference to such data in the case when a person will 
> evlauate a human supplied biometric.  His arguments were not 
> persuasive enough to warrant inclusion of the biometric data in the 
> cert per se, nor in more general biometric contexts.  This is not a 
> function of the quality of the biometrics involved, but a fundamental 
> issue with any biometric.

True, Biometric data has no meaning remotely, that's why I don't see
why a in order to verify a person carrying a digital ID card I should
need anything but the information on the card itself. I also don't
see why, if technology permits it, I shouldn't be able to be machine
authenticated.

> Steve
> 

My main point is that it seems that we are shutting the door on options
that technology will soon make available. Standards we are etching here
take a long time until they are well accepted in the market, our job is
to look forward at the needs of the market for today and for the 
following years. We don't have to do the specifics of stuff we can't
yet work out, but at least leave a good opening for those specifics.

Ilan


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01366 for <[e-mail]>; Sun, 5 Dec 1999 20:05:21 -0800 (PST)
Received: from [128.33.238.100] (TC100.BBN.COM [128.33.238.100]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA27934; Sun, 5 Dec 1999 23:08:01 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b4708dc15da8@[171.78.30.108]>
In-Reply-To: <01BF3F30.5F3A0040@HYDRA>
References: <01BF3F30.5F3A0040@HYDRA>
Date: Sun, 5 Dec 1999 16:51:38 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC's - for human eyes only?
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>, SEIS-listan <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ian & Anders,

We had this discussion a year ago, as Anders noted.  We did not 
choose to put biometric data in certs because such data is large, 
because its inclusion in a cert potentially exposes it to 
unauthorized acquisition, and because it is not generally required.

In general, biometric user authentication is NOT a good idea for 
remote authentication.  Anders made a persuasive argument for 
inclusion of a reference to such data in the case when a person will 
evlauate a human supplied biometric.  His arguments were not 
persuasive enough to warrant inclusion of the biometric data in the 
cert per se, nor in more general biometric contexts.  This is not a 
function of the quality of the biometrics involved, but a fundamental 
issue with any biometric.

Steve


Received: from hotmail.com (f165.law4.hotmail.com [216.33.149.165]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA14570 for <[e-mail]>; Sun, 5 Dec 1999 18:06:34 -0800 (PST)
Received: (qmail 12914 invoked by uid 0); 6 Dec 1999 02:09:00 -0000
Message-ID: <[e-mail]>
Received: from 202.84.254.4 by www.hotmail.com with HTTP; Sun, 05 Dec 1999 18:09:00 PST
X-Originating-IP: [202.84.254.4]
From: "Franklin Lee" <[e-mail]>
To: [e-mail]
Subject: Re: CRL Distribution Mechanism Evaluation and Considerations
Date: Mon, 06 Dec 1999 02:09:00 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Dear all,

Actually, I'm a student in the Mainland China having a reserach on the 
"Digital Certificate" applications and limitations --- e-commerce and 
cryptograhpy are still relatively new to our region.

Regarding the CRL distribution mechanism, I have found few topics yet there 
are of 98 versions:

a) Phillip Hallum-Baker
http://csrc.nist.gov/pki/twg/papers/hallum-baker.html

b) Mike Myers
http://csrc.nist.gov/pki/twg/twg98_6.html

Therefore, would be greatly appreciated for the comments and advice from the 
corresponding knowledge leads.

Again, thanks a lot and all comments are very welcomed.

>From: "Franklin Lee" <[e-mail]>
>To: [e-mail]
>Subject: CRL Distribution Mechanism Evaluation and Considerations
>Date: Sun, 05 Dec 1999 04:18:45 GMT
>
>Dear all,
>
>I'm interested in all experts' views on evaulating the distribution of the
>CRL(Certificate Revocation List) -
>
>LADP over SSL vs. HTTPS (HTTP over SSL)
>
>e.g,
>- what are the key considerations (e.g, performance, infrastructure) for
>choosing either protocol?
>- what are the current preferred practice as performed by the various CAs?
>(e.g. Thawte, Verisign)?
>
>
>Thanks a lot and any comments (e.g., links to any relevant docu") are
>greatly appreciated.
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA10460 for <[e-mail]>; Sun, 5 Dec 1999 13:55:57 -0800 (PST)
Received: from mega (t1o69p93.telia.com [62.20.144.93]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA25679; Sun, 5 Dec 1999 22:53:43 +0100
Message-ID: <003501bf3f73$d26904b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Ilan Shacham" <[e-mail]>, "Eric Murray" <[e-mail]>
Subject: Re: QC's - for human eyes only?
Date: Sun, 5 Dec 1999 22:55:26 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA10461

Eric,

>There's nothing preventing one from sending the biometric outside the
>certificate to be machine verified.  The hash is there to tie that into
>the cert.

The point by Ilan was that the QC draft explicitly calls for HUMAN verification

<snip>


>However putting a biometric in a certificate is like putting your Social
>Security Number and mother's maiden name in a certificate- it would
>allow anyone who receives the certificate to be able to use those
>irrevocable identifiers to impersonate you.

If you steal somebody's private keys, the inclusion of biometric data
in the certificate will on the contrary REDUCE the possibilities to
impersonate the true owner.  Privacy is another thing.


Anders



Received: from slack.lne.com ([e-mail] [209.157.136.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08406 for <[e-mail]>; Sun, 5 Dec 1999 09:01:06 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id JAA01673; Sun, 5 Dec 1999 09:00:39 -0800
Message-ID: <[e-mail]>
Date: Sun, 5 Dec 1999 09:00:39 -0800
From: Eric Murray <[e-mail]>
To: Ilan Shacham <[e-mail]>
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: Re: QC's - for human eyes only?
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76
In-Reply-To: <[e-mail]>; from Ilan Shacham on Sun, Dec 05, 1999 at 02:39:13PM +0200

On Sun, Dec 05, 1999 at 02:39:13PM +0200, Ilan Shacham wrote:
> Hi all,
> Section 3.2.4 of the QC profile, which describes the biometricInfo 
> extension states:
> 
> "   ...This extension SHALL only be used to store a hash of biometric
>    information suitable for human verification, i.e. where decision
>    whether this information is an accurate representation of the subject
>    is performed by a physical person. This implies a usage where the
>    biometric information is represented by for example a graphical
>    image, displayed to the relying party, which MAY be used by the
>    relying party to enhance identification of the subject..."
> 
> I don't see why we should limit ourselves in such a way, and not allow
> for machine verification of biometric data (such as finger-prints, etc.).
> It seems to me that even if today biometrics aren't advanced enough,
> we should not limit ourselves towards the future.

There's nothing preventing one from sending the biometric outside the
certificate to be machine verified.  The hash is there to tie that into
the cert.

> Another shortcoming of the biometricInfo extension, is that it does
> not allow for the actual biometric data to be included, but instead
> mandates the data to be accessed through a URI. This approach
> may be relevent today, when biometric data is large, and memory
> on smartcards is limited, but surely advances in the future would
> allow the actual biometric data to be put in the certificate, it would
> be a shame to create a new extension for ActualBiometricInfo...

Actually, that would make sense.  Since there are a number of
different ways of representing biometric data, there would need to
be some indication of which method (and which biometric) was used. 
A seperate extension could describe that in the OID, rather than
needing to put that data in the extension itself.

It's possible to shrink some biometric information down small enough to
get it on a smartcard with no problem-  I have done some work in the
past which allowed me to accurately represent a fingerprint in at little
as 100 bytes... if both biometric readers use the same algorithm for
finding minutae and matching them, all you need to send are the minutae
points themselves.

However putting a biometric in a certificate is like putting your Social
Security Number and mother's maiden name in a certificate- it would
allow anyone who receives the certificate to be able to use those
irrevocable identifiers to impersonate you.  So biometric data should
only be sent encrypted in a session key, if it's ever sent at all.


-- 
 Eric Murray www.lne.com/~ericm  ericm at the site lne.com  PGP keyid:E03F65E5


Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA06868 for <[e-mail]>; Sun, 5 Dec 1999 05:56:03 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id OAA41417; Sun, 5 Dec 1999 14:53:47 +0100
Received: by HYDRA with Microsoft Mail id <01BF3F30.5F3A0040@HYDRA>; Sun, 5 Dec 1999 14:52:37 +0100
Message-ID: <01BF3F30.5F3A0040@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>, "'Ilan Shacham'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, "'Magnus Nystrom'" <[e-mail]>
Subject: RE: QC's - for human eyes only?
Date: Sun, 5 Dec 1999 14:52:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ilan,
I agree 100% to what you are saying and exactly the points given by you 
I put in this list about a year ago.

I.e. Finger-print support, in-line biometric data option, and no mentioning of
how the verification is actually performed.

The reason for not putting in finger-print information was said to be due to no
request for such data [I don't count apparently - now we are two :-)] and that finger-print techniques are
not yet established.  My reaction to this was: Who have been asked?  The PKIX-list is
maybe not the only place to look in.  And there are at least 10 companies working 
and shipping biometric finger-print sensors.  Several "standard" formats exist today.

Regarding the in-line data of biometric data, the IETF chair has told me that current computer
technology is not capable of processing certs of lets say 10K size.
My reaction to this is: What systems do really have such limitations?  Must we
create a standard for the next Millennium based on Windows 3.1-type of platforms?
The only sensible thing would be to add a biometric data-type that contains a MIME-type
identifying the content-type and a blob holding the actual data.  The in-line feature has
huge advantages over the current definition as you reduce network overhead, remain
compatible with current authentication and signing schemes, and get a nice persistent
container for all user data.

You are absolutely right on the networked certificate solution as well.  Even a part of PKCS #15 I think.

I.e. there are no TECHNICAL problems whatsoever with adding your suggested features!

Regards
Anders Rundgren
[slightly flaming] Senior Internet e-commerce architect

----------
From:  Ilan Shacham [SMTP:[e-mail]]
Sent:  Sunday, December 05, 1999 13:39
To:  Ietf-Pkix (E-mail)
Subject:  QC's - for human eyes only?

Hi all,
Section 3.2.4 of the QC profile, which describes the biometricInfo 
extension states:

"   ...This extension SHALL only be used to store a hash of biometric
   information suitable for human verification, i.e. where decision
   whether this information is an accurate representation of the subject
   is performed by a physical person. This implies a usage where the
   biometric information is represented by for example a graphical
   image, displayed to the relying party, which MAY be used by the
   relying party to enhance identification of the subject..."

I don't see why we should limit ourselves in such a way, and not allow
for machine verification of biometric data (such as finger-prints, etc.).
It seems to me that even if today biometrics aren't advanced enough,
we should not limit ourselves towards the future.

Another shortcoming of the biometricInfo extension, is that it does
not allow for the actual biometric data to be included, but instead
mandates the data to be accessed through a URI. This approach
may be relevent today, when biometric data is large, and memory
on smartcards is limited, but surely advances in the future would
allow the actual biometric data to be put in the certificate, it would
be a shame to create a new extension for ActualBiometricInfo...
I could also see why it would be relevent not to rely on the network
for maintaining all the information needed to validate a certificate.

Comments?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864




Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06131 for <[e-mail]>; Sun, 5 Dec 1999 04:36:02 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <VL213YFS>; Sun, 5 Dec 1999 14:39:15 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: QC's - for human eyes only?
Date: Sun, 5 Dec 1999 14:39:13 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"

Hi all,
Section 3.2.4 of the QC profile, which describes the biometricInfo 
extension states:

"   ...This extension SHALL only be used to store a hash of biometric
   information suitable for human verification, i.e. where decision
   whether this information is an accurate representation of the subject
   is performed by a physical person. This implies a usage where the
   biometric information is represented by for example a graphical
   image, displayed to the relying party, which MAY be used by the
   relying party to enhance identification of the subject..."

I don't see why we should limit ourselves in such a way, and not allow
for machine verification of biometric data (such as finger-prints, etc.).
It seems to me that even if today biometrics aren't advanced enough,
we should not limit ourselves towards the future.

Another shortcoming of the biometricInfo extension, is that it does
not allow for the actual biometric data to be included, but instead
mandates the data to be accessed through a URI. This approach
may be relevent today, when biometric data is large, and memory
on smartcards is limited, but surely advances in the future would
allow the actual biometric data to be put in the certificate, it would
be a shame to create a new extension for ActualBiometricInfo...
I could also see why it would be relevent not to rely on the network
for maintaining all the information needed to validate a certificate.

Comments?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02115 for <[e-mail]>; Sun, 5 Dec 1999 01:55:35 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2448.0) id <VL213YB8>; Sun, 5 Dec 1999 11:58:52 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: Internal conflict in QC profile?
Date: Sun, 5 Dec 1999 11:58:42 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"

Hi all,
The QC profile, in section 3.1.2 states:

 "  ...Of these attributes, the subject field SHALL include at least one of
   the following:

      Choice   I:  commonName
      Choice  II:  givenName
      Choice III:  pseudonym

   Other attributes may be present but MUST NOT be necessary to
   distinguish the subject name from other subject names within the
   issuer domain.
...
...
   The dnQualifier attribute type SHALL, when present, be used to
   differentiate between names where the subject field would otherwise
   be identical.  This qualifier has no defined semantics beyond
   ensuring uniqueness of subject names.  It MAY contain a number or
   code assigned by the CA or an identifier assigned by a government or
   civil authority.  It is the CA's responsibility to ensure that the
   dnQualifier is sufficient to resolve any subject name collisions..."

It looks to me that the first of these paragraphs should be changed to
something like:

   Other attributes may be present but MUST NOT be necessary to
   distinguish the subject name from other subject names within the
   issuer domain, except for the dnQualifier attribute which may be
   used as described below.
 
Ilan
------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: from hotmail.com (f9.law4.hotmail.com [216.33.149.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA13733 for <[e-mail]>; Sat, 4 Dec 1999 20:16:32 -0800 (PST)
Received: (qmail 27956 invoked by uid 0); 5 Dec 1999 04:18:45 -0000
Message-ID: <[e-mail]>
Received: from 168.70.232.233 by www.hotmail.com with HTTP; Sat, 04 Dec 1999 20:18:45 PST
X-Originating-IP: [168.70.232.233]
From: "Franklin Lee" <[e-mail]>
To: [e-mail]
Subject: CRL Distribution Mechanism Evaluation and Considerations
Date: Sun, 05 Dec 1999 04:18:45 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Dear all,

I'm interested in all experts' views on evaulating the distribution of the 
CRL(Certificate Revocation List) -

LADP over SSL vs. HTTPS (HTTP over SSL)

e.g,
- what are the key considerations (e.g, performance, infrastructure) for 
choosing either protocol?
- what are the current preferred practice as performed by the various CAs? 
(e.g. Thawte, Verisign)?


Thanks a lot and any comments (e.g., links to any relevant docu") are 
greatly appreciated.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from dfw-smtpout3.email.verio.net (dfw-smtpout3-ext.email.verio.net [129.250.36.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15520 for <[e-mail]>; Fri, 3 Dec 1999 20:29:02 -0800 (PST)
Received: from dfw-mmp3.email.verio.net ([129.250.38.63]) by dfw-smtpout3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM78KV00.4WS for <[e-mail]>; Sat, 4 Dec 1999 04:31:43 +0000 
Received: from nma.com ([209.21.28.126]) by dfw-mmp3.email.verio.net (Netscape Messaging Server 4.05) with ESMTP id FM78JT00.KLV; Sat, 4 Dec 1999 04:31:05 +0000 
Message-ID: <[e-mail]>
Date: Fri, 03 Dec 1999 20:31:42 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: [e-mail]
Subject: Re: non-repudiation, was Re: proposed key usage text
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Williams wrote:

> <snip, snip>
>
> Perhaps, what we need is the "durable communications"
> assertion bit.
>
> Binding NR to asymmetric signatures is just a bad idea, in
> my view. Its pretty clear to me that the EC directive will
> accept a SSL server-generated, certificate-supported,
> key exchange blob-set as one or more admissable and effective
> electronic signature(s), just as it would an asymmetric
> signature blob.
>
> You may have got the NR defn off of the NSA-aberism of
> time-dependent, not evidence-dependent semantics, but its
> still linked to asymmetric signatures, and thus
> at odds with the technology-neutral regulatory
> frameworks.

Peter:

I have no doubt that non-repudiation can be based on
symmetric signatures.  This is also mentioned in this
list's archives, and by more than one poster.  I may say
thus this WG is NOT binding NR to asymmetric signatures,
but just specifying the least requirements for NR *when* it
is based on asymmetric signatures.  I think your comment
helps make this clear.

Now, I must also say that nowhere in X.509 it is specified
that NR can NOT be based on symmetric signatures.  It
only so restricts *authentication*, to wit:

"The strong authentication method specified in this
Recommendation | International Standard is based upon
public-key cryptosystems."

Thus, since we did manage to more clearly differentiate
between authentication and non-repudiation functions
in PKIX, which separation X.509 also predicates as quoted
in the archives, it is IMO clear that yours is a valid
question to ask -- "Why stop the NR  discussion at
asymmetric signatures in PKIX? Why not be more
technologically-neutral?"

Well, PKIX itself is NOT technologically-neutral
for authentication (see above) --  which may already
preempt the "technology-neutral" argument for
PKIX in the eyes of many.  So, this may be one
answer to your question -- it is not required.

However, in time and again, I believe facts will show
that unless we enlarge our models (e.g., with symmetric
NR) we will not be able to represent the real-world as
we ourselves enlarge it.  Then, IMO your question will
be rediscovered and a solution will be more clearly
needed.  But, right now, I believe we should try to
achieve closure on the current (limited, but useful)
definition of NR in PKIX.  It will be always fun
though to investigate the next issues.

Cheers,

Ed Gerck



Received: from xeti.com ([208.163.59.148]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA11128 for <[e-mail]>; Fri, 3 Dec 1999 15:52:28 -0800 (PST)
Received: from xeti.com by xeti.com (SMI-8.6/SMI-SVR4) id QAA05129; Fri, 3 Dec 1999 16:12:31 -0800
Message-ID: <[e-mail]>
Date: Fri, 03 Dec 1999 15:54:40 -0800
From: Lewis McCarthy <[e-mail]>
Organization: Critical Path    http://www.criticalpath.net
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX WG <[e-mail]>
CC: [e-mail], Lewis McCarthy <[e-mail]>
Subject: TSP 4: socket protocol negPollRep message type
Content-Type: multipart/mixed; boundary="------------412E8BA059D7AA24DC999717"

This is a multi-part message in MIME format.
--------------412E8BA059D7AA24DC999717
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I'm trying to understand the purpose of the socket-based protocol's negPollRep
message type in draft-...-time-stamp-04.  I gather that the message type was
copied from the CMP spec to the TSP draft.  CMP section 5.2 specifies an
intended usage of negPollRep messages:

       "Where a PKIConfirm message is to be transported (always from the
       initiator to the responder) then a pkiMsg message is sent and a
       negPollRep is returned."

However I don't see a situation in TSP where a negPollRep message would be
needed.  The draft states that a negPollRep is a valid reply to a tsaMsg or a
pollReq.  But a message indicating normal completion of the transaction -- with
no additional information included -- doesn't appear useful in response to a
TimeStampReq tsaMsg or a pollReq.  If the client is asking for further
information, then the TSA should furnish further information or signal an error.

Could negPollRep be removed from the TSP socket protocol?

Regards
-Lewis McCarthy
[e-mail]


--------------412E8BA059D7AA24DC999717
Content-Type: text/x-vcard; charset=us-ascii;
 name="lewis.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Lewis McCarthy
Content-Disposition: attachment;
 filename="lewis.vcf"

begin:vcard 
n:McCarthy;Lewis
tel;cell:1-408-499-5708
tel;work:1-650-694-6813
x-mozilla-html:TRUE
url:http://www.criticalpath.net
org:Critical Path
version:2.1
email;internet:[e-mail]
title:Software Engineer
adr;quoted-printable:;;5150 El Camino Real=0D=0ASuite A-32;Los Altos;CA;94022;USA
fn:Lewis McCarthy
end:vcard

--------------412E8BA059D7AA24DC999717--



Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA10092 for <[e-mail]>; Fri, 3 Dec 1999 14:33:43 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 Dec 1999 12:34:28 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <YG18L446>; Fri, 3 Dec 1999 12:34:28 -0800
Message-ID: <[e-mail]>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Johannes Farmer'" <[e-mail]>, [e-mail]
Subject: RE: Certificates with DSA keys
Date: Fri, 3 Dec 1999 12:33:50 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3DCD.CBA7836A"

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

------_=_NextPart_001_01BF3DCD.CBA7836A
Content-Type: text/plain;
	charset="iso-8859-1"

There are a set of certificates an keys in the smime-examples draft from the
s/mime group.

> -----Original Message-----
> From: Johannes Farmer [mailto:[e-mail]]
> Sent: Friday, December 03, 1999 12:55 AM
> To: [e-mail]
> Subject: Certificates with DSA keys
> 
> 
> Does anybody know of a certification authority issuing X.509 
> certificates
> with DSA keys where the parameters are not included in the
> subjectPublicKeyInfo AlgorithmIdentifier and therefore have 
> to be got from
> the issuer certificate? If so, it would be great if she/he 
> would send me the
> corresponding cert chain. We are implementing a Java 
> Cryptography toolkit
> including a X.509 library and are interested in parsing such 
> a chain (of
> course, we can build it by ourselves with our tool, but it 
> would be better
> to compare it against some other implementations).
> 
> Thank you very much in advance
> 
> --
> Johannes Farmer
> 
> 
> 
> 

------_=_NextPart_001_01BF3DCD.CBA7836A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: Certificates with DSA keys</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>There are a set of certificates an keys in the smime-examples draft from the s/mime group.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Johannes Farmer [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, December 03, 1999 12:55 AM</FONT>
<BR><FONT SIZE=2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Certificates with DSA keys</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Does anybody know of a certification authority issuing X.509 </FONT>
<BR><FONT SIZE=2>&gt; certificates</FONT>
<BR><FONT SIZE=2>&gt; with DSA keys where the parameters are not included in the</FONT>
<BR><FONT SIZE=2>&gt; subjectPublicKeyInfo AlgorithmIdentifier and therefore have </FONT>
<BR><FONT SIZE=2>&gt; to be got from</FONT>
<BR><FONT SIZE=2>&gt; the issuer certificate? If so, it would be great if she/he </FONT>
<BR><FONT SIZE=2>&gt; would send me the</FONT>
<BR><FONT SIZE=2>&gt; corresponding cert chain. We are implementing a Java </FONT>
<BR><FONT SIZE=2>&gt; Cryptography toolkit</FONT>
<BR><FONT SIZE=2>&gt; including a X.509 library and are interested in parsing such </FONT>
<BR><FONT SIZE=2>&gt; a chain (of</FONT>
<BR><FONT SIZE=2>&gt; course, we can build it by ourselves with our tool, but it </FONT>
<BR><FONT SIZE=2>&gt; would be better</FONT>
<BR><FONT SIZE=2>&gt; to compare it against some other implementations).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you very much in advance</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --</FONT>
<BR><FONT SIZE=2>&gt; Johannes Farmer</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF3DCD.CBA7836A--


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08787 for <[e-mail]>; Fri, 3 Dec 1999 12:55:42 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <WZF04QAF>; Fri, 3 Dec 1999 12:54:13 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Ed Gerck <[e-mail]>, [e-mail]
Subject: RE: non-repudiation, was Re: proposed key usage text
Date: Fri, 3 Dec 1999 12:54:12 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

http://europa.eu.int/comm/dg15/en/media/sign/elecsignen.pdf

to get the benefits of QC, providers must use
"durable means of [electronic] communication" to bind 
subscribers to governing terms and conditions concerning the
use of certs.

Is an SSL-server protocol session, using
NON-signature-based data origin authentication,
sufficient to act as a "durable means of communication",
as it is used in Thawte/VeriSign CA world today
to perform the binding of users to CPS-agreements?

If it is, then "encryption-based" authentication **underpins**
QC-grade, "signature-based" authentication and NR services.

If encryption-based authentication is sufficient 
for this "durable" communciation purpose, why is it not sufficient
for durable "authentication of communications" in 
general?

If it can enable the contract which makes a QC-cert reliable,
why cannot it enable other contract regimes!?

Perhaps, what we need is the "durable communications" 
assertion bit.

Binding NR to asymmetric signatures is just a bad idea, in 
my view. Its pretty clear to me that the EC directive will
accept a SSL server-generated, certificate-supported,
key exchange blob-set as one or more admissable and effective
electronic signature(s), just as it would an asymmetric 
signature blob.

You may have got the NR defn off of the NSA-aberism of
time-dependent, not evidence-dependent semantics, but its
still linked to asymmetric signatures, and thus
at odds with the technology-neutral regulatory 
frameworks.

> -----Original Message-----
> From: Ed Gerck [mailto:[e-mail]]
> Sent: Tuesday, November 30, 1999 11:04 AM
> To: Peter Williams; [e-mail]
> Subject: Re: non-repudiation, was Re: proposed key usage text
> 
> 
> Peter:
> 
> Thanks for the useful links, including patents.  The topic
> extension seems to be off-charter for PKIX -- though one may
> expect that other standards and references may realign
> themselves with PKIX, but this is on their turf.  What could
> be done here was IMO done to a large extent -- to clear the
> PKIX discourse and to make NR useful and distinguished
> from authentication, while reducing its potentially misleading
> aspects.  Especially useful was to clarify that NR has nothing
> to do with "willful intent", it has to do with evidences.  So,  this
> WG has now a rather objective  agreement (if one also includes
> the archives, for context) on NR and work can go on until this
> agreement is again challenged by facts.  Until then, I am happy
> to pursue this discussion in private or in other technical fora
> such as the MCG -- in particular on modeling NR as a "modus
> tolens" logical affirmation in modal logic.
> 
> Cheers,
> 
> Ed Gerck
> 
> 


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08180 for <[e-mail]>; Fri, 3 Dec 1999 12:18:16 -0800 (PST)
Message-ID: <001d01bf3dcb$e9a0ace0$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: unqualified topic - not solved yet.
Date: Sat, 4 Dec 1999 06:20:39 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

----- Original Message -----
From: Stefan Santesson <[e-mail]>
To: Charles Moore <[e-mail]>; David P. Kemp
<[e-mail]>; <[e-mail]>
Sent: Friday, December 03, 1999 11:15 PM
Subject: Re: unqualified topic - not solved yet.


Charles,

At 06:36 AM 12/3/99 +1000, Charles Moore wrote:
<Snip>
>> The description of the Subject is not as clear, but in a roundabout
>> manner it indicates that the unmistakable identity of the subject is
>> specified using a set of attributes where no single attribute is
>> required to be populated.
>
>cm> This is the point...
>
>As we seem to agree, just need to make the text align...
>

I don't get it.

We seems to agree that no unique identifier must be present.

cm> I agree that a unique identifiy needs to be present, when and only when,
there is a need to disabiguate non unique ( using whatever criteria one
requires) people.
This means that a) there is not a requirenment to populate either Dnq or
Serial number ( the legacy attributes) if there s already unique
identifiaction information present. On a policy basis, these values MAY be
populated subject to national requirements.

Note: The RFC is for open systems, a closed or propriety system may do what
ever it likes, so a company system can make mandatory any of the above, but
this is outside the scope of the RFC...



But where do we have to align the text ?????

cm> Make it represent what we agree without ambiguity....


If you assume that the term "unmistakable identity" = unique identifying
code in a single attribute, then you must have missed the definition of
unmistakable identity (section 2.4)
cm> I dont, see above...


  "An unmistakable identity denotes a set of attributes and/or data
   elements, which forms an identity that by unmistakable means relates
   to a specific entity. The unmistakable connection between the
   identity and the entity may be dependent on the context within which
   the name is formed. This context should however be evident for any
   relying party given the information in the certificate. Some
   contexts, such as when identities are based on pseudonyms, may
   require assistance from the CA or a registration authority, to obtain
   a corresponding officially registered identity under some predefined
   circumstances, such as investigation of criminal offence."

So, what is the problem here?

cm> Does not address the issue.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]
211 20  Malmö                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------




Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02814 for <[e-mail]>; Fri, 3 Dec 1999 05:39:19 -0800 (PST)
From: [e-mail]
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.certco.com [10.100.24.12]) by btec-fw.certco.com (Postfix) with ESMTP id E309232DE0; Fri,  3 Dec 1999 08:41:31 -0500 (EST)
Received: by nycertco-srv1.certco.com with Internet Mail Service (5.5.2650.21) id <XRZL88MD>; Fri, 3 Dec 1999 08:42:55 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Certificates with DSA keys
Date: Fri, 3 Dec 1999 08:42:54 -0500 
X-Mailer: Internet Mail Service (5.5.2650.21)

There are two ways to represent a DSA public key:

with its parameters
without its paramets

One is identified by id-dsa and the other by id-dsa-common. I forget which
is which and would have to do some research to figure out which is which.

Hope this helps.

Frank Balluffi
CertCo

-----Original Message-----
From: Johannes Farmer [mailto:[e-mail]]
Sent: Friday, December 03, 1999 3:55 AM
To: [e-mail]
Subject: Certificates with DSA keys


Does anybody know of a certification authority issuing X.509 certificates
with DSA keys where the parameters are not included in the
subjectPublicKeyInfo AlgorithmIdentifier and therefore have to be got from
the issuer certificate? If so, it would be great if she/he would send me the
corresponding cert chain. We are implementing a Java Cryptography toolkit
including a X.509 library and are interested in parsing such a chain (of
course, we can build it by ourselves with our tool, but it would be better
to compare it against some other implementations).

Thank you very much in advance

--
Johannes Farmer





Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02356 for <[e-mail]>; Fri, 3 Dec 1999 05:12:43 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id OAA14042; Fri, 3 Dec 1999 14:15:09 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 03 Dec 1999 14:15:45 +0100
To: "Charles Moore" <[e-mail]>, "David P. Kemp" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: unqualified topic - not solved yet.
In-Reply-To: <001701bf3d04$e4d8a4f0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA02357

Charles,

At 06:36 AM 12/3/99 +1000, Charles Moore wrote:
<Snip>
>> The description of the Subject is not as clear, but in a roundabout
>> manner it indicates that the unmistakable identity of the subject is
>> specified using a set of attributes where no single attribute is
>> required to be populated.
>
>cm> This is the point...
>
>As we seem to agree, just need to make the text align...
>

I don't get it.

We seems to agree that no unique identifier must be present.

But where do we have to align the text ?????

If you assume that the term "unmistakable identity" = unique identifying
code in a single attribute, then you must have missed the definition of
unmistakable identity (section 2.4)

  "An unmistakable identity denotes a set of attributes and/or data
   elements, which forms an identity that by unmistakable means relates
   to a specific entity. The unmistakable connection between the
   identity and the entity may be dependent on the context within which
   the name is formed. This context should however be evident for any
   relying party given the information in the certificate. Some
   contexts, such as when identities are based on pseudonyms, may
   require assistance from the CA or a registration authority, to obtain
   a corresponding officially registered identity under some predefined
   circumstances, such as investigation of criminal offence."

So, what is the problem here?

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA27430 for <[e-mail]>; Fri, 3 Dec 1999 00:56:17 -0800 (PST)
Received: from cicero [129.27.152.137] by iaik.tu-graz.ac.at (SMTPD32-5.05) id A57D5B30052; Fri, 03 Dec 1999 09:55:25 +0100
Received: from localhost [127.0.0.1] by cicero (IAIK S/MIME Mapper 2.0alpha2d 26/November/1999); Fri, 03 Dec 1999 09:55:09 +0100
Message-ID: <004101bf3d6c$19ea96f0$[e-mail]>
From: "Johannes Farmer" <[e-mail]>
To: <[e-mail]>
Subject: Certificates with DSA keys
Date: Fri, 3 Dec 1999 09:55:07 +0100
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.0BE64DA5--"; protocol="application/x-pkcs7-signature"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.0BE64DA5--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does anybody know of a certification authority issuing X.509 certificates
with DSA keys where the parameters are not included in the
subjectPublicKeyInfo AlgorithmIdentifier and therefore have to be got from
the issuer certificate? If so, it would be great if she/he would send me the
corresponding cert chain. We are implementing a Java Cryptography toolkit
including a X.509 library and are interested in parsing such a chain (of
course, we can build it by ourselves with our tool, but it would be better
to compare it against some other implementations).

Thank you very much in advance

--
Johannes Farmer




----IAIK.SMIME.MAPPER.0BE64DA5--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIUvDCCBBswggMHoAMCAQICAwGGzzAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyNTEzMTcyM1oXDTAwMTEy
NTEzMTcyM1owgZgxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGDAWBgNV
BAMTD0pvaGFubmVzIEZhcm1lcjCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA
pRW9GhKHHWzU1dj3YRAi1ffARNhAf+zD85GpmK4HXeBWaYoHswtjh1iHYcHeahPJ
S6Dg08m5ABvChwYdX6vUBIYNtqFirfzpvH0eEpwewhG+CJr6KFTamI5a5k7fz3iD
mUSFl8H32ecO1krGNQxlRVPhykWCJW4d/2Nkd96Vg2sCAQejfjB8MBEGCWCGSAGG
+EIBAQQEAwIAoDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRS
QU5FVDAMBgNVHRMEBTADAQEAMCIGA1UdEQQbMBmBF0pvaGFubmVzLkZhcm1lckBp
YWlrLmF0MAsGA1UdDwQEAwIGwDAJBgUrDgMCHQUAA4IBAQBphMi1ssvvYfNIWXUq
Aa5F/DAGg/HCkUAaN0Txw1gtMSko72C9xSaLBGIhBO6sJydejcr05OcvSaMNFv+l
ytW2lDPAyuBEnqtf4I3qVRb9h8wqzbHbf1l6a0HvK8UUS4ClnA7OKj6oU3aaHtBP
FgDh9Qr4gc3Zh4/GFi0+mBysIUWOAbhwJD64OOyUL0oB9QEHL5csfgY/xDOp5x4h
ikPRPWacHo9WHgUwkViP3cbEoPL8RohfXwaT1yFArsC+YJeH8ltoxZsAm5E/Flxm
Y0LvRUI8zRYK/fovqI31DNdW0KnQny/ZkkwWduqfGuThMUq9t68twLz236CNCG61
zUdWMIIEVDCCA0CgAwIBAgICTiAwCQYFKw4DAh0FADCBmTELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5FVCBDQTAeFw05
OTExMTQxMjUxNDlaFw0wMjEyMzEyMjU5MzBaMIIBEzELMAkGA1UEBhMCQVQxDzAN
BgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5mZmVsZGdh
c3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kx
RzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl
c3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElOVFJBTkVU
IENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJQUlLIGVs
ZWN0cm9uaWMgc2lnbmF0dXJlMIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKC
AQEA0soSrmRrC9RD5OZjkxvEc4R0v1Wvv1mI7O2ZvdZ8FR7tflxSyXifOQCApEkO
8qvZVmvbq9+HMsGzYZf/UMWjgToh5DLwLl8bNgav7oXv4RG9U+14DtdqbRvNKkjj
/P5yscNT15W1JHdaw/e9u5jv+bab2oBEH8+wmUOcCOB5KzcObh/77Ce9sEXEUxc5
h8v5zl92PbFy3f1e0xvI9cdKDVrEd29LRxFjPjnNUKuRXwpJ6DDAorUg9/HFCwgn
CybVcZDomqVmmaw11ALob7IYbET45F4eiM6arGRLUSOuErqy6FFEoT79dPBCxOq3
0CrZvRTZ5RUQ/eeHYsHxR5KP5QIBBaMzMDEwEQYJYIZIAYb4QgEBBAQDAgACMA8G
A1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMAkGBSsOAwIdBQADggEBAHNup75e
Y0LKaKg9H846WZKhgEZhVY/bhzalaFrbasP8ureOjoSVHHjxJl5CrBT+DbghcdjM
r5m1m+kekDUOVn6GqxlskN/NnEDepnHD0ucHg41wM2HhmVJMffSu9J3FcZMKu6yD
QISbWq4tl0i8ZnwSck2K2blhIHeQvTQbn9rt4mcgK2qzij26wY2cY5l8AW2e7bHw
IUlTBkq9jg4EHEI3+2Z3TSLEGS++R5DdtT4/v8d8JzAgEBedPj7fIqAIGf0gLncZ
nWDa9orSNL5rFf8Yw9TULsG+vh8Jkdi8XJYTM609VW7Uw5ESw/4fCygtTqSlfJUJ
UuyK/jnf1zWnyiYwggPKMIICsqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMIGZMQsw
CQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xP
R1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFBy
b2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJB
TkVUIENBMB4XDTk5MTExNDEyMzE1OVoXDTAyMTIzMTIyNTkzMFowgZkxCzAJBgNV
BAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFH
MEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vz
c2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5UUkFORVQg
Q0EwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEIAoIBAQDC6/iB3uqngLWC5H78
ckSOqIK7wT+YijxAWe4909clSS+wgzxh/IYD7COKrehZ84djLgKvOCUufM1+cS6h
FAvxOccNccgM6KwuslsMRkYW/n704ODpTNiVbE5ciTuhfwVpV7mVN95YBpMv0V/O
LCLVyoZoW1D7HJx2AbFSnEDuaxXEaySv+XNTIWv23EDVQ0GkMPh0Qr6+0+JgFWIv
g1Sb+o29/dwqAwZ33xj/5nCJBRhTuQ+pcnz/EIkrNOvtLpyGFsFJ9WM0CNkTQQI1
6wrgCbZX+KmKxlwtPTXoPMpqCNrjoJaOrHFomV7f6a8VqIvm7T1/KFg5efuwxLQn
9K8fAgEHox0wGzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBBjANBgkqhkiG9w0B
AQQFAAOCAQEAH3TjCf3j5Zq2NH5ZIIi+r8kQwblhnCGgf6BqH54Cc20C2u19rIVs
6SIlab6OuF3IyAbqHKRK4SEH3NlGU0qmGE+0dlMnYdMFXqknFEbsLooRVET4SOxl
gkqzcMptpa8LL2tl4fzE8s4V7Pb6NvXT9nY43pTfJ9+O3V4SiTmCdLbAOfN2nxCp
ir5H8wG/rEC8RJj8mrEEwhiTHnP4loy07BA0Xwq0TmFYA2eDXAqYkUr/ZlsOrD2A
fAoX+XyatcGhc5bhWElJLhduDSlaKa9ROHSrdi3Nc3TERkc7SkFnlIgS5KhQkMbI
uoma5dZ7zAnRfrHLi4+xuJTbIcep9WXGmzCCBBswggMHoAMCAQICAwMNbzAJBgUr
DgMCHQUAMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UE
BxMER3JhejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JB
WiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZv
ciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRp
b25zMRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRswGQYDVQQDExJJQUlLIFRV
LUdSQVogQ1JZUFQxIDAeBgNVBAwTF0lBSUsgY29uZmlkZW50aWFsaXR5IENBMB4X
DTk5MTEyNTEzMTgxNloXDTAwMTEyNTEzMTgxNlowgZgxCzAJBgNVBAYTAkFUMSYw
JAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+
SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg
Q29tbXVuaWNhdGlvbnMxGDAWBgNVBAMTD0pvaGFubmVzIEZhcm1lcjCBnTANBgkq
hkiG9w0BAQEFAAOBiwAwgYcCgYEA5/AaYpZQm1kSSfYWLChCui4dOdlTJjilAIo0
U9WzajiaMa3bEdlhz/7KVQKJ2s7zvvVW2Hcb6dpcj+6qqDZM6JAcgvtMqnzCBqHw
DaXPNhgPGoQmA+U9ymiRqCthw3xCTFpNvzzZZs/EjmnxoZXWyw8kkqUzstkNvqr/
nBd+IdcCAQOjfjB8MBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgBhvhCAQ0EGxYZ
VXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEAMCIGA1UdEQQb
MBmBF0pvaGFubmVzLkZhcm1lckBpYWlrLmF0MAsGA1UdDwQEAwIDeDAJBgUrDgMC
HQUAA4IBAQA+Z03ZapH4FPt3NHzlTRrZF2+L5igdStueegzFspcaJnCp/cVwLBhd
tlKaHiUEuDoBL6TMO5mCPCPYBfsImtzgCuiOrExA4l5LrTPDGJfvF/xCW6xeMGNJ
4QT7wug8RF+mirfvzX34nBxtXozTPrWT+4kkuhXaUP/SkTuGOHbqMiibv179h2Ka
WTsQPsb+TR1gBUGYFcS2100OR+XBSES9U6D+ngSqmJAXNBhXR201SYU4SuSv/NWH
KqJGM0keRemugc1mKXiVuF0qEB7NgHIOMK/Mvv2o8f2NRNUq5hvpHHTq+3z6LKSg
xWJjOisGFJYs0NmcYWCbvUM5TS27THnlMIIEVDCCA0CgAwIBAgICdTAwCQYFKw4D
Ah0FADCBmTELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBP
RiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZv
cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQ
SUFJSyBJTlRSQU5FVCBDQTAeFw05OTExMTQxMjU1MzZaFw0wMjEyMzEyMjU5MzBa
MIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER3Jh
ejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklW
RVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBs
aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkw
FwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRswGQYDVQQDExJJQUlLIFRVLUdSQVog
Q1JZUFQxIDAeBgNVBAwTF0lBSUsgY29uZmlkZW50aWFsaXR5IENBMIIBIDANBgkq
hkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAwSfONq2Jz3TGLlVGavSLY7XpnVpISVAV
mK2g28DMbD4p6E5O4p5SvkAseJv20Yic2b6M9NZUaX+7kdpvUlHNePTEArKq9n4q
mEbLpqDpVwJXJImZ5jUCpMzRbvxd0VBeeVm5yIG/TQq2i6Vv8q2CHpzRg2CjhQxV
3GMYcnB6JtPUAa+UV7YGq6XC27A4ui8wi4jIceH6joXYddgpQHngYmmJrUHYh+ap
ykEEV1i0OUfKvG6AHlCG6EujQGMPyMJ7wHaCRCcjbAh7J+kuUf67f9VACXXZxkqS
pqo+k6A//Oex2HrZAFJputGW68Kn05Bb0zy76YmWvEghXC1OF/MhbQIBBaMzMDEw
EQYJYIZIAYb4QgEBBAQDAgACMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEG
MAkGBSsOAwIdBQADggEBAFr6/gkjOpsHJ28U5o/90DkP8YtYRaM9MXy0pw+HGURg
AEfx1bkTa2T+c0TYIPIaOQm1H6j2SIIMJrg3+qVzYt6kmlrQjbweLjAJ3QK7FJak
S4Mc0Otbpj9tTyAnwOmyRWX6VHRAWSpIJYC7dtjR7ZW9R9+TaW2vHUq87ri8Zf5r
JmfY/udoYc99iMIFZQrNbTNLxyFV/Rp6G7+pcW5kN/LUyUOASc+XUNDW9IsIyYUQ
Nz32I3NwJTsguf5GBY81g9WEJSqgNDpu5fTSiF81VL84eCqRalrUcu8tFeoT02Zh
Qm9+ETbMJjrDptMwTch8MJdFq3ZDe3A/j+I/3G2xNs8xggJ4MIICdAIBATCCARww
ggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFa
MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZF
UlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxp
ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAX
BgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBT
SUcxIjAgBgNVBAwTGUlBSUsgZWxlY3Ryb25pYyBzaWduYXR1cmUCAwGGzzAJBgUr
DgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTk5MTIwMzA4NTUwOVowIwYJKoZIhvcNAQkEMRYEFP+EEK7bq/L9Po1tCU6D
E0plGPD6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIHMA0GCSqG
SIb3DQEBAQUABIGAT3Yrx7eVbDAekEPsREd//fRnFAoDvKmDezsfPdrwDIICItLT
Tpr5jFQk+520SDIQmmgqWw+Uz0EHXS1r9FSIJ6lNPKHb/sJJPba3Un4LRIUjnL8F
Sfsc8bJcPzTuPNXdRdham0aPDMtU8SdU5Tii4JRT8X51WDtDowhj2kU4G3EAAAAAAAA=
----IAIK.SMIME.MAPPER.0BE64DA5----



Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04816 for <[e-mail]>; Thu, 2 Dec 1999 12:33:49 -0800 (PST)
Message-ID: <001701bf3d04$e4d8a4f0$[e-mail]>
From: "Charles Moore" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: unqualified topic - not solved yet.
Date: Fri, 3 Dec 1999 06:36:00 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: David P. Kemp <[e-mail]>
To: <[e-mail]>
Sent: Friday, December 03, 1999 1:03 AM
Subject: RE: unqualified topic - not solved yet.


> The current QC profile (draft -02) does not require that any "feature"
> be populated  ... how did you get the impression that one particular
> attribute might be special-cased in the next draft?
cm> This email thread...

>
>snip
>
> The description of the Subject is not as clear, but in a roundabout
> manner it indicates that the unmistakable identity of the subject is
> specified using a set of attributes where no single attribute is
> required to be populated.

cm> This is the point...

As we seem to agree, just need to make the text align...

>
> Dave Kemp
>
>
>
> > From: Charles Moore <[e-mail]>
> >
> > -----Original Message-----
> > From: Anders Rundgren [mailto:[e-mail]]
> > Sent: Wednesday, 1 December 1999 20:18
> > To: '[e-mail]'; 'Stefan Santesson'; 'Tony Bartoletti'; 'Charles
> > Moore'
> > Cc: 'David P. Kemp'
> > Subject: RE: unqualified topic - not solved yet.
> >
> >
> > Charles,
> >
> > <snip>
> >
> > cm> If all certs must have an unique identifier then one CANNOT control
the
> > usage of the number....
> >
> > They don't.  This is just a "feature" that some QC-implementations
> > (profiles) require.
> >
> > If unique identifiers are bad or good is outside of the QC-draft.  The
> > technical reasons
> > for using them are pretty clear.    As well as the possible consequences
as
> > you point out.
> >
> > cm> My point was that the QC profile must not require that the "feature"
is
> > always populated... I belive that you agree....
>



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29395; Thu, 2 Dec 1999 07:09:24 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id KAA13603; Thu, 2 Dec 1999 10:11:25 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 02 Dec 1999 10:15:37 -0500
To: Paul Hoffman / IMC <[e-mail]>, Russ Housley <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: Denis Pinkas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

Russ & Paul,


I agree, the security considerations section is the right place to
address this.  Do you have a problem with the paragraph if it goes
there?


Thanks,


Tim


At 11:56 AM 12/01/1999 -0800, Paul Hoffman / IMC wrote:

>At 12:48 PM 12/1/99 -0500, Russ Housley wrote:

>>>>

<excerpt>>Denis Pinkas proposed the following:

>

>    The protection afforded private keys is a critical factor in main-

>    taining security.  On a small scale, failure of users to protect

>    their private keys will permit an attacker to masquerade as them,
or

>    decrypt their personal information. [stuff about CA keys deleted]

>

>Tim Polk countered with the following:

>

>       A CA may include the key usage extension and assert the 

>nonRepudiation bit

>       when issuing a certificate.  This implies that a reliable third 

>party will

>       be able to determine the authenticity of signed data in the event
of 

>a dispute.

>       If the certificate subject uses the private key in an insecure 

>environment,

>       it may be difficult to detect or prevent key compromise.  This
could 

>prevent a

>       reliable third party from determining the authenticity of signed 

>data.  A CA

>       should consider the environment of the private key before
asserting the

>       nonRepudiation bit.

>

>I have a problem with either paragraph being added to this 

>section.  Consequences of detected and undetected compromise belong in
the 

>Security Considerations section, not here.

>

>Russ

</excerpt><<<<<<<<


>>

>I agree fully with Russ. There are dozens of places in this document
where 

>we could also talk about the problem of the signing party's key being 

>compromised, and this one isn't all that important relative to the
others.

>

>--Paul Hoffman, Director

>--Internet Mail Consortium

>

>


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29175 for <[e-mail]>; Thu, 2 Dec 1999 07:05:45 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA15453 for <[e-mail]>; Thu, 2 Dec 1999 10:08:46 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA15449 for <[e-mail]>; Thu, 2 Dec 1999 10:08:45 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA07602 for <[e-mail]>; Thu, 2 Dec 1999 10:07:59 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA19187 for <[e-mail]>; Thu, 2 Dec 1999 10:03:24 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 2 Dec 1999 10:03:24 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: yn3/Q0lsKVU56TuxFseYLw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

The current QC profile (draft -02) does not require that any "feature"
be populated  ... how did you get the impression that one particular
attribute might be special-cased in the next draft?

The description of every attribute in the current draft, including
dnQualifier, begins with:

   "The xxx attribute type SHALL, when present, be used to ..."

The description of the Issuer is quite clear:

   "The unmistakable identity of the issuer SHALL be specified using an
   appropriate subset of the following attributes.:"

The description of the Subject is not as clear, but in a roundabout
manner it indicates that the unmistakable identity of the subject is
specified using a set of attributes where no single attribute is
required to be populated.

Dave Kemp



> From: Charles Moore <[e-mail]>
>
> -----Original Message-----
> From: Anders Rundgren [mailto:[e-mail]]
> Sent: Wednesday, 1 December 1999 20:18
> To: '[e-mail]'; 'Stefan Santesson'; 'Tony Bartoletti'; 'Charles
> Moore'
> Cc: 'David P. Kemp'
> Subject: RE: unqualified topic - not solved yet.
> 
> 
> Charles,
> 
> <snip>
> 
> cm> If all certs must have an unique identifier then one CANNOT control the 
> usage of the number....
> 
> They don't.  This is just a "feature" that some QC-implementations
> (profiles) require.
> 
> If unique identifiers are bad or good is outside of the QC-draft.  The
> technical reasons
> for using them are pretty clear.    As well as the possible consequences as
> you point out.
> 
> cm> My point was that the QC profile must not require that the "feature" is
> always populated... I belive that you agree....



Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA22670 for <[e-mail]>; Thu, 2 Dec 1999 02:21:47 -0800 (PST)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA01979 for <[e-mail]>; Thu, 2 Dec 1999 11:23:52 +0100 (MET)
Message-ID: <[e-mail]>
Date: Wed, 01 Dec 1999 22:55:36 +0100
From: Harald Giehl <[e-mail]>
Organization: SECUDE Sicherheitstechnologie Informationssysteme GmbH
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01415 for <[e-mail]>; Wed, 1 Dec 1999 16:35:20 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093AE3@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, Charles Moore <[e-mail]>
Cc: "'David P. Kemp'" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Thu, 2 Dec 1999 10:38:42 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Wednesday, 1 December 1999 20:18
To: '[e-mail]'; 'Stefan Santesson'; 'Tony Bartoletti'; 'Charles
Moore'
Cc: 'David P. Kemp'
Subject: RE: unqualified topic - not solved yet.


Charles,

<snip>

cm> If all certs must have an unique identifier then one CANNOT control the 
usage of the number....

They don't.  This is just a "feature" that some QC-implementations
(profiles) require.

If unique identifiers are bad or good is outside of the QC-draft.  The
technical reasons
for using them are pretty clear.    As well as the possible consequences as
you point out.

cm> My point was that the QC profile must not require that the "feature" is
always populated... I belive that you agree....


Regarding the changed serialnumber semantics: Does it break any existing
code?
I can hardly see that.

cm> See assocaited email, that provides an example (not mine)....

Anders



Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27222; Wed, 1 Dec 1999 11:52:51 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Wed, 01 Dec 1999 11:56:46 -0800
To: Russ Housley <[e-mail]>, Tim Polk <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: Denis Pinkas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:48 PM 12/1/99 -0500, Russ Housley wrote:
>I have a problem with either paragraph being added to this 
>section.  Consequences of detected and undetected compromise belong in the 
>Security Considerations section, not here.

I agree fully with Russ. There are dozens of places in this document where 
we could also talk about the problem of the signing party's key being 
compromised, and this one isn't all that important relative to the others.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26807 for <[e-mail]>; Wed, 1 Dec 1999 11:34:18 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA23200; Wed, 1 Dec 1999 11:34:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 01 Dec 1999 12:48:41 -0500
To: Tim Polk <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: proposed key usaged text -- the final round
Cc: Denis Pinkas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis Pinkas proposed the following:

    The protection afforded private keys is a critical factor in main-
    taining security.  On a small scale, failure of users to protect
    their private keys will permit an attacker to masquerade as them, or
    decrypt their personal information. [stuff about CA keys deleted]

Tim Polk countered with the following:

       A CA may include the key usage extension and assert the 
nonRepudiation bit
       when issuing a certificate.  This implies that a reliable third 
party will
       be able to determine the authenticity of signed data in the event of 
a dispute.
       If the certificate subject uses the private key in an insecure 
environment,
       it may be difficult to detect or prevent key compromise.  This could 
prevent a
       reliable third party from determining the authenticity of signed 
data.  A CA
       should consider the environment of the private key before asserting the
       nonRepudiation bit.

I have a problem with either paragraph being added to this 
section.  Consequences of detected and undetected compromise belong in the 
Security Considerations section, not here.

Russ






Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25859 for <[e-mail]>; Wed, 1 Dec 1999 10:59:54 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA04308; Wed, 1 Dec 1999 11:01:55 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 01 Dec 1999 11:01:33 -0800
To: Tim Polk <[e-mail]>, "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the  final round
In-Reply-To: <[e-mail]>
References: <002001bf3bb8$bce41a30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

At 11:18 AM 12/01/1999 -0500, Tim Polk wrote:


>>>>

<excerpt>Here is the full paragraph from RFC 2459.


<bigger>   The protection afforded private keys is a critical factor in

   maintaining security.  On a small scale, failure of users to protect

   their private keys will permit an attacker to masquerade as them, or

   decrypt their personal information. On a larger scale, compromise of

   a CA's private signing key may have a catastrophic effect.  If an

   attacker obtains the private key unnoticed, the attacker may issue

   bogus certificates and CRLs.  Existence of bogus certificates and

   CRLs will undermine confidence in the system. If the compromise is

   detected, all certificates issued to the CA shall be revoked,

   preventing services between its users and users of other CAs.

   Rebuilding after such a compromise will be problematic, so CAs are

   advised to implement a combination of strong technical measures

   (e.g., tamper-resistant cryptographic modules) and appropriate

   management procedures (e.g., separation of duties) to avoid such an

   incident.


</bigger></excerpt>

Tim,


Thanks.  It helped to have the full paragraph.  It now comes across as

speaking to potential CAs more than to EEs.  Compromise of CA signing

keys is certainly catastrophic!


___tony___



<excerpt>Yes, things are slightly different if the key represents a
corporate identity (instead of a person), but not much.  Compromise still
permits an attacker to masquerade, but as a corporate entity instead of
as a person.


In my opinion, the security considerations text can ignore these
differences.  The NR document, on the other hand, may need to address
those subtleties.


Thanks,


Tim Polk



</excerpt><<<<<<<<





Tony Bartoletti                                             LL

IOWA Center                                              LL LL

Lawrence Livermore National Laboratory                LL LL LL

PO Box 808, L - 089                                   LL LL LL

Livermore, CA 94551-9900                              LL LL LLLLLLLL

phone: [phone]   fax: [phone]               LL LLLLLLLL

email: [e-mail]                                   LLLLLLLL


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24588 for <[e-mail]>; Wed, 1 Dec 1999 10:39:17 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA21633; Wed, 1 Dec 1999 10:41:37 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 01 Dec 1999 10:41:15 -0800
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
In-Reply-To: <002001bf3bb8$bce41a30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:58 AM 12/01/1999 -0000, Anders Rundgren wrote:
>Tony,
>I may be wrong but I assumed that the text below was to be included in the NR-document
>and if so is the case it talks about things like "users" and "personal information" which
>is not coherent with server-generated signatures.
>
>>>    >The protection afforded private keys is a critical factor in main-
>>>    >taining security. On a small scale, failure of users to protect
>>>    >their private keys will permit an attacker to masquerade as them, or
>>>    >decrypt their personal information. [stuff about CA keys deleted]

OK, I agree.  There is no particular reason to assume that a "private
signing key" is held by an "individual" (human) or necessarily controls
access to human-related information.  Perhaps the above paragraph could
be reworded:

   The protection afforded private keys is a critical factor in maintaining
   security.  Failure to protect the privacy of private signing keys may
   permit an attacker to masquerade as the key's owner or authorized agent.
   The consequences of private key compromise may include loss of privacy or
   integrity in key-controlled transactions.  

I intentionally dropped the qualifier "On a small scale".  I did not
understand its justification.  Perhaps the original author(s) have a
low expectation for the future ubiquity of key-controlled transactions.

___tony___




Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23970 for <[e-mail]>; Wed, 1 Dec 1999 10:00:45 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <X7GCAAGL>; Wed, 1 Dec 1999 13:02:48 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Charles Moore <[e-mail]>, "'Anders Rundgren'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, [e-mail]
Cc: "David P. Kemp" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 13:02:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3C26.46B1DD8E"

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

------_=_NextPart_001_01BF3C26.46B1DD8E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Just to clarify,

My comment was based on a conversation with Hoyt Kesterson who chairs=20
the X.500 group. We both agree that this could be a minor defect. =
However,
we can't speak for the group and a defect report would need to be =
submitted,

reviewed and ballotted before we could be sure of the support for it.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Wednesday, December 01, 1999 4:38 AM
To: Charles Moore; 'Anders Rundgren'; 'Tony Bartoletti';
[e-mail]
Cc: David P. Kemp
Subject: RE: unqualified topic - not solved yet.


Charles,

At 04:02 PM 12/1/99 +1000, Charles Moore wrote:
<snip>
>Back to the past....
>
>I am not arguing that serial number or dnq be exclusively used, my =
personal
>preference would be dnq, but rather require we have a standard that
reflects
>reality and provides a long term solution that can be used by all =
existing
>communities...not selective interest groups...
>
>I have a problem with overloading of semantics, as they produce
>indeterminate results...
>I also dont believe a CP is the means to achieve this, keep the =
protocol
>clean and use rules/policy to determine the usage....
>

One thing that may have to be clarified here is that I have had a =
dialogue
with Sharon Boyen, who is involved in the X.509, X.520 and X.521
standardization, and she claims that they are willing to change the
definition of serialNumber and related object classes, so that this
attribute can be used for any type of object.

Sharon says that this is considered to be a minor adjustment that =
almost
was fixed 4 years ago but was forgotten in the process.

This is the fundamental reason for proposing use of serialNumber.

Having this in mind, I fail to see any problems.


I' don't want to enter a privacy discussion here, but I just want to =
stress
that there is NOTHING in the QC profile that require inclusion of =
privacy
sensitive information. In fact, the possibility to use a Pseudonym name =
is
clearly stated. The use of a unique identifier doesn't necessarily =
means
that it is privacy sensitive. That depends completely what you can do =
with
that number.

The fact is that we need to add support for inclusion of such =
identifiers,
regardless of their actual content.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]             =20
211 20  Malm=F6                   Fax. [phone]             =20
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

------_=_NextPart_001_01BF3C26.46B1DD8E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: unqualified topic - not solved yet.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Just to clarify,</FONT>
</P>

<P><FONT SIZE=2>My comment was based on a conversation with Hoyt Kesterson who chairs </FONT>
<BR><FONT SIZE=2>the X.500 group. We both agree that this could be a minor defect. However,</FONT>
<BR><FONT SIZE=2>we can't speak for the group and a defect report would need to be submitted, </FONT>
<BR><FONT SIZE=2>reviewed and ballotted before we could be sure of the support for it.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Stefan Santesson [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, December 01, 1999 4:38 AM</FONT>
<BR><FONT SIZE=2>To: Charles Moore; 'Anders Rundgren'; 'Tony Bartoletti';</FONT>
<BR><FONT SIZE=2>[e-mail]</FONT>
<BR><FONT SIZE=2>Cc: David P. Kemp</FONT>
<BR><FONT SIZE=2>Subject: RE: unqualified topic - not solved yet.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Charles,</FONT>
</P>

<P><FONT SIZE=2>At 04:02 PM 12/1/99 +1000, Charles Moore wrote:</FONT>
<BR><FONT SIZE=2>&lt;snip&gt;</FONT>
<BR><FONT SIZE=2>&gt;Back to the past....</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I am not arguing that serial number or dnq be exclusively used, my personal</FONT>
<BR><FONT SIZE=2>&gt;preference would be dnq, but rather require we have a standard that reflects</FONT>
<BR><FONT SIZE=2>&gt;reality and provides a long term solution that can be used by all existing</FONT>
<BR><FONT SIZE=2>&gt;communities...not selective interest groups...</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;I have a problem with overloading of semantics, as they produce</FONT>
<BR><FONT SIZE=2>&gt;indeterminate results...</FONT>
<BR><FONT SIZE=2>&gt;I also dont believe a CP is the means to achieve this, keep the protocol</FONT>
<BR><FONT SIZE=2>&gt;clean and use rules/policy to determine the usage....</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
</P>

<P><FONT SIZE=2>One thing that may have to be clarified here is that I have had a dialogue</FONT>
<BR><FONT SIZE=2>with Sharon Boyen, who is involved in the X.509, X.520 and X.521</FONT>
<BR><FONT SIZE=2>standardization, and she claims that they are willing to change the</FONT>
<BR><FONT SIZE=2>definition of serialNumber and related object classes, so that this</FONT>
<BR><FONT SIZE=2>attribute can be used for any type of object.</FONT>
</P>

<P><FONT SIZE=2>Sharon says that this is considered to be a minor adjustment that almost</FONT>
<BR><FONT SIZE=2>was fixed 4 years ago but was forgotten in the process.</FONT>
</P>

<P><FONT SIZE=2>This is the fundamental reason for proposing use of serialNumber.</FONT>
</P>

<P><FONT SIZE=2>Having this in mind, I fail to see any problems.</FONT>
</P>
<BR>

<P><FONT SIZE=2>I' don't want to enter a privacy discussion here, but I just want to stress</FONT>
<BR><FONT SIZE=2>that there is NOTHING in the QC profile that require inclusion of privacy</FONT>
<BR><FONT SIZE=2>sensitive information. In fact, the possibility to use a Pseudonym name is</FONT>
<BR><FONT SIZE=2>clearly stated. The use of a unique identifier doesn't necessarily means</FONT>
<BR><FONT SIZE=2>that it is privacy sensitive. That depends completely what you can do with</FONT>
<BR><FONT SIZE=2>that number.</FONT>
</P>

<P><FONT SIZE=2>The fact is that we need to add support for inclusion of such identifiers,</FONT>
<BR><FONT SIZE=2>regardless of their actual content.</FONT>
</P>

<P><FONT SIZE=2>/Stefan</FONT>
<BR><FONT SIZE=2>-------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>Stefan Santesson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=2>Accurata AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.accurata.se" TARGET="_blank">http://www.accurata.se</A></FONT>
<BR><FONT SIZE=2>Slagthuset&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. [phone]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>211 20&nbsp; Malmö&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax. [phone]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile [phone]</FONT>
</P>

<P><FONT SIZE=2>PGP fingerprint: 89BC 6C79 5B3D 591B 8547&nbsp; 1512 7D11 DBF4 528F 29A0</FONT>
<BR><FONT SIZE=2>-------------------------------------------------------------------</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF3C26.46B1DD8E--


Received: from www.certifiedtime.com (w133.z208176006.sjc-ca.dsl.cnc.net [208.176.6.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22861 for <[e-mail]>; Wed, 1 Dec 1999 08:41:52 -0800 (PST)
Received: from gw (gw [208.176.6.131]) by www.certifiedtime.com (8.9.3/8.9.3) with SMTP id IAA11780 for <[e-mail]>; Wed, 1 Dec 1999 08:45:04 -0800 (PST)
Message-ID: <059601bf3c1b$53a79b60$[e-mail]>
From: "todd.glassey" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 1 Dec 1999 08:44:25 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

subscribe [e-mail]



Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22404 for <[e-mail]>; Wed, 1 Dec 1999 08:12:56 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.9.3+Sun/8.6.4jck0) with SMTP id LAA14273; Wed, 1 Dec 1999 11:14:30 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 01 Dec 1999 11:18:39 -0500
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>, "Tony Bartoletti" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
In-Reply-To: <002001bf3bb8$bce41a30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

Anders,


Actually, the text below was from the Security Considerations text in RFC
2459.    


At 04:58 AM 12/01/1999 -0000, Anders Rundgren wrote:

>Tony,

>I may be wrong but I assumed that the text below was to be included in
the NR-document

>and if so is the case it talks about things like "users" and "personal
information" which

>is not coherent with server-generated signatures.

>

>>>    >The protection afforded private keys is a critical factor in
main-

>>>    >taining security. On a small scale, failure of users to protect

>>>    >their private keys will permit an attacker to masquerade as them,
or

>>>    >decrypt their personal information. [stuff about CA keys
deleted]

>

>

> [stuff deleted]


Here is the full paragraph from RFC 2459.


<bigger>   The protection afforded private keys is a critical factor in

   maintaining security.  On a small scale, failure of users to protect

   their private keys will permit an attacker to masquerade as them, or

   decrypt their personal information. On a larger scale, compromise of

   a CA's private signing key may have a catastrophic effect.  If an

   attacker obtains the private key unnoticed, the attacker may issue

   bogus certificates and CRLs.  Existence of bogus certificates and

   CRLs will undermine confidence in the system. If the compromise is

   detected, all certificates issued to the CA shall be revoked,

   preventing services between its users and users of other CAs.

   Rebuilding after such a compromise will be problematic, so CAs are

   advised to implement a combination of strong technical measures

   (e.g., tamper-resistant cryptographic modules) and appropriate

   management procedures (e.g., separation of duties) to avoid such an

   incident.



</bigger>Yes, things are slightly different if the key represents a
corporate identity (instead of a person), but not much.  Compromise still
permits an attacker to masquerade, but as a corporate entity instead of
as a person.


In my opinion, the security considerations text can ignore these
differences.  The NR document, on the other hand, may need to address
those subtleties.


Thanks,


Tim Polk


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21877 for <[e-mail]>; Wed, 1 Dec 1999 07:51:39 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA391886; Wed, 1 Dec 1999 10:52:53 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA207520; Wed, 1 Dec 1999 10:53:35 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525683A.00574A85 ; Wed, 1 Dec 1999 10:53:27 -0500
X-Lotus-FromDomain: IBMUS
To: "Anders Rundgren" <[e-mail]>
cc: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "Tim Polk" <[e-mail]>, [e-mail], "Tony Bartoletti" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 1 Dec 1999 10:53:11 -0500
Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA21878

     Shouldn't most of this distinction be handled by distinguishing
between certificates based on the object class of the subject, especially
the object classes organizational person,  organizational role, application
process, and application entity?

          Tom Gindin

"Anders Rundgren" <[e-mail]> on 11/30/99 11:58:39 PM

To:   "Denis Pinkas" <[e-mail]>, "Russ Housley"
      <[e-mail]>, "Tim Polk" <[e-mail]>,
      <[e-mail]>, "Tony Bartoletti" <[e-mail]>
cc:
Subject:  Re: Server-signatures: Re: proposed key usaged text -- the final
      round



Tony,
I may be wrong but I assumed that the text below was to be included in the
NR-document
and if so is the case it talks about things like "users" and "personal
information" which
is not coherent with server-generated signatures.

>>    >The protection afforded private keys is a critical factor in main-
>>    >taining security. On a small scale, failure of users to protect
>>    >their private keys will permit an attacker to masquerade as them, or
>>    >decrypt their personal information. [stuff about CA keys deleted]


When I refer to server-based signatures I meant for example things like
automated
bills from energy and phone companies.  Such bills are usually never
touched by
a human and would typically only have a company ID of some kind as subject
when/if
converted into an electronic digitally signed format.

The user is "certificateSubject" or "entity owning the private keys"

<snip>

I agree with your nicely formulated lines regarding "company owned keys"
below

>Let me explore the latter application.  Suppose I am a "company-trusted"
>employee, using a company-owned "private key".  I assume further that the
>company has its own mechanism for (hoping to) control who has the use of
>a given key at a given time, or at least who is responsible for its use.
>
>Now, I use the private key in question, entering into some obligation with
>an external RP.  Later, I attempt to deny my actions, causing this RP some
>hardship.
>
>My understanding is that this "bindings" in question look like:
>
>   RP <---> Transaction <---> Key/Cert <---> Company <---> Me
>
>That is, the RP must take up issue with the company, being the owner
>(or certSubject or Operator) of the key, directly.  It falls upon the
>company to follow the chain, so to speak, and take me to task.
>
>The central point is that the RP has only a certificate, and its
>"named holder", to point to in a dispute.  If the means by which
>the company above "secures the connection between key and user"
>is hidden from view, no amount of NR-servicing on the RP side can
>suffice to hold the "user" accountable.  They are forced instead to
>pressure the company, who may in turn pressure the employee.



>Perhaps I don't fully understand all of the details you assume to
>hold in the server-based example.  I may be confusing different
>scenarios:
>
>1.  Cert says "owned by BigCorp, as key nnn" but I control its use,
>    or at least I did last Thursday when I checked it out.


This is the hard one.  "I" may have checked it out but I installed in
an automated system which is administered and owned by BigCorp


>2.  Cert says "owned by Tony", and the company controls its use in
>    some automated system, with my supposed blessings/restrictions.
>
>In the second case, the RP would be expected to come after me directly.
>If I am innocent, I am forced to take issue with the company.

Unusual case but possible¨

>
>In each case, the RP can turn only to the "certificateSubject".


Absolutely!  But the reference in the cited text in the beginning is
slightly wrong if
it deals woth personal data in situations like #1

Anders





Received: from gauntlet.corecom.com ([206.74.64.137]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21463 for <[e-mail]>; Wed, 1 Dec 1999 07:29:50 -0800 (PST)
Received: by gauntlet.corecom.com; id KAA13468; Wed, 1 Dec 1999 10:56:15 -0500 (EST)
Received: from unknown(207.86.152.184) by gauntlet.corecom.com via smap (V4.2) id xmaa13462; Wed, 1 Dec 99 10:55:50 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail2.netreach.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 01 Dec 1999 10:15:16 -0500
To: [e-mail]
From: Dave Piscitello <[e-mail]>
Subject: TISC Call for Papers
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

The Fourth Internet Security Conference will be held
April 24-28, 2000 in San Jose, CA, at the Fairmont
Hotel. TISC is an educational forum for security
professionals and practitioners. The TISC Security
Symposium is an opportunity for individuals to share
their expertise and practical experience with others
involved in the design, implementation and deployment
of networked security systems.

For April, we have invited a few original papers from
past TISC workshop instructors and speakers. Accepted
papers will be presented at the conference.

We cordially invite you to submit a session abstract for
consideration, or if you prefer, to present a topic as
a panel member. We encourage you to submit abstracts and
topics by December 17. Further information can be found
at http://tisc.corecom.com. Or send your proposal to me
directly (mailto:[e-mail]).

We look forward to your participation. Thank you.

Warm Regards,

Dave Piscitello
On behalf of the TISC Advisory Board 


-------------------
David M. Piscitello
Core Competence, Inc.
3 Myrtle Bank Lane
Hilton Head, SC 29926
1.843.683-9988
[e-mail]
PGP Fingerprint: 070A 9F01 C35C 4D41 A460 EF2C 2992 2F12 11D2 02DC
http://www.corecom.com



Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA14737 for <[e-mail]>; Wed, 1 Dec 1999 02:21:20 -0800 (PST)
Received: from HYDRA ([195.198.186.73]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA22945; Wed, 1 Dec 1999 11:18:54 +0100
Received: by HYDRA with Microsoft Mail id <01BF3BED.AC536E20@HYDRA>; Wed, 1 Dec 1999 11:17:37 +0100
Message-ID: <01BF3BED.AC536E20@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, "'Charles Moore'" <[e-mail]>
Cc: "'David P. Kemp'" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 11:17:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Charles,

<snip>

cm> If all certs must have an unique identifier then one CANNOT control the 
usage of the number....

They don't.  This is just a "feature" that some QC-implementations (profiles) require.

If unique identifiers are bad or good is outside of the QC-draft.  The technical reasons
for using them are pretty clear.    As well as the possible consequences as you point out.

Regarding the changed serialnumber semantics: Does it break any existing code?
I can hardly see that.

Anders




Received: from ozspyrusmail.spyrus.com.au (fwuser@[203.46.55.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13308 for <[e-mail]>; Wed, 1 Dec 1999 01:51:24 -0800 (PST)
Message-ID: <917ACEDEAC7DD211A0660080C890305F093AE0@OZSPYRUSMAIL>
From: Charles Moore <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, Charles Moore <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>
Cc: "'David P. Kemp'" <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Date: Wed, 1 Dec 1999 19:56:04 +1000 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA13309

>===== Original Message From Stefan Santesson <SMTP:[e-mail]>
=====
>Charles,
>
>At 04:02 PM 12/1/99 +1000, Charles Moore wrote:
><snip>
>>Back to the past....
>>
>>I am not arguing that serial number or dnq be exclusively used, my
personal
>>preference would be dnq, but rather require we have a standard that
reflects
>>reality and provides a long term solution that can be used by all existing
>>communities...not selective interest groups...
>>
>>I have a problem with overloading of semantics, as they produce
>>indeterminate results...
>>I also dont believe a CP is the means to achieve this, keep the protocol
>>clean and use rules/policy to determine the usage....
>>
>
>One thing that may have to be clarified here is that I have had a dialogue
>with Sharon Boyen, who is involved in the X.509, X.520 and X.521
>standardization, and she claims that they are willing to change the
>definition of serialNumber and related object classes, so that this
>attribute can be used for any type of object.
cm> Who is they?? I have not seen this proposal in the current ITU text, but

then I could have missied it??

>
>Sharon says that this is considered to be a minor adjustment that almost
>was fixed 4 years ago but was forgotten in the process.
>
>This is the fundamental reason for proposing use of serialNumber.
>
>Having this in mind, I fail to see any problems.
>
cm> This issue we are addressing is one of existing usage, not an pure 
stanadards issue, I take some exception to people that change semantics or 
syntax and leave the OIDs the same. X.9.42 DH key as an example ( only
saving 
grace was that there was very little deployments). In the end of the day
these 
fall on the people that build systems....


>
>I' don't want to enter a privacy discussion here, but I just want to stress
>that there is NOTHING in the QC profile that require inclusion of privacy
>sensitive information. In fact, the possibility to use a Pseudonym name is
>clearly stated. 
cm> Pseudonyms are not the issue...

The use of a unique identifier doesn't necessarily means
>that it is privacy sensitive. That depends completely what you can do with
>that number.
cm> If all certs must have an unique identifier then one CANNOT control the 
usage of the number.... I understand the requirement for uniqueness or I 
prefer disabiguation information, just want to be sure it has the right 
objective...
Hence the semantics of the proposal....


>
>The fact is that we need to add support for inclusion of such identifiers,
>regardless of their actual content.
cm> Why??

>
>/Stefan
>-------------------------------------------------------------------
>Stefan Santesson                <[e-mail]>
>Accurata AB                     http://www.accurata.se
>Slagthuset                      Tel. [phone]
>211 20  Malmö                   Fax. [phone]
>Sweden                        Mobile [phone]
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------


Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12975 for <[e-mail]>; Wed, 1 Dec 1999 01:35:36 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id KAA02985; Wed, 1 Dec 1999 10:37:33 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 01 Dec 1999 10:38:06 +0100
To: Charles Moore <[e-mail]>, "'Anders Rundgren'" <[e-mail]>, "'Tony Bartoletti'" <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: unqualified topic - not solved yet.
Cc: "David P. Kemp" <[e-mail]>
In-Reply-To: <917ACEDEAC7DD211A0660080C890305F093ADE@OZSPYRUSMAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA12978

Charles,

At 04:02 PM 12/1/99 +1000, Charles Moore wrote:
<snip>
>Back to the past....
>
>I am not arguing that serial number or dnq be exclusively used, my personal
>preference would be dnq, but rather require we have a standard that reflects
>reality and provides a long term solution that can be used by all existing
>communities...not selective interest groups...
>
>I have a problem with overloading of semantics, as they produce
>indeterminate results...
>I also dont believe a CP is the means to achieve this, keep the protocol
>clean and use rules/policy to determine the usage....
>

One thing that may have to be clarified here is that I have had a dialogue
with Sharon Boyen, who is involved in the X.509, X.520 and X.521
standardization, and she claims that they are willing to change the
definition of serialNumber and related object classes, so that this
attribute can be used for any type of object.

Sharon says that this is considered to be a minor adjustment that almost
was fixed 4 years ago but was forgotten in the process.

This is the fundamental reason for proposing use of serialNumber.

Having this in mind, I fail to see any problems.


I' don't want to enter a privacy discussion here, but I just want to stress
that there is NOTHING in the QC profile that require inclusion of privacy
sensitive information. In fact, the possibility to use a Pseudonym name is
clearly stated. The use of a unique identifier doesn't necessarily means
that it is privacy sensitive. That depends completely what you can do with
that number.

The fact is that we need to add support for inclusion of such identifiers,
regardless of their actual content.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------