Re: Changes to RFC2459

["Peter Williams" <[e-mail]>]

-----Original Message-----
From: Jim Schaad (Exchange) <[e-mail]>
To: 'Stephen Kent' <[e-mail]>; Moshe Litvin <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, March 31, 1999 3:04 PM
Subject: RE: Changes to RFC2459


>Steve,
>
I think it is important to note that
>there is nothing in a certificate that says I am PKIX compliant.  This
>certificate could have been issued by somebody following the boondogle X509
>certificate profile,:) and we are interpreting it under a different
profile.
>If we make sure the profile can make explicit statements then we don't have
>this issue.



The cert policy id field is surely usable as a CA-signal that a profile is
in use,
and its assurances enable one to trust that a cert conforms to a
profile. relying parties require particular extension schemas etc, by
requiring
particular cert policy ids, or local policy id mappings.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03326 for ietf-pkix-bks; Wed, 31 Mar 1999 13:42:17 -0800 (PST)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03321 for <[e-mail]>; Wed, 31 Mar 1999 13:42:16 -0800 (PST)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [209.185.6.5]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id NAA19095; Wed, 31 Mar 1999 13:41:46 -0800 (PST)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id NAA16771; Wed, 31 Mar 1999 13:41:48 -0800 (PST)
Message-ID: <006301be7baf$2bb70320$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Jim Schaad (Exchange)" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Changes to RFC2459
Date: Wed, 31 Mar 1999 13:46:29 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Jim Schaad (Exchange) <[e-mail]>
To: 'Stephen Kent' <[e-mail]>; Moshe Litvin <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, March 31, 1999 3:04 PM
Subject: RE: Changes to RFC2459


>Steve,
>
I think it is important to note that
>there is nothing in a certificate that says I am PKIX compliant.  This
>certificate could have been issued by somebody following the boondogle X509
>certificate profile,:) and we are interpreting it under a different
profile.
>If we make sure the profile can make explicit statements then we don't have
>this issue.



The cert policy id field is surely usable as a CA-signal that a profile is
in use,
and its assurances enable one to trust that a cert conforms to a
profile. relying parties require particular extension schemas etc, by
requiring
particular cert policy ids, or local policy id mappings.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23481 for ietf-pkix-bks; Wed, 31 Mar 1999 11:31:06 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23477 for <[e-mail]>; Wed, 31 Mar 1999 11:31:05 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <HY5MGDKT>; Wed, 31 Mar 1999 11:30:47 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5E01@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Moshe Litvin <[e-mail]>
Cc: [e-mail]
Subject: RE: Changes to RFC2459
Date: Wed, 31 Mar 1999 11:30:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I think that there are some significant differences between the case of the
ASN where the value is implicit and the idea that the value is implicit
because it is in the PKIX profile.

In the ASN there is a known spot for the value and only one way to interpret
the absentence of that value.  If the entire extension is missing there are
atleast two different ways to interpret the missing value.  One if you
assume the certificate is issued in accordence with the PKIX profile and one
if you don't make that assumption.  I think it is important to note that
there is nothing in a certificate that says I am PKIX compliant.  This
certificate could have been issued by somebody following the boondogle X509
certificate profile,:) and we are interpreting it under a different profile.
If we make sure the profile can make explicit statements then we don't have
this issue.

I think that the working needs to be MAY, but I have no problems with adding
text to the effect that the same information can be derived from the
KeyUsage extension if it is present (which it does not need to be).  I also
agree that a statement about savings can be put in.  But since there is
nothing to make a positive statement about a certificate being under the
PKIX profile the assuming that something is true by omission is dangerous.

jim


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Tuesday, March 30, 1999 3:06 PM
To: Moshe Litvin
Cc: [e-mail]
Subject: Re: Changes to RFC2459


I agree that the second approach leaves less room for error, but then one
could make similar observations for many other aspects of this and other
standards.  For example, throughout X.509 we make use of default values
that result in NULL or non-present encodings.  In fact, the convention that
you suggest we adopt relies on the default value for the CA Boolean being
false, and thus encoded as NULL, right?  Would it not be better, in the
spirit you describe, to have an explicit flag for an EE?

I think this example points out that we have made a number of decisions of
this flavor in these standards.  We are not talking about fundamental
differences, just value judgements about when we want to save space and
rely on implicit values (not in the ASN.1 tagging sense) vs. putting in
explicit flags, version numbers, etc.   The authors of 2459 made a decision
and so far we have not seen a flood of sentiment that suggests we ought to
change this part of the standard.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22621 for ietf-pkix-bks; Wed, 31 Mar 1999 11:20:19 -0800 (PST)
Received: from raptor.globalsign.net (unknown-195-207.eunet.be [195.207.49.1] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22614 for <[e-mail]>; Wed, 31 Mar 1999 11:20:17 -0800 (PST)
Received: from globalsign.net (unverified [195.238.25.13]) by raptor.globalsign.net (Rockliffe SMTPRA 3.2.1) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 31 Mar 1999 20:19:54 +0100
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 21:19:04 +0200
From: Marc Jadoul <[e-mail]>
Organization: BelSign NV/SA
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: fr, en, nl
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Does it exist: CA certificate DP ?
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I am asking my self how to download the CA certificate (or even a chain
to a root CA certificate if we do it recursively) when we just know the
client certificate.

In rfc2459 speak about 'Authority Information Access' but it does not
seems to respond to my question or may be i does not understand it.

Does it exist some kind of standard CA certificate distribution point
extension (like crl DP extention) that would permit to download all the
CA certificates(possibly from an pkiCA object in a ldap) of the CA that
signed the certificate.

That would permit to find all path from the certificate i want verify to
Root CAs and see if any of these Root is trusted by me.

Marc Jadoul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA20243 for ietf-pkix-bks; Wed, 31 Mar 1999 10:48:59 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA20237 for <[e-mail]>; Wed, 31 Mar 1999 10:48:59 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id KAA11211; Wed, 31 Mar 1999 10:49:18 -0800
Message-ID: <008301be7ba6$900a1500$c74bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Wed, 31 Mar 1999 10:44:50 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19088 for ietf-pkix-bks; Wed, 31 Mar 1999 10:34:41 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19073 for <[e-mail]>; Wed, 31 Mar 1999 10:34:34 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id KAA04337; Wed, 31 Mar 1999 10:31:00 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 31 Mar 1999 10:30:38 -0800
To: "Todd S. Glassey" <[e-mail]>, "Paul Koning" <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Cc: <[e-mail]>
In-Reply-To: <002b01be7b28$d2446ac0$cb4bffd0@brick>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:44 PM 3/30/99 -0800, Todd S. Glassey wrote:
>How will you deal with leap seconds?
>

The only solution I can think of would be UGLY, but would preserve
the all-important monotonicity.  At least it would work when a
leap-second is added. (Subtracting is another matter.  You would
already have monotonicity, but differencing might be difficult.) 

Add another field to the "seconds", as little as one "bit", that
is always zero except for a leap-second, when it is "one."

  E.G.   leap.seconds.milliseconds

Now, if (say) the 23rd second of this minute had to be "repeated"
(the clock is being set back 1 second, "gaining" a leap second,)
then it would first occur as 0.23.ms, and then a second later
as 1.23.ms.

Thus, the sequence of timestamps of seconds from 21 to 25 might
be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with

    0.23 < 1.23, and 1.23 < 0.24

Losing a leap-second (should that ever happen) is another matter.
One could just drop the "missing" second as the clock advances.
E.G.

    0.21, 0.22, 0.24, 0.25

Monotonicity is preserved.  Differencing is a headache.

I wonder how they will actually deal with this.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16545 for ietf-pkix-bks; Wed, 31 Mar 1999 10:03:39 -0800 (PST)
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16539 for <[e-mail]>; Wed, 31 Mar 1999 10:03:38 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgiyi23316; Wed, 31 Mar 1999 13:02:45 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01833; Wed, 31 Mar 99 12:58:41 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA03008; Wed, 31 Mar 1999 13:02:39 -0500
Date: Wed, 31 Mar 1999 13:02:39 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
References: <002b01be7b28$d2446ac0$cb4bffd0@brick>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05421 for ietf-pkix-bks; Wed, 31 Mar 1999 05:49:16 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05417 for <[e-mail]>; Wed, 31 Mar 1999 05:49:13 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA27142; Wed, 31 Mar 1999 15:49:03 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 31 Mar 1999 15:49:03 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id PAA03719; Wed, 31 Mar 1999 15:49:02 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id PAA18311; Wed, 31 Mar 1999 15:49:01 +0200
Date: Wed, 31 Mar 1999 15:49:01 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Low-fat leaf certificates
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> That is what CyberPhone is all about.  A CyberID SUBJECT is
> supposed to consist of just two items:
> 
> 1)  "Name"  (an alias/friendly name [as you are allowed to change name without changing "e"-identity])
> 
> 2) "dnQualifier"  (a static [probably random] unique identifier in the domain)
> 
> It is hard to get much slimmer than that!
> 
No, you don't need 1. 

Actually 2 is 'the name' in the sense of a unique identifier to find a directory entry.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04721 for ietf-pkix-bks; Wed, 31 Mar 1999 04:05:55 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04715 for <[e-mail]>; Wed, 31 Mar 1999 04:05:53 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id OAA14880; Wed, 31 Mar 1999 14:05:57 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 31 Mar 1999 14:06:39 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Conclusion - Biometric inclusion in QC
Cc: IETF-PXIX <[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 mail.proper.com id EAA04718
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:09 AM 3/31/99 +0200, Denis Pinkas wrote:
<snip>
>I do not believe you met any Dennis Pinkas, maybe you met a Denis Pinkas.

Sorry for that !

<snip>
>> And don't forget that putting a hash of a picture in a QC, is already a
>> valid option. For example you can use this hash as a unique identifier
>> (issued by the CA) and put it in the dNQualifier attribute. Then include an
>> attributeSemantics OID defining this property. And you are all set !!
>
>If I understand correctly, you mean that we have some means to have an
extension,
>... but we still need to define that extension.
>This is exactly what I am advocating for.
>

Not exactly an extension. We define a new "PersonalData" field stored in
the otherName field in the subjectAltName extension. All this is found in
section 3.2.1 of the draft. 

This field has the capability you are asking for. i.e. holding a hash of a
photo, plus the fact that you can communicate to the relying party that it
does.

/Stefan


>Regards,
>
>Denis



-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA04647 for ietf-pkix-bks; Wed, 31 Mar 1999 03:55:36 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA04643 for <[e-mail]>; Wed, 31 Mar 1999 03:55:34 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA14753 for <[e-mail]>; Wed, 31 Mar 1999 13:55:33 +0200
Received: from HYDRA ([195.198.186.68]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA98910; Wed, 31 Mar 1999 13:55:26 +0200
Received: by HYDRA with Microsoft Mail id <01BE7B7E.2DB86EB0@HYDRA>; Wed, 31 Mar 1999 13:55:47 +0200
Message-ID: <01BE7B7E.2DB86EB0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Low-fat leaf certificates
Date: Wed, 31 Mar 1999 13:55:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,
Just to make sure that you don't misunderstand me:

I am VERY much in favor of your "Low-fat leaf certificates".

That is what CyberPhone is all about.  A CyberID SUBJECT is
supposed to consist of just two items:

1)  "Name"  (an alias/friendly name [as you are allowed to change name without changing "e"-identity])

2) "dnQualifier"  (a static [probably random] unique identifier in the domain)

It is hard to get much slimmer than that!

But a "low-fat" cert may have a "fat" cousin cert that does the dirty work in the
rare situations that requires it.  And if they can share a common format life will
be simpler than if all "fat" data has to be handled "out-of-band" instead of in
nice "structured signed and certified containers of data"

Regards
Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA04609 for ietf-pkix-bks; Wed, 31 Mar 1999 03:42:04 -0800 (PST)
Received: from cbucc.chungbuk.ac.kr (cbucc.chungbuk.ac.kr [134.75.201.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA04605 for <[e-mail]>; Wed, 31 Mar 1999 03:41:57 -0800 (PST)
Received: from dblab.chungbuk.ac.kr (dblab.chungbuk.ac.kr [210.115.167.65]) by cbucc.chungbuk.ac.kr (8.8.8/8.8.8) with SMTP id UAA09596; Wed, 31 Mar 1999 20:48:52 +0900 (KST)
Received: from dblab.chungbuk.ac.kr by dblab.chungbuk.ac.kr (SMI-8.6/SMI-SVR4) id UAA05608; Wed, 31 Mar 1999 20:46:38 +0900
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 20:42:21 +0900
From: Sung-Hee Park <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: ko,en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: question
References: <[e-mail]>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi !!
Delta CRL don't include  Whole lists of certificate which  are revocated
by issuing CA. It include only latest revocation list of certificates.

You can find it in RFC 2459 and also it is  as following as site

ftp://ftp.isi.edu/in-notes/rfc2459.txt

[e-mail] wrote:

> Hello.
>
> I would like to know Delta-CRL.
> Is there anybody who know it?
> Please let me know.
>
> Best regards
>
> --
> Joong-Hyo Oh
> Technical Research Office, Elec. Banking R&D Center
> Korea Telecommunications & Clearings Institute
>
> Tel : [phone]
> Fax : [phone]
> E-mail : [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA00841 for ietf-pkix-bks; Wed, 31 Mar 1999 01:13:15 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA00833 for <[e-mail]>; Wed, 31 Mar 1999 01:13:09 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA11684; Wed, 31 Mar 1999 11:08:39 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA43184; Wed, 31 Mar 1999 11:09:40 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 11:09:23 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Conclusion - Biometric inclusion in QC
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

My comments are along the lines.

> Denis,
>
> I believe it was me who pointed out the possibility to include a hash of a
> precalculated bio-metric template.

There may be quite true, I did not checked who it was.


> It didn't get that much support on this
> list but I agree that it would work very well in some applications.

Good.


> To the problem. How do I know that the message I now reply to, was written
> by that Dennis Pinkas that I met in Minneapolis???

I do not believe you met any Dennis Pinkas, maybe you met a Denis Pinkas.


> Probably because that would certainly be the only Dennis Pinkas in the
> world who would talk about "low-fat leaf certificates" :-)  Right?

No. Any one of the 400 persons that was at the PKIX meeting could impersonate me
by talking of "low-fat leaf certificates". Anyway, this is not the main topic.


> So your name is not the only thing that convince me that this is you. Even
> so in this environment anyone could use your name. Still I'm almost 100%
> sure that this message came from the real Dennis Pinkas. Why? Because it
> makes sense.

More important, because it comes from an e-mail address that sounds correct.

> What I'm trying to say is that in most cases in life, we do just fine with
> a name, and the fact that the person speaks about the right things, and in
> a way, that makes sense to us. In some cases this is not enough but that's
> often the cases where the "trusting" party also know you by some of your
> unique identifiers (such as SSN).
>
> But never the less. Your scenario may also be very valid.

Fine.

> I just wander if
> this is such a large issue that it makes it worth putting down all the hard
> work it takes to come up with an agreeable solution that will enhance
> interoperability in any meaningful way (more than the current profile
> already does).

I believe that, if we have consensus, it will be interesting to support this
capability.

> And don't forget that putting a hash of a picture in a QC, is already a
> valid option. For example you can use this hash as a unique identifier
> (issued by the CA) and put it in the dNQualifier attribute. Then include an
> attributeSemantics OID defining this property. And you are all set !!

If I understand correctly, you mean that we have some means to have an extension,
... but we still need to define that extension.
This is exactly what I am advocating for.

Regards,

Denis


> /Stefan
>
> At 04:42 PM 3/30/99 +0200, Denis Pinkas wrote:
> >Stefan,
> >
> >I have kept silent but looked at this interresting discussion. I will re-use
> >some of the arguments sent to the list.
> >
> >How can I make a difference between "the" John Brown I met last monday and
> the
> >other 2000 (?) John Brown's ?
> >Maybe "my" John Brown is John Brown 1278, but in fact I do not know. I could
> >easily make the difference if the picture from John Brown was included in the
> >certificate. While reading this, some might jump from their chair since I
> have
> >been advocating low-fat leaf certificates at the last PKIX meeting !
> >
> >The solution has already been given on this list. Instead of including the
> >whole picture, a hash of the picture could be included. Now John Brown could
> >provide me with the picture while sending me a signed message and I could
> >verify that it corresponds to the picture of the John Brown I met.
> >
> >Two observations:
> >
> >1) John Brown is free to release me his picture or not. In this way his
> privacy
> >may be respected, even if his certificate is published.
> >2) Once I got the picture, I do not need it once again. This solves bandwith
> >for other exchanges.
> >
> >As a conclusion, I would welcomme an extension able to handle hash values of
> >biometric information, in particular pictures.
> >
> >Denis
> >
> >
> >> I have now concluded the bio-metric topic as settled.
> >>
> >> The conclusion is to NOT include support for bio-metric data in the profile
> >> at this stage.
> >> At least not until the list has provided an agreeable solution that can
> >> enhance interoperability in some meaningful way.
> >>
> >> The informational web site http://www.accurata.se/QC/ has been updated with
> >> the rationale for this conclusion.
> >>
> >> Look under "Settled topics"
> >>
> >> /Stefan
> >> -------------------------------------------------------------------
> >> Stefan Santesson                <[e-mail]>
> >> Accurata Systemsäkerhet 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
> >> -------------------------------------------------------------------
> >
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA00749 for ietf-pkix-bks; Wed, 31 Mar 1999 01:10:56 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA00744 for <[e-mail]>; Wed, 31 Mar 1999 01:10:54 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA09771; Wed, 31 Mar 1999 11:10:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 31 Mar 1999 11:10:51 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA28914; Wed, 31 Mar 1999 11:10:50 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA17055; Wed, 31 Mar 1999 11:10:50 +0200
Date: Wed, 31 Mar 1999 11:10:50 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Time-stamp server. TimePrecision info
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> How will you deal with leap seconds?
Sleep. :-)

 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA29644 for ietf-pkix-bks; Wed, 31 Mar 1999 00:45:45 -0800 (PST)
Received: from kftc.kftc.or.kr (nsmail@[210.103.193.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA29637 for <[e-mail]>; Wed, 31 Mar 1999 00:45:43 -0800 (PST)
From: [e-mail]
Received: from kftc.or.kr ([203.242.199.26]) by kftc.kftc.or.kr (Netscape Messaging Server 3.6)  with ESMTP id AAAFA2 for <[e-mail]>; Wed, 31 Mar 1999 17:44:43 +0900
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 17:43:59 +0900
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello.

I would like to know Delta-CRL.
Is there anybody who know it?
Please let me know.

Best regards

--
Joong-Hyo Oh
Technical Research Office, Elec. Banking R&D Center
Korea Telecommunications & Clearings Institute

Tel : [phone]
Fax : [phone]
E-mail : [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA29419 for ietf-pkix-bks; Wed, 31 Mar 1999 00:30:12 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA29415 for <[e-mail]>; Wed, 31 Mar 1999 00:30:10 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id KAA12036; Wed, 31 Mar 1999 10:30:00 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 31 Mar 1999 10:30:42 +0200
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Conclusion - Biometric inclusion in QC
Cc: IETF-PXIX <[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 mail.proper.com id AAA29416
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I believe it was me who pointed out the possibility to include a hash of a
precalculated bio-metric template. It didn't get that much support on this
list but I agree that it would work very well in some applications.

To the problem. How do I know that the message I now reply to, was written
by that Dennis Pinkas that I met in Minneapolis??? 
Probably because that would certainly be the only Dennis Pinkas in the
world who would talk about "low-fat leaf certificates" :-)  Right?

So your name is not the only thing that convince me that this is you. Even
so in this environment anyone could use your name. Still I'm almost 100%
sure that this message came from the real Dennis Pinkas. Why? Because it
makes sense.

What I'm trying to say is that in most cases in life, we do just fine with
a name, and the fact that the person speaks about the right things, and in
a way, that makes sense to us. In some cases this is not enough but that's
often the cases where the "trusting" party also know you by some of your
unique identifiers (such as SSN).

But never the less. Your scenario may also be very valid. I just wander if
this is such a large issue that it makes it worth putting down all the hard
work it takes to come up with an agreeable solution that will enhance
interoperability in any meaningful way (more than the current profile
already does).

And don't forget that putting a hash of a picture in a QC, is already a
valid option. For example you can use this hash as a unique identifier
(issued by the CA) and put it in the dNQualifier attribute. Then include an
attributeSemantics OID defining this property. And you are all set !!

/Stefan
 

At 04:42 PM 3/30/99 +0200, Denis Pinkas wrote:
>Stefan,
>
>I have kept silent but looked at this interresting discussion. I will re-use
>some of the arguments sent to the list.
>
>How can I make a difference between "the" John Brown I met last monday and
the
>other 2000 (?) John Brown's ?
>Maybe "my" John Brown is John Brown 1278, but in fact I do not know. I could
>easily make the difference if the picture from John Brown was included in the
>certificate. While reading this, some might jump from their chair since I
have
>been advocating low-fat leaf certificates at the last PKIX meeting !
>
>The solution has already been given on this list. Instead of including the
>whole picture, a hash of the picture could be included. Now John Brown could
>provide me with the picture while sending me a signed message and I could
>verify that it corresponds to the picture of the John Brown I met.
>
>Two observations:
>
>1) John Brown is free to release me his picture or not. In this way his
privacy
>may be respected, even if his certificate is published.
>2) Once I got the picture, I do not need it once again. This solves bandwith
>for other exchanges.
>
>As a conclusion, I would welcomme an extension able to handle hash values of
>biometric information, in particular pictures.
>
>Denis
>
>
>> I have now concluded the bio-metric topic as settled.
>>
>> The conclusion is to NOT include support for bio-metric data in the profile
>> at this stage.
>> At least not until the list has provided an agreeable solution that can
>> enhance interoperability in some meaningful way.
>>
>> The informational web site http://www.accurata.se/QC/ has been updated with
>> the rationale for this conclusion.
>>
>> Look under "Settled topics"
>>
>> /Stefan
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet 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
>> -------------------------------------------------------------------
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA27346 for ietf-pkix-bks; Tue, 30 Mar 1999 23:54:34 -0800 (PST)
Received: from natasha1. (natasha-gw.checkpoint.com [199.203.73.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA27336 for <[e-mail]>; Tue, 30 Mar 1999 23:54:31 -0800 (PST)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id JAA02262; Wed, 31 Mar 1999 09:56:22 +0200 (IST)
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 1999 09:53:42 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Changes to RFC2459
References: <v04020a25b31e71f88059@[128.33.238.119]> <v04020a12b327073ae689@[128.89.0.110]>
Content-Type: multipart/mixed; boundary="------------E5C0071681B75CE091A91769"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------E5C0071681B75CE091A91769
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

The main point wasn't about default values, but relying on inventing a PKIX way to
convey information where there was another way in the X.509 standards. By using the
PKIX  way you limit the number of implementations that can understand you correctly
(and you do it without giving them a clue that they misunderstand you).

Moshe

Stephen Kent wrote:

> Moseh,
>
> >There is no ambiguity as long as you know that the certificate issuer
> >completely
> >obey RFC 2459, if you are not sure then the absence of the extension is
> >ambiguous. That is if you create a certificate and want to mark it as EE
> >you have
> >two options:
> >
> >1. You can go by RFC 2459 and not put the basic constraints extension.
> >Every one
> >that read the fine prints of the RFC and know that you obey all the fine
> >prints
> >will understand that this is an EE certificate.
> >
> >2. You can put a basic constraints extension that explicitly says that the
> >certificate is not a CA certificate. Everyone that know how to parse the basic
> >extension will understand it (without assuming what X509 profile you are
> >following).
> >
> >I think that the second option is better and should be encourage (if not
> >mandated).
>
> I agree that the second approach leaves less room for error, but then one
> could make similar observations for many other aspects of this and other
> standards.  For example, throughout X.509 we make use of default values
> that result in NULL or non-present encodings.  In fact, the convention that
> you suggest we adopt relies on the default value for the CA Boolean being
> false, and thus encoded as NULL, right?  Would it not be better, in the
> spirit you describe, to have an explicit flag for an EE?
>
> I think this example points out that we have made a number of decisions of
> this flavor in these standards.  We are not talking about fundamental
> differences, just value judgements about when we want to save space and
> rely on implicit values (not in the ASN.1 tagging sense) vs. putting in
> explicit flags, version numbers, etc.   The authors of 2459 made a decision
> and so far we have not seen a flood of sentiment that suggests we ought to
> change this part of the standard.
>
> Steve

--------------E5C0071681B75CE091A91769
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------E5C0071681B75CE091A91769--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA09112 for ietf-pkix-bks; Tue, 30 Mar 1999 20:10:51 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA09099 for <[e-mail]>; Tue, 30 Mar 1999 20:10:49 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id UAA10784; Tue, 30 Mar 1999 20:10:31 -0800
Message-ID: <003d01be7b2b$d03ecf60$cb4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Simon Laing" <SECURITY/SDPL/[e-mail]>, "Andrew Shellshear" <SECURITY/SDPL/[e-mail]>
Subject: Re: Time-stamp server. Extra field for MessageImpring
Date: Tue, 30 Mar 1999 20:06:09 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SNIP ---



>We'd like to propose adding an extra field to the messageImprint structure:
>
>Currently, there is no easy way to link the message hash included in the
time-stamp-request to the original >message. However, most systems will have
an [obvious] requirement to associate a time stamp with the >original
message. Most  simply, this could be done by incorporating the original
message's filename (or >some other >internal >reference information) into
the time stamp.

As far as the evidentiary processes is concerned, I would think that making
this extension a pointer to an external structure is not the best way to
accomplish an archival process, rather the better method is encapsulating
the whole timestamp into a complex token structure. Which brings us to the
next requirement of timestamping, the creation and standardization of basic
time tokens...

Todd




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA06601 for ietf-pkix-bks; Tue, 30 Mar 1999 19:53:55 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA06597 for <[e-mail]>; Tue, 30 Mar 1999 19:53:54 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id TAA10770; Tue, 30 Mar 1999 19:54:04 -0800
Message-ID: <003601be7b29$85ec6410$cb4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "'Simon Laing'" <SECURITY/SDPL/[e-mail]>, "'Andrew Shellshear'" <SECURITY/SDPL/[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Tue, 30 Mar 1999 19:49:43 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert -
The precision of the timestamp is actually of key interest to few subsecond
processes existing today, but its really there for tomorrow - The real issue
is that with the amount of calendar time that it takes to get a standard in
place, the resolution of the timestamps will likely be of serious
technological import *prior* to any significant legislation or approval at
the end user level being enacted.

So address a couple of issues proactively and deal with the resolution
issue, down to microseconds at least.


Todd



-----Original Message-----
From: Robert Zuccherato <[e-mail]>
To: '[e-mail]' <[e-mail]>; '[e-mail]'
<[e-mail]>; '[e-mail]'
<[e-mail]>
Cc: 'Simon Laing' <SECURITY/SDPL/[e-mail]>; 'Andrew
Shellshear' <SECURITY/SDPL/[e-mail]>
Date: Tuesday, March 30, 1999 7:25 AM
Subject: RE: Time-stamp server. TimePrecision info


>Personally, I have no problem with adding an optional timePrecision field
to
>specify the accuracy of the given time stamp.  I think that in some
>applications that can be useful information, particularly when the time
>stamp token will be kept for evidence purposes.  However, I really don't
>think it would be wise to make the serial number mandatory.  I agree that
in
>some situations it may be critical for clients to know "who was first" if
>the resolution of the timestamp means that they both have the same value
for
>the time.  But, I don't think that it will be critical in all applications.
>Therefore, I would rather not make it mandatory and force its use on those
>applications (and TSA's supporting them) where it is not required.
>
> Robert Zuccherato.
>
>> ----------
>> From: Michael Zolotarev[SMTP:[e-mail]]
>> Reply To: [e-mail]
>> Sent: Monday, March 29, 1999 10:38 PM
>> To: '[e-mail]'; '[e-mail]'
>> Cc: 'Simon Laing'; 'Andrew Shellshear'
>> Subject: RE: Time-stamp server. TimePrecision info
>>
>> Michael,
>> Technically you are right, and I certainly agree that monotonicity is
>> absolutely essential, and assumed. It is accuracy and precision which I
am
>>
>> trying to address here.
>>
>> I believe that when considering what might go into a time stamp, we
should
>>
>> think in terms of what a user would NEED to know. After all, what matters
>> for a client is
>> 1) how trustworthy is the TSA in general, and
>> 2) how accurate is the time in that particular time stamp.
>>
>> Presenting a customer with extra details, like splitting the quality of
>> the
>> time into its precision and accuracy, may unnecessarily overcomplicate
the
>>
>> issue, without giving much information anyway.
>>
>> A reference to the source(s) of time data, available from the TSA's
>> policy,
>> should be a starting point for anybody who wants to know more about
>> characteristics of the time.
>>
>> Thinking of monotonicity:
>> Should the TSTInfo::serialNumber field be OPTIONAL? In addition to
serving
>>
>> as just an extra proof of monotonicity, which is assumed anyway, the
>> serialNumber may be the only way to resolve a 'who was the first'
>> argument.
>> If two requests arrived virtually 'simultaneously', the TSS will generate
>> two time stamps with the same time value. The probability of it depends
on
>>
>> the resolution of the time source used. It may be critical for the
clients
>>
>> to know who was actually the first (thinking of on-line betting,
auctions,
>>
>> etc). This turns the serialNumber into a mandatory field, doesn't it?
>>
>> Michael Zolotarev
>> Technical Architect, Baltimore Technologies Ltd (Australia)
>>
>> -----Original Message-----
>> From: Michael Sierchio [SMTP:[e-mail]]
>> Sent: Monday, March 29, 1999 3:32 PM
>> To: [e-mail]
>> Cc: '[e-mail]'; Simon Laing; Andrew Shellshear
>> Subject: Re: Time-stamp server. TimePrecision info
>>
>> Michael Zolotarev wrote:
>> > ...
>> > for example, the policy might state: "The time returned will be
accurate
>>
>> to
>> > within 100ms, and if the time-stamp server cannot
>> > provide this level of accuracy, it will not issue a time-stamp."
>>
>> It seems to me that there are three qualities of interest for
>> timestamps, in increasing order of importance -- precision, accuracy,
>> and monotonicity.  The last is essential,  and perhaps more important
>> than the other two.
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA05850 for ietf-pkix-bks; Tue, 30 Mar 1999 19:49:03 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA05838 for <[e-mail]>; Tue, 30 Mar 1999 19:48:54 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id TAA10767; Tue, 30 Mar 1999 19:49:02 -0800
Message-ID: <002b01be7b28$d2446ac0$cb4bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "Paul Koning" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
Date: Tue, 30 Mar 1999 19:44:40 -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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

How will you deal with leap seconds?

T.

-----Original Message-----
From: Paul Koning <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Tuesday, March 30, 1999 10:26 AM
Subject: RE: Time-stamp server. TimePrecision info


>>>>>> "Robert" == Robert Zuccherato <[e-mail]> writes:
>
> Robert> Personally, I have no problem with adding an optional
> Robert> timePrecision field to specify the accuracy of the given time
> Robert> stamp. ...
>
> >> ---------- From: Michael Zolotarev
> >> ...we should
> >> think in terms of what a user would NEED to know. After all, what
> >> matters for a client is 1) how trustworthy is the TSA in general,
> >> and 2) how accurate is the time in that particular time stamp.
> >>
> >> Presenting a customer with extra details, like splitting the
> >> quality of the time into its precision and accuracy, may
> >> unnecessarily overcomplicate the
> >> issue, without giving much information anyway.
>
>These sound like good things.  If they are done, though, it would be
>very helpful if ambiguous words like "precision" and "accuracy" are
>avoided (and in particular, not used as terms intended to describe
>*different* things).  What is needed are descriptions of what a
>parameter tells you, e.g.,
>
>a. the smallest representable increment in the timestamp (often called
>"resolution")
>
>b. the bound on the difference between the timestamp value and the
>current UTC ("accuracy"?  "precision"?)
>
>c. whether the timestamp is monotonic (or possibly, if non-monotonic,
>the bound on its nonmonotonicity).
>
>Obviously, a < b, and if c != 0, a < c < b.  b is the hardest to
>supply, but also the one that's essential if you want to draw
>conclusions from timestamps generated by two servers.
>
> paul
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15481 for ietf-pkix-bks; Tue, 30 Mar 1999 15:07:22 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15476 for <[e-mail]>; Tue, 30 Mar 1999 15:07:19 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04564; Tue, 30 Mar 1999 18:07:09 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a12b327073ae689@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a25b31e71f88059@[128.33.238.119]>
Date: Tue, 30 Mar 1999 18:05:30 -0500
To: Moshe Litvin <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Moseh,

>There is no ambiguity as long as you know that the certificate issuer
>completely
>obey RFC 2459, if you are not sure then the absence of the extension is
>ambiguous. That is if you create a certificate and want to mark it as EE
>you have
>two options:
>
>1. You can go by RFC 2459 and not put the basic constraints extension.
>Every one
>that read the fine prints of the RFC and know that you obey all the fine
>prints
>will understand that this is an EE certificate.
>
>2. You can put a basic constraints extension that explicitly says that the
>certificate is not a CA certificate. Everyone that know how to parse the basic
>extension will understand it (without assuming what X509 profile you are
>following).
>
>I think that the second option is better and should be encourage (if not
>mandated).


I agree that the second approach leaves less room for error, but then one
could make similar observations for many other aspects of this and other
standards.  For example, throughout X.509 we make use of default values
that result in NULL or non-present encodings.  In fact, the convention that
you suggest we adopt relies on the default value for the CA Boolean being
false, and thus encoded as NULL, right?  Would it not be better, in the
spirit you describe, to have an explicit flag for an EE?

I think this example points out that we have made a number of decisions of
this flavor in these standards.  We are not talking about fundamental
differences, just value judgements about when we want to save space and
rely on implicit values (not in the ASN.1 tagging sense) vs. putting in
explicit flags, version numbers, etc.   The authors of 2459 made a decision
and so far we have not seen a flood of sentiment that suggests we ought to
change this part of the standard.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10791 for ietf-pkix-bks; Tue, 30 Mar 1999 08:27:11 -0800 (PST)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10785 for <[e-mail]>; Tue, 30 Mar 1999 08:27:07 -0800 (PST)
Received: from xedia.com by relay3.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgiuj07904; Tue, 30 Mar 1999 11:25:54 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA11650; Tue, 30 Mar 99 11:21:10 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA01652; Tue, 30 Mar 1999 11:25:07 -0500
Date: Tue, 30 Mar 1999 11:25:07 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Time-stamp server. TimePrecision info
References: <01E1D01C12D7D211AFC70090273D20B112BD4E@sothmxs06>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Robert" == Robert Zuccherato <[e-mail]> writes:

 Robert> Personally, I have no problem with adding an optional
 Robert> timePrecision field to specify the accuracy of the given time
 Robert> stamp. ...

 >> ---------- From: Michael Zolotarev
 >> ...we should
 >> think in terms of what a user would NEED to know. After all, what
 >> matters for a client is 1) how trustworthy is the TSA in general,
 >> and 2) how accurate is the time in that particular time stamp.
 >> 
 >> Presenting a customer with extra details, like splitting the
 >> quality of the time into its precision and accuracy, may
 >> unnecessarily overcomplicate the
 >> issue, without giving much information anyway.

These sound like good things.  If they are done, though, it would be
very helpful if ambiguous words like "precision" and "accuracy" are
avoided (and in particular, not used as terms intended to describe
*different* things).  What is needed are descriptions of what a
parameter tells you, e.g.,

a. the smallest representable increment in the timestamp (often called
"resolution")

b. the bound on the difference between the timestamp value and the
current UTC ("accuracy"?  "precision"?)

c. whether the timestamp is monotonic (or possibly, if non-monotonic,
the bound on its nonmonotonicity).

Obviously, a < b, and if c != 0, a < c < b.  b is the hardest to
supply, but also the one that's essential if you want to draw
conclusions from timestamps generated by two servers.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA09414 for ietf-pkix-bks; Tue, 30 Mar 1999 06:41:49 -0800 (PST)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA09408 for <[e-mail]>; Tue, 30 Mar 1999 06:41:44 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id QAA11452; Tue, 30 Mar 1999 16:41:17 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id QAA45022; Tue, 30 Mar 1999 16:42:17 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 30 Mar 1999 16:42:03 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Conclusion - Biometric inclusion in QC
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I have kept silent but looked at this interresting discussion. I will re-use
some of the arguments sent to the list.

How can I make a difference between "the" John Brown I met last monday and the
other 2000 (?) John Brown's ?
Maybe "my" John Brown is John Brown 1278, but in fact I do not know. I could
easily make the difference if the picture from John Brown was included in the
certificate. While reading this, some might jump from their chair since I have
been advocating low-fat leaf certificates at the last PKIX meeting !

The solution has already been given on this list. Instead of including the
whole picture, a hash of the picture could be included. Now John Brown could
provide me with the picture while sending me a signed message and I could
verify that it corresponds to the picture of the John Brown I met.

Two observations:

1) John Brown is free to release me his picture or not. In this way his privacy
may be respected, even if his certificate is published.
2) Once I got the picture, I do not need it once again. This solves bandwith
for other exchanges.

As a conclusion, I would welcomme an extension able to handle hash values of
biometric information, in particular pictures.

Denis


> I have now concluded the bio-metric topic as settled.
>
> The conclusion is to NOT include support for bio-metric data in the profile
> at this stage.
> At least not until the list has provided an agreeable solution that can
> enhance interoperability in some meaningful way.
>
> The informational web site http://www.accurata.se/QC/ has been updated with
> the rationale for this conclusion.
>
> Look under "Settled topics"
>
> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA08891 for ietf-pkix-bks; Tue, 30 Mar 1999 05:40:15 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA08887 for <[e-mail]>; Tue, 30 Mar 1999 05:40:14 -0800 (PST)
Received: 	id IAA02125; Tue, 30 Mar 1999 08:32:16 -0500
Received: by gateway id <G4CAYSAB>; Tue, 30 Mar 1999 08:34:34 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD4F@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Time-stamp server. Extra field for MessageImpring
Date: Tue, 30 Mar 1999 08:29:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have no problem with adding this optional field into both the Time Stamp
and DCS drafts.  I think that it could be useful for clients when trying to
link their tokens with the corresponding data.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, March 29, 1999 9:04 PM
> To: 	'Peter Sylvester'; [e-mail]
> Cc: 	'[e-mail]'; '[e-mail]'
> Subject: 	RE: Time-stamp server. Extra field for MessageImpring
> 
> Agree.
> In fact, there is yet another point in favor of taking the MessageInfo out
> 
> of the MessageImprint - the TSS draft defines the messageImprint as 
> OPTIONAL. This caters for the situations when only a trusted time value is
> 
> required, without linking it to any specific message. However, the client 
> may still want to externally associate the obtained 'no messageImprint' 
> time stamp with some data/event/entity. In this case the messageInfo will 
> be even more useful, serving as an external tag value.
> 
> The TimeStamp request would become:
> 
> TimeStampReq ::= SEQUENCE  {
>      version                      Integer  { v1(0) },
>      reqPolicy                    PolicyInformation OPTIONAL,
>      tdas                         SEQUENCE OF GeneralName OPTIONAL,
>      nonce                        Integer,
>     messageInfo          		        OCTET STRING OPTIONAL
>      messageImprint               MessageImprint OPTIONAL
> }
> 
> and the TSTInfo (in the TimeStampToken) would become:
> 
> TSTInfo ::= SEQUENCE  {
>  	.........
>      tstTime                      TSTTime,
>      tdaTokens                    SEQUENCE OF TemporalDataToken
>      nonce                        Integer OPTIONAL,
>     messageInfo          		        OCTET STRING OPTIONAL
>        --must be present if the similar field in TimeStampReq is
>        --present
>        --this field must have the same value as the similar field
>        --in TimeStampReq
>      messageImprint               MessageImprint OPTIONAL,
> 	...............
> }
> 
> As for the DCS, I reckon it is more logical to add MessageInfo as an 
> optional field to the ReqInfo structure.
> Relying on a similar field in the OPTIONAL(!) ReqTime structure would
> force 
> us to add the ReqInfo to the message, even if we did not want to. And it 
> seems like a long way down for just attaching a label to the whole
> request. 
> 
> 
> 
> -----Original Message-----
> From:	Peter Sylvester [SMTP:[e-mail]]
> Sent:	Monday, March 29, 1999 11:44 PM
> To:	[e-mail]; [e-mail]
> Cc:	SECURITY/SDPL/[e-mail]; 
> SECURITY/SDPL/[e-mail]
> Subject:	Re: Time-stamp server. Extra field for MessageImpring
> 
> 
> I would prefer not to have such a field messageInfo inside the 
> MessageImprint but rather
> elsewhere. Given this, it could also be used in DCS inside either
> 
> ReqData ::= SEQUENCE  {
>      reqInfo                ReqInfo,
>      data                   Data
>      messageInfo OCTET STRING OPTIONAL
> }
> 
> and
> Info ::= SEQUENCE  {
>      reqInfo                ReqInfo,
>      messageImprint       MessageImprint,
>      messageInfo          [0] OCTET STRING OPTIONAL
>      reqSignature         [1]    SignerInfo OPTIONAL,
> ...
> 
> }
> or simply as an optional field inside ReqInfo.
> 
> Peter Sylvester
> EdelWeb SA
> Paris France
> 
> 
> > We'd like to propose adding an extra field to the messageImprint 
> structure:
> >
> > Currently, there is no easy way to link the message hash included in the
> 
> time-stamp-request to the original message.
> > However, most systems will have an [obvious] requirement to associate a 
> time stamp with the original message. Most
> > simply, this could be done by incorporating the original message's 
> filename (or some other internal reference
> > information) into the time stamp.
> >
> > This could be done by adding a messageInfo field to the MessageImprint:
> >
> > MessageImprint ::= SEQUENCE  {
> >      hashAlgorithm                AlgorithmIdentifier,
> >      hashedMessage             [0]	IMPLICIT 	OCTET STRING,
> >      messageInfo                   [1] 	IMPLICIT 	OCTET STRING
> OPTIONAL
> >           -- a user-defined tag for a pointer to the original message.
> > }
> >
> >
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA08844 for ietf-pkix-bks; Tue, 30 Mar 1999 05:34:32 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA08840 for <[e-mail]>; Tue, 30 Mar 1999 05:34:31 -0800 (PST)
Received: 	id IAA01134; Tue, 30 Mar 1999 08:30:12 -0500
Received: by gateway id <G4CAYR0T>; Tue, 30 Mar 1999 08:32:31 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD4E@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Simon Laing'" <SECURITY/SDPL/[e-mail]>, "'Andrew Shellshear'" <SECURITY/SDPL/[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Tue, 30 Mar 1999 08:27:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Personally, I have no problem with adding an optional timePrecision field to
specify the accuracy of the given time stamp.  I think that in some
applications that can be useful information, particularly when the time
stamp token will be kept for evidence purposes.  However, I really don't
think it would be wise to make the serial number mandatory.  I agree that in
some situations it may be critical for clients to know "who was first" if
the resolution of the timestamp means that they both have the same value for
the time.  But, I don't think that it will be critical in all applications.
Therefore, I would rather not make it mandatory and force its use on those
applications (and TSA's supporting them) where it is not required.

	Robert Zuccherato.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, March 29, 1999 10:38 PM
> To: 	'[e-mail]'; '[e-mail]'
> Cc: 	'Simon Laing'; 'Andrew Shellshear'
> Subject: 	RE: Time-stamp server. TimePrecision info
> 
> Michael,
> Technically you are right, and I certainly agree that monotonicity is 
> absolutely essential, and assumed. It is accuracy and precision which I am
> 
> trying to address here.
> 
> I believe that when considering what might go into a time stamp, we should
> 
> think in terms of what a user would NEED to know. After all, what matters 
> for a client is
> 1) how trustworthy is the TSA in general, and
> 2) how accurate is the time in that particular time stamp.
> 
> Presenting a customer with extra details, like splitting the quality of
> the 
> time into its precision and accuracy, may unnecessarily overcomplicate the
> 
> issue, without giving much information anyway.
> 
> A reference to the source(s) of time data, available from the TSA's
> policy, 
> should be a starting point for anybody who wants to know more about 
> characteristics of the time.
> 
> Thinking of monotonicity:
> Should the TSTInfo::serialNumber field be OPTIONAL? In addition to serving
> 
> as just an extra proof of monotonicity, which is assumed anyway, the 
> serialNumber may be the only way to resolve a 'who was the first'
> argument. 
> If two requests arrived virtually 'simultaneously', the TSS will generate 
> two time stamps with the same time value. The probability of it depends on
> 
> the resolution of the time source used. It may be critical for the clients
> 
> to know who was actually the first (thinking of on-line betting, auctions,
> 
> etc). This turns the serialNumber into a mandatory field, doesn't it?
> 
> Michael Zolotarev
> Technical Architect, Baltimore Technologies Ltd (Australia)
> 
> -----Original Message-----
> From:	Michael Sierchio [SMTP:[e-mail]]
> Sent:	Monday, March 29, 1999 3:32 PM
> To:	[e-mail]
> Cc:	'[e-mail]'; Simon Laing; Andrew Shellshear
> Subject:	Re: Time-stamp server. TimePrecision info
> 
> Michael Zolotarev wrote:
> > ...
> > for example, the policy might state: "The time returned will be accurate
> 
> to
> > within 100ms, and if the time-stamp server cannot
> > provide this level of accuracy, it will not issue a time-stamp."
> 
> It seems to me that there are three qualities of interest for
> timestamps, in increasing order of importance -- precision, accuracy,
> and monotonicity.  The last is essential,  and perhaps more important
> than the other two.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11206 for ietf-pkix-bks; Mon, 29 Mar 1999 19:38:40 -0800 (PST)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11194 for <[e-mail]>; Mon, 29 Mar 1999 19:38:37 -0800 (PST)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id NAA10500; Tue, 30 Mar 1999 13:38:19 +1000
Received: by localhost with Microsoft MAPI; Tue, 30 Mar 1999 13:38:14 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Simon Laing'" <SECURITY/SDPL/[e-mail]>, "'Andrew Shellshear'" <SECURITY/SDPL/[e-mail]>
Subject: RE: Time-stamp server. TimePrecision info
Date: Tue, 30 Mar 1999 13:38:09 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,
Technically you are right, and I certainly agree that monotonicity is 
absolutely essential, and assumed. It is accuracy and precision which I am 
trying to address here.

I believe that when considering what might go into a time stamp, we should 
think in terms of what a user would NEED to know. After all, what matters 
for a client is
1) how trustworthy is the TSA in general, and
2) how accurate is the time in that particular time stamp.

Presenting a customer with extra details, like splitting the quality of the 
time into its precision and accuracy, may unnecessarily overcomplicate the 
issue, without giving much information anyway.

A reference to the source(s) of time data, available from the TSA's policy, 
should be a starting point for anybody who wants to know more about 
characteristics of the time.

Thinking of monotonicity:
Should the TSTInfo::serialNumber field be OPTIONAL? In addition to serving 
as just an extra proof of monotonicity, which is assumed anyway, the 
serialNumber may be the only way to resolve a 'who was the first' argument. 
If two requests arrived virtually 'simultaneously', the TSS will generate 
two time stamps with the same time value. The probability of it depends on 
the resolution of the time source used. It may be critical for the clients 
to know who was actually the first (thinking of on-line betting, auctions, 
etc). This turns the serialNumber into a mandatory field, doesn't it?

Michael Zolotarev
Technical Architect, Baltimore Technologies Ltd (Australia)

-----Original Message-----
From:	Michael Sierchio [SMTP:[e-mail]]
Sent:	Monday, March 29, 1999 3:32 PM
To:	[e-mail]
Cc:	'[e-mail]'; Simon Laing; Andrew Shellshear
Subject:	Re: Time-stamp server. TimePrecision info

Michael Zolotarev wrote:
> ...
> for example, the policy might state: "The time returned will be accurate 
to
> within 100ms, and if the time-stamp server cannot
> provide this level of accuracy, it will not issue a time-stamp."

It seems to me that there are three qualities of interest for
timestamps, in increasing order of importance -- precision, accuracy,
and monotonicity.  The last is essential,  and perhaps more important
than the other two.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05435 for ietf-pkix-bks; Mon, 29 Mar 1999 18:05:32 -0800 (PST)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05431 for <[e-mail]>; Mon, 29 Mar 1999 18:05:28 -0800 (PST)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA08477; Tue, 30 Mar 1999 12:05:03 +1000
Received: by localhost with Microsoft MAPI; Tue, 30 Mar 1999 12:04:57 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Time-stamp server. Extra field for MessageImpring
Date: Tue, 30 Mar 1999 12:04:53 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree.
In fact, there is yet another point in favor of taking the MessageInfo out 
of the MessageImprint - the TSS draft defines the messageImprint as 
OPTIONAL. This caters for the situations when only a trusted time value is 
required, without linking it to any specific message. However, the client 
may still want to externally associate the obtained 'no messageImprint' 
time stamp with some data/event/entity. In this case the messageInfo will 
be even more useful, serving as an external tag value.

The TimeStamp request would become:

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
    messageInfo          		        OCTET STRING OPTIONAL
     messageImprint               MessageImprint OPTIONAL
}

and the TSTInfo (in the TimeStampToken) would become:

TSTInfo ::= SEQUENCE  {
 	.........
     tstTime                      TSTTime,
     tdaTokens                    SEQUENCE OF TemporalDataToken
     nonce                        Integer OPTIONAL,
    messageInfo          		        OCTET STRING OPTIONAL
       --must be present if the similar field in TimeStampReq is
       --present
       --this field must have the same value as the similar field
       --in TimeStampReq
     messageImprint               MessageImprint OPTIONAL,
	...............
}

As for the DCS, I reckon it is more logical to add MessageInfo as an 
optional field to the ReqInfo structure.
Relying on a similar field in the OPTIONAL(!) ReqTime structure would force 
us to add the ReqInfo to the message, even if we did not want to. And it 
seems like a long way down for just attaching a label to the whole request. 



-----Original Message-----
From:	Peter Sylvester [SMTP:[e-mail]]
Sent:	Monday, March 29, 1999 11:44 PM
To:	[e-mail]; [e-mail]
Cc:	SECURITY/SDPL/[e-mail]; 
SECURITY/SDPL/[e-mail]
Subject:	Re: Time-stamp server. Extra field for MessageImpring


I would prefer not to have such a field messageInfo inside the 
MessageImprint but rather
elsewhere. Given this, it could also be used in DCS inside either

ReqData ::= SEQUENCE  {
     reqInfo                ReqInfo,
     data                   Data
     messageInfo OCTET STRING OPTIONAL
}

and
Info ::= SEQUENCE  {
     reqInfo                ReqInfo,
     messageImprint       MessageImprint,
     messageInfo          [0] OCTET STRING OPTIONAL
     reqSignature         [1]    SignerInfo OPTIONAL,
...

}
or simply as an optional field inside ReqInfo.

Peter Sylvester
EdelWeb SA
Paris France


> We'd like to propose adding an extra field to the messageImprint 
structure:
>
> Currently, there is no easy way to link the message hash included in the 
time-stamp-request to the original message.
> However, most systems will have an [obvious] requirement to associate a 
time stamp with the original message. Most
> simply, this could be done by incorporating the original message's 
filename (or some other internal reference
> information) into the time stamp.
>
> This could be done by adding a messageInfo field to the MessageImprint:
>
> MessageImprint ::= SEQUENCE  {
>      hashAlgorithm                AlgorithmIdentifier,
>      hashedMessage             [0]	IMPLICIT 	OCTET STRING,
>      messageInfo                   [1] 	IMPLICIT 	OCTET STRING 	OPTIONAL
>           -- a user-defined tag for a pointer to the original message.
> }
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA02660 for ietf-pkix-bks; Mon, 29 Mar 1999 14:24:38 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA02656 for <[e-mail]>; Mon, 29 Mar 1999 14:24:37 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 29 Mar 1999 15:09:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Mon, 29 Mar 1999 15:09:07 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Delurking on Biometrics
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 mail.proper.com id OAA02657
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

The points you raise are good ones. and even though the issue may 
be closed with respect to QC certificates, there are clearly lots and 
lots of people who are attracted to the promise of infallibility by 
biometrics who don't understand the problems.

Just a couple of clarifications, though.

1. Even though an individual may not have a _classifiable_ fingerprint using
the standard FBI classification technique, that fingerprint is almost surely 
identifiable as matching a previously enrolled sample, even if it is nothing 
but scar tissue.

2. Although I haven't investigated the field recently, the best 
fingerprint reader I am aware of as of three years ago was the Identix reader, 
which scans the finger using three different colors of LED, one of which 
is in the near infrared and "sees" the capillary pattern beneath the surface.  
Even if someone had no fingerprints at all, as I have heard claimed but 
haven't confirmed for bricklayers and those who might have had their 
prints removed by acid, I assume that they still have capillaries.

3.  I once attended a biometrics show that featured two vendors of retinal 
scan equipment.  One touted the advantages of retinal scans for 
biometric purposes, claiming that they were unalterable. The other claimed 
that they were excellent diagnostic tools, because of their ability to detect
changes due to diabetes, high blood pressure, etc.  Clearly they can't 
both be right, and knowing something about such illnesses, I'd bet on 
the diagnostic folks.

4.  Even the capillary pattern devices are subject to change, leading
to false rejections.  I once had an employee who flushed easily. If the 
fingerprint reader rejected his print, it would irritate him to the point where his
capillaries expanded, hence rejecting him all the more in a positive feedback.
Although as the system manager I ran the threshold for my own prints at a 
very high level, I had to lower his to well below the recommended level 
so he could get in consistently.

Bob

>>> "Zmudzinski, Tom" <[e-mail]> 03/29/99 12:04PM >>>
I've listened quietly and I know that this topic has come to an end.  But 
before it dies (actually it won't die, it'll just hide from the sunlight for
a while) 
I would like to throw in one point that is often forgotten when discussing 
biometrics, to wit: NOT EVERYONE HAS THEM.

Fingerprints?  Roughly 2% of the general population doesn't have readily
identifiable prints (BTW, 10% of those are doctors -- their fingertips
were scarred by repeated blood sampling when they went through medical
school).  And a very small percentage of the population is born without
fingerprints.  Ever shake hands with someone who doesn't have prints?
I have, and I can tell you it's past being slightly disconcerting!

Lip prints?  Well, let me mention this man ran into when I was selling
cookware door to door; he was a napalm victim who didn't have a FACE
-- once used to that fact and what it did to his speech, you'd find that
he still had a lightning wit -- and if he's still around I suspect he might
be 
listening to a talking computer.  Facial heat prints are the latest craze, 
partly because they can correctly differentiate so-called identical twins 
based on the fact that capillaries are grown in a fractal pattern.  The 
market hype claims that the pattern "never" changes -- even after facial 
surgery.  I'll reserve my opinion until I see the before-and-after bioscans 
of someone who has had their face stripped to the bone and rebuilt.

Retinal patterns?  Just because someone doesn't have eyes doesn't mean
they can't use a computer, a specially adapted one I'll admit.  See above.

DNA?  At the Army Medical Center at Fort Detrick, I once knew a man 
who was fraternal twins -- I don't mean he was *A* fraternal twin.  He has
different DNA in his hands and his feet.  He was a failed *SET* of twins!
The best the doctors could tell was that he had once been a pair of
fraternal zygotes that fused before they implanted in his mother's womb.

RNA?  We inherit it from our mothers (that's why my fraternal twin
friend has the same RNA, top and bottom, "both" of him had the same
mother), but RNA mutates every time we catch a virus.

The simple, unvarnished truth is that humans are colloidal lifeforms[*]
and there's nothing about us that is both universal and unchanging.

Tom Zmudzinski 

[*] We're jelly in the same sense as glass is a liquid.

"Reality is for people who can't handle science fiction."
            - variously attributed to Heinlein, Bradbury, or Asimov
"Trouble is, we're LIVING science fiction!" - me


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01735 for ietf-pkix-bks; Mon, 29 Mar 1999 12:36:10 -0800 (PST)
Received: from bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01731 for <[e-mail]>; Mon, 29 Mar 1999 12:36:08 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by bbn.com (8.9.1/8.9.1) with ESMTP id PAA27513; Mon, 29 Mar 1999 15:28:03 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0cb32590a3ddc8@[128.89.0.110]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0D737F@DSG1>
Date: Mon, 29 Mar 1999 15:24:18 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Cc: "'Bob Jueneman '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,


>I am not to sure what going to a DNS based name does does in terms of
>process - eg. validation process or things that use certificates - can
>someone please enlighten me.

DNS names are often native to the applications, e.g., IPsec, SSL/TLS, and
S/MIME, and thus it is preferable to make use of them as a more direct
input to an access control decision.  For example, browsers using SSL
usually match the URL against a DNS name crudely encoded as a common name.
It would be preferable (as 2459 points out) if the encoding were direct,
rather than kludged in this fashion.  Also, there are standards for storing
certs in the DNS, which might allow one to take advantage of a very large,
deployed repository infrastructure in the Internet.

>ie. if there are problems with Issuer DN (ie its an SMTP address in the
>extensions) and I am in the process of path validation - do I mail the
>Issuer with something?

That's not the motivation for use of DNS names here.

>What about CRLs - are they attached to these DNS indexed things.

Yes, there are provisions for storing CRLs, as well as certs, in DNS.

>I understand that AIAs are useful as they deal with explicit a cert
>based function such as OCSP.
>I just dont understand the process (that must be related to the
>certficate) if DNS type names are used for issuers, etc.

If a DNS name is used exclusively, we restrict it to the subject field for
an end entity certificate.  Otherwise a DN must be present in the Issuer
and/or Subject fields.

>In addition - if one mixed name forms in a cert path - the process rules
>can get messy. eg mail here, ldap there, OCSP over there, etc

As noted above, the simple case is to use DNS names only for end entities.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00906 for ietf-pkix-bks; Mon, 29 Mar 1999 11:00:17 -0800 (PST)
Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00902 for <[e-mail]>; Mon, 29 Mar 1999 11:00:16 -0800 (PST)
Message-Id: <[e-mail]>
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <H6QRYFMW>; Mon, 29 Mar 1999 14:00:05 -0500
From: "Zmudzinski, Tom" <[e-mail]>
To: IETF-PXIX <[e-mail]>
Subject: Delurking on Biometrics
Date: Mon, 29 Mar 1999 14:04:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've listened quietly and I know that this topic has come to an end.  But 
before it dies (actually it won't die, it'll just hide from the sunlight for
a while) 
I would like to throw in one point that is often forgotten when discussing 
biometrics, to wit: NOT EVERYONE HAS THEM.

Fingerprints?  Roughly 2% of the general population doesn't have readily
identifiable prints (BTW, 10% of those are doctors -- their fingertips
were scarred by repeated blood sampling when they went through medical
school).  And a very small percentage of the population is born without
fingerprints.  Ever shake hands with someone who doesn't have prints?
I have, and I can tell you it's past being slightly disconcerting!

Lip prints?  Well, let me mention this man ran into when I was selling
cookware door to door; he was a napalm victim who didn't have a FACE
-- once used to that fact and what it did to his speech, you'd find that
he still had a lightning wit -- and if he's still around I suspect he might
be 
listening to a talking computer.  Facial heat prints are the latest craze, 
partly because they can correctly differentiate so-called identical twins 
based on the fact that capillaries are grown in a fractal pattern.  The 
market hype claims that the pattern "never" changes -- even after facial 
surgery.  I'll reserve my opinion until I see the before-and-after bioscans 
of someone who has had their face stripped to the bone and rebuilt.

Retinal patterns?  Just because someone doesn't have eyes doesn't mean
they can't use a computer, a specially adapted one I'll admit.  See above.

DNA?  At the Army Medical Center at Fort Detrick, I once knew a man 
who was fraternal twins -- I don't mean he was *A* fraternal twin.  He has
different DNA in his hands and his feet.  He was a failed *SET* of twins!
The best the doctors could tell was that he had once been a pair of
fraternal zygotes that fused before they implanted in his mother's womb.

RNA?  We inherit it from our mothers (that's why my fraternal twin
friend has the same RNA, top and bottom, "both" of him had the same
mother), but RNA mutates every time we catch a virus.

The simple, unvarnished truth is that humans are colloidal lifeforms[*]
and there's nothing about us that is both universal and unchanging.

Tom Zmudzinski 

[*] We're jelly in the same sense as glass is a liquid.

"Reality is for people who can't handle science fiction."
            - variously attributed to Heinlein, Bradbury, or Asimov
"Trouble is, we're LIVING science fiction!" - me


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25133 for ietf-pkix-bks; Mon, 29 Mar 1999 05:44:22 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25129 for <[e-mail]>; Mon, 29 Mar 1999 05:44:20 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16355; Mon, 29 Mar 1999 15:44:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 29 Mar 1999 15:44:15 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id PAA29943; Mon, 29 Mar 1999 15:44:14 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id PAA23325; Mon, 29 Mar 1999 15:44:14 +0200
Date: Mon, 29 Mar 1999 15:44:14 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Time-stamp server. Extra field for MessageImpring
Cc: SECURITY/SDPL/[e-mail], SECURITY/SDPL/[e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would prefer not to have such a field messageInfo inside the MessageImprint but rather 
elsewhere. Given this, it could also be used in DCS inside either

ReqData ::= SEQUENCE  {
     reqInfo                ReqInfo,
     data                   Data
     messageInfo OCTET STRING OPTIONAL
}

and 
Info ::= SEQUENCE  {
     reqInfo                ReqInfo,
     messageImprint       MessageImprint,
     messageInfo          [0] OCTET STRING OPTIONAL
     reqSignature         [1]    SignerInfo OPTIONAL,
...

}
or simply as an optional field inside ReqInfo.

Peter Sylvester
EdelWeb SA
Paris France


> We'd like to propose adding an extra field to the messageImprint structure:
> 
> Currently, there is no easy way to link the message hash included in the time-stamp-request to the original message. 
> However, most systems will have an [obvious] requirement to associate a time stamp with the original message. Most 
> simply, this could be done by incorporating the original message's filename (or some other internal reference 
> information) into the time stamp. 
> 
> This could be done by adding a messageInfo field to the MessageImprint:
>  
> MessageImprint ::= SEQUENCE  {
>      hashAlgorithm                AlgorithmIdentifier,
>      hashedMessage             [0]	IMPLICIT 	OCTET STRING,
>      messageInfo                   [1] 	IMPLICIT 	OCTET STRING 	OPTIONAL
>           -- a user-defined tag for a pointer to the original message.
> }
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA18916 for ietf-pkix-bks; Sun, 28 Mar 1999 21:39:33 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-119.dialup.dnai.com [207.181.255.119]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA18911 for <[e-mail]>; Sun, 28 Mar 1999 21:39:31 -0800 (PST)
Received: from dnai.com (windoze [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id VAA02184; Sun, 28 Mar 1999 21:32:03 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 28 Mar 1999 21:31:59 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, Simon Laing <SECURITY/SDPL/[e-mail]>, Andrew Shellshear <SECURITY/SDPL/[e-mail]>
Subject: Re: Time-stamp server. TimePrecision info
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Zolotarev wrote:
> ...
> for example, the policy might state: "The time returned will be accurate to
> within 100ms, and if the time-stamp server cannot
> provide this level of accuracy, it will not issue a time-stamp."

It seems to me that there are three qualities of interest for
timestamps, in increasing order of importance -- precision, accuracy,
and monotonicity.  The last is essential,  and perhaps more important
than the other two.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04481 for ietf-pkix-bks; Sun, 28 Mar 1999 18:36:09 -0800 (PST)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04475 for <[e-mail]>; Sun, 28 Mar 1999 18:36:06 -0800 (PST)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA25882 for <[e-mail]>; Mon, 29 Mar 1999 12:35:59 +1000
Received: by localhost with Microsoft MAPI; Mon, 29 Mar 1999 12:35:51 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: Simon Laing <SECURITY/SDPL/[e-mail]>, Andrew Shellshear <SECURITY/SDPL/[e-mail]>
Subject: Time-stamp server. Extra field for MessageImpring
Date: Mon, 29 Mar 1999 12:35:47 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We'd like to propose adding an extra field to the messageImprint structure:

Currently, there is no easy way to link the message hash included in the time-stamp-request to the original message. 
However, most systems will have an [obvious] requirement to associate a time stamp with the original message. Most 
simply, this could be done by incorporating the original message's filename (or some other internal reference 
information) into the time stamp. 

This could be done by adding a messageInfo field to the MessageImprint:
 
MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage             [0]	IMPLICIT 	OCTET STRING,
     messageInfo                   [1] 	IMPLICIT 	OCTET STRING 	OPTIONAL
          -- a user-defined tag for a pointer to the original message.
}




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA04453 for ietf-pkix-bks; Sun, 28 Mar 1999 18:31:48 -0800 (PST)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04449 for <[e-mail]>; Sun, 28 Mar 1999 18:31:43 -0800 (PST)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA25746 for <[e-mail]>; Mon, 29 Mar 1999 12:31:31 +1000
Received: by localhost with Microsoft MAPI; Mon, 29 Mar 1999 12:31:23 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: Simon Laing <SECURITY/SDPL/[e-mail]>, Andrew Shellshear <SECURITY/SDPL/[e-mail]>
Subject: Time-stamp server. TimePrecision info
Date: Mon, 29 Mar 1999 12:31:18 +1000
Organization: Baltimore Pty Ltd
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We are proposing to add an extra optional field to the TSTTime structure:

It is reasonable to except a TSA to maintain a set of more then one source 
of timing data. Typically, a TSA might derive its time from a high-accuracy 
source (such as a GPS clock), but may fall back to a lower accuracy one 
(such as an NTP server), if its primary time source is temporarily 
unavailable (e.g. due to hardware failure).
Currently, the policy information is the only place where accuracy of time 
may be returned by the time-stamp server -
for example, the policy might state: "The time returned will be accurate to 
within 100ms, and if the time-stamp server cannot
provide this level of accuracy, it will not issue a time-stamp."

However, it seems reasonable to anticipate business cases where a more 
flexible approach is necessary - a loss of
quality might be acceptable so long as a time-stamp is issued. The policy 
in this case might state something like:
"The time returned will be accurate to within 100ms over 99% of the time. 
 The actual time quality is given in the field
timePrecision in the TSTTime."
The timePrecision would depend on the characteristics of the time data 
sources used by the TSA.

In this case, an additional parameter would be required in the TSTTime 
structure:

TSTTime ::= SEQUENCE {
	genTime	GenerilizedTime,
	milliseconds	[0] IMPLICIT INTEGER OPTIONAL
	timePrecision	[1] IMPLICIT INTEGER OPTIONAL
		-- Precision in milliseconds.
}

the precision field, if present, should be interpreted as 'the exact time 
lies within the [ TSTTime-timePrecision/2
-- TSTTime+timePrecision/2 ] interval'.

If the TSA policy contains the 'quality of the time'  statement, most 
likely it will be a pessimistic one.
Consequently, the timePrecision field will be useful not only in a 
situation when the quality of the time in the time stamp
is below the limit, but also when it is well above the bottom mark.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA14658 for ietf-pkix-bks; Fri, 26 Mar 1999 23:31:20 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA14653 for <[e-mail]>; Fri, 26 Mar 1999 23:31:16 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <HSFQXDR7>; Sat, 27 Mar 1999 18:36:53 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0D737F@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Bob Jueneman '" <[e-mail]>, "'Stephen Kent '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Sat, 27 Mar 1999 18:36:49 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well - this seems to highlight a problem if the name form isnt a DN and
the entity is not in a directory. 

The intent of 500/509 was that CAs are a directory entry - as per
subjects.
Attached to these entries are contact details etc - just in case of
things going wrong.

I am not to sure what going to a DNS based name does does in terms of
process - eg. validation process or things that use certificates - can
someone please enlighten me.

ie. if there are problems with Issuer DN (ie its an SMTP address in the
extensions) and I am in the process of path validation - do I mail the
Issuer with something?

What about CRLs - are they attached to these DNS indexed things.

I understand that AIAs are useful as they deal with explicit a cert
based function such as OCSP.
I just dont understand the process (that must be related to the
certficate) if DNS type names are used for issuers, etc.

In addition - if one mixed name forms in a cert path - the process rules
can get messy. eg mail here, ldap there, OCSP over there, etc 

please advise
regards alan




----------
From: Stephen Kent
To: Bob Jueneman
Cc: [e-mail]; [e-mail]; [e-mail]
Sent: 3/22/99 11:43:07 AM
Subject: Re: Certificates, Directories, and Distinguished Names

Bob,

>Because of the potential impact on evolving software, I'd like
>to escalate this issue to the PKIX co-chairs, Steve Kent and
>Warwick Ford, and to the chair of X.509, Hoyt Kesterson,
>in order to force a expeditious resolution to this issue.

We live but to serve as arbiters in such disputes :-).

>One of these name forms, at least, ought to be usable to
>retrieve a certificate from a directory, whereas the others,
>although potentially candidates for inclusion in a directory,
>may not represent a real directory entry but may be for
>display purposes to RP software, or for other application
>purposes.
>
>I believe that it is extremely important that at least one of the
>multiple name forms that may be carried in a directory reflect
>the primary directory name used to store and retrieve such
>certificates.  If I start searching a directory, I don't want to
>have to try every name in a certificate looking for other, related
>certificates.

I tend to agree that it would be good if at least one subject name could
be
used for directory lookup.  But, we have multiple directory options in
the
Internet.  If the subject name is present, it's a DN and might be
appropriate for lookup in an X.500 directory.  But, if that DN is made
up
DC attribuites, maybe it's really destined to be looked up in the DNS.
Also, if the subject name is NULL and an altName is present, that name
might be a DNS name, an RFC822 name, or an IP address, all of which are
suitable for lookup in the DNS.  So, if you are willing to allow for
both
X.500 and DNS directory lookups, it would seem that we have lots of
options
here.  I'll leave it to Hoyt to tell me where to lookup EDI party names
:-).


Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21152 for ietf-pkix-bks; Fri, 26 Mar 1999 14:55:16 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21148 for <[e-mail]>; Fri, 26 Mar 1999 14:55:15 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id AAA11033 for <[e-mail]>; Sat, 27 Mar 1999 00:02:36 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 27 Mar 1999 00:03:16 +0100
To: "IETF-PXIX" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Conclusion - Biometric inclusion in QC
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 mail.proper.com id OAA21149
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have now concluded the bio-metric topic as settled.

The conclusion is to NOT include support for bio-metric data in the profile
at this stage.
At least not until the list has provided an agreeable solution that can
enhance interoperability in some meaningful way.

The informational web site http://www.accurata.se/QC/ has been updated with
the rationale for this conclusion.

Look under "Settled topics"

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20478 for ietf-pkix-bks; Fri, 26 Mar 1999 13:44:46 -0800 (PST)
Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20474 for <[e-mail]>; Fri, 26 Mar 1999 13:44:45 -0800 (PST)
From: [e-mail]
Received: from panga.ny.certco.com (panga.ny.certco.com [192.168.69.21]) by btec-fw.certco.com (Postfix) with ESMTP id 3064E32DDC; Fri, 26 Mar 1999 16:51:54 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.ny.certco.com [192.168.69.12]) by panga.ny.certco.com (Postfix) with ESMTP id 0796154001; Fri, 26 Mar 1999 16:51:54 -0500 (EST)
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <GR9L6L7P>; Fri, 26 Mar 1999 16:51:54 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: "Alternatively-encoded" extensions
Date: Fri, 26 Mar 1999 16:51:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since Extension.extnValue is an OCTET STRING, I am a little confused by this
thread, including Peter Williams's question:

> If a X.509 extension is proposed to IETF (PKIX) which is designed to
> be interpreted - by a binary-decoding based process
> other than ASN.1/DER - is there an objection in principle?

My below comment, referred to DER-encoding in general.

Frank

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, March 26, 1999 3:29 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: "Alternatively-encoded" extensions


Timothy Fisher wrote:

> I like the idea of "alterniatively-encoded" extensions.  I agree with
> Peter's rationale that a non-critical extension should not have to be
> ASN.1 encoded.  I also, would like to hear other opinions on this
> subject.

If ASN.1 included a type called NOTANY, I would agree. It does not. There
many be tools and applications that inspect a DER-encoded certificate in its
entirety. If ANY data is not ANY ASN.1 data, they may fail.

Frank Balluffi
CertCo


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19800 for ietf-pkix-bks; Fri, 26 Mar 1999 12:25:54 -0800 (PST)
Received: from btec-fw.certco.com (btec-fw.certco.com [209.2.102.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19796 for <[e-mail]>; Fri, 26 Mar 1999 12:25:53 -0800 (PST)
From: [e-mail]
Received: from panga.ny.certco.com (panga.ny.certco.com [192.168.69.21]) by btec-fw.certco.com (Postfix) with ESMTP id 4AB3732DDC; Fri, 26 Mar 1999 15:28:42 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com (nycertco-srv1.ny.certco.com [192.168.69.12]) by panga.ny.certco.com (Postfix) with ESMTP id 1771054001; Fri, 26 Mar 1999 15:28:42 -0500 (EST)
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <GR9L6LXK>; Fri, 26 Mar 1999 15:28:42 -0500
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: "Alternatively-encoded" extensions
Date: Fri, 26 Mar 1999 15:28:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Timothy Fisher wrote:

> I like the idea of "alterniatively-encoded" extensions.  I agree with
> Peter's rationale that a non-critical extension should not have to be
> ASN.1 encoded.  I also, would like to hear other opinions on this
> subject.

If ASN.1 included a type called NOTANY, I would agree. It does not. There
many be tools and applications that inspect a DER-encoded certificate in its
entirety. If ANY data is not ANY ASN.1 data, they may fail.

Frank Balluffi
CertCo


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19585 for ietf-pkix-bks; Fri, 26 Mar 1999 11:56:56 -0800 (PST)
Received: from chopin.digsigtrust.com (chopin.digsigtrust.com [208.30.64.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19581 for <[e-mail]>; Fri, 26 Mar 1999 11:56:55 -0800 (PST)
Received: (from root@localhost) by chopin.digsigtrust.com (8.9.1a/8.9.1) id NAA10663 for [e-mail]; Fri, 26 Mar 1999 13:03:47 -0700 (MST)
Received: from picasso (picasso.digsigtrust.com [208.30.64.104]) by chopin.digsigtrust.com (8.9.1a/8.9.1) with SMTP id NAA10659 for <[e-mail]>; Fri, 26 Mar 1999 13:03:46 -0700 (MST)
From: "Scott Kern" <[e-mail]>
To: <[e-mail]>
Date: Fri, 26 Mar 1999 12:59:10 -0700
MIME-Version: 1.0
Message-ID: <001c01be77c3$1d150f00$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0017_01BE7788.6CD1D0E0"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01BE7788.6CD1D0E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

auth e7360050 subscribe ietf-pkix "Scott Kern"
<[e-mail]>



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaDCCAqsw
ggIUoAMCAQICEQDQHkBiAAACfAAAAAYAAAAFMA0GCSqGSIb3DQEBBAUAMIGiMQswCQYDVQQGEwJV
UzENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0
YWwgU2lnbmF0dXJlIFRydXN0IENvLjEMMAoGA1UECxMDTUlTMRQwEgYDVQQDEwtFbXBsb3llZSBD
QTEhMB8GCSqGSIb3DQEJARYSY2FAZGlnc2lndHJ1c3QuY29tMB4XDTk5MDMwODIwNTA0NloXDTk5
MDQyMTIwNTA0NlowgbExCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwRVdGFoMRcwFQYDVQQHEw5TYWx0
IExha2UgQ2l0eTEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRQwEgYDVQQL
EwtDQSBTZXJ2aWNlczETMBEGA1UEAxMKU2NvdHQgS2VybjEpMCcGCSqGSIb3DQEJARYac2NvdHQu
a2VybkBkaWdzaWd0cnVzdC5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAxMPo88BOLEvmGGvu
oX8xZ5AV5pEwSWgfKJ6Xl5seS876xDZg6CEWHgsRbMPnBl0Ay27xe+vcuzr3eMcwDPpU1wIDAQAB
oxQwEjAQBgNVHREECTAHgQVTY290dDANBgkqhkiG9w0BAQQFAAOBgQC/fanzZJnIN7Ut22c+fe2P
SgTwirbZUXvO4gYwaqHXckA3dswne/XOXKZOShOf1ehBaUlQb2G66/F1jCfUcnkohX51tWnmVwUn
kzqpuggOO2Zy83DfGrzbh7PA0dqen0IdmE//v2Om8Fsx8QxO5dz065u4n098dFDN/KHZ6LjyoTCC
ArUwggIeAgEAMA0GCSqGSIb3DQEBBAUAMIGiMQswCQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDEX
MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0
IENvLjEMMAoGA1UECxMDTUlTMRQwEgYDVQQDEwtFbXBsb3llZSBDQTEhMB8GCSqGSIb3DQEJARYS
Y2FAZGlnc2lndHJ1c3QuY29tMB4XDTk4MDQyNDIyNDcwNVoXDTk5MDQyNDIyNDcwNVowgaIxCzAJ
BgNVBAYTAlVTMQ0wCwYDVQQIEwRVdGFoMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEkMCIGA1UE
ChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMQwwCgYDVQQLEwNNSVMxFDASBgNVBAMTC0Vt
cGxveWVlIENBMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVzdC5jb20wgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBANjcyFikjVra3twLU0HsvKVBXkGfEEYsHbTU0GySTuRf9qycZ9zi99jt
z70VF6G4WC23wBasLnXz6kvXemfq/EzpGpfof3lQgepI5Ckj7pbMSJ7f2eyD33ZJ9odx1uDubqlb
Ido7eHIZkgP5EbnYkkTjt1a9W8muwvbbrNf7ZnBpAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEA0yQB
FliAWKT61gdWjoO8kJO7rSmUjA2IATQDnNG43K9egk0O80Tq1NMTNlokBEr1uxQ0OzVtm29Vbv+J
LolD2WTnLtt4VTD1Ott/VrNKHUUd9xCdCSC+5TO355JXL7V0ZuAv4/6byYz2RjU4AG3StUbSs48w
SXo/EigurnxvDrMxggKAMIICfAIBATCBuDCBojELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgx
FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVz
dCBDby4xDDAKBgNVBAsTA01JUzEUMBIGA1UEAxMLRW1wbG95ZWUgQ0ExITAfBgkqhkiG9w0BCQEW
EmNhQGRpZ3NpZ3RydXN0LmNvbQIRANAeQGIAAAJ8AAAABgAAAAUwCQYFKw4DAhoFAKCCAV4wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwMzI2MTk1OTAzWjAjBgkq
hkiG9w0BCQQxFgQUckvXI/1VH5uVSFZkPTAq1UowbaowMwYJKoZIhvcNAQkPMSYwJDANBggqhkiG
9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCByQYJKwYBBAGCNxAEMYG7MIG4MIGiMQswCQYD
VQQGEwJVUzENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxJDAiBgNVBAoT
G0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLjEMMAoGA1UECxMDTUlTMRQwEgYDVQQDEwtFbXBs
b3llZSBDQTEhMB8GCSqGSIb3DQEJARYSY2FAZGlnc2lndHJ1c3QuY29tAhEA0B5AYgAAAnwAAAAG
AAAABTANBgkqhkiG9w0BAQEFAARAYLKycN2zWS1cJt+CCzFq5u3CP5CbBXepNqgn/3qluBpFCMry
mZFFA6if6YxuLNOl8U6X/EAad4C0QnN6wONP/QAAAAAAAA==

------=_NextPart_000_0017_01BE7788.6CD1D0E0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19242 for ietf-pkix-bks; Fri, 26 Mar 1999 11:05:13 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA19238 for <[e-mail]>; Fri, 26 Mar 1999 11:05:13 -0800 (PST)
Received: (qmail 19524 invoked from network); 26 Mar 1999 19:12:34 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 26 Mar 1999 19:12:34 -0000
Received: (qmail 12874 invoked from network); 26 Mar 1999 19:07:07 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 26 Mar 1999 19:07:07 -0000
Message-ID: <004b01be9000$35640660$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: Re: PKIX notice files, and markup
Date: Mon, 26 Apr 1999 11:16:58 -0500
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Russ Housley <[e-mail]>
To: Peter Williams <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Date: Friday, March 26, 1999 10:20 AM
Subject: Re: PKIX notice files, and markup


>Peter:
>
>The ASN.1 types limit some choices, although DisplayText provides alot of
>flexibility.
>
>Russ
>


Are you suggesting that the notice file content is limited to DisplayText,
like the 200 chars of embedded notice content is so limited?

The original intent of the design was that the notice file would
have an (unspecified) compound document architecture with referencable
elements, so that certs could function as notice-deliving vehicles
in trade-terms protocols conducted via the negotiation and interchange of
certs
in SSL and IKE  handshakes. The implicitely embedded legal terms
and conditions are an important part of trade negotiation, assuming certs
are to serve as the backbone for interactive commerce, not merely
a boring network security and authentication infrastructure replacing
kerberos.

It is true today's first implementation of this is used to send threatening
and dire
CPS warnings to browser users, as a minimal notice protocol. And that use
could perhaps be limited to a simple string.  But that was not
the limited purpose of the design which has much potential, now the
mechanism is standardized.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16799 for ietf-pkix-bks; Fri, 26 Mar 1999 10:23:49 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16795 for <[e-mail]>; Fri, 26 Mar 1999 10:23:48 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA18243 for <[e-mail]>; Fri, 26 Mar 1999 13:31:09 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA18239 for <[e-mail]>; Fri, 26 Mar 1999 13:31:09 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA20028 for <[e-mail]>; Fri, 26 Mar 1999 13:29:41 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA11765 for <[e-mail]>; Fri, 26 Mar 1999 13:31:14 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 26 Mar 1999 13:31:14 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: "Alternatively-encoded" extensions
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mcHY0FATDPJD7jCiAN4qZQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Stephen Kent <[e-mail]>
> 
>    [snip]
>
> VeriSign and other vendors, in bid to get to market first, have sometimes
> introduced their own conventions into certificates, prior to the adoption
> of standards.  That's why we have such "features" as e-mail addresses
> encoded as common names, DNS names of servers encoded as common names, and,
> my favorite, the short form CPS encoded as a text string extension in a
> certificate.  So, I place little weight on conventions adopted in this
> fashion, just as RFC 2459 and the S-MIME RFCs have found it appropriate to
> denigrate what we now consider inappropriate name form conventions of the
> sort cited above.
> 
>    [Peter Williams wrote...]
> 
> >(The VeriSIgn CPS extension is/was not a name-form, for the record, and
> >is useful in a very particular application context, and for specific (legal)
> >purpose.)
> 
> See my comments on that extension above.


The following name-form was included in a VeriSign certificate which I
happened to have laying around.  Of particular interest is the URL
contained in an OrganizationalUnit RDN.  I agree with Steve that such
exhibits of expediency should not guide the development of PKIX
standards / best operating practices.


CompanyX's binary-encoded multimedia extension, patented or not, should
not be standardized by PKIX.  If CompanyX insists on placing this
information in a certificate instead of using a more conventional
CMS (PKCS-7) object, they are free to do so.  And if they wish to
standardize their cert extension, they should take their proposal to
an industry Multimedia-Intellectual-Property-Cryptographic-Protection
forum, not the PKIX working group.


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

SEQUENCE length = 282 {
    SET length = 17 {
        SEQUENCE length = 15 {
            OID 2.5.4.localityName(7)
            PrintableString "Internet"
        }
    }
    SET length = 23 {
        SEQUENCE length = 21 {
            OID 2.5.4.organizationName(10)
            PrintableString "VeriSign, Inc."
        }
    }
    SET length = 52 {
        SEQUENCE length = 50 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "VeriSign Class 1 CA - Individual Subscriber"
        }
    }
    SET length = 70 {
        SEQUENCE length = 68 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "www.verisign.com/repository/CPS Incorp. by 
Ref.,LIAB.LTD(c)96"
        }
    }
    SET length = 39 {
        SEQUENCE length = 37 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "Digital ID Class 1 - Microsoft"
        }
    }
    SET length = 21 {
        SEQUENCE length = 19 {
            OID 2.5.4.commonName(3)
            PrintableString "John Citizen"
        }
    }
    SET length = 46 {
        SEQUENCE length = 44 {
            OID 1.2.840.113549.1.9.emailAddress(1)
            IA5String "[e-mail]"
        }
    }
}



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15109 for ietf-pkix-bks; Fri, 26 Mar 1999 08:32:17 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15104 for <[e-mail]>; Fri, 26 Mar 1999 08:32:16 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA16681; Fri, 26 Mar 1999 11:39:28 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0cb3200d9413d3@[128.33.238.119]>
In-Reply-To: <005e01be8e6b$c9df6be0$[e-mail]>
Date: Fri, 26 Mar 1999 11:35:51 -0500
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: "Alternatively-encoded" extensions
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>Lets us establish principles, so PKIX is fair, non-arbitrary,
>and rule-based. Im more interested in the principles
>for use of "alternatively-encoded objects" in certs, than whatever
>Anders was contemplating, for context.

PKIX is a WG and operates on a rough concensus basis, as judged by the WG
chair(s), subject to adjudication by the IESG and IAB, when necessary. As a
WG chair I consider inputs from WG members in forming an opinion, and I
weigh technical and architectural considerations, based on my judgement.
Hopefully, the judgement that WG chairs employ as part of this process is
not arbitrary, though it is not codified in a simple rule set.

> Interestingly, in the VeriSign trust domain, there is/was already
>an implicitly MIME-encoded object (text/plain) - be this
>sensible or nay - in certificates, whose
>profile and issuing practices is/are licensed
>and accredited by a US state authority and a Big 6 firm, one
>may note. Said content is/was an X.509 extension.

VeriSign and other vendors, in bid to get to market first, have sometimes
introduced their own conventions into certificates, prior to the adoption
of standards.  That's why we have such "features" as e-mail addresses
encoded as common names, DNS names of servers encoded as common names, and,
my favorite, the short form CPS encoded as a text string extension in a
certificate.  So, I place little weight on conventions adopted in this
fashion, just as RFC 2459 and the S-MIME RFCs have found it appropriate to
denigrate what we now consider inappropriate name form conventions of the
sort cited above.

>One  could argue the object is actually an implicitely encoded SMTP-body if
>you
>prefer, or a SGML-tagged <PRE> element - it does not matter for
>the argument - it ain't BER-encoded or an ASN.1-specified object
>or string. There are/or at least were a few hundred thousand of such
>certificates floating out there, today. Nothing has broken to my knowledge,
>including interaction with S/MIME. The Internet world today is largely happy
>to
>accept certs with unknown, non-critical extensions, even large ones.

One could interpret encodings in this fashion, but I fear one would be
engaging in sophistry.  In my mind, pre-existing bad practices do not
justify codification, nor should they be used to justify future bad
practice.

>(The VeriSIgn CPS extension is/was not a name-form, for the record, and
>is useful in a very particular application context, and for specific (legal)
>purpose.)

See my comments on that extension above.

>But let me ask the question, a different way, and propose an example
>and a concluding argument, so we might establish the principle :
>
>
>If a X.509 extension is proposed to IETF (PKIX) which is designed to
>be interpreted - by a binary-decoding based process
>other than ASN.1/DER - is there an objection in principle?

Unless there are very persuasive, extenuating circumstances, yes.  Certs
are binary objects that have to be DER encoded for signing and there needs
to be very good reason to deviate from the model presented in X.500.

>For example, CompanyX patented a (binary-encoded)
>extension for certs  designed to be intepreted by
>multimedia hardware. The content of the extension was
>a simple state-machine language which drove the multimedia capability
>of the chip, which leveraged public key cryptography to perform
>certain cert-based protection functions for multimedia content/capabilities
>based on the cert subject's identity, as authenticated using certificates.

Since this is a patented encoding, I would not suggest that PKIX consider
such an extension for standardization. I suggest that Company X get an OID
for a private extension.

>Now, I know X.509 and the various national standards bodies making up ISO
>does/do not object to string-encoded objects embedded in octet-string
>extensions, per se.
>
>Do PKIX WG managers, and the IESG? Nothing in 2459 suggests
>such an interpretation. 2459 suggests quite the opposite, in fact.

Strings are fine represetnations when they represent a natural base
encoding for the data in question.  The JPEG exmample we were debating
clearly fails this test.

>My conclusion is: a minimally-conforming PKIX 2459
>implementation should not reject a cert because of
>an unknown (non-critical) extension, unless other signals such
>as a policy (known to the implementation) requires extension-type and
>schema and extension value-constraint checking for
>cert validity, or subsequent digital signature verification.

I would not disagree with this statement, but it also does not seem to be
especially relevant to the ongoing debate.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15099 for ietf-pkix-bks; Fri, 26 Mar 1999 08:32:14 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15093 for <[e-mail]>; Fri, 26 Mar 1999 08:32:12 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA16669; Fri, 26 Mar 1999 11:39:26 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0bb31ff4b3f12f@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Thu, 25 Mar 1999 10:56:03 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Location and Identification
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

I think we agree on most of the principles underlying biometric systems,
but we disagree about the difficulty of working backwards to create a bit
stream that will be accepted by the biometric validation system.  I do not
believe that most of the functions used to create templates are designed
with the features of one-way hash functions, for the reasons we have both
cited, e.g., the functions must tolerate the inevitable capture errors.
Thus I do not assume that it is computationally diffiuclt to work backwards
to create inputs that will be accepted. I am willing to be convinced on a
case-by-case basis, but so far no vendor of one of these systems has been
willing/able to establish non-invertability.

I believe that it is feasible to make fake fingers for fingerprints, given
a latent image. An example was given last year in tests reported on in
Network Security magazine, using a copier and transparency material. Most
of the tested fingerprint scanners were fooled.  To the best of my
knowledge, none of the widely available biometric capture devices for use
with a PC meets objective tamper-resistance standards (e.g., 140-1 level 3
or better), which suggests that even the few that employ crypto to protect
captured data can be subverted.

So, I stand by my contention that a capable adversary can, in general,
generate a bit stream that will fool a biometric authentication system,
given that the capture is not physically 9and crypto) secure, and given
access to a template.  For many such systems, one can also generate such a
bit stream from incidential capture of the biometrics of the target subject
by other means, e.g., latent prints, etc.  Thus one should consider
carefully under what circumstances it is appropriate to use this sort of
technology in conjunction with certificates.  Some of the example put forth
don't suffer from all of the problems cited above, and this might be
reasonable uses of biometrics.  For example, human matching of a cerified
image of a user's face against a physically present individual.  But, even
in this case, it is far from clear that we should put such an image in a
certificate, as David mentioned.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14374 for ietf-pkix-bks; Fri, 26 Mar 1999 07:37:08 -0800 (PST)
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14370 for <[e-mail]>; Fri, 26 Mar 1999 07:37:08 -0800 (PST)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <[e-mail]> for <[e-mail]>; Fri, 26 Mar 1999 07:44:28 -0800
Message-ID: <[e-mail]>
Date: Fri, 26 Mar 1999 08:42:44 -0700
From: Timothy Fisher <[e-mail]>
Reply-To: [e-mail]
Organization: Cyclone Software
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: "Alternatively-encoded" extensions
References: <005e01be8e6b$c9df6be0$[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I like the idea of "alterniatively-encoded" extensions.  I agree with
Peter's rationale that a non-critical extension should not have to be
ASN.1 encoded.  I also, would like to hear other opinions on this
subject.

Timothy Fisher


Peter Williams wrote:
> 
> Steve,
> 
> Lets us establish principles, so PKIX is fair, non-arbitrary,
> and rule-based. Im more interested in the principles
> for use of "alternatively-encoded objects" in certs, than whatever
> Anders was contemplating, for context.
> 
>  Interestingly, in the VeriSign trust domain, there is/was already
> an implicitly MIME-encoded object (text/plain) - be this
> sensible or nay - in certificates, whose
> profile and issuing practices is/are licensed
> and accredited by a US state authority and a Big 6 firm, one
> may note. Said content is/was an X.509 extension.
> 
> One  could argue the object is actually an implicitely encoded SMTP-body if
> you
> prefer, or a SGML-tagged <PRE> element - it does not matter for
> the argument - it ain't BER-encoded or an ASN.1-specified object
> or string. There are/or at least were a few hundred thousand of such
> certificates floating out there, today. Nothing has broken to my knowledge,
> including interaction with S/MIME. The Internet world today is largely happy
> to
> accept certs with unknown, non-critical extensions, even large ones.
> 
> (The VeriSIgn CPS extension is/was not a name-form, for the record, and
> is useful in a very particular application context, and for specific (legal)
> purpose.)
> 
> But let me ask the question, a different way, and propose an example
> and a concluding argument, so we might establish the principle :
> 
> If a X.509 extension is proposed to IETF (PKIX) which is designed to
> be interpreted - by a binary-decoding based process
> other than ASN.1/DER - is there an objection in principle?
> 
> For example, CompanyX patented a (binary-encoded)
> extension for certs  designed to be intepreted by
> multimedia hardware. The content of the extension was
> a simple state-machine language which drove the multimedia capability
> of the chip, which leveraged public key cryptography to perform
> certain cert-based protection functions for multimedia content/capabilities
> based on the cert subject's identity, as authenticated using certificates.
> 
> Now, I know X.509 and the various national standards bodies making up ISO
> does/do not object to string-encoded objects embedded in octet-string
> extensions, per se.
> 
> Do PKIX WG managers, and the IESG? Nothing in 2459 suggests
> such an interpretation. 2459 suggests quite the opposite, in fact.
> 
> My conclusion is: a minimally-conforming PKIX 2459
> implementation should not reject a cert because of
> an unknown (non-critical) extension, unless other signals such
> as a policy (known to the implementation) requires extension-type and
> schema and extension value-constraint checking for
> cert validity, or subsequent digital signature verification.
> 
> -----Original Message-----
> From: Stephen Kent <[e-mail]>
> To: Peter Williams <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Date: Wednesday, March 24, 1999 9:38 AM
> Subject: Re: Biometrics in Qualified Certificates
> 
> Peter,
> 
> >You may wish to define a name form for the alternative subject name
> >extension, as permitted by X509 and PKIX. Its form can be
> >a MIME-encoded name, an SMTP-extended address field, etc.
> >
> >My reading of PKIX-1 is that implementations receving such
> >a field should not balk at its mere inclusion, unless the security
> >policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
> >is more strict than RFC 2459 regarding the extension and
> >extension-value schema rules.
> 
> Yes, one could do what you say, Peter, but it seems to make no sense to use
> any MIME encoding here, given the binary nature of certificates.  Thus, the
> WG co-chair would not view such a proposal as appropriate, unless you can
> provide some good rationale for it.  Extensible syntax is not a license to
> do silly things; we always need a good rationale for adding extensions,
> name forms, etc.
> 
> >As for your
> >>second query, my position is that it is a bad idea to put such information
> >>into a public key certificate.
> >
> >X.509 supports the idea that an opaque data field created by
> >the Naming Authority be conveyed in a public-key certificate,
> >to engender assurances relevant to uniqueness of
> >(subject) naming (vs key certification) quality.
> >
> >"A certification authority produces the certificate of a user by signing
> >(see clause 9)
> >a collection of information, including the user’s distinguished name and
> >public key, as well
> >as an optional unique identifier containing additional information about
> the
> >user. The exact
> >form of the unique identifier contents is unspecified here and left to the
> >certification
> >authority and might be, for example, an object identifier, a certificate, a
> >date, or some
> >other form of certification on the validity of the distinguished name. "
> 
> But the argument that has been made here is not the use of this data for
> further qualification of a user DN; it is "let's find a place in a cert to
> put some data we think might be useful in some application contexts."
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14168 for ietf-pkix-bks; Fri, 26 Mar 1999 07:19:19 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14164 for <[e-mail]>; Fri, 26 Mar 1999 07:19:18 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA12616; Fri, 26 Mar 1999 07:25:38 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 25 Mar 1999 19:23:43 -0500
To: "Peter Williams" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PKIX notice files, and markup
Cc: "IETF-PXIX" <[e-mail]>
In-Reply-To: <001501be8f4a$eba67860$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

The ASN.1 types limit some choices, although DisplayText provides alot of
flexibility.

Russ

   certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }

   -- policyQualifierIds for Internet policy qualifiers

   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

   PolicyQualifierId ::=
        OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

   Qualifier ::= CHOICE {
        cPSuri           CPSuri,
        userNotice       UserNotice }

   CPSuri ::= IA5String

   UserNotice ::= SEQUENCE {
        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL}

   NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER }

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

At 01:39 PM 4/25/99 -0500, Peter Williams wrote:
>RFC 2459 is useful for OCSP.
>
>"The application software SHOULD display all   user notices in all
>certificates
>of the certification path used...]
>
>"The user notice has two optional fields: the noticeRef field and the
>explicitText field.   The noticeRef field, if used, names an organization
>and
> identifies, by number, a particular textual statement prepared by      that
>organization.  For example, it might identify the  organization
>CertsRUs and notice number 1.
>
>In a typical  implementation, the
>application software will have a notice file  containing the current set of
>notices for CertsRUs; the application will extract the notice text from the
>file and display  it.  Messages may be multilingual, allowing the software
>to select  the particular language message for its own environment."
>
>
>Is it fair to say, that PKIX does not prescribe any approach for
>compliant implementations to handle the selection of texts from, or the
>technology for displaying material from, a notice file?
>
>Presumably, in today's consumer-environment, the notice file can be in
>markup,
>if the extension-using application understands markup, to allow
>notice-writing
>parties to underline, embolden, etc, use the full range of chars and
>symbols,
>have accept buttons, follow URLs, have internal links for Table of
>Contents, etc., etc.
>
>Do Netscape or Microsoft browsers already support this feature, perhaps,
>as markup-oriented or simple text rendering cert-applications?
>
>I'm thinking of reusing this extension for certs in an OCSP response
>extension
>so that the same policy enforcement and notice-delivery
>framework can be applied to value-added OCSP-based
>validation and revocation/suspension/hold status services.
>
>The approach can be used also for DCS.
>
>Peter.
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA09080 for ietf-pkix-bks; Fri, 26 Mar 1999 02:57:40 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09076 for <[e-mail]>; Fri, 26 Mar 1999 02:57:38 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA27003; Fri, 26 Mar 1999 12:04:54 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 26 Mar 1999 12:04:54 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id MAA27964; Fri, 26 Mar 1999 12:04:52 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id MAA10014; Fri, 26 Mar 1999 12:04:52 +0100
Date: Fri, 26 Mar 1999 12:04:52 +0100
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX notice files, and markup
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While trying to implement dcs it was obvious that some
small changes became necessary: including some obvious
asn.1 syntax corrections, the following resumes changes
that I propose. 

The only non obvious piece the replacement of a certificate
list by a sequence of target and chain in the response.

This can be used properly for example in a cpkc request:

The requester enters a liste of certs to be validated, 
and the response includes for each cert a chain or a
list of certs that are somehow related to that cert, and
the policy information that was used. 

Peter


ReqInfo ::= SEQUENCE  {
     version                      Integer ,
     service                      ServiceType,
     requester                    [0] GeneralName OPTIONAL,
     reqPolicy                    [1] PolicyInformation OPTIONAL,
     dcs                          [2] GeneralName ,
     nonce                        Integer,
     reqTime                      ReqTime OPTIONAL,
     extensions                   Extensions OPTIONAL   
}

TargetandChain ::= SEQUENCE {
     target                       Certificate,
     chain                        [0] SEQUENCE OF Certificate OPTIONAL,
     pathProcInput                [1] PathProcInput OPTIONAL  
}

Info ::= SEQUENCE  {
     reqInfo                ReqInfo,
       messageImprint               MessageImprint,
     reqSignature             [0]    SignerInfo OPTIONAL,
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         ReqTime, 
     serialNumber                 Integer OPTIONAL,
     chainCerts              [1]  SEQUENCE OF TargetandChain OPTIONAL, 
     crls                    [2]  SEQUENCE OF Certificate OPTIONAL,
     extensions               [3]    Extensions OPTIONAL  
}


PathProcInput ::= SEQUENCE {
     acceptablePolicySet          CertificatePolicies ,
     inhibitPolicyMapping         [0] BOOLEAN DEFAULT FALSE,
     explicitPolicyReqd           [1] BOOLEAN DEFAULT FALSE 
}

> 
> The approach can be used also for DCS.
> 
> Peter.
> 
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04880 for ietf-pkix-bks; Thu, 25 Mar 1999 13:27:37 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA04876 for <[e-mail]>; Thu, 25 Mar 1999 13:27:36 -0800 (PST)
Received: (qmail 16788 invoked from network); 25 Mar 1999 21:34:53 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 25 Mar 1999 21:34:53 -0000
Received: (qmail 24673 invoked from network); 25 Mar 1999 21:29:27 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 25 Mar 1999 21:29:27 -0000
Message-ID: <001501be8f4a$eba67860$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "IETF-PXIX" <[e-mail]>
Subject: PKIX notice files, and markup
Date: Sun, 25 Apr 1999 13:39:15 -0500
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 2459 is useful for OCSP.

"The application software SHOULD display all   user notices in all
certificates
of the certification path used...]

"The user notice has two optional fields: the noticeRef field and the
explicitText field.   The noticeRef field, if used, names an organization
and
 identifies, by number, a particular textual statement prepared by      that
organization.  For example, it might identify the  organization
CertsRUs and notice number 1.

In a typical  implementation, the
application software will have a notice file  containing the current set of
notices for CertsRUs; the application will extract the notice text from the
file and display  it.  Messages may be multilingual, allowing the software
to select  the particular language message for its own environment."


Is it fair to say, that PKIX does not prescribe any approach for
compliant implementations to handle the selection of texts from, or the
technology for displaying material from, a notice file?

Presumably, in today's consumer-environment, the notice file can be in
markup,
if the extension-using application understands markup, to allow
notice-writing
parties to underline, embolden, etc, use the full range of chars and
symbols,
have accept buttons, follow URLs, have internal links for Table of
Contents, etc., etc.

Do Netscape or Microsoft browsers already support this feature, perhaps,
as markup-oriented or simple text rendering cert-applications?

I'm thinking of reusing this extension for certs in an OCSP response
extension
so that the same policy enforcement and notice-delivery
framework can be applied to value-added OCSP-based
validation and revocation/suspension/hold status services.

The approach can be used also for DCS.

Peter.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04714 for ietf-pkix-bks; Thu, 25 Mar 1999 13:09:52 -0800 (PST)
Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04710 for <[e-mail]>; Thu, 25 Mar 1999 13:09:51 -0800 (PST)
Received: from earthlink.net ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 25 Mar 1999 13:17:06 -0800
Message-ID: <[e-mail]>
Date: Thu, 25 Mar 1999 14:15:12 -0700
From: Timothy Fisher <[e-mail]>
Reply-To: [e-mail]
Organization: Cyclone Software
X-Mailer: Mozilla 4.5 [en]C-AtHome0405  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Object IDs for PKIBody types?
References: <005e01be8e6b$c9df6be0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Do Object Identifiers exist for the various PKIBody message types?

For example, the Object ID for the PKCS7-SignedData type is:
1.2.840.113549.1.7.2

Is there any such IDs for the PKIBody types, such as the CertReqMessage,
or the CertRepMessage?

Thanks,
Timothy Fisher


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA04188 for ietf-pkix-bks; Thu, 25 Mar 1999 12:11:11 -0800 (PST)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04184 for <[e-mail]>; Thu, 25 Mar 1999 12:11:05 -0800 (PST)
From: [e-mail]
Subject: Re: Cross certification message protection (RFC2510)
To: [e-mail]
Cc: ietf-pkix <[e-mail]>
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 12 1999"
Date: Thu, 25 Mar 1999 20:17:48 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Epic/Iris_at_03/25/99_03:20:34_PM" (Daily Build (based on 166)|Mar 23 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,
     I am not really questioning the benifits/differences between signing
     and generating a MAC. My question is about what appears to be a
conflict
     in the spec. In one place it says you must protect the message with a
MAC,
     and in another place it says you must protect the message with a
digital
     signature. I was wondering which section (B7 or 4.6.1) is correct.


                              Mike







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03859 for ietf-pkix-bks; Thu, 25 Mar 1999 11:28:46 -0800 (PST)
Received: from dimoni.upc.es (dimoni.upc.es [147.83.2.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03855 for <[e-mail]>; Thu, 25 Mar 1999 11:28:36 -0800 (PST)
Received: from sert.ac.upc.es (sert.ac.upc.es [147.83.33.7]) by dimoni.upc.es (8.8.6/8.8.6) with ESMTP id UAA15467; Thu, 25 Mar 1999 20:33:16 +0100 (MET)
Received: (from smap@localhost) by sert.ac.upc.es (8.9.1/8.9.1) id UAA14499; Thu, 25 Mar 1999 20:29:39 +0100 (MET)
Received: from mila10.ac.upc.es(147.83.34.83) by sert.ac.upc.es via smap (V2.0) id xma014497; Thu, 25 Mar 99 20:29:30 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 25 Mar 1999 20:30:30 +0100
To: [e-mail]
From: Jaime Delgado <[e-mail]>
Subject: IS&N'99 Barcelona approaching (27th-29th April)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Colleagues,

This is to remind you that the deadline for early registration for IS&N'99
(Sixth International Conference on Intelligence in Services and Networks)
is 15th April. The same applies to the CLIMATE Industrial Agent Workshop.

IS&N'99 will take place in Barcelona (Spain) on 27th - 29th April 1999,
while the Agent Workshop will take place on the 26th, also in Barcelona.
During the first day of IS&N'99 (27th April), an industrial showcase will
be run in parallel.

The Conference is jointly sponsored by the European Commission, the
Universitat Politecnica de Catalunya (UPC) and Telefonica. It is
technically co-sponsored by IEEE Communications Society.

The Conference is supported by the ACTS projects in the IS&N Domain,
Eurescom, TeleManagement Forum, OMG, TINA-C and Media Technology Group.

You can find detailed information about the Conference at:

	http://www.ac.upc.es/isn99/

You can also request a printed brochure to:
						[e-mail].

Please apologise if you receive this mail more than once, and if you
already registered to the Conference. Please pass it to any colleague you
think might be interested. Thank you very much in advance.

Best regards,


	Jaime Delgado
	Chairman of the IS&N'99 Organising Committee



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03682 for ietf-pkix-bks; Thu, 25 Mar 1999 11:03:35 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03678 for <[e-mail]>; Thu, 25 Mar 1999 11:03:34 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id LAA18466 for <[e-mail]>; Thu, 25 Mar 1999 11:10:51 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 25 Mar 1999 11:10:36 -0800
To: <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: 2 Where is the Silver Bullet?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:41 AM 3/25/99 -0000, you wrote:
>The URL was bad.  resent
>
>http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP
>>
>>>3) The absolute critical function to integrity protect the capture data
>>>between the capture device and the comparing algorithm, and the equally
>>>critical function to authenticate and integrity protect pre stored data
>>>used by the comparing algorithm.
>>
>
>
>Tony,
>bio-metrics behave as you say.
>
>Should I interpret your views as:  We should continue forever with
>easily faked ID-cards with ordinary photos.  Or should we stop
>using ID-cards (passports) as well?
>
>Or do you have another "silver bullet"?
>
>Just wondering a bit
>
>best regards
>Anders

Anders,

Actually, the "best" solution is to require a panoply of identification
methods, and find (or fail to find) coherence among the results.  Granted,
this is a multi-transaction, multi-path, high-bandwidth solution.

When you walk down a street in a strange town, and see someone you think
that you recognise, you apply a wide range of "checks" in ascertaining
the accuracy of the identification.  The face seems the same, but they
are too tall/short.  Or you speak to them, and they sound/don't-sound
familiar.  Or you ask them some questions, and they know/don't know
the answers.  I feel that identification should be based upon such a
methodology (and damn the bandwidth).

I am especially concerned that by seeking a "magic bullet" (a short and
simple piece of data that in itself represents the "final word", we are
actually decreasing security, and producing a system more fragile and
more easily targeted by fraudsters.

Curiously, a photo is in some ways superior to fingerprints or retina.
I imaging it just a bit more difficult to "look like" someone else,
especially to familiar companions (and perhaps future neural-net
processors), and yet my face (for instance) is hardly something
that I can consider to be held secret or non-public.

Regards,

___tony___


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03310 for ietf-pkix-bks; Thu, 25 Mar 1999 10:25:41 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA03306 for <[e-mail]>; Thu, 25 Mar 1999 10:25:39 -0800 (PST)
Received: 	id NAA19347; Thu, 25 Mar 1999 13:30:19 -0500
Received: by gateway id <G4CAX7LC>; Thu, 25 Mar 1999 13:32:36 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BD33@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: IETF-PXIX <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Subject: RE: DCS or DVS ?
Date: Thu, 25 Mar 1999 13:27:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis sent this message to the list back in January and I never got around
to responding to it.  He reminded me last week that I hadn't done so.  My
responses are embedded below.

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Tuesday, January 19, 1999 6:35 AM
> To: 	IETF-PXIX
> Subject: 	DCS or DVS ?
> 
> 
> These comments are relative to the document: Internet X.509 Public Key
> Infrastructure. Data Certification Server Protocols
> During the last IETF meeting I have been requested to re-post these
> comments.
> Here it is.
> 
> The various facets of the DCS functionality need to be looked at very
> carefully before looking at the protocols.
> 
> The abstract says:
> 
> "Useful Data Certification Server responsibilities in a PKI are to
> validate
> signatures and to provide up-to-date information regarding the status of
> public key certificates".
> 
> This addresses two items:
> 
> a) validation of signatures,
> b) up-to-date information regarding the status of public key certificates.
> 
> Let us address the validation of signatures first.
> 
> When a signer signs something this is in accordance with a security
> policy.
> That policy may specify one OR MORE trusted points but also the allowed
> certification paths that can be used. That policy may be implicit for a
> given
> application/context or may be extracted from the data itself, e.g. when
> you
> receive a signed contract that contains the policy.
> 
> The policy does not specify only the trusted points. It may also specify
> other
> conditions, like which TSAs (Time Stamping Authorities) need to be
> involved,
> the grace time period for a user to ask for the revocation of its
> certificate
> in case of a private key compromise, ...
> 
> The implication is that nominating one or more trusted points is not
> enough in
> the general case and only a security policy is able to encompass all the
> checks that need to be made.
> 
> Degenerated cases may consider only one or more trusted point, but saying
> that
> the signature is *valid* is insufficient unless we say against what (see
> later
> the various cases that may be considered).
> 
> Considering a "certification path validity checking" would thus be more
> appropriate. This would leave room for more complete tests.
> 
I agree with what you say here.  I will change the introduction to more
fully state "certificate path validity checking" as the purpose of this
protocol.

> An intermediate conclusion is thus to consider in addition to the validity
> of
> a signature, the validity of a certification path. What means performing a
> checking against trusted points ? This includes the certification path
> that
> may be used. One way (but not the single one) to define them, is to use
> self-signed certificates that include naming constraints. The key point is
> to
> remember that it is not because a certificate exists that it should be
> used.
> 
> When trust points are used instead of security policies, it would be
> needed to
> refer to ONE OR MORE self-signed certificates. In order to make sure that
> the
> path used for the verification is correct, it should be given back to the
> requester so that it can check that it is OK.
> 
Again, I agree.  I believe that the present draft does this.

> Let us then address the second item: up-to-date information regarding the
> status of public key certificates.
> 
> The *status* of public key certificates is already being addressed by
> OCSP, so
> we should not duplicate the work here. It is NOT addressed for an old
> status,
> but it is not evident that it should (see arguments later on, why it
> should
> not).
> 
> It would be better to consider "up-to-date information regarding the
> *validity* of public key certificates".
> 
Again, I agree.  I will change the wording appropriately.

> So both items would be about validity/validation. A better name would be a
> Data Validation Server (DVS) instead of DCS where the word "Certification"
> (from Data Certification server) may be confusing with the function of a
> CA.
> As an example of this kind of problem the actual text speaks about: "When
> certifying a public key certificate, the DCS verifies ..." A CA
> (Certification
> Authority) does such a certification, not a DCS.
> 
> In the introduction (section 1) three functions are introduced:
> 
> 1) validity and correctness of an entity's claim to possess data,
> 2) validity and revocation status of an entity's public key certificate,
> 3) validity and correctness of another entity's signature.
> 
> For the item 1, the TSA (Time Stamping Authority) already allows to prove
> that
> the requester possessed the data in the request at the time indicated by
> the
> DVS.
> 
Actually a TSA just proves that the data existed at a given point in time,
not that any particular entity possessed it.

> Is it thus needed in addition to consider the case where a single entity
> (the
> DVS) both proves that the requester possessed the data in the request and
> a
> valid signature key at the time indicated by the DVS ?
> 
> It would be better to keep the two functionality independent. The TSA
> signature is always for later use, while the DVS signature is not (see
> additional arguments later on). If needed, the same entity can support
> both
> protocols. Since the last case (3) is about any entity's signature, it
> would
> be easier to consider only that case and use the TSA, in addition, when
> needed.
> 
Exactly.  If you sign a document and get it timestamped, this can prove that
you possessed the data at the given time, but the verifier must still
validate the signature.  By using the DCS service, the DCS would validate
the signature for you and provide a token attesting to the fact.

> In the item 2, if validity is checked, by implication the revocation
> status is
> also checked.
> 
> Note: It is not clear to understand what "correctness" means in addition
> to
> validity in the items 1) and 3).
> 
> The various facets to consider for a DVS would then be along the following
> (and the document should be restructured along thse lines) :
> 
> 1) validity of an entity's public key certificate.
> 2) validity of a certification path.
> 3) validity of an entity's signature.
> 
> The validity may be checked against:
> 
> a) a security policy.
> b) one or more self-signed certificates.
> c) one or more certification paths.
> d) one or more trusted points (provided that the path being used is
> returned).
> 
> The next question is what kind of information should be given to the DVS ?
> 
> There is not a single answer to this question, but it would be better to
> restrict some of the possibilities when verifications "in the past" occur.
> 
> When something is signed, it seems natural that the verifier makes sure
> that,
> at the first time it makes the verification, it gets everything back that
> he
> will need later on to prove that the signature was valid (according to a
> non
> repudiation policy).
> 
> If he (or someone else) wants to make the verification later on, it seems
> then
> natural that he provides what he got at that time. This has two important
> implications:
> 
> 1) This means that the DVS does not have to fetch, e.g. back 3 years old
> CRLs
> or ARLs.
> 
> 2) This also means that the DVS *should return all what is needed for
> later
> proof*. That stuff may then be used by any DVS to make the verification,
> without the need for anyone to trust the first DVS for its good faith.
> This
> would be a nice way to support the non repudiation APIs described in IDUP
> (Independent Data Unit Protection, now RFC 2479 and authored by Carlisle)
> where such a functionality exists.
> 
> CRLS and ARLs may then be part of the data that is given or returned to
> the
> DVS. Time Stamp tokens may also be part of it.
> 
> All the functions listed above can be used in the context where the DVS is
> a
> server trusted only by its requester (a short term signature from the DVS
> is
> being used) and not necessarily by other users.
> 
I think everything you say above is supported by the present protocol.  If
it isn't could you please suggest some additions that would be required?

	Robert.









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA01517 for ietf-pkix-bks; Thu, 25 Mar 1999 06:28:18 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA01513 for <[e-mail]>; Thu, 25 Mar 1999 06:28:16 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id PAA29773; Thu, 25 Mar 1999 15:35:04 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 25 Mar 1999 15:35:43 +0100
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC Certificates, Directories, and Distinguished Names
Cc: <[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 mail.proper.com id GAA01514
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

At 09:25 PM 3/24/99 -0700, Bob Jueneman wrote:
<snip>
>So if I understand the purpose that the QC is intended to serve (and I
>confess that I haven't read the document, although I'm supportive of
>the effort), I would suggest that you modify the requirement to more
>carefully 
>state a requirement that the unmistakable identity provide a least a
>strong
>hint as to where to start looking for that individual if necessary,
>e.g.,
>though some physical location that he has a strong tie to, whether by
>financial, residence, or other means.  If the individual is a itinerant
>laborer or 
>vagrant with not fixed address, all of the identity details in the
>world may 
>not help if he doesn't want to be found.
>
>Bob

I would strongly argue against this. The means of locating a person may
strictly be provided outside of the certificate (and the CA:s service).

In a Swedish ID-card. There are no adress information. There are however a
civic registration number that can be used to track down the person via
official registers.

The way things are stated now is the only reasonable requirement, i.e. that
the information by unmistakable means relates to e specific individual. But
you might still need cooperation from a registration authority (Not only a
CA:s RA in some cases, but a public one) to locate the person.

We can't possibly require more. We have to leave this matter up to the
implementing CA to decide.

/Stefan 

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA00296 for ietf-pkix-bks; Thu, 25 Mar 1999 03:47:16 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00292 for <[e-mail]>; Thu, 25 Mar 1999 03:47:14 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id MAA27830; Thu, 25 Mar 1999 12:54:23 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 25 Mar 1999 12:55:02 +0100
To: "Tolga Acar" <[e-mail]>, <[e-mail]>, "Bob Jueneman" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Location and Identification
Cc: <[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 mail.proper.com id DAA00293
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 04:49 PM 3/23/99 -0700, Tolga Acar wrote:
>Besides, how can you revoke a biometric info if it's compromised (assuming
it's used as a secret info) ? Use the other finger ? If I remember
correctly, Steve Kent already has a posting on this issue in the last week
or so.

This is a major point.

You can not revoke biometrics. And NO biometric verification system should
rely on biometric data to be secret.

The bio-metric system MUST rely on the secure capturing device to ensure
that only biological originals are able to feed the system with capture data.

And this IS a major design criteria for biometric capture devices.

Then, how reliable this have to be in a certain system is just a matter of
policy, as always. And this goes also for how long time in the future we
must assume that the capture device can't be fooled by a faked bio-copy. If
this is just used for authentication this parameter might be set to almost
zero (We always have to replace the capture devices when they no longer are
reliable). In non-repudiation we have to prove that the means of producing
a signature was secure at the time of signature creation, and that's
another problem which by no means are unique to the use of biometrics.

As was said earlier, BIOMETRICS ARE NOT SECRETS! (they are only unique
biological properties)

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA00149 for ietf-pkix-bks; Thu, 25 Mar 1999 03:20:50 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00145 for <[e-mail]>; Thu, 25 Mar 1999 03:20:48 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id MAA27529; Thu, 25 Mar 1999 12:27:28 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 25 Mar 1999 12:28:08 +0100
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Location and Identification
Cc: <[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 mail.proper.com id DAA00146
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

I think I agree to most of what you are saying, but I fail to see where I
was wrong.

>Sorry, but WRONG!
>
>The 4 criteria are necessary but not sufficient.
>
>Even if all four are done with absolute perfection it is still not
sufficient,
>if a biometric identification can be taken in another completely 
>different context, and then applied to authenticate something completely
>different.

This doesn't mean that my described system is failing. This means that some
other system that doesn't meet req 1-4 is failing, thus prove my
assumptions to be right, not wrong.

/Stefan

At 08:14 PM 3/24/99 -0700, Bob Jueneman wrote:
>Sorry, but WRONG!
>
>The 4 criteria are necessary but not sufficient.
>
>Even if all four are done with absolute perfection it is still not
sufficient,
>if a biometric identification can be taken in another completely 
>different context, and then applied to authenticate something completely
>different.
>
>The OJ case I referred to in a previous message is an example.
>It was, allegedly, a case of what we would call in computer security 
>terms either a replay or spoofing attack. There was little question 
>that it was OJ's blood -- the question is how did it get on the fence.
>
>If you present a document in court that has as xeroxed copy of my
>fingerprint on it, does that prove that I approved that document?
>
>No, it certainly does not. I very well might never have seen the 
>document, and the fingerprint could have been photocopied by 
>the police who picked me up, dusted from a fingerprint on a glass offered
>to me by the prosecution attorney, or obtained in any other way.
>
>And even binding the biometrics to the document itself doesn't prove
>very much, because some other application might have legitimately 
>collected and saved the raw input, gone through the process, and 
>hashed (message digest sense) the biometric result and the document.
>
>As Schneirer has succinctly put it, BIOMETRICS ARE NOT SECRETS!
>
>They may be very useful if they involve a physical presence at a 
>tamper-resistant boundary for access control, whether that boundary is
>a human clerk examining a driver's license, a door controller or the 
>much desired fingerprint reader on a smart card.
>
>But if they have to be collected by an application and transmitted over a
wire, 
>they are highly suspect, and are quite likely to do much more harm than 
>good, both to authentication and privacy.
>
>And BTW, I would love to be proven wrong on this -- if someone can provide 
>me suitable evidence of such an application that could reasonable be 
>considered secure against this class of attack, I would gladly buy them a 
>drink, and maybe even a nice dinner.
>
>Bob
>
>>>> Paul Koning <[e-mail]> 03/23/99 03:41PM >>>
>>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:
>
>> The reliability in a biometric identification scheme lies in a combination
>> of:
>> 1) The subjects unique posession of the original biological limb itself
>> (the finger, eye etc.)
>> 2) The function of a capture device which only allows the real biological
>> human original to produce valid digital capture data.
>> 3) The absolute critical function to integrity protect the capture data
>> between the capture device and the comparing algorithm, and the equally
>> critical function to authenticate and integrity protect pre stored data
>> used by the comparing algorithm.
>> 4) The function of a comparing algorithm, comparing captured data with the
>> pre stored information in such way that it produce a good balanced, low
>> probability, of both false positive (wrong original accepted) and false
>> negative (right original rejected) response.
>> 
>> If any of these 4 fail, the system is unreliable. If not, the system works.
>
>It seems to me that all four of these are, at best, highly immature
>and at worst, beyond the state of the art.
> 
>> But note that none of these steps require any digital representation of the
>> bio-data to be secret.
>
>Yes, IF all four are rigorously satisfied.  If they are not, then when 
>an attacker has access to the digital representation, he has the means 
>to create forgeries that get past imperfect implementations of
>properties 1 through 4 you listed.
>
>	paul
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA27557 for ietf-pkix-bks; Thu, 25 Mar 1999 02:43:10 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27553 for <[e-mail]>; Thu, 25 Mar 1999 02:43:08 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id LAA27071; Thu, 25 Mar 1999 11:50:18 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 25 Mar 1999 11:50:58 +0100
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Cc: "[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 mail.proper.com id CAA27554
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes this is pretty much what I had in mind.

We all agree that the complete template has to be processed by the
comparing algorithm. Inclusion of just a hash of the templace in a
certificate enables authentication of the template when the pre stored
template itself is retreived from another source, e.g. an unsecure
directory, or supplied as part of a message.

Still, I don't say that this is the preferred way, but it could be in some
cases. At least it may provide necessary functionality without displaying
the template in the certificate.

/Stefan

At 04:32 AM 3/24/99 -0500, Stephen Kent wrote:
>Stefan,
>
>>Agree to all.
>>
>>What I mean is: Whatever is used as the approximation data of a biometric
>>property of the subject, this can be hashed and signed in the certificate.
>>The hashed data has then to be supplied separate from the cert.
>>
>>This will work. Desired? I don't know. But it has it's pros and cons.
>>
>>The example of a hashed static picture can be used if I want you as a
>>recipient to se my face and to know that this static image shows the face
>>of the owner of the certified key.
>>
>>Desired? I don't know, but it would work and it has its pros and cons as
well.
>
>I'm not sure I understand your example here; let me try to describe what i
>think you might have meant.
>
>The template against which a captured biometric is compared must be
>available in unhased form for processing.  The goal is to know that this
>template is correctly associated with the user in question. So, yes, one
>could store the template somewhere and then bind it to the user via a hash
>of the template embedded in a public key or attribute cert. This is a
>different strategy from what was originally proposed, namely inclusion of
>the template itself in a certificate. The question then arises as to
>whether it is preferable to bind the template to the user in this fashion.
>
>Let me know if this is what you had in mind.
>
>Steve
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA27023 for ietf-pkix-bks; Thu, 25 Mar 1999 02:09:57 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA27019 for <[e-mail]>; Thu, 25 Mar 1999 02:09:55 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 36CCE4F; Thu, 25 Mar 1999 11:17:08 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id LAA05833; Thu, 25 Mar 1999 11:17:16 +0100
Message-ID: <[e-mail]>
Date: Thu, 25 Mar 1999 11:17:12 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
References: <v04020a09b3183998e653@[128.33.238.181]> <[e-mail]> <v04020a2db31ea62bdfcd@[128.33.238.119]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

Stephen Kent wrote:
> 
> Juergen,
> 
> >I would like to consider a similar problem. What is to do if I want to
> >certifiy a server public key. Who is the subject? Is it the server or
> >the entity responsible for it? What cert extensions are commonly
> >recognized in server certificates?
> 
> The server's name, e.g., as a DNS name, should be used as the Subject, or
> subject alt name. I would not put the name of the entity responsible for
> the server in the cert, especially if the entity is a person!

I see the advantage of this approach too. But such certificates focus on
server authentication. A relying party receives the assurance that the
denoted server is the server that it is claimed to be. The entity (a
person or organization) who is responsible for server operations may be
not mentioned. Please note that many enterprises around the world have
names originated by the (first) owner e. g. Ford. Server names derived
by the name of the person who is responsible is not so strange as it
seems to be at a first glance.

> 
> >I prefer a human being as subject. All other informations should be
> >contained in the cert extensions.

OK, I should consider organizations as well. Today´s bussiness differs
from bussiness when Ford established his factory.

> 
> Usually access control decisions are be made based on the purported
> identity, and it is easiest to get this from the Subject name.  For
> example, browsers using SSL compare (a aprt of) the Subject name against
> the URL to make sure that the server is the one the user intended.  Now,
> I'd prefer if the server name were expressed as a pure DNS name, either as
> a sequence of DC attributes or as a suitable subjectAltName. Hopefully that
> will come, over time.

When the server´s DNS name contains at least the organization
responsible the name may be meaningful for the relying party. Whenever a
server´s affiliation changes the DNS name may be misleading. Is it then
acceptable for the relying party to look up a special service provider
in such cases?

> 
> If you put in the name of the person responsible for managing the server,
> you would have to revoke and reissue the certs whenever management
> responsibilities.

Management fluctuations may be of some interest for the relying party,
especially why certificates provide security.

>  If one puts in the "responsible" organization name, this
> too is not always easy. What if the server is running on a machine run by
> an ISP?  Is the ISP the responsible entity, or the organization that
> "appears" to be running the server?

Then the server may have a DN pointing to the ISP. But the ISP may have
not any knowledge about the service provided by the server. A
certificate may help to make it clear who is responsible for the
particular server. For example, it should be clear who is responsible
for an e-bussiness server. It should be expressed in the certificate.
One may think about the right place ie cert extensions or subject or
subjectAltName. Is there a specific attribute available for this
purpose?

> 
> Also, if I were to lookup a certificate for a sever in any form of
> directory, I probably know the name of the server I want to access, but
> have no clue about the name of the person or an ISP managing the server.
> All reasonable respositories will be able to serach and retrieve certs
> based on subject names but not all may be able to search on other extension
> values.

This is the operational advantage of server´s DNS name. Nevertheless at
least the organization responsible for it should be known to the public.
An appropriate certificate extension may a way to express
responsibilities.

[snip]

> Steve
-- 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA23282 for ietf-pkix-bks; Wed, 24 Mar 1999 23:55:37 -0800 (PST)
Received: from mail.campuspipeline.com ([209.160.196.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA23278 for <[e-mail]>; Wed, 24 Mar 1999 23:55:36 -0800 (PST)
Received: from linus ([209.160.196.100]) by mail.campuspipeline.com (Netscape Messaging Server 3.54)  with SMTP id 430; Thu, 25 Mar 1999 01:06:11 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 25 Mar 1999 01:02:57 -0700
To: "Bob Jueneman" <[e-mail]>
From: "Jan Nielsen" <[e-mail]>
Subject: Re: Location and Identification
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Bob,

I think of secure I&A as the secure possession, collection, transmission
and evaluation of credential(s).  All phases must be performed within the
TCB.  The use of biometrics in I&A does not change this.  However, the fact
that biometric revocation is not a palatable option places significantly
greater burden on the system to perform each of these phases correctly.
The network partitioning of these phases is, however, not restricted; the
phases may be performed within a NTCB.  (But I cannot identify an
appropriately designed biometric device, which probably saves you the
expense a Squatters stout, and possibly even their Jambalaya.)

In traditional secure I&A systems, e.g., password/passphrase system,
possession is not disputed because of credential policy enforcement, i.e.,
credentials must be of a certain size, with certain alphanumic
characterists, and changed every so often.  Collection, however, is
disputed much of the time, typically because of the lack of a trusted path
in the operating system for the credential collection.  Transmission and
evaluation are usually not disputed because appropriate protocols have been
designed and analyzed

In your example, possession is not disputed, but the collection,
transmission and evaluation of the biometric material was not maintained
appropriately.  Had the crime scene been properly sealed upon discovery,
then collection of the biometric material, transmission to a forensic
laboratory, and the subsequent evaluation by the appropriate specialist
would have been possible with a higher degree of trust than that which was
executed by the LAPD in this case.  (Each of these phases would, of course,
have been "attacked", and rightfully so, by the defendant's lawyers but
with a "good" crime scence policy and "good" compliance, the verdict may
have been different.)

In a previous example of a verified representation of a biometric, e.g., a
signed picture, possession and evaluation are in dispute because,
presumably, the evaluator must accept the signed picture of the individual
and then correlate the signed picture with the individual presenting the
signed picture.  Given that evaluation of possession of physical
characteric(s) and correlation of those characteristic(s) to some verified
representation is a "hard" problem this type of system must involve a human
as the evaluator.


Regards, and "hello" to all of Gabe's group,


Jan Nielsen





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA11291 for ietf-pkix-bks; Wed, 24 Mar 1999 20:19:04 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA11284 for <[e-mail]>; Wed, 24 Mar 1999 20:19:02 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 21:25:45 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 21:25:34 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: SEIS:  Certificates, Directories, and Distinguished Names
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 mail.proper.com id UAA11286
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I think we are in pretty close agreement on this. It's just that 
after reading Petra's post it wasn't clear that we were all on the same 
page. But maybe I misinterpreted what she said -- I was (am) concerned 
that we had a diametrically opposite view of what a DN should be.

Section 2.5 as quoted seems quite clear, and particularly the notion 
that that the DN has to be unique within a particular domain, in particular
at least the domain of the CA.  That would suggest, as I think I also
proposed recently, that by qualifying the DN with the identity (in some form)
of the CA, it would be possible to merge otherwise ambiguous 
references to some entity within a common directory.

Of course, it would be nice if all of the names in the directory would be 
globally unambiguous without the necessity of qualifying them by the CA's
name, but the possibility that the directory is operated by an ISP (close to the
original conception of a directory operated by a monopoly carrier), while 
both the CA and the end-entity are unrelated to that directory provided makes
it unlike that this will always be possible.

With respect to the requirement for the PersonalData field contain an
"unmistakable identity", that may or may not be a requirement or even 
desirable depending on your point of view, but it may also not be sufficient.

I may know with almost perfect confidence the "unmistakable identity"
of Elvis, Jimmy Hoffa, Adolph Eichman, or the Unabomber.  But that
knowledge does me very little good unless I can FIND them, at least from
the perspective of arresting them or serving a summons on them.

So if I understand the purpose that the QC is intended to serve (and I 
confess that I haven't read the document, although I'm supportive of the
effort), I would suggest that you modify the requirement to more carefully 
state a requirement that the unmistakable identity provide a least a strong
hint as to where to start looking for that individual if necessary, e.g.,
though some physical location that he has a strong tie to, whether by
financial, residence, or other means.  If the individual is a itinerant laborer or 
vagrant with not fixed address, all of the identity details in the world may 
not help if he doesn't want to be found.

Bob

>>> Stefan Santesson <[e-mail]> 03/22/99 04:07AM >>>
Bob,

The intension is that if any name form (in Qualified Certificates) serve as
locator of a directory entry, this is the DN hold in the subject field. The
concept of distinguished name (hold in the subject field) and unmistakable
identity (hold in either the subject field or the SubjectAltName ext.) are
explained in section 2.5

Section 2.5 says:

   Distinguished name is originally defined in X.501 [X.501] as a
   representation of a directory name, defined as a construct that iden-
   tifies a particular object from among the set of all objects. An
   object can be assigned a distinguished name without being represented
   by an entry in the Directory, but this name is then the name its
   object entry would have had if it were represented in the Directory.
   In the context of qualified certificates, a distinguished name
   denotes a set of attribute values [X.501] which forms a name that is
   unambiguous within a certain domain that forms either a real or a
   virtual DIT (Directory Information Tree)[X.501]. In the case of sub-
   ject names the domain is assumed to be at least the issuing domain of
   the CA.

And section 3.1.2 continues with:

   The subject field SHALL contain a distinguished name of the subject
   (see 2.5 for definition of distinguished name)

   An unmistakable identity (see 2.5) of the subject(based on registered
   name or a pseudonym name) SHALL be present in the certificate in the
   subject field and/or the PersonalData field in the subjectAltName
   extension (see 3.2.1.)

   If the PersonalData field is empty, the unmistakable identity of the
   subject is determined by just the subject field. If the PersonalData
   field is present, it SHALL contain a complete unmistakable identity
   of the subject. In this case the subject field SHALL still contain a
   complete distinguished name.


So this means that a DN shall ALWAYS be present in the subject field.

Hope this answer your question.

/Stefan


At 03:47 PM 3/19/99 -0700, Bob Jueneman wrote:
>--- Message on the SEIS mailing list ([e-mail])
>
>[Apologies if this is a duplicate. I sent it yesterday, but
>it doesn't seem to have shown up on either list yet.]
>
>The message from Petra Gloeckner illustrates that there is an
>obvious lack of agreement about the semantics of a DN vs.
>the semantics of an alternateSubjectName.
>
>Because of the potential impact on evolving software, I'd like
>to escalate this issue to the PKIX co-chairs, Steve Kent and 
>Warwick Ford, and to the chair of X.509, Hoyt Kesterson, 
>in order to force a expeditious resolution to this issue.
>
>One of these name forms, at least, ought to be usable to 
>retrieve a certificate from a directory, whereas the others,
>although potentially candidates for inclusion in a directory,
>may not represent a real directory entry but may be for
>display purposes to RP software, or for other application 
>purposes.
>
>I believe that it is extremely important that at least one of the 
>multiple name forms that may be carried in a directory reflect
>the primary directory name used to store and retrieve such 
>certificates.  If I start searching a directory, I don't want to
>have to try every name in a certificate looking for other, related 
>certificates.
>
>(For example, I may have received a digital signature
>certificate from someone, and now I want to look up his 
>encryption certificate.  Or maybe my correspondent sent me 
>his encryption certificate, but the key length is too long for
>my US-exportable software to handle.)
>
>As a practical matter, I don't care much one way or the other
>which name form is picked as the primary one, but I very 
>much need to have it nailed down, and quickly.  I would 
>argue, however, that both historical precedent and the
>wording in the standards would argue that the DN should be the
>primary directory index name, and that other names, e.g., for display
>purposes, should be subjectAltNames.
>
>Bob
>
>
>>>> "Petra Gl÷ckner" <[e-mail]> 03/18/99 06:39AM >>>
>
>> I certainly understand that there are lots of certificates
>> containing DNs which don't correspond to entries in ANY
>> directory, much less some well-structured, as-God-intended
>> x.500 directory with X.520 DIT structure and schema.
>> 
>> My point is, and I am agreeing with you to at least a certain
>> extent, that if we continue to throw completely arbitrary
>> name constructs in the DN, we will make it increasingly difficult
>> to ever store or retrieve those certificates in or from a directory.
>> 
>> So my goal was to get people to recognize that the primary
>> purpose of the DN was to facilitate interoperation with a directory.
>> And since there may very well be a proliferation of directories with
>> incompatible DIT structures and schemas, it is necessary to
>> recognize that it is the _subscriber's_ directory that must dictate the
>> DIT structure and schema -- not the CA's, and not the recipient's.
>
>I don't think that the primary purpose of the DName is to facilitate 
>interoperation with a directory. That was the motivation when they 
>defined the X.509v3 certificates, but I think this is not valid anymore.
>
>> Other technical functions such as name subordination may or may
>> not have a role to play with respect to the DN.  They could, but
>> I suspect that it may not be terribly useful in most cases, just
>> because directory names are (unfortunately) not often organized
>> along the lines of organizational boundaries that name subordination
>> assumes.
>> 
>> I agree that when writing application software you cannot always
>> assume that the DN points to an X.500 entry, as one may never have
>> been created.  I would say that it OUGHT to, but it might not.
>> 
>> On the other hand, I believe that it would be WRONG to believe
>> that an alternateSubjectName, in particular, would always point to
>> a certificate, or even to a directory entry of any kind.  Again, perhaps
>> it ought to, but I may have chosen to express my name and organizational
>> structure in a more conventional fashion, perhaps for ease of display and
>> recognition, but without a corresponding entry in any existing directory --
>> not even an alias.
>> 
>> For example, my directory name in Novell's corporate directory in business
>> card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.
>> 
>> But what I would like to have displayed in someone's certificate viewing
>> software would be c=US, o="Novell, Inc.", ou="Network Products Division",
>> ou="Network Security Department", cn="Robert R. Jueneman"
>>
>> Since the purpose of the DN is to convey an entry in the directory, the
>> first name form clearly has to be the DN, and the second name form the
>> alternateSubjectName.  But that second name form is not an entry in the
>> Novell corporate directory,  not even an alias, and not likely to be any
time
>> soon, even if it has the form directoryName.
>
>I disagree, the directoryName of the SubjectAltName has to convey an
>entry 
>in the directory, not necessarily the subject DName. So, IMO you should
>put 
>the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
>directoryName 
>of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
>ou=Network 
>ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman" 
>in the subject DName.
> 
>> I agree that it would be quite reasonable to create an alias for such a
>> name in a directory somewhere, and I would encourage such a practice.
>> I also believe that it may be desirable to include other directory style
>> names as additional alternateSubjectNames, perhaps to support other DIT
>> structures and/or schemas, but I don't believe that the ietf-pkix group
>> is in a position to mandate that a particular alternateSubjectName reflect
>> a real entry in any particular directory.  And whether they mandate it or
>> not, it isn't likely to happen world-wide any time soon.
>> 
>> As for the additional information you may require that go beyond "name"
>> information per se, I would suggest that you make your PersonalData
>> structure a subjectDirectoryAttributes attribute extension (if someone can
>> ever figure out what the semantics of _that_ attribute are supposed to be),
>> or else simply define a new attribute extension.
>> 
>> But in general I would be rather opposed to listing much of the type of
>> information you have suggested in a certificate at all, and certainly
not in
>> a name field.
>
>The PersonalData structure shall contain as much information of a person
>as 
>necessary in order to identify him. You don't have to use all
>attributes!
>
>We have chosen the SubjectAltName instead of the
>subjectDirectoryAttributes 
>extension because the PersonalData structure contains the name of the
>person
>plus any other required identity information to make the name unique.
>But you can easily use any of the attributes defined in the QC-draft,
>which 
>are not necessary to unmistakably identify the person, within the 
>subjectDirectoryAttributes extension since the
>subjectDirectoryAttributes 
>and the PersonalData structure are both a sequence of attribute.
> 
>Petra
>
>PS.: I will be on vacation next week. I'll answer as soon I'm back at
>work.
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis 
>SEIS Contact: [e-mail] 
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA09701 for ietf-pkix-bks; Wed, 24 Mar 1999 19:58:10 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA09696 for <[e-mail]>; Wed, 24 Mar 1999 19:58:08 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 21:04:38 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 21:04:26 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Correct use of subject DN and subjectAltName
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 mail.proper.com id TAA09697
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I would suggest that BOTH of the ways you suggested may very 
well be "wrong."

IMHO, the Subject (DN) must reflect the desired index into the primary
directory/database/heap of certificates lying on the floor.  That 
preferred index necessarily has to agree with the DIT structure of the
(primary) directory owner, whoever that might be. If it doesn't, either go find 
another directory supplier, or another CA, or change employers.

IF that directory owner happens to be the corporate entity that Joe T. 
works for, then fine -- that organizationalPerson structure is perfectly 
acceptable, and in that case it is quite unnecessary to debate the 
semantics of what StateOrProvinceName is -- where the organization is
incorporated, where the headquarters is physically located, where they 
are currently doing business, etc., because IT IS ONLY A DIRECTORY
INDEX, and doesn't necessarily have to correspond to any physical 
reality.

Now, this DN may be sufficient in and of itself -- we don't necessarily 
NEED any other physical "meat space" reference, as the SPKI folks 
would happily point out to you.

On the other hand, if a human being is going to have to make the decision
as to whether the entity which is presumably bound to that public key
by the use of the corresponding private key is actually to be TRUSTED,
rather than merely authenticated, then some additional information may 
be highly desirable.

An alternateSubjectName could certainly be used for this purpose, but as
my previous message pointed out, there are at least some people who view 
that as being an attribute that is _required_ to represent a directory entry.

That is going a little further than I would recommend, although I think that 
a reasonable assumption might be that such an alt name should be
construed as being at least an alias, in at least some directory or pseudo-
directory (e.g., DNS).

So I don't have any problem with putting the user's RFC822 name in the 
alt name field, and I might even want to look up the name that way,
even if it isn't the primary entry in my directory.

I also think that the QC spec may be on to something, by trying to separate
"meat space" information that is primarily for human consumption and display,
as opposed to directory and "rights" management.

I have always objected to the cavalier way that we quibble about syntax, 
and then quietly swallow completely ambiguous and overloaded semantic 
constructs.

It now appears that Peter Gutman may have actually enshrined my infamous 
MPEG cat movie in a certificate, and I would like to have the ASN.1 
encoding of that certificate chiseled on my tombstone (probably a very large 
tombstone).  Clearly that was intended to be a horrible example of what 
_not_ to put in a DN, or, I would argue, even in an alternateSubjectName, 
but instead belongs in some kind of personal data attribute, depending 
on taste. (De gustibus ...)

To paraphrase Patrick Henry, I disagree with much of what is proposed to be
put in the QC in a personal data field, but I will defend to the death their right 
to put it there. (So long as it isn't considered mandatory to implement, at least.)

Bob


>>> Stefan Santesson <[e-mail]> 03/23/99 08:34AM >>>
The Qualified Certificates draft has a way to handle this.

But the way is opposite to the one you propose. In QC the corporate
information is stored in the Subject field while the personal data is
stored in the SubjectAltName (PersonalData field)

Your example could be expressed:

Subject field:
---------------
Country = US
StateOrProvinceName = Delaware
Organization = Wysiwyg Corp.
OrganizationalUnitName = Internet Products Division
Address = xxxxx, San Mateo, CA
CommonName = Joe T. Soap
Title = Project Manager


PersonalData field: (SubjectAltName ext. / OtherNames)
------------------------------------------------------
RegistrationAuthority = Wysiwyg Corp. CA service
AttributeSemantics = OID xxx (declaring that the country attribute defines the
                              country within which names are registered and
                              the country within which the address is 
                              expressed.
                              Also declaring that the dNQualifier contains
                              a number locally assigned by the specified
                              registrationAuthority (Wysiwyg Corp CA)) 
Attributes:
Country = US
Surname = Soap
GivenName = Joe
GivenName = Thomas
CommonName = Joe T. Soap
Address = xxxxx, Palo Alto, CA
Gender = M
dNQualifier = 123456789
countryOfResidence = US
countryOfCitizenship = US


Some remarks:
I'm not sure if I treated the subject field entirely correct given that the
state in which the company is registered, differ from the state in the
company local address. Others may have a different solution to this.

The PersonalData field could be different and not all of the data in the
example need to be present. It must however contain a complete unmistakable
identity within itself i.e. without combining it with data from the subject
field.

/Stefan


At 01:33 PM 3/23/99 +0200, Mark Shuttleworth wrote:
>Hi folk
>
>Is there an established best practice for the layout of the following
>information in a PKIX end-entity certificate? This is the (fictional and
>complex) scenario:
>
>Joe T. Soap, <[e-mail]>, 
>   who lives in
>Palo Alto, CA, US
>   and works for
>Wysiwyg Corp., 
>   which is registered in 
>Delaware, US
>   as a
>Project Manager
>   in the
>Internet Products Division
>   in their office in
>San Mateo, CA, US
>
>One way to do this would be to have personal information as the subject
>name, and then the corporate info and office info as a set of
>subjectAltNames, but there does not appear to be a way to identify which
>subjectAltName means what kind of location. Is there a legitimate way to
>represent this?
>
>--
>Mark Shuttleworth
>Thawte
>Attachment Converted: "c:\internet\eudora\attach\smime5.p7s"
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA05762 for ietf-pkix-bks; Wed, 24 Mar 1999 19:30:21 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA05754 for <[e-mail]>; Wed, 24 Mar 1999 19:30:20 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 20:37:03 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 20:36:45 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Correct use of subject DN and subjectAltName
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 mail.proper.com id TAA05756
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let the record show that I agree with Steve on this point. :-)

>One always ought to ask what level of detail should be put into a Subject
>(or Issuer) DN?  Putting in more details runs afoul of Steve's Rule of
>Revocation, and makes the certs bigger too. Attempts to put more into a
>name to simplify access control management are common, and almost always a
>bad idea.

If anything, I believe that a number of major organizations are beginning 
to conclude that simpler certificates are better, even if it requires more of them.

More and more organizations, including major ones like the US Navy, are 
tending toward using a directory name (DN) that is very simple, like
a high level organization (people don't move from the Navy to the Army 
very often), plus a common name, plus a permanently assigned UID,
in order to manage that person's long term records (30+ year career 
plus retirement benefits).

If they need to have a certificate that shows that person's current rank, 
job title, current duty station, etc., they'll issue one.  But the primary DN is still 
the simple version, and the other facts are (probably -- it ain't over till 
the fat lady sings) included in an alternateSubjectName for display and 
reference purposes.


Bob



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02332 for ietf-pkix-bks; Wed, 24 Mar 1999 19:07:36 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA02322 for <[e-mail]>; Wed, 24 Mar 1999 19:07:34 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 20:14:32 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 20:14:13 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Location and Identification
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 mail.proper.com id TAA02323
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry, but WRONG!

The 4 criteria are necessary but not sufficient.

Even if all four are done with absolute perfection it is still not sufficient,
if a biometric identification can be taken in another completely 
different context, and then applied to authenticate something completely
different.

The OJ case I referred to in a previous message is an example.
It was, allegedly, a case of what we would call in computer security 
terms either a replay or spoofing attack. There was little question 
that it was OJ's blood -- the question is how did it get on the fence.

If you present a document in court that has as xeroxed copy of my
fingerprint on it, does that prove that I approved that document?

No, it certainly does not. I very well might never have seen the 
document, and the fingerprint could have been photocopied by 
the police who picked me up, dusted from a fingerprint on a glass offered
to me by the prosecution attorney, or obtained in any other way.

And even binding the biometrics to the document itself doesn't prove
very much, because some other application might have legitimately 
collected and saved the raw input, gone through the process, and 
hashed (message digest sense) the biometric result and the document.

As Schneirer has succinctly put it, BIOMETRICS ARE NOT SECRETS!

They may be very useful if they involve a physical presence at a 
tamper-resistant boundary for access control, whether that boundary is
a human clerk examining a driver's license, a door controller or the 
much desired fingerprint reader on a smart card.

But if they have to be collected by an application and transmitted over a wire, 
they are highly suspect, and are quite likely to do much more harm than 
good, both to authentication and privacy.

And BTW, I would love to be proven wrong on this -- if someone can provide 
me suitable evidence of such an application that could reasonable be 
considered secure against this class of attack, I would gladly buy them a 
drink, and maybe even a nice dinner.

Bob

>>> Paul Koning <[e-mail]> 03/23/99 03:41PM >>>
>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

> The reliability in a biometric identification scheme lies in a combination
> of:
> 1) The subjects unique posession of the original biological limb itself
> (the finger, eye etc.)
> 2) The function of a capture device which only allows the real biological
> human original to produce valid digital capture data.
> 3) The absolute critical function to integrity protect the capture data
> between the capture device and the comparing algorithm, and the equally
> critical function to authenticate and integrity protect pre stored data
> used by the comparing algorithm.
> 4) The function of a comparing algorithm, comparing captured data with the
> pre stored information in such way that it produce a good balanced, low
> probability, of both false positive (wrong original accepted) and false
> negative (right original rejected) response.
> 
> If any of these 4 fail, the system is unreliable. If not, the system works.

It seems to me that all four of these are, at best, highly immature
and at worst, beyond the state of the art.
 
> But note that none of these steps require any digital representation of the
> bio-data to be secret.

Yes, IF all four are rigorously satisfied.  If they are not, then when 
an attacker has access to the digital representation, he has the means 
to create forgeries that get past imperfect implementations of
properties 1 through 4 you listed.

	paul



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA29056 for ietf-pkix-bks; Wed, 24 Mar 1999 18:48:31 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA29051 for <[e-mail]>; Wed, 24 Mar 1999 18:48:30 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 19:55:13 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 19:54:56 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Subject:  Trivia
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 mail.proper.com id SAA29052
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>> Stephen Kent <[e-mail]> 03/23/99 09:06AM >>>
>Remember the words of a former (in)famous U.S. Attorney General, "we could
do it, but it would wrong."

Actually, I believe it was Nixon who said that.

Bob



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA29000 for ietf-pkix-bks; Wed, 24 Mar 1999 18:42:16 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA28996 for <[e-mail]>; Wed, 24 Mar 1999 18:42:15 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 24 Mar 1999 19:48:57 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 24 Mar 1999 19:48:41 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Location and Identification
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 mail.proper.com id SAA28997
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I should have been more precise in my terminology, although 
I am not certain that there is an agreed upon vocabulary 
in this field. So let me try to clarify.

Generally speaking, a biometric authentication operation takes 
a set of measurements of the biometric indicia and translates that 
into some kind of a digital "result" through a complex, almost
always proprietary algorithm.  That "result" is then compared 
against a previously calculated "template," which is typically 
produced through an enrollment process under the watchful eye
of some kind of an administrator, either the person who is 
responsible for deciding whether Joe Dokes gets into a particular
building, office, or secure facility; or perhaps a CA-like function
that binds that biometric template to an identity, either as part 
of a X.509 certificate which also binds both the identity , biometric 
template, or other attributes to a public key, or not.

When I used the term "hash," I did not mean to imply a message
digest algorithm, which has the property that a single bit of change 
of the input produces a huge difference in the output.  Instead, I 
was using "hash" in its older, computer science/compiler sense
of a many to few (not necessarily many to one) mapping between 
an input and the output.

Although for certain biometric measures, notably a facial image,
the template may be a more or less literal and reproducible
image of the person that if displayed in human visible form could be
easily compared to the subject who is standing in front of the clerk,
in general this is NOT what is used.  Instead, a more complex 
pattern-matching algorithm is used to compare the reduced "result" 
of the input to the target or template.

Depending on the desired false negative and/or false positive ratios,
this matching process then produces a yes/not, or sometimes 
yes/no/maybe result.  (I won't go into the question of whether the
goodness of fit criteria is decided by the mechanism which captures
the input, by the administrator who enrolls the individual, or the relying 
party who is making the decision, as this can vary from system to system 
and may significantly affect both the system design and the security 
of the system.)

But the primary issue, at least with respect to this forum, is exactly 
analogous to the asymmetric cryptography case:  Given a template
(which bears no obvious relationship to the individual, and is analogous
to a public key), is it, or is it not, computationally infeasible to reverse 
engineer that template and produce a simulated input stream that if then
put back through original the "hash" process would satisfy the template 
matching algorithm, without having to effectively reproduce the 
original input through some form of exhaustive search?  In particular,
it is not necessary that an exact match be produced, as even the biometric 
input cant' do that -- it is sufficient if the input just produces a "yes"
result.

Granted that for many applications it is not necessary that the process 
be all that computationally infeasible to reverse to be economically useful, 
just as even a 256 bit RSA key may have some utility for very short-term 
authentication or encryption function.  However, in deciding whether or not 
to use such a mechanism for any important purpose, it is necessary to 
consider the problem of revocation.  I only have ten fingers, and I'm 
rather attached to them emotionally as well as physically, and would hate to
give them up!  so if it is possible to compromise the system, the compromise 
is effectively eternal..

So in addition to the computationally infeasible question, it is also necessary to
ask whether in fact the biometric is a secret, or whether it is routinely available
in other contexts.  If it is, then its use for any important purpose is highly 
questionable.

A latent fingerprint is one such example -- given such a print, it would probably 
be simple to make a wax or latex "finger" that would produce that same image
if pressed on a platen.  If the fingerprint reader scans it in color, and could 
for example tell the difference in skin tone between a red-headed, fair-complected 
Irish lass and her dark complected African sister-under-the-skin counterpart,
spoofing the system becomes more difficult. And if the reader uses near infrared
to scan the capillary pattern under the skin, which is does not leave a latent print
(any more than a retinal scan does), then it becomes much harder yet.

That is, right up until the moment that that same lass voluntarily lets her fingerprint 
be taken for some other, even benign purpose, just as Sears requests that I sign
my name using the electronic stylus to capture my signature. (There have been 
recent cases in criminal court where the police solicitously asked a suspect
whether he would like a drink of water, and afterwards whisked away the glass 
with both his fingerprints and a DNA sample from his saliva and skin particles.
Object lesson -- never drink water from a glass. Suck ice cubes instead.)

At that point, all is lost, and we have the O.J. DNA problem.  The question in 
many people's mind was not whether it was O.J. blood that was found on the 
fence, but how it got there.  And since the rather inept handing of much of 
the evidence plus the high powered defense made it difficult to conclude
beyond a reasonable doubt that O.J. himself put it there under the circumstances
that were alleged, he walked.

Bob


>>> Stephen Kent <[e-mail]> 03/21/99 06:28PM >>>
Bob,

>With respect to the biometric identifiers, my assumption is that
>if these mechanisms are to be at all useful for use at a distance
>(as opposed to at an ATM machine, for example), the biometric
>template must be public, in the same sense that a public key is
>public.
>
>But in order to make this at all feasible, it is ESSENTIAL that the
>transformation from the recorded biometric indicia produce a
>one-way mapping to the template, so that the biometric
>measurement itself cannot be compromised.
>
>In other words, given the template, it must be computationally
>infeasible to produce some biometric indicia, either real or
>artificially constructed, that would satisfy the template.

As I mentioned in a private note to Bob, my experience with biometric
templates suggests that it is generally NOT possible to store templates in
this fashion.  The reason is that the matching algorithm for a biometric
must take the captured data and score it against the template.  Since the
captured data will almost alwways be a little "off," one needs to be able
to determine how far off the data is.  A good hash function defeats this
purpose, e.g., a single bit error is a distant (hamming distance) as a
multi-bit error.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22055 for ietf-pkix-bks; Wed, 24 Mar 1999 10:50:29 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22051 for <[e-mail]>; Wed, 24 Mar 1999 10:50:28 -0800 (PST)
Received: (qmail 12290 invoked from network); 24 Mar 1999 18:57:39 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 24 Mar 1999 18:57:39 -0000
Received: (qmail 25388 invoked from network); 24 Mar 1999 18:52:12 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 24 Mar 1999 18:52:12 -0000
Message-ID: <005e01be8e6b$c9df6be0$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: "Alternatively-encoded" extensions
Date: Sat, 24 Apr 1999 11:02:00 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

Lets us establish principles, so PKIX is fair, non-arbitrary,
and rule-based. Im more interested in the principles
for use of "alternatively-encoded objects" in certs, than whatever
Anders was contemplating, for context.

 Interestingly, in the VeriSign trust domain, there is/was already
an implicitly MIME-encoded object (text/plain) - be this
sensible or nay - in certificates, whose
profile and issuing practices is/are licensed
and accredited by a US state authority and a Big 6 firm, one
may note. Said content is/was an X.509 extension.

One  could argue the object is actually an implicitely encoded SMTP-body if
you
prefer, or a SGML-tagged <PRE> element - it does not matter for
the argument - it ain't BER-encoded or an ASN.1-specified object
or string. There are/or at least were a few hundred thousand of such
certificates floating out there, today. Nothing has broken to my knowledge,
including interaction with S/MIME. The Internet world today is largely happy
to
accept certs with unknown, non-critical extensions, even large ones.

(The VeriSIgn CPS extension is/was not a name-form, for the record, and
is useful in a very particular application context, and for specific (legal)
purpose.)



But let me ask the question, a different way, and propose an example
and a concluding argument, so we might establish the principle :



If a X.509 extension is proposed to IETF (PKIX) which is designed to
be interpreted - by a binary-decoding based process
other than ASN.1/DER - is there an objection in principle?

For example, CompanyX patented a (binary-encoded)
extension for certs  designed to be intepreted by
multimedia hardware. The content of the extension was
a simple state-machine language which drove the multimedia capability
of the chip, which leveraged public key cryptography to perform
certain cert-based protection functions for multimedia content/capabilities
based on the cert subject's identity, as authenticated using certificates.

Now, I know X.509 and the various national standards bodies making up ISO
does/do not object to string-encoded objects embedded in octet-string
extensions, per se.

Do PKIX WG managers, and the IESG? Nothing in 2459 suggests
such an interpretation. 2459 suggests quite the opposite, in fact.

My conclusion is: a minimally-conforming PKIX 2459
implementation should not reject a cert because of
an unknown (non-critical) extension, unless other signals such
as a policy (known to the implementation) requires extension-type and
schema and extension value-constraint checking for
cert validity, or subsequent digital signature verification.

-----Original Message-----
From: Stephen Kent <[e-mail]>
To: Peter Williams <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, March 24, 1999 9:38 AM
Subject: Re: Biometrics in Qualified Certificates


Peter,

>You may wish to define a name form for the alternative subject name
>extension, as permitted by X509 and PKIX. Its form can be
>a MIME-encoded name, an SMTP-extended address field, etc.
>
>My reading of PKIX-1 is that implementations receving such
>a field should not balk at its mere inclusion, unless the security
>policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
>is more strict than RFC 2459 regarding the extension and
>extension-value schema rules.

Yes, one could do what you say, Peter, but it seems to make no sense to use
any MIME encoding here, given the binary nature of certificates.  Thus, the
WG co-chair would not view such a proposal as appropriate, unless you can
provide some good rationale for it.  Extensible syntax is not a license to
do silly things; we always need a good rationale for adding extensions,
name forms, etc.



>As for your
>>second query, my position is that it is a bad idea to put such information
>>into a public key certificate.
>
>X.509 supports the idea that an opaque data field created by
>the Naming Authority be conveyed in a public-key certificate,
>to engender assurances relevant to uniqueness of
>(subject) naming (vs key certification) quality.
>
>"A certification authority produces the certificate of a user by signing
>(see clause 9)
>a collection of information, including the user’s distinguished name and
>public key, as well
>as an optional unique identifier containing additional information about
the
>user. The exact
>form of the unique identifier contents is unspecified here and left to the
>certification
>authority and might be, for example, an object identifier, a certificate, a
>date, or some
>other form of certification on the validity of the distinguished name. "

But the argument that has been made here is not the use of this data for
further qualification of a user DN; it is "let's find a place in a cert to
put some data we think might be useful in some application contexts."

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21064 for ietf-pkix-bks; Wed, 24 Mar 1999 09:17:13 -0800 (PST)
Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21060 for <[e-mail]>; Wed, 24 Mar 1999 09:17:09 -0800 (PST)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id TAA25746; Wed, 24 Mar 1999 19:25:54 +0200 (IST)
Message-ID: <[e-mail]>
Date: Wed, 24 Mar 1999 19:23:35 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Changes to RFC2459
References: <v04020a25b31e71f88059@[128.33.238.119]>
Content-Type: multipart/mixed; boundary="------------82D2389F6EFB1BCE3061E3A4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------82D2389F6EFB1BCE3061E3A4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve,

There is no ambiguity as long as you know that the certificate issuer completely
obey RFC 2459, if you are not sure then the absence of the extension is
ambiguous. That is if you create a certificate and want to mark it as EE you have
two options:

1. You can go by RFC 2459 and not put the basic constraints extension. Every one
that read the fine prints of the RFC and know that you obey all the fine prints
will understand that this is an EE certificate.

2. You can put a basic constraints extension that explicitly says that the
certificate is not a CA certificate. Everyone that know how to parse the basic
extension will understand it (without assuming what X509 profile you are
following).

I think that the second option is better and should be encourage (if not
mandated).

Moshe

Stephen Kent wrote:

> Jim,
>
> As RFC 2459 moves forward and we start to find problems, we are requested to
> >bring this to the list  One of the last arguments that I remember (but it
> >may have been partly in private) had to do with the BasicConstrants for
> >End-Entities and if the current text is correct.  Currently the RFC states
> >that the extensions SHOULD NOT be present for End-Entities and is MUST and
> >critical for CAs.
> >
> >Given that lack of information does not really imply that it is an entity.
> >I feel that CAs need to be given the option of putting the extension on for
> >all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
> >preference) or MAY.
>
> I don't understand the first part of your comment, assuming that it should
> have ended with "an end entity" vs. "an entity."  Since the current spec
> says that a CA MUST have the extension, any v3 cert without the extension
> is an EE, right?  A cert with the extension is either explicitly marked as
> a CA or is NULL and thus explicitly an EE. There is no ambiguity.
>
> Steve

--------------82D2389F6EFB1BCE3061E3A4
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------82D2389F6EFB1BCE3061E3A4--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19619 for ietf-pkix-bks; Wed, 24 Mar 1999 06:52:48 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA19615 for <[e-mail]>; Wed, 24 Mar 1999 06:52:47 -0800 (PST)
Received: from st12.ncsl.nist.gov (st12.ncsl.nist.gov [129.6.54.66]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id JAA26976; Wed, 24 Mar 1999 09:59:50 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 24 Mar 1999 10:02:08 -0500
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Changes to RFC2459
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tomaz,

I missed your earlier email, but you are right.  This section has a couple
of problems that were pointed out to me in the last week (off-list).

The omission of mapping is an oversight in the specification., and I will
be fixing it.  The acceptable policy set should be a state variable, not a
constant.  The text includes a catch-all (apply critical extensions,) but
that is insufficient.  This section deserves more detail.

There is also an X.509 defect report that may affect this section.  The
gist of the defect report is that mapping should be performed *before* the
comparison step.  PKIX is silent on this but the current X.509 text
specifies that mapping occurs afterwards.

The X.509 folks will settle this one in May, but I am guessing they will
agree and make the change.

I will have new text for this section next week, and will post it here for
discussion.  The new text will *assume* the defect report is approved with
the requested change.

Thanks,

Tim Polk

At 10:54 AM 3/24/99 +0100, you wrote:
>Since nobody gave any comments to my previous mail about equivalent policies
>in a basic path validation procedure, I would like to rise this issue again.
>Is there a particular reason why certificates from policy mappings extension 
>are not explicitly mentioned in the path processing actions in RFC 2459? 
>The acceptable policy set in the procedure is defined as 
>
>"a set of certificate policy identifiers comprising the policy or policies 
>recognized by the public key user together with policies deemed equivalent 
>through policy mapping. The initial value of the acceptable policy set is
>the special value "any-policy".
>
>Since in each step of the algorithm the acceptable policy set is obtained
>as the intersection of the old value and critically marked policies
extension,
>does this mean that equivalent policies from the policy mappings extension
>are added to the initial policy set and the acceptable policy set somewhere
>in items (d) and (e) of the algorithm? Or is it assumed that for the 
>computation of intersections (items g and h) equivalent policies are
actually 
>the same? In this case, is the definition of the acceptable policy set
correct?
>
>Regards,
>
>Tomaz Klobucar
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19454 for ietf-pkix-bks; Wed, 24 Mar 1999 06:37:34 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19450 for <[e-mail]>; Wed, 24 Mar 1999 06:37:31 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04359; Wed, 24 Mar 1999 09:44:36 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a2db31ea62bdfcd@[128.33.238.119]>
In-Reply-To: <[e-mail]>
References: <v04020a09b3183998e653@[128.33.238.181]> <[e-mail]>
Date: Wed, 24 Mar 1999 09:38:04 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
Cc: ietf-pkix <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,

>I would like to consider a similar problem. What is to do if I want to
>certifiy a server public key. Who is the subject? Is it the server or
>the entity responsible for it? What cert extensions are commonly
>recognized in server certificates?

The server's name, e.g., as a DNS name, should be used as the Subject, or
subject alt name. I would not put the name of the entity responsible for
the server in the cert, especially if the entity is a person!

>I prefer a human being as subject. All other informations should be
>contained in the cert extensions.

Usually access control decisions are be made based on the purported
identity, and it is easiest to get this from the Subject name.  For
example, browsers using SSL compare (a aprt of) the Subject name against
the URL to make sure that the server is the one the user intended.  Now,
I'd prefer if the server name were expressed as a pure DNS name, either as
a sequence of DC attributes or as a suitable subjectAltName. Hopefully that
will come, over time.

If you put in the name of the person responsible for managing the server,
you would have to revoke and reissue the certs whenever management
responsibilities.  If one puts in the "responsible" organization name, this
too is not always easy. What if the server is running on a machine run by
an ISP?  Is the ISP the responsible entity, or the organization that
"appears" to be running the server?

Also, if I were to lookup a certificate for a sever in any form of
directory, I probably know the name of the server I want to access, but
have no clue about the name of the person or an ISP managing the server.
All reasonable respositories will be able to serach and retrieve certs
based on subject names but not all may be able to search on other extension
values.

>Has somebody seen a solution where a separation of duty scheme is mapped
>to certs? I mean the case whereby two entities share the responsibility
>over one signature key. Any thoughts about this problem?

One can do this in different ways, depending on the technology underlying
the protection of the privayte keys. Most of those ways are then not
visible to a relying party.  One might have used various shared key
generation schemes, or you might use a product that embodies multi-party
control to enable use of a signing key (e.g., the SafeKeyper works this
way).  I have not seen approaches that try to express separateion of duty
explicitly in a certs for a single signing key, although one could imagine
expressing this notion (but not the identities) via the policy info
extension.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19446 for ietf-pkix-bks; Wed, 24 Mar 1999 06:37:25 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19442 for <[e-mail]>; Wed, 24 Mar 1999 06:37:24 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04304; Wed, 24 Mar 1999 09:44:20 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a2ab31e7dca46f8@[128.33.238.119]>
In-Reply-To: <[e-mail]>
References: <v04020a09b3183998e653@[128.33.238.181]>
Date: Wed, 24 Mar 1999 06:36:35 -0500
To: Keith Johnston <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
Cc: Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:00 PM -0600 3/19/99, Keith Johnston wrote:
>Stephen Kent wrote:
>
>> Keith,
>>
>> >I am on a project where we want to use digital certificates to
>> >authenticate various server processes to each other over SSL.  What we'd
>> >like to do is define a certificate extension that has the name of the
>> >server in it, and then have each customer create certificates with the
>> >standard fields (organizaiton, country, etc) set to their information,
>> >and the extension field set to the name of the server.
>>
>> I would stgrongly recommend against creation of an extension for this
>> purpose. What you seem to want is a cert that identifies a user executing a
>> process on a server.  If so, then you should issue a cert that has a
>> subject name with sufficient info to uniquely identify the processes in
>> question.  X.509 has a naming model that presumes that the subject name
>> uniquely identifies the subject, period.  If the intent here is to identify
>> the subject in the context of the server, then one should construct a
>> subject name that does so.
>>
>
>OK, I see your point - think of the server as a particular user.  And this
>works fine if the customer has their own CA software - they would be perfectly
>willing to sign a certificate that has a name like
>"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
>doesn't provide a signing service - I was mistaken there) wouldn't know how to
>prove that you are really running ProcessFooBar on your server, or even what
>ProcessFooBar is.  So I don't see how this works with an external CA that
>doesn't understand what it is you are trying to do.  Sure, they can sign
>certificates with DNS names or a persons name, but a process name?

Well, because the process name is qualified by the server name, the
argument should be that you can demonstrate that you are the "owner" of the
DNS name for the server, and then the process name is obviously within your
purview and thus you are the appropriate registration authority for that
name.  I think CyberTrust would probably issuing a certificate under this
model, as it is analogous to the sorts of checks we do when issuing SSL
certs to servers for use under our roots in the Netscape and IE browsers.

>Another alternative we are investigating is allowing each server process
>to map
>a certificate distinguished name to a process identity.  This could mean that
>JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
>different serial numbers.  Then each process would have a hashtable that maps
>the serial number to the process name.  Each process could then
>authenticate to
>the others.  But that's kind of annoying to have to distribute that map
>around.  Sure, you could put it in LDAP or on some central server, but then
>you've got a single point of failure or a complicated caching/replication
>system.  So putting the process name in the certificate is really, really
>cool,
>because all each server needs is a copy of the CA certificate.

You are right, that would be annoying, and you would probably make errors
in the process, so I would recommend against this approach.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19437 for ietf-pkix-bks; Wed, 24 Mar 1999 06:36:59 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19433 for <[e-mail]>; Wed, 24 Mar 1999 06:36:58 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04214; Wed, 24 Mar 1999 09:44:00 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a25b31e71f88059@[128.33.238.119]>
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5DD9@DINO>
Date: Wed, 24 Mar 1999 05:49:18 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Changes to RFC2459
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

As RFC 2459 moves forward and we start to find problems, we are requested to
>bring this to the list  One of the last arguments that I remember (but it
>may have been partly in private) had to do with the BasicConstrants for
>End-Entities and if the current text is correct.  Currently the RFC states
>that the extensions SHOULD NOT be present for End-Entities and is MUST and
>critical for CAs.
>
>Given that lack of information does not really imply that it is an entity.
>I feel that CAs need to be given the option of putting the extension on for
>all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
>preference) or MAY.

I don't understand the first part of your comment, assuming that it should
have ended with "an end entity" vs. "an entity."  Since the current spec
says that a CA MUST have the extension, any v3 cert without the extension
is an EE, right?  A cert with the extension is either explicitly marked as
a CA or is NULL and thus explicitly an EE. There is no ambiguity.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19431 for ietf-pkix-bks; Wed, 24 Mar 1999 06:36:51 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19427 for <[e-mail]>; Wed, 24 Mar 1999 06:36:49 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04156; Wed, 24 Mar 1999 09:43:47 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a24b31e667fe6ea@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Wed, 24 Mar 1999 05:52:55 -0500
To: Alex Deacon <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Changes to RFC2459
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex,

>I agree that there are cases where basicConstraints and keyUsage extensions
>in end entity certificates may be  redundant, however I also feel that CAs
>should have the option of using an empty sequence to signify an end entity
>cert.  The X.509 spec allows for this...
>
>>From section 12.4.2.1 of X.509, Note 2 "To constrain a certificate subject
>to being only an end entity, i.e. not a CA, the issuer can include this
>extension field containing only an empty SEQUENCE value.

Well, that's a hack I hadn't noticed before! Guess one should always reed
the fine print. I assume the motivation was to produce a very small,
explicit marker for EE certs.  It is syntactically valid since the CA flag
has a DEFAULT specification of FALSE, and path length subcomponent of this
extension is marked OPTIONAL, and path length subcomponent of this
extension is marked OPTIONAL.  I think the rationale for 2459 strongly
discouraging use of this extension for EEs cert is to avoidthe confusion
sometimes associated with NULL encodings, and because it seems redundant,
irrespective of the presence of key usage.


Steve




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19423 for ietf-pkix-bks; Wed, 24 Mar 1999 06:36:37 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19419 for <[e-mail]>; Wed, 24 Mar 1999 06:36:36 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04123; Wed, 24 Mar 1999 09:43:42 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <v04020a23b31e645965de@[128.33.238.119]>
In-Reply-To: <00c101be8dac$5e5e4400$[e-mail]>
Date: Wed, 24 Mar 1999 04:50:31 -0500
To: "Peter Williams" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA19420
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

>You may wish to define a name form for the alternative subject name
>extension, as permitted by X509 and PKIX. Its form can be
>a MIME-encoded name, an SMTP-extended address field, etc.
>
>My reading of PKIX-1 is that implementations receving such
>a field should not balk at its mere inclusion, unless the security
>policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
>is more strict than RFC 2459 regarding the extension and
>extension-value schema rules.

Yes, one could do what you say, Peter, but it seems to make no sense to use
any MIME encoding here, given the binary nature of certificates.  Thus, the
WG co-chair would not view such a proposal as appropriate, unless you can
provide some good rationale for it.  Extensible syntax is not a license to
do silly things; we always need a good rationale for adding extensions,
name forms, etc.

>As for your
>>second query, my position is that it is a bad idea to put such information
>>into a public key certificate.
>
>X.509 supports the idea that an opaque data field created by
>the Naming Authority be conveyed in a public-key certificate,
>to engender assurances relevant to uniqueness of
>(subject) naming (vs key certification) quality.
>
>"A certification authority produces the certificate of a user by signing
>(see clause 9)
>a collection of information, including the user’s distinguished name and
>public key, as well
>as an optional unique identifier containing additional information about the
>user. The exact
>form of the unique identifier contents is unspecified here and left to the
>certification
>authority and might be, for example, an object identifier, a certificate, a
>date, or some
>other form of certification on the validity of the distinguished name. "

But the argument that has been made here is not the use of this data for
further qualification of a user DN; it is "let's find a place in a cert to
put some data we think might be useful in some application contexts."

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19417 for ietf-pkix-bks; Wed, 24 Mar 1999 06:36:29 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19413 for <[e-mail]>; Wed, 24 Mar 1999 06:36:27 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA04021; Wed, 24 Mar 1999 09:43:21 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a20b31e5fb64eff@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Wed, 24 Mar 1999 04:32:13 -0500
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

>Agree to all.
>
>What I mean is: Whatever is used as the approximation data of a biometric
>property of the subject, this can be hashed and signed in the certificate.
>The hashed data has then to be supplied separate from the cert.
>
>This will work. Desired? I don't know. But it has it's pros and cons.
>
>The example of a hashed static picture can be used if I want you as a
>recipient to se my face and to know that this static image shows the face
>of the owner of the certified key.
>
>Desired? I don't know, but it would work and it has its pros and cons as well.

I'm not sure I understand your example here; let me try to describe what i
think you might have meant.

The template against which a captured biometric is compared must be
available in unhased form for processing.  The goal is to know that this
template is correctly associated with the user in question. So, yes, one
could store the template somewhere and then bind it to the user via a hash
of the template embedded in a public key or attribute cert. This is a
different strategy from what was originally proposed, namely inclusion of
the template itself in a certificate. The question then arises as to
whether it is preferable to bind the template to the user in this fashion.

Let me know if this is what you had in mind.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19410 for ietf-pkix-bks; Wed, 24 Mar 1999 06:36:04 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19406 for <[e-mail]>; Wed, 24 Mar 1999 06:36:03 -0800 (PST)
Received: from [128.33.238.119] (TC113.BBN.COM [128.33.238.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA03961; Wed, 24 Mar 1999 09:43:09 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a1cb31e5ac425b9@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Wed, 24 Mar 1999 04:08:04 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Location and Identification
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

>
>>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:
>
>> The reliability in a biometric identification scheme lies in a
>combination
>> of:
>> 1) The subjects unique posession of the original biological limb itself
>> (the finger, eye etc.)
>> 2) The function of a capture device which only allows the real biological
>> human original to produce valid digital capture data.
>> 3) The absolute critical function to integrity protect the capture data
>> between the capture device and the comparing algorithm, and the equally
>> critical function to authenticate and integrity protect pre stored data
>> used by the comparing algorithm.
>
>[Tom Gindin] There seems to be another critical step here, which may be
>more difficult than either number 2 or number 3 above.  How does the
>comparing algorithm authenticate that the data being sent in step 3 is
>coming from a capture device and not from something else?  I know a
>certified key pair for the device will work - I wouldn't know how else to
>do it.

I  think Stefan tried to subsume the authenticity/integrity requirement in
step 2. Having the data be signed by the capture device is a good strategy,
though not nthe only one.  A symmetric crypto approach might suffice as
well, since what we need here is point-to-point authentication and
integrity for the captrured data. However, one must also examine the
physical security of the device and the associated cryptography, to really
satisfy the requirements established in the second step.

>> 4) The function of a comparing algorithm, comparing captured data with
>the
>> pre stored information in such way that it produce a good balanced, low
>> probability, of both false positive (wrong original accepted) and false
>> negative (right original rejected) response.
>>
>> If any of these 4 fail, the system is unreliable. If not, the system
>works.
>
>It seems to me that all four of these are, at best, highly immature
>and at worst, beyond the state of the art.
>
>> But note that none of these steps require any digital representation of
>the
>> bio-data to be secret.
>
>Yes, IF all four are rigorously satisfied.  If they are not, then when
>an attacker has access to the digital representation, he has the means
>to create forgeries that get past imperfect implementations of
>properties 1 through 4 you listed.
>
>[Tom Gindin] If the capture device signs its data on transmission and
>includes a timestamp, the forgeries will be detected as not coming from a
>registered device.  If arbitrary senders are permitted, even a perfect
>device and comparison algorithm will not help.

Note my earlier comment; in the real world we need to pay attention to the
implementation of the crypto and its resistance to physical attacks.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18245 for ietf-pkix-bks; Wed, 24 Mar 1999 03:46:28 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18241 for <[e-mail]>; Wed, 24 Mar 1999 03:46:27 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 1AEA34B; Wed, 24 Mar 1999 12:53:35 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id MAA02321; Wed, 24 Mar 1999 12:53:35 +0100
Message-ID: <[e-mail]>
Date: Wed, 24 Mar 1999 12:53:37 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: SEIS:  Regarding "Given names"
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:
> 
> I agree that would be possible, to issue multiple certificates and to put
> appropriate ID information into each certificate,

X.509 proposes DN or certID. Any other proposals?

> although it may lead
> to an enormous proliferation of certificates -- one for each unique
> application, at worst.  (Of course if you sell certificates, the more the merrier! :-)

I am not a CA service provider :-) but one long vehicle certificate
containing all attributes is even cost-intensive. If one attribute
changes then you will need a new certificate. The more attributes are
included the higher the possibility of a certificate update. Certificate
management expenses are necessary in addition. 

> 
> But with respect to the "additional security problems associated with
> directories," I was not referring to directories operated by some
> independent third-party, but to enterprise directories that are operated
> by the same people that administer the various applications.
> 
> If I authenticate a user using one primary certificate, and then look
> up additional names forms and/or other attributes in the enterprise directory,
> that association can certainly be as trusted as the applications themselves,
> as they are probably managed by the same sets of people.
> 
> For that matter, the same basic sets of people are probably operating the
> RA functions that are used to issue the certificates as well.

This is a policy issue on the one hand and a PKI design issue on the
other hand. I think the main ideas has been already discussed on this
list. Nevertheless I would like to note that a CA service provider
should not warrants for all attributes. Attribute certificates may be a
scheme for delegating responsibility by delegating signing.

> 
[snip]

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA14948 for ietf-pkix-bks; Wed, 24 Mar 1999 01:53:52 -0800 (PST)
Received: from e5.ijs.si ([e-mail] [193.138.1.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA14942 for <[e-mail]>; Wed, 24 Mar 1999 01:53:45 -0800 (PST)
From: [e-mail]
Received: (qmail 6337 invoked by uid 1021); 24 Mar 1999 09:54:07 -0000
Message-ID: <[e-mail]>
Subject: Re: Changes to RFC2459
To: [e-mail]
Date: Wed, 24 Mar 1999 10:54:06 +0100 (MET)
X-Mailer: ELM [version 2.4 PL0]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since nobody gave any comments to my previous mail about equivalent policies
in a basic path validation procedure, I would like to rise this issue again.
Is there a particular reason why certificates from policy mappings extension 
are not explicitly mentioned in the path processing actions in RFC 2459? 
The acceptable policy set in the procedure is defined as 

"a set of certificate policy identifiers comprising the policy or policies 
recognized by the public key user together with policies deemed equivalent 
through policy mapping. The initial value of the acceptable policy set is
the special value "any-policy".

Since in each step of the algorithm the acceptable policy set is obtained
as the intersection of the old value and critically marked policies extension,
does this mean that equivalent policies from the policy mappings extension
are added to the initial policy set and the acceptable policy set somewhere
in items (d) and (e) of the algorithm? Or is it assumed that for the 
computation of intersections (items g and h) equivalent policies are actually 
the same? In this case, is the definition of the acceptable policy set correct?

Regards,

Tomaz Klobucar


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07812 for ietf-pkix-bks; Tue, 23 Mar 1999 22:43:25 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07808 for <[e-mail]>; Tue, 23 Mar 1999 22:43:23 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA15218; Wed, 24 Mar 1999 18:50:28 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92225822805332>; Wed, 24 Mar 1999 18:50:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Changes to RFC2459
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 24 Mar 1999 18:50:28 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad (Exchange)" <[e-mail]> writes:
 
>A second comment is that the text should be changed to address the question 
>of dates prior to 1950 as they are probably general time, but not explicitly 
>stated.  PLease change  in 4.1.2.5 to read "validity dates from the year 1950 
>through the year 2049 as UTCTime; certificates validtity prior to 1950 and in 
>2050 or later MUST be encoded as GeneralizedTime."
 
I agree with this.  Every time I load one of these mis-encoded pre-1950 certs 
into the ENIAC in the basement it blows half a dozen tubes trying to handle 
the date, and it takes me all afternoon to replace the fried circuits.  This 
is a real irritation.  My Difference Engine handles it even more poorly, the 
lack of extra positions in the date field breaks the teeth of several of the 
gears, and it's a major hassle getting new ones machined to replace them.  I 
haven't even dared feed these certs to the strange device made of a metal 
allow not found on earth which was found in a Sumerian tomb because I fear 
replacement parts could be tricky to obtain if the bad date causes it to 
malfunction.
 
Also, if we're going to really fix this date problem I think we need to 
address the Y10K issue as well.  We should set this as a work item right now 
to increase the chances of getting consensus on a solution by the time the 
problem manifests itself.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15663 for ietf-pkix-bks; Tue, 23 Mar 1999 16:18:34 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15659 for <[e-mail]>; Tue, 23 Mar 1999 16:18:30 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id QAA19065; Tue, 23 Mar 1999 16:25:31 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 23 Mar 1999 16:25:17 -0800
To: Stefan Santesson <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Location and Identification
Cc: <[e-mail]>, "Bob Jueneman" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:34 PM 3/23/99 +0100, you wrote:
>At 05:31 PM 3/19/99 -0800, Tony Bartoletti wrote:
><snip>
>>Out of curiosity, what do you think would happen if everyone
>>posted crisp images of their fingerprints and retinas to
>>the usenet newsgroup "alt.kill.biometrics"?
>>
>>Of what use can it be to have another's fingerprints if it
>>is assumed that anyone can spoof them?
>>
>>(There is no such newsgroup, but I might start one;)
>>
>>___tony___
>
>
>I sense a major misconception.
>
>The reliability in a biometric identification scheme does NOT lie in ANY
>digital representation of the captured biometrics (if the system is well
>designed).

The definition of "well-designed" may be at issue here, in particular with
regard to assumptions about near-term future capabilities of attackers.

>Yes, there must be a pre stored record some ware, but that is not
>necessarily secret. It must be integrity protected, Yes, but not secret (to
>provide reliability)
>
>The reliability in a biometric identification scheme lies in a combination
>of: 
>1) The subjects unique posession of the original biological limb itself
>(the finger, eye etc.)

This assumes that I will never be able to "produce" a physical "thumb"
that exhibits your thumbprint (and temperature, surface conductivity, et al)
from a copy of your thumbprint I have lifted from a soda can.  Correct?

>2) The function of a capture device which only allows the real biological
>human original to produce valid digital capture data.

This "may" require the presence of a human operator-witness, and also
involve some intense scrutiny, given my previous comment.

>3) The absolute critical function to integrity protect the capture data
>between the capture device and the comparing algorithm, and the equally
>critical function to authenticate and integrity protect pre stored data
>used by the comparing algorithm.

Authenticating the pre-stored data (aside from subsequent integrity
protections) may be problematic.  There are many possible avenues of
attack.  If I can produce a serviceable "thumb" with YOUR thumbprint
(and driver's licence with your name, but MY picture) I might be able
to get such elements "certified".  Alternately, I could use MY thumb
print, with a driver's licence bearing YOUR name/address, but MY
picture, thus binding your "credentials" to my physical presence.

>4) The function of a comparing algorithm, comparing captured data with the
>pre stored information in such way that it produce a good balanced, low
>probability, of both false positive (wrong original accepted) and false
>negative (right original rejected) response.
>
>If any of these 4 fail, the system is unreliable. If not, the system works.
>
>But note that none of these steps require any digital representation of the
>bio-data to be secret.

Again, only under the assumption that (say) 5-10 years from now, it will
not be trivial to produce a thumb with matching thumbprints, an eye with
matching retina, etc., given the source of the said bio-data.

And to reiterate, I can use MY thumb, with a fake driver's licence and
birth-certificate, to "take over" your identity even more thoroughly,
especially if you have not already had your bio-stats "registered" first.

>A digitally signed hash of the pre stored bio-data (included in a
>certificate) could for example provide the needed authentication of pre
>stored bio-data (in step 3 above), even if it was held in a totally
>unsecure directory.
>
>I also believe that the pre stored data could have a form which does not
>reveal the exact shape of the bio-original, but that is only guessing. If
>that's not the case, the only reason for keeping the pre stored data
>secret, would be of privacy reasons. Otherwise, I believe there is no
>reason at all.

My final point, and one that seems to go unaddressed:  If every person
on earth were easily able to "leave", via reproduction, my fingerprints
or retinal images anywhere they like, then no one will assume that the
occurance of such a trace necessarily represents "me".  So there is no
longer a privacy concern.

___tony___

>
>/Stefan  
>


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15306 for ietf-pkix-bks; Tue, 23 Mar 1999 15:43:15 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA15302 for <[e-mail]>; Tue, 23 Mar 1999 15:43:14 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 23 Mar 1999 16:49:49 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 23 Mar 1999 16:49:32 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Location and Identification
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 mail.proper.com id PAA15303
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>> Tony Bartoletti <[e-mail]> 3/19/99 18:31:18 >>>
>Out of curiosity, what do you think would happen if everyone
>posted crisp images of their fingerprints and retinas to
>the usenet newsgroup "alt.kill.biometrics"?

It is also my cruosity about the use of biometrics. I fail to see how biometric information is treated in the same pot as secret/private keys. That information should be treated as public. I don't see how that information or its transformed form can be used as a passsword, or as some other form of secret. As you pointed out, posting that information, or data from which that information can be extracted (well, say a good photo of some very well-known person in Time magazine posing for "Got milk?")

>Of what use can it be to have another's fingerprints if it
>is assumed that anyone can spoof them?

I share the same curiosity here. One thing I think right now is that biometric info can be used as some sort of identification or as a Globally Unique Identifier of a person assuming that info is certified in some manner - ok, in a certificate for example. And, it is public. 

Besides, how can you revoke a biometric info if it's compromised (assuming it's used as a secret info) ? Use the other finger ? If I remember correctly, Steve Kent already has a posting on this issue in the last week or so.

>(There is no such newsgroup, but I might start one;)
Maybe the paparazzis are already doing that job some retinas ;-))

- Tolga




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15235 for ietf-pkix-bks; Tue, 23 Mar 1999 15:32:16 -0800 (PST)
Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15231 for <[e-mail]>; Tue, 23 Mar 1999 15:32:14 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id SAA91824; Tue, 23 Mar 1999 18:38:38 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id SAA140686; Tue, 23 Mar 1999 18:38:48 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525673D.0081E50A ; Tue, 23 Mar 1999 18:38:47 -0500
X-Lotus-FromDomain: IBMUS
To: Paul Koning <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 1999 18:40:44 -0500
Subject: Re: Location and Identification
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Koning <[e-mail]> on 03/23/99 05:41:35 PM

To:   [e-mail]
cc:   [e-mail] (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: Location and Identification





>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

> The reliability in a biometric identification scheme lies in a
combination
> of:
> 1) The subjects unique posession of the original biological limb itself
> (the finger, eye etc.)
> 2) The function of a capture device which only allows the real biological
> human original to produce valid digital capture data.
> 3) The absolute critical function to integrity protect the capture data
> between the capture device and the comparing algorithm, and the equally
> critical function to authenticate and integrity protect pre stored data
> used by the comparing algorithm.

[Tom Gindin] There seems to be another critical step here, which may be
more difficult than either number 2 or number 3 above.  How does the
comparing algorithm authenticate that the data being sent in step 3 is
coming from a capture device and not from something else?  I know a
certified key pair for the device will work - I wouldn't know how else to
do it.

> 4) The function of a comparing algorithm, comparing captured data with
the
> pre stored information in such way that it produce a good balanced, low
> probability, of both false positive (wrong original accepted) and false
> negative (right original rejected) response.
>
> If any of these 4 fail, the system is unreliable. If not, the system
works.

It seems to me that all four of these are, at best, highly immature
and at worst, beyond the state of the art.

> But note that none of these steps require any digital representation of
the
> bio-data to be secret.

Yes, IF all four are rigorously satisfied.  If they are not, then when
an attacker has access to the digital representation, he has the means
to create forgeries that get past imperfect implementations of
properties 1 through 4 you listed.

[Tom Gindin] If the capture device signs its data on transmission and
includes a timestamp, the forgeries will be detected as not coming from a
registered device.  If arbitrary senders are permitted, even a perfect
device and comparison algorithm will not help.

     paul




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15091 for ietf-pkix-bks; Tue, 23 Mar 1999 15:18:50 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15087 for <[e-mail]>; Tue, 23 Mar 1999 15:18:50 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA19424; Tue, 23 Mar 1999 15:21:43 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA23404; Tue, 23 Mar 1999 15:25:19 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRA38MC>; Tue, 23 Mar 1999 15:25:21 -0800
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: Changes to RFC2459
Date: Tue, 23 Mar 1999 15:25:20 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that there are cases where basicConstraints and keyUsage extensions
in end entity certificates may be  redundant, however I also feel that CAs
should have the option of using an empty sequence to signify an end entity
cert.  The X.509 spec allows for this...

>From section 12.4.2.1 of X.509, Note 2 "To constrain a certificate subject
to being only an end entity, i.e. not a CA, the issuer can include this
extension field containing only an empty SEQUENCE value. 

Other than possible redundant info, I cant think of any other reasons why
PKIX should explicitly not allow this.

Alex


> -----Original Message-----
> From: Brian Korver [mailto:[e-mail]]
> Sent: Tuesday, March 23, 1999 2:49 PM
> To: Jim Schaad (Exchange)
> Cc: IETF-PKIX (E-mail)
> Subject: Re: Changes to RFC2459
> 
> 
> "Jim Schaad (Exchange)" wrote:
> > 
> > As RFC 2459 moves forward and we start to find problems, we 
> are requested to
> > bring this to the list  One of the last arguments that I 
> remember (but it
> > may have been partly in private) had to do with the 
> BasicConstrants for
> > End-Entities and if the current text is correct.  Currently 
> the RFC states
> > that the extensions SHOULD NOT be present for End-Entities 
> and is MUST and
> > critical for CAs.
> > 
> > Given that lack of information does not really imply that 
> it is an entity.
> > I feel that CAs need to be given the option of putting the 
> extension on for
> > all certificates and the SHOULD NOT needs to be changed to 
> either SHOULD (my
> > preference) or MAY.
> 
> Jim,
> 
> I'm not totally against MAY, but I will note that there are cases 
> where BasicConstraints in EE certificates is redundant.  For 
> instance, 
> if the KeyUsage extension is present, that provides 
> sufficient information 
> to determine whether it is a CA or EE certificate.  
> Similarly, if issuing
> the CA certificate contains BasicConstraints with 
> pathLenConstraint==0, 
> then the subject certificate must be an EE certificate.
> 
> If SHOULD NOT is changed to SHOULD or MAY, I wouldn't mind seeing
> text explaining when EE BasicConstraints may be redundant.
> 
> 
> > 
> > A second comment is that the text should be changed to 
> address the question
> > of dates prior to 1950 as they are probably general time, 
> but not explicitly
> > stated.  PLease change  in 4.1.2.5 to read "validity dates 
> from the year
> > 1950 through the year 2049 as UTCTime; certificates 
> validtity prior to 1950
> > and in 2050 or later MUST be encoded as GeneralizedTime."
> > 
> > jim
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14760 for ietf-pkix-bks; Tue, 23 Mar 1999 14:42:09 -0800 (PST)
Received: from oe8.briank.com (oe8.briank.com [209.133.59.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14756 for <[e-mail]>; Tue, 23 Mar 1999 14:42:04 -0800 (PST)
Received: from cs.stanford.edu (blatz.briank.com [209.133.59.212]) by oe8.briank.com (8.8.8/8.8.8) with ESMTP id OAA13965; Tue, 23 Mar 1999 14:48:36 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 1999 14:48:36 -0800
From: Brian Korver <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.51 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jim Schaad (Exchange)" <[e-mail]>
CC: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Re: Changes to RFC2459
References: <2FBF98FC7852CF11912A0000000000010ECB5DD9@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad (Exchange)" wrote:
> 
> As RFC 2459 moves forward and we start to find problems, we are requested to
> bring this to the list  One of the last arguments that I remember (but it
> may have been partly in private) had to do with the BasicConstrants for
> End-Entities and if the current text is correct.  Currently the RFC states
> that the extensions SHOULD NOT be present for End-Entities and is MUST and
> critical for CAs.
> 
> Given that lack of information does not really imply that it is an entity.
> I feel that CAs need to be given the option of putting the extension on for
> all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
> preference) or MAY.

Jim,

I'm not totally against MAY, but I will note that there are cases 
where BasicConstraints in EE certificates is redundant.  For instance, 
if the KeyUsage extension is present, that provides sufficient information 
to determine whether it is a CA or EE certificate.  Similarly, if issuing
the CA certificate contains BasicConstraints with pathLenConstraint==0, 
then the subject certificate must be an EE certificate.

If SHOULD NOT is changed to SHOULD or MAY, I wouldn't mind seeing
text explaining when EE BasicConstraints may be redundant.


> 
> A second comment is that the text should be changed to address the question
> of dates prior to 1950 as they are probably general time, but not explicitly
> stated.  PLease change  in 4.1.2.5 to read "validity dates from the year
> 1950 through the year 2049 as UTCTime; certificates validtity prior to 1950
> and in 2050 or later MUST be encoded as GeneralizedTime."
> 
> jim


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14697 for ietf-pkix-bks; Tue, 23 Mar 1999 14:35:54 -0800 (PST)
Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14693 for <[e-mail]>; Tue, 23 Mar 1999 14:35:52 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQghvm10160; Tue, 23 Mar 1999 17:41:33 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA10557; Tue, 23 Mar 99 17:37:43 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA15911; Tue, 23 Mar 1999 17:41:35 -0500
Date: Tue, 23 Mar 1999 17:41:35 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Location and Identification
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

> The reliability in a biometric identification scheme lies in a combination
> of:
> 1) The subjects unique posession of the original biological limb itself
> (the finger, eye etc.)
> 2) The function of a capture device which only allows the real biological
> human original to produce valid digital capture data.
> 3) The absolute critical function to integrity protect the capture data
> between the capture device and the comparing algorithm, and the equally
> critical function to authenticate and integrity protect pre stored data
> used by the comparing algorithm.
> 4) The function of a comparing algorithm, comparing captured data with the
> pre stored information in such way that it produce a good balanced, low
> probability, of both false positive (wrong original accepted) and false
> negative (right original rejected) response.
> 
> If any of these 4 fail, the system is unreliable. If not, the system works.

It seems to me that all four of these are, at best, highly immature
and at worst, beyond the state of the art.
 
> But note that none of these steps require any digital representation of the
> bio-data to be secret.

Yes, IF all four are rigorously satisfied.  If they are not, then when 
an attacker has access to the digital representation, he has the means 
to create forgeries that get past imperfect implementations of
properties 1 through 4 you listed.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14560 for ietf-pkix-bks; Tue, 23 Mar 1999 14:24:23 -0800 (PST)
Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14556 for <[e-mail]>; Tue, 23 Mar 1999 14:24:22 -0800 (PST)
Received: from datakey.com ([205.218.59.22]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 345; Tue, 23 Mar 1999 16:34:59 -0600
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 1999 16:31:22 -0600
From: "Dale Gustafson" <[e-mail]>
Organization: Datakey, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'David P. Kemp'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Pictures in QCs - No problems!
References: <01BE7509.9B3E9D40@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Yours is one of the more widely applicable ideas suggested here recently and I believe it
should be evolved further.  Intuitively, there is a need to add innovative capabilities like
this to PKIX that will be difficult to satisfy simply by extending x.509 v3 public key / ID
certificates with a plethora of non critical extensions -- primarily due to the impact on
certificate size and a growing, installed base of ID certificates and secure applications that
use them.

Over time it may well become increasingly difficult to achieve consensus on any proposed
addition or modification to the x.509 v3 certificate profile -- especially if each new secure
application is likely to need / want to define more "application specific" information that
needs to be included in ID-certs.

Perhaps this concept could be evolved more readily through inclusion within Attribute
Certificates that will, in some cases, be distributed to a more targeted set of users (e.g.,
depending on the needs of secure applications).  In theory, such an approach would enable
secure application developers to evolve their designs more rapidly.  Presumably, the high level
design of attribute certificate support in PKIX would provide secure application developers
with a structured method that helps them define which data elements { must | should | may } be
included in a given attribute-cert, how to reference other data elements, etc.  This also
suggests that it might be beneficial to define a set of standard data elements that are
available for use in attribute-certs when applicable.

Best Regards,

Dale Gustafson


Anders Rundgren wrote:

> David,
> >There is nothing technically challenging about defining such an extension,
> >but why should PKIX do it?  What is the advantage of stuffing a
> >JPEG image into a certificate, as opposed to signing a MIME structure
> >(web page or message body) containing the JPEG image and everything
> >else of interest?  Browsers already know how to decode a variety of
> >mime-types, and will sooner or later know how to validate signatures
> >the PKIX-S/MIME way.
>
> It is surely not technically challenging but it is nifty if you are working with ID-cards
> based on smart cards.  Cost (always important!) , security (I have confirmed with
> a major bank that they like this idea) and convenience would be greatly improved
> by adding a few biometrics to a cert:
>
> http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP
>
> >In other words, attaching attributes, biometric values, and other metadata
> >to the subject of a certificate sounds more like an application issue
> >than a Public Key Infrastructure issue.  A PKI binds a public key to
> >an identity, where an identity is the domain-specific unique ID of
> >the subject.  A picture is not an identity; it is not reasonable
> >to store public keys in a database using a picture of the subject's
> >face or handwritten signature as the primary index.
>
> You are probably right in theory about what PKI is but in a practical application
> like an ID-card scheme you can be less stringent without losing a single advantage
> of PKI.  I consider much of the QC attributes as pure metadata as well although they
> can be searched for in a database.
>
> >I hope that PKIX's new, expanded charter covering Attribute Certificates
> >will be limited to ensuring that attributes can be issued, distributed,
> >located and securely bound to subjects.  The attributes themselves
> >should be opaque blobs (OID/OctetString pairs) as far as PKIX is
> >concerned.
>
> I can hardly see that things become much better because you put JPEGs in Attribute
> certificates instead of in QCs.   Just more overhead.   The prime uses of attribute
> certificates will IMO be for dynamic data like roles and authority.
>
> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>
> But the real question is:  There are proponents and opponents to extending certificates
> to contain biometric data.  If the QC-spec. does not support this in a structured fashion
> people like me will insert them anyway.  Does IETF gain anything by creating a mess
> for those who support this scheme?
>
> Or is the IETF afraid that to technically support biometrics in QCs could be interpreted as
> IETF says: "Biometrics is the way to go" ?
>
> Also note that such an extension does not affect any "sensible" and "politically correct"
> usages of QCs.
>
> Anders Rundgren
> Senior Internet e-commerce Architect
> http://www.mobilephones-tng.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14362 for ietf-pkix-bks; Tue, 23 Mar 1999 14:04:39 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14358 for <[e-mail]>; Tue, 23 Mar 1999 14:04:37 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27860; Tue, 23 Mar 1999 17:11:11 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-03.txt
Date: Tue, 23 Mar 1999 17:11:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) 
Working Group of the IETF.

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu, J. Schaad, J. Weinstein
	Filename	: draft-ietf-pkix-cmc-03.txt
	Pages		: 42
	Date		: 22-Mar-99
	
This document defines a Certificate Management protocol using CMS (CMC).
 This protocol addresses two immediate needs within the Internet PKI
 community:
 
 1. The need for an interface to public key certification products and
    services based on [CMS] and [PKCS10], and
 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-
    signed certificates with Diffie-Hellman public keys.
 
 A small number of additional services are defined to supplement the core
 certificate request service.
 
 Throughout this specification the term CMS is used to refer to both [CMS]
 and [PKCS7].  For signedData the two specifications are equivalent.  For
 envelopedData CMS is a superset of the PKCS7. In general, the use of
 PKCS7 in this document is aligned to the Cryptographic Message Syntax
 [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers
 to this specification.
 
 The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in
 this document are to be interpreted as described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14302 for ietf-pkix-bks; Tue, 23 Mar 1999 14:00:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14296 for <[e-mail]>; Tue, 23 Mar 1999 14:00:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27701; Tue, 23 Mar 1999 17:07:26 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-01.txt
Date: Tue, 23 Mar 1999 17:07:26 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) 
Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure PKIX Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-01.txt
	Pages		: 37
	Date		: 22-Mar-99
	
   This document provides an overview or 'roadmap' of the work done by
   the IETF PKIX working group. It describes some of the terminology
   used in the working group's documents, and the theory behind an
   X.509-based PKI. It identifies each document developed by the PKIX
   working group, and describes the relationships among the various
   documents.  It also provides advice to would-be PKIX implementors
   about some of the issues discussed at length during PKIX development,
   in hopes of making it easier to build implementations that will
   actually interoperate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-roadmap-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14075 for ietf-pkix-bks; Tue, 23 Mar 1999 13:37:27 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14071 for <[e-mail]>; Tue, 23 Mar 1999 13:37:26 -0800 (PST)
Received: from [128.33.238.119] (TC131.BBN.COM [128.33.238.131]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id QAA08836; Tue, 23 Mar 1999 16:44:05 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a15b31dba638ba2@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Tue, 23 Mar 1999 16:40:53 -0500
To: Martin =?iso-8859-1?Q?Lindstr=F6m?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CRL version field confusion
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Martin,

>Regarding the issue with the slightly different approaches of
>coding the CRL version field.
>
>"Both sides" have now stated an explanation of why/why not the
>CRL version field should be present in a CRL containing only
>non-critical extensions.
>However, the fact remains that a CA following X.509 may be
>imcompatible with a client processing CRLs according to rfc2459.
>This is of course not desirable in any way and I'm a bit surprised
>that no effort in resolving the ambiguity was made.
>
>Clearly, rfc2459 should be compatible with X.509, or?

RFC 2459 differs from X.509 in several minor respects already, e.g., in
terms of what extensions are marked critical, etc.  This is another minor
difference.  I do not currently see us changing the RFC, since we had good
reasons for our decision, and I understand the points Hoyt made as well.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13967 for ietf-pkix-bks; Tue, 23 Mar 1999 13:27:19 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13963 for <[e-mail]>; Tue, 23 Mar 1999 13:27:18 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id WAA09413; Tue, 23 Mar 1999 22:34:15 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 22:34:57 +0100
To: Tony Bartoletti <[e-mail]>, "Bob Jueneman" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Location and Identification
Cc: <[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 mail.proper.com id NAA13964
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:31 PM 3/19/99 -0800, Tony Bartoletti wrote:
<snip>
>Out of curiosity, what do you think would happen if everyone
>posted crisp images of their fingerprints and retinas to
>the usenet newsgroup "alt.kill.biometrics"?
>
>Of what use can it be to have another's fingerprints if it
>is assumed that anyone can spoof them?
>
>(There is no such newsgroup, but I might start one;)
>
>___tony___


I sense a major misconception.

The reliability in a biometric identification scheme does NOT lie in ANY
digital representation of the captured biometrics (if the system is well
designed).

Yes, there must be a pre stored record some ware, but that is not
necessarily secret. It must be integrity protected, Yes, but not secret (to
provide reliability)

The reliability in a biometric identification scheme lies in a combination
of: 
1) The subjects unique posession of the original biological limb itself
(the finger, eye etc.)
2) The function of a capture device which only allows the real biological
human original to produce valid digital capture data.
3) The absolute critical function to integrity protect the capture data
between the capture device and the comparing algorithm, and the equally
critical function to authenticate and integrity protect pre stored data
used by the comparing algorithm.
4) The function of a comparing algorithm, comparing captured data with the
pre stored information in such way that it produce a good balanced, low
probability, of both false positive (wrong original accepted) and false
negative (right original rejected) response.

If any of these 4 fail, the system is unreliable. If not, the system works.

But note that none of these steps require any digital representation of the
bio-data to be secret.

A digitally signed hash of the pre stored bio-data (included in a
certificate) could for example provide the needed authentication of pre
stored bio-data (in step 3 above), even if it was held in a totally
unsecure directory.

I also believe that the pre stored data could have a form which does not
reveal the exact shape of the bio-original, but that is only guessing. If
that's not the case, the only reason for keeping the pre stored data
secret, would be of privacy reasons. Otherwise, I believe there is no
reason at all.


/Stefan  


 
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13652 for ietf-pkix-bks; Tue, 23 Mar 1999 13:00:47 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13648 for <[e-mail]>; Tue, 23 Mar 1999 13:00:46 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA03788 for <[e-mail]>; Tue, 23 Mar 1999 16:07:53 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA03778 for <[e-mail]>; Tue, 23 Mar 1999 16:07:52 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA20311 for <[e-mail]>; Tue, 23 Mar 1999 16:06:26 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA01040 for <[e-mail]>; Tue, 23 Mar 1999 16:08:03 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 23 Mar 1999 16:08:03 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Changes to RFC2459
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 0HLMVATqkbDTQakoyL6P4g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Jim Schaad (Exchange)" <[e-mail]>
> 
> Given that lack of information does not really imply that it is an [end-] 
entity.
> I feel that CAs need to be given the option of putting the extension on for
> all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
> preference) or MAY.

I disagree.  Where key usage is present, basic constraints is redundant
and unnecessary.

CAs and applications MUST recognize the key usage extension, which
SHOULD be marked critical when present.  If the keyCertSign and cRLSign
bits are not asserted, the subject is an end entity.

The keyUsage extension is widely useful to end entities.  But even if it
were not otherwise needed, it could be populated in lieu of a basic
contstraints extension. 

I am not proposing, but I would support, a statement that the key usage
extension SHOULD appear in end entity certificates.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13171 for ietf-pkix-bks; Tue, 23 Mar 1999 12:00:22 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA13167 for <[e-mail]>; Tue, 23 Mar 1999 12:00:21 -0800 (PST)
Received: (qmail 9227 invoked from network); 23 Mar 1999 20:07:28 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 23 Mar 1999 20:07:28 -0000
Received: (qmail 14523 invoked from network); 23 Mar 1999 20:02:00 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 23 Mar 1999 20:02:00 -0000
Message-ID: <00c101be8dac$5e5e4400$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Date: Fri, 23 Apr 1999 12:11:46 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: Stephen Kent <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Date: Tuesday, March 23, 1999 1:14 PM
Subject: RE: Biometrics in Qualified Certificates


>Stefan,
>>
>>Add new supported attributes to the list in the PersonalData field:
>>
>>    photo;
>>    handWrittenSignature;
>>
>>These attributes should contain:
>>
>>        mime-type PrintableString,
>>        body      OctetString
>>
>>(Complete definition of attributes has to be done)
>>
>>Since this is not my field of expertise I would like opinions from the
list
>>whether this is a good approach or not. Please also comment if this should
>>be addressed at all.
>
>As I mentioned in another message, this is still bad syntax, i.e., there is
>no justification for using a MIME type for these images.  You certainly
>would need more realistic proposed syntax before proceeding.

You may wish to define a name form for the alternative subject name
extension, as permitted by X509 and PKIX. Its form can be
a MIME-encoded name, an SMTP-extended address field, etc.

My reading of PKIX-1 is that implementations receving such
a field should not balk at its mere inclusion, unless the security
policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
is more strict than RFC 2459 regarding the extension and
extension-value schema rules.


As for your
>second query, my position is that it is a bad idea to put such information
>into a public key certificate.

X.509 supports the idea that an opaque data field created by
the Naming Authority be conveyed in a public-key certificate,
to engender assurances relevant to uniqueness of
(subject) naming (vs key certification) quality.

"A certification authority produces the certificate of a user by signing
(see clause 9)
a collection of information, including the user’s distinguished name and
public key, as well
as an optional unique identifier containing additional information about the
user. The exact
form of the unique identifier contents is unspecified here and left to the
certification
authority and might be, for example, an object identifier, a certificate, a
date, or some
other form of certification on the validity of the distinguished name. "




>
>Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13113 for ietf-pkix-bks; Tue, 23 Mar 1999 11:53:30 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13109 for <[e-mail]>; Tue, 23 Mar 1999 11:53:29 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <GFNX266T>; Tue, 23 Mar 1999 12:00:16 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5DD9@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Changes to RFC2459
Date: Tue, 23 Mar 1999 12:00:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As RFC 2459 moves forward and we start to find problems, we are requested to
bring this to the list  One of the last arguments that I remember (but it
may have been partly in private) had to do with the BasicConstrants for
End-Entities and if the current text is correct.  Currently the RFC states
that the extensions SHOULD NOT be present for End-Entities and is MUST and
critical for CAs. 

Given that lack of information does not really imply that it is an entity.
I feel that CAs need to be given the option of putting the extension on for
all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
preference) or MAY.


A second comment is that the text should be changed to address the question
of dates prior to 1950 as they are probably general time, but not explicitly
stated.  PLease change  in 4.1.2.5 to read "validity dates from the year
1950 through the year 2049 as UTCTime; certificates validtity prior to 1950
and in 2050 or later MUST be encoded as GeneralizedTime."

jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12972 for ietf-pkix-bks; Tue, 23 Mar 1999 11:37:56 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12968 for <[e-mail]>; Tue, 23 Mar 1999 11:37:54 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id UAA08772; Tue, 23 Mar 1999 20:44:51 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 20:45:32 +0100
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Biometrics in Qualified Certificates
Cc: "'[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 mail.proper.com id LAA12969
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just to clarify this,

THIS IS NOT MY PROPOSAL!!!!!

I was just summing up Anders proposal in order to get reactions on it.
And personally I don't like it either of several reasons besides the ASN.1.
So we agree on that point.

Read my reasons below.

At 10:56 AM 3/23/99 -0500, Stephen Kent wrote:
>Stefan,
>>
>>Add new supported attributes to the list in the PersonalData field:
>>
>>    photo;
>>    handWrittenSignature;
>>
>>These attributes should contain:
>>
>>        mime-type PrintableString,
>>        body      OctetString
>>
>>(Complete definition of attributes has to be done)
>>
>>Since this is not my field of expertise I would like opinions from the list
>>whether this is a good approach or not. Please also comment if this should
>>be addressed at all.
>
>As I mentioned in another message, this is still bad syntax, i.e., there is
>no justification for using a MIME type for these images.  You certainly
>would need more realistic proposed syntax before proceeding. As for your
>second query, my position is that it is a bad idea to put such information
>into a public key certificate.
>
>Steve
>

Here are my primary reasons for not liking this:

1) There is a conceptual difference between biometric data and ID-reference
attributes. ID-attributes are used as index for identity searches in a
direct and well understood way, while biometric data have a much more
unclear usage when included in a certificate.

2) The concept of data storage is different. With ID-attributes, the data
is a direct and exact representation of the attribute value, while
biometrics are an approximation of the original information object. This
requires further agreements in order to successfully understand and use the
information.

3) While use of ID-attributes is well understood and can relate to existing
products and widely adopted procedures, biometrics are not (to my
understanding).

4) The set of supported attributes SHALL form an unmistakable identity,
even if other information, such as biometric data, are included. If
bio-metrics are included in the set of supported attributes, we then say
indirectly that it's OK to form an unmistakable identity ONLY based on
these bio-metrics. And I don't like that at all. This is to me another
reason to handle bio-metrics as a different type of descriptive information
(If handled at all at this stage).


/Stefan


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11442 for ietf-pkix-bks; Tue, 23 Mar 1999 09:11:36 -0800 (PST)
Received: from smtp4.server.ibm.com (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11438 for <[e-mail]>; Tue, 23 Mar 1999 09:11:35 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp4.server.ibm.com (8.8.7/8.8.7) with ESMTP id MAA57852; Tue, 23 Mar 1999 12:18:22 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id MAA213168; Tue, 23 Mar 1999 12:17:50 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525673D.005F06E1 ; Tue, 23 Mar 1999 12:17:49 -0500
X-Lotus-FromDomain: IBMUS
To: =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 1999 12:19:33 -0500
Subject: Re: CRL version field confusion
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 mail.proper.com id JAA11439
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     In my opinion, the best way to deal with this would be to allow both
options, by modifying both X.509 (1997) section 11.2 Note 3 and RFC 2459
section 5.1.2.1 as follows:

X.509 note:    Replace the second sentence of this note (If no extensions
defined as critical are included, the version element shall be absent.) by:
If no extensions are included, the version element shall be absent.  If
non-critical extensions are present, but no critical extensions are
present, the version number should be absent but it shall be accepted if
present.

RFC 2459 section:  Replace the second sentence of this section (When
extensions are used, as required by this profile, this field MUST be
present and MUST specify version 2 (the integer value is 1).) by: When
critical extensions are present, this field MUST be present and MUST
specify version 2 (the integer value is 1).  In all other cases of CRL's
conforming to this profile, this field SHOULD be present and, if present,
MUST specify version 2.

     These two amendments would allow conforming implementations of each
standard to work with each other.

          Tom Gindin



Martin Lindström <[e-mail]> on 03/23/99 10:14:20 AM

To:   [e-mail]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: CRL version field confusion






Regarding the issue with the slightly different approaches of
coding the CRL version field.

"Both sides" have now stated an explanation of why/why not the
CRL version field should be present in a CRL containing only
non-critical extensions.
However, the fact remains that a CA following X.509 may be
imcompatible with a client processing CRLs according to rfc2459.
This is of course not desirable in any way and I'm a bit surprised
that no effort in resolving the ambiguity was made.

Clearly, rfc2459 should be compatible with X.509, or?

Comments?

Regards Martin Lindström



______________________________________
         Entegrity Solutions

  Martin Lindström
  Senior Systems Engineer

  Finlandsgatan 60
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11004 for ietf-pkix-bks; Tue, 23 Mar 1999 08:26:04 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10999 for <[e-mail]>; Tue, 23 Mar 1999 08:26:02 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id RAA07339; Tue, 23 Mar 1999 17:33:04 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 17:33:45 +0100
To: Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Cc: "[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 mail.proper.com id IAA11001
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

Agree to all.

What I mean is: Whatever is used as the approximation data of a biometric
property of the subject, this can be hashed and signed in the certificate.
The hashed data has then to be supplied separate from the cert.

This will work. Desired? I don't know. But it has it's pros and cons.

The example of a hashed static picture can be used if I want you as a
recipient to se my face and to know that this static image shows the face
of the owner of the certified key.

Desired? I don't know, but it would work and it has its pros and cons as well.

/Stefan 

At 11:06 AM 3/23/99 -0500, Stephen Kent wrote:
>Stefan,
>
>>A hash would work just fine given that you provide the complete biometric
>>data apart from the certificate. You could send a Jpeg picture attached to
>>your document and have a hash of the picture in the cert.
>
>Yes, one coud do this if the hash was created from the JPEG picture you are
>sending, but that picture could not be one that was just captured by a
>camera as  part of verifying who is currently present at some location.
>This is because that captured image will certainly differ from the one used
>to generate the hash, and so there will always be a mismatch.
>
>So, if what is happening here is sending a static picture and having a
>recipient match it against a hash in a cert, what's the purpose?  This is
>not the aplication that usually comes to mind when one talks about
>biometric user authentication.
>
>If the goal is to provide a certified photo image of a user for visual
>inspection by another person, I agree with David Kemp, i.e., make this a
>separate object, signed by whomever is appropriate, which may not be a CA!
>After all, a CA ought not include the hash in the cert without having the
>picture in gand and matching the picture to the user.  But our standards
>for user or RA interaction with a CA don't necessarily require such
>physical presence.
>
>In general, I would suggest putting images, to be used in human-verified,
>in-person authentication systems, into separate objects.  Otherwise the
>result would be a very big cert, and a raft of privacy issues that have
>been discussed previously.  There is a natural tendency to try to put more
>stuff into certs, because certs are extensible, signed data objects, and
>have a raft of associated protocols for transmission, storage, etc.
>
>Remember the words of a former (in)famous U.S. Attorney General, "we could
>do it, but it would wrong."
>
>Steve
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10907 for ietf-pkix-bks; Tue, 23 Mar 1999 08:16:27 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10903 for <[e-mail]>; Tue, 23 Mar 1999 08:16:26 -0800 (PST)
Received: from [128.33.238.119] (TC152.BBN.COM [128.33.238.152]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA00235; Tue, 23 Mar 1999 11:23:13 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a11b31d6965176a@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Tue, 23 Mar 1999 10:56:03 -0500
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Biometrics in Qualified Certificates
Cc: "'[e-mail]'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
>
>Add new supported attributes to the list in the PersonalData field:
>
>    photo;
>    handWrittenSignature;
>
>These attributes should contain:
>
>        mime-type PrintableString,
>        body      OctetString
>
>(Complete definition of attributes has to be done)
>
>Since this is not my field of expertise I would like opinions from the list
>whether this is a good approach or not. Please also comment if this should
>be addressed at all.

As I mentioned in another message, this is still bad syntax, i.e., there is
no justification for using a MIME type for these images.  You certainly
would need more realistic proposed syntax before proceeding. As for your
second query, my position is that it is a bad idea to put such information
into a public key certificate.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10897 for ietf-pkix-bks; Tue, 23 Mar 1999 08:16:10 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10893 for <[e-mail]>; Tue, 23 Mar 1999 08:16:08 -0800 (PST)
Received: from [128.33.238.119] (TC152.BBN.COM [128.33.238.152]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA00202; Tue, 23 Mar 1999 11:23:06 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a10b31d66ec82db@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Tue, 23 Mar 1999 11:06:56 -0500
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

>A hash would work just fine given that you provide the complete biometric
>data apart from the certificate. You could send a Jpeg picture attached to
>your document and have a hash of the picture in the cert.

Yes, one coud do this if the hash was created from the JPEG picture you are
sending, but that picture could not be one that was just captured by a
camera as  part of verifying who is currently present at some location.
This is because that captured image will certainly differ from the one used
to generate the hash, and so there will always be a mismatch.

So, if what is happening here is sending a static picture and having a
recipient match it against a hash in a cert, what's the purpose?  This is
not the aplication that usually comes to mind when one talks about
biometric user authentication.

If the goal is to provide a certified photo image of a user for visual
inspection by another person, I agree with David Kemp, i.e., make this a
separate object, signed by whomever is appropriate, which may not be a CA!
After all, a CA ought not include the hash in the cert without having the
picture in gand and matching the picture to the user.  But our standards
for user or RA interaction with a CA don't necessarily require such
physical presence.

In general, I would suggest putting images, to be used in human-verified,
in-person authentication systems, into separate objects.  Otherwise the
result would be a very big cert, and a raft of privacy issues that have
been discussed previously.  There is a natural tendency to try to put more
stuff into certs, because certs are extensible, signed data objects, and
have a raft of associated protocols for transmission, storage, etc.

Remember the words of a former (in)famous U.S. Attorney General, "we could
do it, but it would wrong."

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10890 for ietf-pkix-bks; Tue, 23 Mar 1999 08:16:04 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10886 for <[e-mail]>; Tue, 23 Mar 1999 08:16:02 -0800 (PST)
Received: from [128.33.238.119] (TC152.BBN.COM [128.33.238.152]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA00097; Tue, 23 Mar 1999 11:22:48 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0eb31d51c1c9b0@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Tue, 23 Mar 1999 09:36:39 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Correct use of subject DN and subjectAltName
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

mark,

>
>Joe T. Soap, <[e-mail]>,
>   who lives in
>Palo Alto, CA, US

If Joe is getting an organizal person cert, which seems to be true given
the rest of the supplied info, then I don't think Joe's home location is
not relevant, so let;'s forget about this piece of data.

>   and works for
>Wysiwyg Corp.,
>   which is registered in
>Delaware, US

Truem, but generally  not interesting.  Many companies are incorporated
under Deleware laws because of legal benefits.  Unless Wysiwyg really has
offices in DL, I would not bother with this info. But, let's assume that in
this case that the comnpany really is headquartered there.

>   as a
>Project Manager
>   in the
>Internet Products Division
>   in their office in
>San Mateo, CA, US
>
>One way to do this would be to have personal information as the subject
>name, and then the corporate info and office info as a set of
>subjectAltNames, but there does not appear to be a way to identify which
>subjectAltName means what kind of location. Is there a legitimate way to
>represent this?

There is no sense that altSubjectNames are to be used to represent to
further qualify the Subject DN.  They certainly are useful for expressing a
name for the subject in other name spaces.  As I look at this list of info,
I begin to wonder if there is an effort to capture TOO MUCH info in the
subject name.  A frequent reason for this is because someone can envision a
way to use some of this data in some access control decision, even though
it may not be needed to uniquely identify Joe, find his directory entry,
etc.  So, for example, one might use the following subject DN in this case,
where parenthesese are used to group attributes that form an RDN set:

C=US, S=DL, O=Wysiwyg Corp, (S=CA, L=San Mateo, OU=Internet Products
Division), CN = Joe T. Soap.

I chose to put the indicated data into an RDN SET because that suggests
that there are multiple instances of the Internet products Division, within
CA, and thus one needs to consider all three of these attributes together
to uniquely identify the org unit in which Joe works.  If this is not the
case, e.g., if the company has just one Internet Products Division, and is
willing to manage names in that OU to ensure that the other Joe T. Soap
hired (or transferred into that division) will be uniquely identified, then
we could simplify the RDN and just make it the OU.

One always ought to ask what level of detail should be put into a Subject
(or Issuer) DN?  Putting in more details runs afould ot Steve's Rule of
Revocation, and makes the certs bigger too. Attempts to put more into a
name to simplify access control management are common, and almost always a
bad idea.

Steve

* Steve's Rule of Revocation states that the effective lifetime of a
certificate is inversely proportional to the square of the number of
attributes in the certificate.  Guess who named it?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10455 for ietf-pkix-bks; Tue, 23 Mar 1999 07:26:40 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10451 for <[e-mail]>; Tue, 23 Mar 1999 07:26:38 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id QAA06677; Tue, 23 Mar 1999 16:33:35 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 16:34:16 +0100
To: [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Correct use of subject DN and subjectAltName
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 mail.proper.com id HAA10452
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The Qualified Certificates draft has a way to handle this.

But the way is opposite to the one you propose. In QC the corporate
information is stored in the Subject field while the personal data is
stored in the SubjectAltName (PersonalData field)

Your example could be expressed:

Subject field:
---------------
Country = US
StateOrProvinceName = Delaware
Organization = Wysiwyg Corp.
OrganizationalUnitName = Internet Products Division
Address = xxxxx, San Mateo, CA
CommonName = Joe T. Soap
Title = Project Manager


PersonalData field: (SubjectAltName ext. / OtherNames)
------------------------------------------------------
RegistrationAuthority = Wysiwyg Corp. CA service
AttributeSemantics = OID xxx (declaring that the country attribute defines the
                              country within which names are registered and
                              the country within which the address is 
                              expressed.
                              Also declaring that the dNQualifier contains
                              a number locally assigned by the specified
                              registrationAuthority (Wysiwyg Corp CA)) 
Attributes:
Country = US
Surname = Soap
GivenName = Joe
GivenName = Thomas
CommonName = Joe T. Soap
Address = xxxxx, Palo Alto, CA
Gender = M
dNQualifier = 123456789
countryOfResidence = US
countryOfCitizenship = US


Some remarks:
I'm not sure if I treated the subject field entirely correct given that the
state in which the company is registered, differ from the state in the
company local address. Others may have a different solution to this.

The PersonalData field could be different and not all of the data in the
example need to be present. It must however contain a complete unmistakable
identity within itself i.e. without combining it with data from the subject
field.

/Stefan


At 01:33 PM 3/23/99 +0200, Mark Shuttleworth wrote:
>Hi folk
>
>Is there an established best practice for the layout of the following
>information in a PKIX end-entity certificate? This is the (fictional and
>complex) scenario:
>
>Joe T. Soap, <[e-mail]>, 
>   who lives in
>Palo Alto, CA, US
>   and works for
>Wysiwyg Corp., 
>   which is registered in 
>Delaware, US
>   as a
>Project Manager
>   in the
>Internet Products Division
>   in their office in
>San Mateo, CA, US
>
>One way to do this would be to have personal information as the subject
>name, and then the corporate info and office info as a set of
>subjectAltNames, but there does not appear to be a way to identify which
>subjectAltName means what kind of location. Is there a legitimate way to
>represent this?
>
>--
>Mark Shuttleworth
>Thawte
>Attachment Converted: "c:\internet\eudora\attach\smime5.p7s"
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10279 for ietf-pkix-bks; Tue, 23 Mar 1999 07:08:33 -0800 (PST)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10275 for <[e-mail]>; Tue, 23 Mar 1999 07:08:29 -0800 (PST)
Received: from roger ([10.0.0.20]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id QAA12057 for <[e-mail]>; Tue, 23 Mar 1999 16:12:20 +0100 (MET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 16:14:20 +0100
To: [e-mail]
From: Martin =?iso-8859-1?Q?Lindstr=F6m?= <[e-mail]>
Subject: Re: CRL version field confusion
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 mail.proper.com id HAA10276
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Regarding the issue with the slightly different approaches of
coding the CRL version field.

"Both sides" have now stated an explanation of why/why not the
CRL version field should be present in a CRL containing only
non-critical extensions.
However, the fact remains that a CA following X.509 may be
imcompatible with a client processing CRLs according to rfc2459.
This is of course not desirable in any way and I'm a bit surprised
that no effort in resolving the ambiguity was made.

Clearly, rfc2459 should be compatible with X.509, or?

Comments?

Regards Martin Lindström



______________________________________
         Entegrity Solutions

  Martin Lindström
  Senior Systems Engineer 

  Finlandsgatan 60 
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09501 for ietf-pkix-bks; Tue, 23 Mar 1999 05:20:17 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09497 for <[e-mail]>; Tue, 23 Mar 1999 05:20:16 -0800 (PST)
Received: from [128.33.238.119] (TC119.BBN.COM [128.33.238.119]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA04118; Tue, 23 Mar 1999 08:20:40 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a04b31b4f226fdd@[128.33.238.110]>
In-Reply-To: <[e-mail]>
Date: Sun, 21 Mar 1999 20:43:07 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Certificates, Directories, and Distinguished Names
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

>Because of the potential impact on evolving software, I'd like
>to escalate this issue to the PKIX co-chairs, Steve Kent and
>Warwick Ford, and to the chair of X.509, Hoyt Kesterson,
>in order to force a expeditious resolution to this issue.

We live but to serve as arbiters in such disputes :-).

>One of these name forms, at least, ought to be usable to
>retrieve a certificate from a directory, whereas the others,
>although potentially candidates for inclusion in a directory,
>may not represent a real directory entry but may be for
>display purposes to RP software, or for other application
>purposes.
>
>I believe that it is extremely important that at least one of the
>multiple name forms that may be carried in a directory reflect
>the primary directory name used to store and retrieve such
>certificates.  If I start searching a directory, I don't want to
>have to try every name in a certificate looking for other, related
>certificates.

I tend to agree that it would be good if at least one subject name could be
used for directory lookup.  But, we have multiple directory options in the
Internet.  If the subject name is present, it's a DN and might be
appropriate for lookup in an X.500 directory.  But, if that DN is made up
DC attribuites, maybe it's really destined to be looked up in the DNS.
Also, if the subject name is NULL and an altName is present, that name
might be a DNS name, an RFC822 name, or an IP address, all of which are
suitable for lookup in the DNS.  So, if you are willing to allow for both
X.500 and DNS directory lookups, it would seem that we have lots of options
here.  I'll leave it to Hoyt to tell me where to lookup EDI party names :-).


Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09450 for ietf-pkix-bks; Tue, 23 Mar 1999 05:13:32 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09446 for <[e-mail]>; Tue, 23 Mar 1999 05:13:31 -0800 (PST)
Received: from [128.33.238.119] (TC119.BBN.COM [128.33.238.119]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA04080; Tue, 23 Mar 1999 08:20:29 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b31b4c53c734@[128.33.238.110]>
In-Reply-To: <[e-mail]>
Date: Sun, 21 Mar 1999 20:28:43 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Location and Identification
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

>With respect to the biometric identifiers, my assumption is that
>if these mechanisms are to be at all useful for use at a distance
>(as opposed to at an ATM machine, for example), the biometric
>template must be public, in the same sense that a public key is
>public.
>
>But in order to make this at all feasible, it is ESSENTIAL that the
>transformation from the recorded biometric indicia produce a
>one-way mapping to the template, so that the biometric
>measurement itself cannot be compromised.
>
>In other words, given the template, it must be computationally
>infeasible to produce some biometric indicia, either real or
>artificially constructed, that would satisfy the template.

As I mentioned in a private note to Bob, my experience with biometric
templates suggests that it is generally NOT possible to store templates in
this fashion.  The reason is that the matching algorithm for a biometric
must take the captured data and score it against the template.  Since the
captured data will almost alwways be a little "off," one needs to be able
to determine how far off the data is.  A good hash function defeats this
purpose, e.g., a single bit error is a distant (hamming distance) as a
multi-bit error.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA08664 for ietf-pkix-bks; Tue, 23 Mar 1999 03:26:24 -0800 (PST)
Received: from bilbo.thawte.com (bilbo.thawte.com [196.25.207.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA08660 for <[e-mail]>; Tue, 23 Mar 1999 03:26:22 -0800 (PST)
Received: from thawte.com (really [196.25.207.2]) by thawte.com via in.smtpd with esmtp id <[e-mail]> (Debian Smail3.2.0.102) for <[e-mail]>; Tue, 23 Mar 1999 13:33:23 +0200 (SAST) 
Message-ID: <[e-mail]>
Date: Tue, 23 Mar 1999 13:33:22 +0200
From: Mark Shuttleworth <[e-mail]>
Reply-To: [e-mail]
Organization: Thawte Consulting
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Correct use of subject DN and subjectAltName
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms16646C1B78F00184D975CD8F"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi folk

Is there an established best practice for the layout of the following
information in a PKIX end-entity certificate? This is the (fictional and
complex) scenario:

Joe T. Soap, <[e-mail]>, 
   who lives in
Palo Alto, CA, US
   and works for
Wysiwyg Corp., 
   which is registered in 
Delaware, US
   as a
Project Manager
   in the
Internet Products Division
   in their office in
San Mateo, CA, US

One way to do this would be to have personal information as the subject
name, and then the corporate info and office info as a set of
subjectAltNames, but there does not appear to be a way to identify which
subjectAltName means what kind of location. Is there a legitimate way to
represent this?

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

MIIIRwYJKoZIhvcNAQcCoIIIODCCCDQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx
Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5
OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1
dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy
ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq
hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso
+hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE
AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB
AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA
FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr
IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8
Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM
rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU
aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp
c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw
MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS
BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE
CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn
FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w
dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw
BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF
AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM
4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl
Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAdowggHWAgEBMIHAMIG5MQswCQYDVQQGEwJa
QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45
LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl
ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkwMzIzMTEzMzIyWjAjBgkqhkiG9w0BCQQxFgQUY574uig6
OBUo4hnux8GJmJSlXqAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEQHzK4fzb8+C4EDd7wUEAcbbwoOG2UNSPA1N2LFxuAvrWnTIQVr1JwwsGiVsYjz9/
GEIrXBRib9/jYwURUz0cUOs=
--------------ms16646C1B78F00184D975CD8F--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA06106 for ietf-pkix-bks; Tue, 23 Mar 1999 02:43:16 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA06102 for <[e-mail]>; Tue, 23 Mar 1999 02:42:42 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id LAA00612 for <[e-mail]>; Tue, 23 Mar 1999 11:49:41 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA106485; Tue, 23 Mar 1999 11:49:37 +0100
Received: by HYDRA with Microsoft Mail id <01BE7523.4FE315A0@HYDRA>; Tue, 23 Mar 1999 11:50:13 +0100
Message-ID: <01BE7523.4FE315A0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Andrew Probert '" <[e-mail]>, "'Alan Lloyd'" <[e-mail]>
Subject: RE: QC Biometric Support.  Was: Location and Identification
Date: Tue, 23 Mar 1999 11:50:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd,
The "directory aficionado ultimata" says:
>a) I agree with andy.

>b) we should not with new technologies and information paradigms (as
>provided by directory services), design and use the system based on old
>procedures. We should adopt new design methodologies comensurate with
>evolving practices and the new system concepts and functionality. 
 
>c) Having some minimal experience with the requirements of crime info
>support systems and the application of directory services  - could mean
>that we can:

>1. put (eg.) fingerprint search engines/databases as subordinate
>directory services to the backbone directory infrastructure.

>2 put directory based relational search engines over the top of the
>directory system to correlate information in the subordinate search
>engines (eg. images) and directory information bases (eg. case
>material).

>3. Use a certificate to cryptographically sign and identify  (by name)
>an image or biometric bit oriented object.

>ie. The  approaches listed above to designing information systems (with
>large scale directory services) -  actually solve many operational
>requirements.

>How such directory functions are applied re Users, Policies, privacy,
>etc are operational matters and upto those who build such systems. 

But unfortunately the directory solution has at least as many
problems as the solution I suggest.  Who will have the right to access bio data?

My solutions allow the CLIENT/USER to choose what information he/she wants to
give to a relying party.  BTW, have you actually read the ID-document?

http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

>The point - there are many commercial and socially accepted reasons for
>putting bios/images in certs - its just there are some uses of bio certs
>which may not be socially accepted in some countries.. 

>However, this is a technical group - and we cant fix the worlds
>social/X.509 issues for all countries.

We don't have to either!  By making room for the bio stuff in certs everybody will
be happy.  If the cert/bio, dir/bio or no-bio will be the "winner" is a thing for the market to
decide.

We all have our favorites and PKI is (at least deployment-wise) a young technology
so where we should be in ten years or so cannot be carved into stone today.

Regards
Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA01622 for ietf-pkix-bks; Mon, 22 Mar 1999 23:38:43 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA01618 for <[e-mail]>; Mon, 22 Mar 1999 23:38:42 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id IAA09474 for <[e-mail]>; Tue, 23 Mar 1999 08:45:43 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA14164; Tue, 23 Mar 1999 08:45:36 +0100
Received: by HYDRA with Microsoft Mail id <01BE7509.9B3E9D40@HYDRA>; Tue, 23 Mar 1999 08:46:13 +0100
Message-ID: <01BE7509.9B3E9D40@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Pictures in QCs - No problems!
Date: Tue, 23 Mar 1999 08:46:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,
>There is nothing technically challenging about defining such an extension,
>but why should PKIX do it?  What is the advantage of stuffing a
>JPEG image into a certificate, as opposed to signing a MIME structure
>(web page or message body) containing the JPEG image and everything
>else of interest?  Browsers already know how to decode a variety of
>mime-types, and will sooner or later know how to validate signatures
>the PKIX-S/MIME way.

It is surely not technically challenging but it is nifty if you are working with ID-cards
based on smart cards.  Cost (always important!) , security (I have confirmed with
a major bank that they like this idea) and convenience would be greatly improved
by adding a few biometrics to a cert:

http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

>In other words, attaching attributes, biometric values, and other metadata
>to the subject of a certificate sounds more like an application issue
>than a Public Key Infrastructure issue.  A PKI binds a public key to
>an identity, where an identity is the domain-specific unique ID of
>the subject.  A picture is not an identity; it is not reasonable
>to store public keys in a database using a picture of the subject's
>face or handwritten signature as the primary index.

You are probably right in theory about what PKI is but in a practical application
like an ID-card scheme you can be less stringent without losing a single advantage
of PKI.  I consider much of the QC attributes as pure metadata as well although they
can be searched for in a database.

>I hope that PKIX's new, expanded charter covering Attribute Certificates
>will be limited to ensuring that attributes can be issued, distributed, 
>located and securely bound to subjects.  The attributes themselves
>should be opaque blobs (OID/OctetString pairs) as far as PKIX is
>concerned.

I can hardly see that things become much better because you put JPEGs in Attribute
certificates instead of in QCs.   Just more overhead.   The prime uses of attribute
certificates will IMO be for dynamic data like roles and authority.

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

But the real question is:  There are proponents and opponents to extending certificates
to contain biometric data.  If the QC-spec. does not support this in a structured fashion
people like me will insert them anyway.  Does IETF gain anything by creating a mess
for those who support this scheme?

Or is the IETF afraid that to technically support biometrics in QCs could be interpreted as
IETF says: "Biometrics is the way to go" ?

Also note that such an extension does not affect any "sensible" and "politically correct" 
usages of QCs.

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA01609 for ietf-pkix-bks; Mon, 22 Mar 1999 23:37:27 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA01605 for <[e-mail]>; Mon, 22 Mar 1999 23:37:18 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <H3MDC8MV>; Tue, 23 Mar 1999 18:42:43 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0D2106@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'Andrew Probert '" <[e-mail]>
Subject: RE: QC Biometric Support.  Was: Location and Identification
Date: Tue, 23 Mar 1999 18:42:41 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA01606
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some thoughts - 
a) I agree with andy.

b) we should not with new technologies and information paradigms (as
provided by directory services), design and use the system based on old
procedures. We should adopt new design methodologies comensurate with
evolving practices and the new system concepts and functionality. 
 
c) Having some minimal experience with the requirements of crime info
support systems and the application of directory services  - could mean
that we can:

1. put (eg.) fingerprint search engines/databases as subordinate
directory services to the backbone directory infrastructure.

2 put directory based relational search engines over the top of the
directory system to correlate information in the subordinate search
engines (eg. images) and directory information bases (eg. case
material).

3. Use a certificate to cryptographically sign and identify  (by name)
an image or biometric bit oriented object.

ie. The  approaches listed above to designing information systems (with
large scale directory services) -  actually solve many operational
requirements.

How such directory functions are applied re Users, Policies, privacy,
etc are operational matters and upto those who build such systems. 


The point - there are many commercial and socially accepted reasons for
putting bios/images in certs - its just there are some uses of bio certs
which may not be socially accepted in some countries.. 

However, this is a technical group - and we cant fix the worlds
social/X.509 issues for all countries.

regards alan 

 

----------
From: Andrew Probert
To: [e-mail]
Sent: 3/23/99 8:33:41 AM
Subject: RE: QC Biometric Support.  Was: Location and Identification

Sorry I beg to differ.  Desire for privacy is an international and
globally
acknowledged FACT.   

I happened to state my personal Australian experience.  From what I read
in
the press many other countries are similar.

I could equally cite Malaysia who have issued a digital id to everybody
over
the age of 14, with photo, dual thumbprints etc as a counter claim.

There are a lot of projects we work on, healthcare for example, where a
unique id would be a blessing to we IT people and solve a hell of a lot
of
technical and data matching issues.

I agree you can easily put stuff like this in standards and do niche
deployments.  

Pragmatically, I think you will find it hard to get mass deployment.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Anders Rundgren [SMTP:[e-mail]]
> Sent:	Monday, March 22, 1999 7:58 PM
> To:	'Bob Jueneman'; [e-mail]; 'Andrew Probert'
> Cc:	[e-mail]; 'SEIS-List'; 'STEPHAN ALMQVIST'; 'Petra
> Glöckner'; 'Stefan Santesson'; 'Stephen Kent'
> Subject:	QC Biometric Support.  Was: Location and Identification
> 
> Andrew.
> >I think the discussion at the moment is philisophically about whether
to
> put
> >some of this biometrics stuff online at all.
> 
> >In our country, the push for a national identity card was totally
sunk
> upon
> >issues of privacy.  We don't even allow so much as the US social
security
> >card style.  Also, the only people with fingerprint databases are the
> police
> >and only for convicted felons.  
> 
> >I believe whilst it is technically feasible to putsome of this
biometrics
> >online, it is not commercially feasible or socially acceptable.
> 
> This is Australian POLITICS and not globally acknowledged FACTS.
Should
> IMO have
> no impact on the specification of QCs.  It is a deployment issue if
you
> use
> SSNs and/or biometrics.
> 
> If you care to read a document in early alpha-stage on why I think it
is
> fairly easily
> to find powerful supporters for biometric data in certs, please read
this:
> 
> http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP
> 
> which I have prepared in great haste in order to also give our
> non-ASN.1 readers a chance to see what it is all about.
> 
> BTW, has the QC task-force actually talked to FBI and immigration
> authorities?
> 
> Regards
> Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA27903 for ietf-pkix-bks; Mon, 22 Mar 1999 22:23:31 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA27899 for <[e-mail]>; Mon, 22 Mar 1999 22:23:21 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <H3MDC8MB>; Tue, 23 Mar 1999 17:28:48 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0D20FD@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Bob Jueneman '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Certificates, Directories, and Distinguished Names
Date: Tue, 23 Mar 1999 17:28:44 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id WAA27900
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 

A couple of points.

No standard or the theory of directories or PKIs can enforce a naming
model that  will be tied to a commercial business. 

Ther is no universal system design agreed by any one in which the Alt
names are used in a cert - for doing something in terms of additive
process that is coupled to the basic certificate issueance, validation,
revocation or archive processes.

That nothing much will be right with PKIs unless they are tied to a
directory service in which the naming policy reflects a business
organisation, its products and services and that the PKI/CA functions
that serve that have a defined DIT structure representing the CA
management model and;

that directories ( ldap servers) and certificate clients implement
certificate component matching so that certs can be found more
effectively.

As said a PKI is a function tied to a business model which is
represented in directory services. The operational policy reflects the
naming model, the efficiency of using certificates (and managing them)
is governed by the "search" facilities specific to these data structures
- ie certficate and CRL component matching.

As for alt names etc,... why are they there?

I agree with hoyt - can we have clarification

regards alan



----------
From: Bob Jueneman
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Sent: 3/20/99 8:47:50 AM
Subject: Certificates, Directories, and Distinguished Names

[Apologies if this is a duplicate. I sent it yesterday, but
it doesn't seem to have shown up on either list yet.]

The message from Petra Gloeckner illustrates that there is an
obvious lack of agreement about the semantics of a DN vs.
the semantics of an alternateSubjectName.

Because of the potential impact on evolving software, I'd like
to escalate this issue to the PKIX co-chairs, Steve Kent and 
Warwick Ford, and to the chair of X.509, Hoyt Kesterson, 
in order to force a expeditious resolution to this issue.

One of these name forms, at least, ought to be usable to 
retrieve a certificate from a directory, whereas the others,
although potentially candidates for inclusion in a directory,
may not represent a real directory entry but may be for
display purposes to RP software, or for other application 
purposes.

I believe that it is extremely important that at least one of the 
multiple name forms that may be carried in a directory reflect
the primary directory name used to store and retrieve such 
certificates.  If I start searching a directory, I don't want to
have to try every name in a certificate looking for other, related 
certificates.

(For example, I may have received a digital signature
certificate from someone, and now I want to look up his 
encryption certificate.  Or maybe my correspondent sent me 
his encryption certificate, but the key length is too long for
my US-exportable software to handle.)

As a practical matter, I don't care much one way or the other
which name form is picked as the primary one, but I very 
much need to have it nailed down, and quickly.  I would 
argue, however, that both historical precedent and the
wording in the standards would argue that the DN should be the
primary directory index name, and that other names, e.g., for display
purposes, should be subjectAltNames.

Bob


>>> "Petra Gl÷ckner" <[e-mail]> 03/18/99 06:39AM
>>>

> I certainly understand that there are lots of certificates
> containing DNs which don't correspond to entries in ANY
> directory, much less some well-structured, as-God-intended
> x.500 directory with X.520 DIT structure and schema.
> 
> My point is, and I am agreeing with you to at least a certain
> extent, that if we continue to throw completely arbitrary
> name constructs in the DN, we will make it increasingly difficult
> to ever store or retrieve those certificates in or from a directory.
> 
> So my goal was to get people to recognize that the primary
> purpose of the DN was to facilitate interoperation with a directory.
> And since there may very well be a proliferation of directories with
> incompatible DIT structures and schemas, it is necessary to
> recognize that it is the _subscriber's_ directory that must dictate
the
> DIT structure and schema -- not the CA's, and not the recipient's.

I don't think that the primary purpose of the DName is to facilitate 
interoperation with a directory. That was the motivation when they 
defined the X.509v3 certificates, but I think this is not valid anymore.

> Other technical functions such as name subordination may or may
> not have a role to play with respect to the DN.  They could, but
> I suspect that it may not be terribly useful in most cases, just
> because directory names are (unfortunately) not often organized
> along the lines of organizational boundaries that name subordination
> assumes.
> 
> I agree that when writing application software you cannot always
> assume that the DN points to an X.500 entry, as one may never have
> been created.  I would say that it OUGHT to, but it might not.
> 
> On the other hand, I believe that it would be WRONG to believe
> that an alternateSubjectName, in particular, would always point to
> a certificate, or even to a directory entry of any kind.  Again,
perhaps
> it ought to, but I may have chosen to express my name and
organizational
> structure in a more conventional fashion, perhaps for ease of display
and
> recognition, but without a corresponding entry in any existing
directory --
> not even an alias.
> 
> For example, my directory name in Novell's corporate directory in
business
> card format (top to bottom) is o=novell, ou=prv, ou=nsrd,
cn=bjueneman.
> 
> But what I would like to have displayed in someone's certificate
viewing
> software would be c=US, o="Novell, Inc.", ou="Network Products
Division",
> ou="Network Security Department", cn="Robert R. Jueneman"
>
> Since the purpose of the DN is to convey an entry in the directory,
the
> first name form clearly has to be the DN, and the second name form the
> alternateSubjectName.  But that second name form is not an entry in
the
> Novell corporate directory,  not even an alias, and not likely to be
any time
> soon, even if it has the form directoryName.

I disagree, the directoryName of the SubjectAltName has to convey an
entry 
in the directory, not necessarily the subject DName. So, IMO you should
put 
the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
directoryName 
of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
ou=Network 
ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman"

in the subject DName.
 
> I agree that it would be quite reasonable to create an alias for such
a
> name in a directory somewhere, and I would encourage such a practice.
> I also believe that it may be desirable to include other directory
style
> names as additional alternateSubjectNames, perhaps to support other
DIT
> structures and/or schemas, but I don't believe that the ietf-pkix
group
> is in a position to mandate that a particular alternateSubjectName
reflect
> a real entry in any particular directory.  And whether they mandate it
or
> not, it isn't likely to happen world-wide any time soon.
> 
> As for the additional information you may require that go beyond
"name"
> information per se, I would suggest that you make your PersonalData
> structure a subjectDirectoryAttributes attribute extension (if someone
can
> ever figure out what the semantics of _that_ attribute are supposed to
be),
> or else simply define a new attribute extension.
> 
> But in general I would be rather opposed to listing much of the type
of
> information you have suggested in a certificate at all, and certainly
not in
> a name field.

The PersonalData structure shall contain as much information of a person
as 
necessary in order to identify him. You don't have to use all
attributes!

We have chosen the SubjectAltName instead of the
subjectDirectoryAttributes 
extension because the PersonalData structure contains the name of the
person
plus any other required identity information to make the name unique.
But you can easily use any of the attributes defined in the QC-draft,
which 
are not necessary to unmistakably identify the person, within the 
subjectDirectoryAttributes extension since the
subjectDirectoryAttributes 
and the PersonalData structure are both a sequence of attribute.
 
Petra

PS.: I will be on vacation next week. I'll answer as soon I'm back at
work.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05403 for ietf-pkix-bks; Mon, 22 Mar 1999 15:01:41 -0800 (PST)
Received: from vignette.com (mi.vignette.com [207.8.7.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA05399 for <[e-mail]>; Mon, 22 Mar 1999 15:01:41 -0800 (PST)
Received: from vignette.com by  vignette.com (8.7.3/BERK-6.8.11) id RAA11037; Mon, 22 Mar 1999 17:07:26 -0600 (CST)
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 1999 17:07:26 -0600
From: Keith Johnston <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Question: Using Certificate Extensions for Applications
References: <v04020a09b3183998e653@[128.33.238.181]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, you have understood correctly.  And yes, there is a need that these
certificates be available through an external CA.  We cannot assume that our
customers are willing to buy CA software and manage it.

Thanks for your comments!  We are still waiting to here from Verisign and Thawte as
to whether or not they will sign certificates with extensions.

Keith

Tony Bartoletti wrote:

> Keith,
>
> Naive question, perhaps, but if I understand you correctly, you want
> processes (or servers) to authenticate each other, irrespective of the
> "person" (if any) that may have started the process, or be at the controls.
>
> If this is the case, why not be your own CA?  I assume you would know if
> a particular server/ethernet-address/IPAddress binding was correct or not.
>
> Is there an independent need that these certificates be available through
> (say) Verisign or Thawte?
>
> ___tony___
>
> At 03:00 PM 3/19/99 -0600, Keith Johnston wrote:
> >Stephen Kent wrote:
> >
> >> Keith,
> >>
> >> >I am on a project where we want to use digital certificates to
> >> >authenticate various server processes to each other over SSL.  What we'd
> >> >like to do is define a certificate extension that has the name of the
> >> >server in it, and then have each customer create certificates with the
> >> >standard fields (organizaiton, country, etc) set to their information,
> >> >and the extension field set to the name of the server.
> >>
> >> I would stgrongly recommend against creation of an extension for this
> >> purpose. What you seem to want is a cert that identifies a user executing a
> >> process on a server.  If so, then you should issue a cert that has a
> >> subject name with sufficient info to uniquely identify the processes in
> >> question.  X.509 has a naming model that presumes that the subject name
> >> uniquely identifies the subject, period.  If the intent here is to identify
> >> the subject in the context of the server, then one should construct a
> >> subject name that does so.
> >>
> >
> >OK, I see your point - think of the server as a particular user.  And this
> >works fine if the customer has their own CA software - they would be perfectly
> >willing to sign a certificate that has a name like
> >"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
> >doesn't provide a signing service - I was mistaken there) wouldn't know how to
> >prove that you are really running ProcessFooBar on your server, or even what
> >ProcessFooBar is.  So I don't see how this works with an external CA that
> >doesn't understand what it is you are trying to do.  Sure, they can sign
> >certificates with DNS names or a persons name, but a process name?
> >
> >Another alternative we are investigating is allowing each server process to map
> >a certificate distinguished name to a process identity.  This could mean that
> >JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
> >different serial numbers.  Then each process would have a hashtable that maps
> >the serial number to the process name.  Each process could then authenticate to
> >the others.  But that's kind of annoying to have to distribute that map
> >around.  Sure, you could put it in LDAP or on some central server, but then
> >you've got a single point of failure or a complicated caching/replication
> >system.  So putting the process name in the certificate is really, really cool,
> >because all each server needs is a copy of the CA certificate.
> >
> >Thanks for your comments, I look forward to your response.
> >
> >Keith
> >
> >
> >
>
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA05007 for ietf-pkix-bks; Mon, 22 Mar 1999 14:28:02 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05003 for <[e-mail]>; Mon, 22 Mar 1999 14:28:00 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <GKMRRFM1>; Tue, 23 Mar 1999 08:33:43 +1000
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A636A@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: [e-mail]
Subject: RE: QC Biometric Support.  Was: Location and Identification
Date: Tue, 23 Mar 1999 08:33:41 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA05004
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry I beg to differ.  Desire for privacy is an international and globally
acknowledged FACT.   

I happened to state my personal Australian experience.  From what I read in
the press many other countries are similar.

I could equally cite Malaysia who have issued a digital id to everybody over
the age of 14, with photo, dual thumbprints etc as a counter claim.

There are a lot of projects we work on, healthcare for example, where a
unique id would be a blessing to we IT people and solve a hell of a lot of
technical and data matching issues.

I agree you can easily put stuff like this in standards and do niche
deployments.  

Pragmatically, I think you will find it hard to get mass deployment.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Anders Rundgren [SMTP:[e-mail]]
> Sent:	Monday, March 22, 1999 7:58 PM
> To:	'Bob Jueneman'; [e-mail]; 'Andrew Probert'
> Cc:	[e-mail]; 'SEIS-List'; 'STEPHAN ALMQVIST'; 'Petra
> Glöckner'; 'Stefan Santesson'; 'Stephen Kent'
> Subject:	QC Biometric Support.  Was: Location and Identification
> 
> Andrew.
> >I think the discussion at the moment is philisophically about whether to
> put
> >some of this biometrics stuff online at all.
> 
> >In our country, the push for a national identity card was totally sunk
> upon
> >issues of privacy.  We don't even allow so much as the US social security
> >card style.  Also, the only people with fingerprint databases are the
> police
> >and only for convicted felons.  
> 
> >I believe whilst it is technically feasible to putsome of this biometrics
> >online, it is not commercially feasible or socially acceptable.
> 
> This is Australian POLITICS and not globally acknowledged FACTS.   Should
> IMO have
> no impact on the specification of QCs.  It is a deployment issue if you
> use
> SSNs and/or biometrics.
> 
> If you care to read a document in early alpha-stage on why I think it is
> fairly easily
> to find powerful supporters for biometric data in certs, please read this:
> 
> http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP
> 
> which I have prepared in great haste in order to also give our
> non-ASN.1 readers a chance to see what it is all about.
> 
> BTW, has the QC task-force actually talked to FBI and immigration
> authorities?
> 
> Regards
> Anders


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02864 for ietf-pkix-bks; Mon, 22 Mar 1999 10:27:31 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02860 for <[e-mail]>; Mon, 22 Mar 1999 10:27:30 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id KAA14655; Mon, 22 Mar 1999 10:33:54 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Mar 1999 10:33:42 -0800
To: Andrew Probert <[e-mail]>, "'Bob Jueneman'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Location and Identification
Cc: [e-mail]
In-Reply-To: <C13ABC20EDDAD111B29E0000B456EABC0A6363@SPRINGFIELD>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:08 AM 3/22/99 +1000, Andrew Probert wrote:
>In my opinion, some directories can be made as secure as any other database
>technology e.g. SQL.  Directories as a form of OO database, with X.500
>access controls actually allow protection over trees, subtrees, object types
>even down to attributes based upon the name you choose to login, including
>strong auth login as well.

Yes, it can be made just as secure as any other database technology.

The maintenance personnel who format and replace those disks when they
go bad may be rather difficult to secure in perpetuity, however.  And
once the data "gets out", as many have observed, it cannot be "revoked".

Public once, public forever.

>I think the discussion at the moment is philisophically about whether to put
>some of this biometrics stuff online at all.
>
>In our country, the push for a national identity card was totally sunk upon
>issues of privacy.  We don't even allow so much as the US social security
>card style.  Also, the only people with fingerprint databases are the police
>and only for convicted felons.  

We can change that.  It is in the power of each individual to publish
their biometrics, if they so desire.

>I believe whilst it is technically feasible to putsome of this biometrics
>online, it is not commercially feasible or socially acceptable.

Many things not considered "socially acceptable" thrive on the internet.

>A more natural approach is to consider that most computer sytems have access
>control mechansms.  RACF, ACF2, Unix file permissions, ACLs etc.  These are
>all closed and proprietary mechansisms.  Attribute Certficates can be used
>to provide open mechanisms that are analogous, for distributed systems.  I
>think personal identity and access to servers that allow privilige are
>technically and socially acceptable.

No argument there.

___tony___
>Andew Probert
>Rotek Consulting   http://www.rotek.com.au
>a Division of Secure Network Solutions
>Tel  [phone]
>Fax [phone]
>
>
>
>> -----Original Message-----
>> From:	Bob Jueneman [SMTP:[e-mail]]
>> Sent:	Saturday, March 20, 1999 6:36 AM
>> To:	[e-mail]
>> Cc:	[e-mail]
>> Subject:	Location and Identification
>> 
>> I think Tony has some interesting points, so I'll take him up on 
>> forwarding them to the list, then respond.
>> 
>> Bob
>> 
>> >>> Tony Bartoletti <[e-mail]> 03/18/99 05:47PM >>>
>> Bob,
>> 
>> I am a bit reticent to jump into the threads with this, but I offer
>> it to you to use as you wish (forward, edit, consider, whatever.)
>> My thoughts here are in response to several recent threads.
>>  
>> I don't pretend to know the intimate details of DNs, AltNames, etc.,
>> (collectively "Name-Like-Things") and the precise handling expected
>> of them by X.509-conforming software.  Nor am I expert at the varied
>> contents (keys, et al) that may be bound into the certificates,
>> (collectively, "Ident-Challenge-Data").
>> 
>> I see from these discussions at least two broad and (in my ideal)
>> orthogonal dimensions that people intend for them to serve:
>> 
>> 1.  Location (of individual/cert or their issuer)
>> 
>>     Ranging from Global-Public-Location to Proprietary-Location
>> 
>> 2.  Secured Identification (of located item.  "Ident-Challenge-Data")
>> 
>>     Ranging from Public/Private Keys to Biometric Data.
>> 
>> I think it is useful to consider this (simplified) "quad-chart"
>> and characterize various schemes/applications accordingly:
>> 
>>   FUNCTION:    |  Object Location         | Object Identification
>>   METHOD:      |  (via Name-Like-Thing)   | (via Challenge-Data)
>>   ---------------------------------------------------------------
>>   (subclass)   |  Global Public Locator   | Keys/Issuer-Keys
>>   ---------------------------------------------------------------
>>   (subclass)   |  Proprietary Locator     | Biometric Data/Hash
>>   ---------------------------------------------------------------
>> 
>> Note:  I do not intend for these "rows" to indicate correspondence.
>> That is, one could deploy a system where a "Proprietary Locator" is
>> used to retrieve "Keys/Issuer-Keys" Challenge-Data, (basically, the
>> current situation with key-certificates) or (God Forbid) a system
>> where a "Global Public Locator" can retrieve an individual's
>> Biometric Challenge Data.
>> 
>> Furthermore, in each possible case, one can imagine a protocol
>> that either does or does not require the "data-owner" to cooperate
>> in the final step of identification (say, you believe you have
>> located someones challenge-data, but can only see a piece of it
>> large enough to query them to release the remainder, and can
>> then proceed with a full challenge if they concur.)
>> 
>> This is how the telephone white-pages work.  If I find (say) three
>> "Bob Jueneman" I can call each one.  If I say "Are you the Bob that
>> posts to the PKIX list," you can either reply with additional
>> confirming data, or say "Sorry, this is Jueneman's Plumbing Supplies,
>> we only carry PVC, no 'PKIX'" just to avoid me.  
>> 
>> If I may characterize the discussions of late, I see some threads
>> hoping to elevate (?) Proprietary Locators to Global Public Locators,
>> (Simon says, "Lets build the X.500 directory of Babel") and others
>> to extend certified content from Keys to Biometrics, for instance.
>> 
>> Worse, I also see a blurring of the functions themselves, to wit,
>> "Let a secure directory hold established name-hierarchies that map
>> precisely to the material world, thus Existence-In-Directory
>> implies Identification, (delete one challenge-response.)"
>>        
>> As sexy and convenient as it may seem to overload these functions,
>> especially Location with Identification, such a scheme would be
>> both unstable and dangerous (the ultimate bad combination).
>> 
>> When someone says "We can make the directories secure" I cringe.
>> How secure?  For what?
>> 
>> The public telephone white-pages are secure enough for their purpose;
>> if a hacker or insider makes malicious modifications, it is just an
>> inconvenience for the most part.  If a directory holding my keys
>> is compromised, more hassle, but I can revoke and be re-issued.
>> 
>> I don't know if nature allows a directory secure enough to house
>> my biometric data, unless it is purely encrypted blobs to the
>> root directory operators, and I have secure control of the keys.
>> 
>> A Final Thought:  I am beginning to wonder if I should start a
>> global movement to have everyone capture all of their biometric
>> data (fingerprints, retinals, DNA sequences, etc) and publish
>> them in a giant, open public repository.  Would this not serve
>> make such data effectively worthless?  The only way this data
>> can be used to effectively "impersonate" me, is if there is a
>> reasonable assumption on the part of the relying party that
>> such information is uniquely held.  Destroy this assumption,
>> and the ability to impersonate disappears, no?
>> 
>> ___tony___
>> 
>> 
>>  
>> 
>> Tony Bartoletti                                             LL
>> Center for Information Operations and Assurance          LL LL
>> Lawrence Livermore National Laboratory                LL LL LL
>> PO Box 808, L - 303                                   LL LL LL
>> Livermore, CA 94551-9900                              LL LL LLLLLLLL
>> phone: [phone]   fax: [phone]               LL LLLLLLLL
>> email: [e-mail]                                   LLLLLLLL
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02558 for ietf-pkix-bks; Mon, 22 Mar 1999 10:06:13 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02554 for <[e-mail]>; Mon, 22 Mar 1999 10:06:12 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id KAA03294; Mon, 22 Mar 1999 10:13:08 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 22 Mar 1999 10:12:56 -0800
To: [e-mail], ietf-pkix <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
In-Reply-To: <[e-mail]>
References: <v04020a09b3183998e653@[128.33.238.181]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 01:09 PM 3/22/99 +0100, Juergen Walter wrote:
>Tony Bartoletti wrote:
>> 
>> Keith,
>> 
>> Naive question, perhaps, but if I understand you correctly, you want
>> processes (or servers) to authenticate each other, irrespective of the
>> "person" (if any) that may have started the process, or be at the controls.
>
>I tend to use attribute certs in the situation described by Keith.
>Attribute certs contain a DN or an ID of public key certificate.
>Therefore an attribute cert binding to a "person" over DN or cert ID is
>given.
>
>I would like to consider a similar problem. What is to do if I want to
>certifiy a server public key. Who is the subject? Is it the server or
>the entity responsible for it? What cert extensions are commonly
>recognized in server certificates?
>
>I prefer a human being as subject. All other informations should be
>contained in the cert extensions.

I agree that Attribute certificates would be more natural for this
situation.  However, I also tend to object to the notion that subjects
need to be human beings.

As far as I can see, ALL PKI certificates ever do is cryptographically
bind a "name" (DN, AltName, ...) and other attributes to a public key.
The presumed binding of this "name" to something "real" is accomplished
only in the minds of those who accept the signatory's (CA's) stated
verification procedures.  It is a semantic layer removed from the
mechanics of the certificates themselves, and should have remained so.

Otherwise, we are building an "Earthling Identification Infrastructure",
rather than engineering a Public Key Infrastructure.

If PKIs did not appear until the year 2099, the first applications
might have been "robot authentication", in which case "Manufacturer"
might have had a prominent position in the DN.  Then, people might
ask "Why is the cert schema so unfriendly to humans?  Humans have no
Manufacturer."

Or is the infrastructure designed mainly to serve "paying customers"?

___tony___


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA02241 for ietf-pkix-bks; Mon, 22 Mar 1999 09:41:58 -0800 (PST)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02231 for <[e-mail]>; Mon, 22 Mar 1999 09:41:43 -0800 (PST)
Received: from mcg.org.br (pm04-13.sac.verio.net [209.162.64.126]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id JAA27050; Mon, 22 Mar 1999 09:48:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 1999 09:47:15 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: SEIS:  Re: Pictures in QCs - No problems!
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David P. Kemp wrote:

David:

Thanks for inserting some good common sense into this thread. The
temptation here is (again) to increase security by taxing privacy --
however, privacy is a long-term asset while security is a short-term
goal. So, this trade-off is not a good idea [1].

> A picture is not an identity; 

Here, I must take issue. This is IMO not correct, even one argues that
it may depend on what is defined to be an identity. 

For example, if you have video footage of a crime, those pictures
constitute not only identities for the persons present at the crime, but
they also identify their actions and reactions. Even if you do not know
the name of the persons, they may still be found and held resposnible
based on those identities. It is of no concern here if such pictures may
be ambigous or even obscure. In the same way that one may be  called
John Smith, which is very ambiguous but is an identity. BTW, even an
expired driver's license can be a valid identity -- even if not valid
for driving a car. 

It is interesting though to see what else is far too often accepted
without questioning. That identity must be "assigned" by someone -- as
the only type of identity possible. But, perhaps we can recognize that
this is a circular attempt to define identity -- "identity is what
identifies". Instead, I suggest in [2] that "to identify is to look for
coherence" -- where coherence is (as usual) "a natural or logical
connection".  Note first that this is a non self-referential definition
of identification -- also, not circular.

Identification can thus be understood not only in the sense of an
"identity" connection, but in the wider sense of "any" connection. Which
one to use is just a matter of protocol expression, need, cost and (very
importantly) privacy concerns. The essence of identification is thus to
find connections -- where absence of connections also counts. 

> it is not reasonable
> to store public keys in a database using a picture of the subject's
> face or handwritten signature as the primary index.
>

Agreed. This is open to debate...but it is certainly a bad idea for
privacy reasons. Any privacy information you give out or allow to be
stored is a security threat [1], not a security gain.
 
> The attributes themselves
> should be opaque blobs (OID/OctetString pairs) as far as PKIX is
> concerned.
>

Agreed, with a comment -- the PKIX model concerns itself with
certificates which bind an identity with a key and such identities are
blobs anyway you look at them, either as Distinguished Names or as
pictures. It is the PKIX standard and the CPS which may provide meaning
to them -- outside the certificate. 

Take Section 11.2 of X.509v3, "Management of certificates". It states
that the certificate allows an association between a name called "unique
distinguished name" or DN for the user and the user's public-key: "A 
certificate  associates the public key and unique distinguished name of
the user it describes.", while Section 7 explains that such DNs are
essential to the security design of X.509: "Authentication relies on
each user possessing a unique distinguished name." But, how are such DNs
assigned? Where are they unique? The DN is denoted by a NA (Naming
Authority) and accepted by a CA (Certification Authority) as unique
within the CA's domain, where the CA can
double as a NA. It is interesting to note that the same user can have
different DNs in different CAs, or can use the same DN in different CAs
even if it is not the first one to use it in a CA -- so different DNs
for different CAs do not necessarily mean different users and
vice-versa. Further, a DN does not have to contain the user's real-world
name or location. Thus, semantically, the CA certificate refers to a
name; however it does not denote it [3].

The same applies to a picture -- which is also a "name", a reference.

Cheers,

Ed Gerck

=========================
REFERENCES:

[1] http://www.mcg.org.br/faust.htm

[2] http://www.mcg.org.br/coherence.txt and
http://www.mcg.org.br/coherence2.txt

[3] http://www.mcg.org.br/certover.pdf
_____________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01236 for ietf-pkix-bks; Mon, 22 Mar 1999 08:12:48 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-100.dialup.dnai.com [207.181.255.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01232 for <[e-mail]>; Mon, 22 Mar 1999 08:12:46 -0800 (PST)
Received: from dnai.com (windoze.tenebras.com [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id IAA18254; Mon, 22 Mar 1999 08:19:02 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 1999 08:18:34 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
Organization: Oversized Metaphysics
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "[e-mail]" <[e-mail]>
Subject: Re: Biometrics in Qualified Certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson wrote:

> >2. Hash of biometric data?  Biometrics are analog (inexact) objects

> A hash would work just fine given that you provide the complete biometric
> data apart from the certificate....

Anders is right.  A hash that is not repeatable or verifiable is
useless.  Biometric data are often never the same twice, even from
the same equipment.  You can have a hash of a *reference* object, 
which of necessity is held by a trusted third party, in which case
there is no point in having it in any form in the cert.  The binding
of the identity to the object is all that matters.

And unless there is complete trust in the device providing biometric
data, and in the channel, you might as well be using cleartext
passwords -- it's subject to replay, man-in-the-middle, etc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00854 for ietf-pkix-bks; Mon, 22 Mar 1999 07:51:05 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00849 for <[e-mail]>; Mon, 22 Mar 1999 07:51:03 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA25405; Mon, 22 Mar 1999 10:57:55 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA25400; Mon, 22 Mar 1999 10:57:54 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA26366; Mon, 22 Mar 1999 10:56:29 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA00432; Mon, 22 Mar 1999 10:58:08 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 22 Mar 1999 10:58:08 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Pictures in QCs - No problems!
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vAB4oU45H60OXFMZYHfl3Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Tom Gindin wrote:
> >  While Anders admittedly knows little about ASN.1, he may be onto
> >  something useful here.  What would be wrong with defining a non-critical
> >  extension called displayableImage with syntax
> >  DisplayableImage ::= SEQUENCE {
> >       mime-type PrintableString,          -- I apologize if it's really
> >  IA5String
> >       body      OctetString
> >  }
> >       and then trying to get the browsers to support it?  They don't do so
> >  yet, of course, but it seems like a good idea and not incredibly difficult.

There is nothing technically challenging about defining such an extension,
but why should PKIX do it?  What is the advantage of stuffing a
JPEG image into a certificate, as opposed to signing a MIME structure
(web page or message body) containing the JPEG image and everything
else of interest?  Browsers already know how to decode a variety of
mime-types, and will sooner or later know how to validate signatures
the PKIX-S/MIME way.

In other words, attaching attributes, biometric values, and other metadata
to the subject of a certificate sounds more like an application issue
than a Public Key Infrastructure issue.  A PKI binds a public key to
an identity, where an identity is the domain-specific unique ID of
the subject.  A picture is not an identity; it is not reasonable
to store public keys in a database using a picture of the subject's
face or handwritten signature as the primary index.

I hope that PKIX's new, expanded charter covering Attribute Certificates
will be limited to ensuring that attributes can be issued, distributed, 
located and securely bound to subjects.  The attributes themselves
should be opaque blobs (OID/OctetString pairs) as far as PKIX is
concerned.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00837 for ietf-pkix-bks; Mon, 22 Mar 1999 07:49:49 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00833 for <[e-mail]>; Mon, 22 Mar 1999 07:49:47 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 098E44B; Mon, 22 Mar 1999 16:56:47 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id QAA28572; Mon, 22 Mar 1999 16:56:53 +0100
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 1999 16:56:47 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], ietf-pkix <[e-mail]>
Subject: Re: Cross certification message protection (RFC2510)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

I beg to differ. MAC based authentication is vulnerable when off-line
guessing attacks are possible (for details see my previous posting on
"Re: New CMC Draft available" that contains comments on CMP). 

Out-of-band methods seems to be quite reasonable. Nevertheless
authentication via digital signature may be reasonable as well.

Authentication based on HMAC where the plaintext (= input for HMAC
without secret key) AND the ciphertext (= output for HMAC) is contained
in the protocol message needs additional security measures. Encryption
of the message may one of suitable measure (but not the best).
Encryption of the protocol message is allowed in CMP but it is still
recommended to send CMP messages without encryption when I have
understood correctly. Other certificate issuance protocols are
well-known and provide more security but they are not supported by CMP.

You have found an ambiguity in the CMP-RFC. Any other interpretations?

Furthermore message authentication methods are well-known. Attacks and
threats are well-recognized. Why should a further review of CMC and CMP
not profit from this knowledge?

Juergen  



--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------

[e-mail] wrote:
> 
> In RFC 2510 in section 4.6.1 it clearly states that a MAC based on an
> authentication code
> should be used for the message authentication and integrity.
> 
> In Appendix B section B7 it states that the protectionAlg should be set to
> MSG_SIG_ALG.
> This does not seem consistent.  I am assuming that B7 really meant to say
> MSG_MAC_ALG,
> if this is not the case I have a ton of other questions ...
> 
>                               Mike

--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00730 for ietf-pkix-bks; Mon, 22 Mar 1999 07:39:07 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00726 for <[e-mail]>; Mon, 22 Mar 1999 07:39:01 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id QAA19022 for <[e-mail]>; Mon, 22 Mar 1999 16:45:54 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA96351; Mon, 22 Mar 1999 16:45:43 +0100
Received: by HYDRA with Microsoft Mail id <01BE7483.83AB9330@HYDRA>; Mon, 22 Mar 1999 16:46:21 +0100
Message-ID: <01BE7483.83AB9330@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: RE: Biometrics in Qualified Certificates 
Date: Mon, 22 Mar 1999 16:46:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Short reply,
>Let me just sum up Anders proposal:

>Add new supported attributes to the list in the PersonalData field:

>    photo;                           
>    handWrittenSignature;            

>These attributes should contain:

>        mime-type PrintableString, 
>        body      OctetString

>(Complete definition of attributes has to be done)

Tom Gindins code looked OK to me.  But my ASN.1 sucks so I may be wrong!

>Since this is not my field of expertise I would like opinions from the list
>whether this is a good approach or not. 

ID-card forging becomes much harder.  That should IMO be a sufficient
reason to add support for biometrics. see:
http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

>Please also comment if this should
>be addressed at all. 

Assume that only 2% need this.  Would you then say it should not be there?
I would at least not stop these 2% from doing something that the other 98% are
completely unaffected by.  In analogy with SSNs that will not generate consensus.
The only reason that SSNs in QCs are not controversial is that you named
them dnQualifiers :-)

>Will anyone out there use this in your products and services?

Wrong forum Stefan!

(Although I obviously does not count I will use photos in remote certs in CyberPhone)

>Can attributes be defined with a structured body according to the proposal?

Do you also have a problem with ASN.1  :-)

Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00271 for ietf-pkix-bks; Mon, 22 Mar 1999 06:50:05 -0800 (PST)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA00267 for <[e-mail]>; Mon, 22 Mar 1999 06:50:04 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 22 Mar 1999 07:52:18 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 22 Mar 1999 07:52:08 -0700
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Biometrics in Qualified Certificates
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just an observation concerning signed biometric representations.  Biometrics are based on "good enough" data.  Digital signatures (including signed certs) are based on exactness.

If using the best image, most complete scan, etc. and then signing that, then everything else will fail up to that same level of "exactness" contained in the cert.  I doubt that any biometric data that is less exact enough to "always" be captured in the biometric device will have any authentication value on its own.

It seems that encoding a "master" or most exact biometric in the certificate would still have some value for disseminating the biometric data between biometric systems without alteration enroute, but I do not see a real use for using signed biometric data outside these specialized systems at this time.

I do think that the PKIX certificate profiles and naming should support biometric data encoded into the subject alt name, I just see its use way off in the future.

michael
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00228 for ietf-pkix-bks; Mon, 22 Mar 1999 06:47:30 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA00223 for <[e-mail]>; Mon, 22 Mar 1999 06:47:27 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id PAA26842; Mon, 22 Mar 1999 15:54:24 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Mar 1999 15:55:04 +0100
To: Anders Rundgren <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Biometrics in Qualified Certificates 
Cc: "'[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 mail.proper.com id GAA00225
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me just sum up Anders proposal:

Add new supported attributes to the list in the PersonalData field:

    photo;                           
    handWrittenSignature;            

These attributes should contain:

        mime-type PrintableString, 
        body      OctetString

(Complete definition of attributes has to be done)

Since this is not my field of expertise I would like opinions from the list
whether this is a good approach or not. Please also comment if this should
be addressed at all. 

Will anyone out there use this in your products and services?
Can attributes be defined with a structured body according to the proposal?

/Stefan



At 02:16 PM 3/22/99 +0100, Anders Rundgren wrote:
>Stefan,
>You would save some list-bandwidth by reading my posts more carefully.  So
the
>following is a compilation of previous posts.
>
>>Anders Rundgren wrote:
>>>2. Hash of biometric data?  Biometrics are analog (inexact) objects that
>require
>>>complicated pattern matching algorithms to be verified.  Regardless if it
>is a machine
>>>or human that is doing the pattern matching they must be in clear.
>
>>A hash would work just fine given that you provide the complete biometric
>>data apart from the certificate. You could send a Jpeg picture attached to
>>your document and have a hash of the picture in the cert.
>>This also have the advantage that the cert don't reveal the biometrics.
>
>Although QCs is about the use of digital signatures, the QC spec. will
affect (or it
>will simply be just IGNORED) the format of authentication certificates as
well.  Therefore
>I think that the example you gave is not entirely valid (apart from the
introduction of a non-
>standard and awkward way to transfer identity information).  So may I ask:
>
>Does your local bank clerk read hashed pictures?  Or the police?  Or the
passport control?
>
>And for those who are Directory Aficionados:  Who and when would have
access to the
>TRUE biometrics?   It seems awfully much simpler to let the user handle
>this (how have I already described zillions of times so I won't repeat it)
but actually
>- this decision is outside the scope of the QC draft.
>
>>A hash further would serve very well as a distinguisher stored in the
>>dNQualifier.
>
>This is as far from an SSN you can get as every new photo will generate
>a new hash value.  But as I said earlier: if the deployer wants to do
something that
>you (or in this case I) consider stupid we should only comment on it as long
>as the feature does not jeopardize or affect the "good", "sensible" and
"politically
>correct" usage.
>
>As an analogy,  we will obviously never agree on the use of SSNs (or
rather static bindings)
>and we don't have to either.  I like them, you don't.  No problems!  Let
the market decide!
>
>>If you have any concrete suggestions on how to store biometrics in QC:s
>>please write a proposal
>
>Has already been posted. Tom Gindin / IBM "ASN.1-ized" my crude sample
>
>DisplayableImage ::= SEQUENCE
>    {
>      mime-type PrintableString, 
>      body      OctetString
>  }
>
>Note: According to Peter Gutman there already are OIDs for various
multimedia types
>so the above may be overkill.
>
>My proposal is to add a few commonly used (since 50 years back or so)
biometrics to
>the list of standard QC attribute types.  From the draft:
>
>Complying applications SHALL expect any subset of the following defined
attribute types 
>within a PersonalDataRecord:
>
>countryName;
>givenName;
>surname;
>pseudonym;
>dNQualifier;
>dateOfBirth;
>placeOfBirth;
>gender;
>postalAddress; 
>countryOfCitizenship; 
>countryOfResidence;
>
> +
>
>photo;                               (DisplayableImage)
>handWrittenSignature;             (DisplayableImage)
>
> +
>
>maybe a few other biometrics like fingerprints that are more or less
standardized.
>
>Your QC-colleague Tim Polk should be able to supply you with this
information since NIST
>has indeed standardized fingerprint data.
>
>>and we will see if there is enough support within
>>the community to include it. But I have my doubts.
>
>If you by "community" refer to the IETF and the PKIX-list you are
definitely off-track.
>QCs are of concern far outside the scope of TLS to name an other example.
>
>If you care to read a document in early alpha-stage on why I think it is
fairly easily
>to find powerful supporters for biometric data in certs, please read this:
>
>http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP
>
>which I have prepared in great haste (pardon the grammatical errors) in
order to also
>give our non-ASN.1 readers a chance to see what this is all about.
>
>BTW, has the QC task-force actually talked to FBI and immigration
authorities?
>
>Regards
>
>Anders Rundgren
>Senior Internet e-commerce Architect
>http://www.mobilephones-tng.com
>
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet 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 majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA29285 for ietf-pkix-bks; Mon, 22 Mar 1999 05:08:47 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA29280 for <[e-mail]>; Mon, 22 Mar 1999 05:08:42 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id OAA01046 for <[e-mail]>; Mon, 22 Mar 1999 14:15:37 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id OAA70221; Mon, 22 Mar 1999 14:15:30 +0100
Received: by HYDRA with Microsoft Mail id <01BE746E.87E2B9C0@HYDRA>; Mon, 22 Mar 1999 14:16:08 +0100
Message-ID: <01BE746E.87E2B9C0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, =?iso-8859-1?Q?=27Petra_Gl=F6ckner=27?= <[e-mail]>
Subject: RE: Biometrics in Qualified Certificates 
Date: Mon, 22 Mar 1999 14:16:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
You would save some list-bandwidth by reading my posts more carefully.  So the
following is a compilation of previous posts.

>Anders Rundgren wrote:
>>2. Hash of biometric data?  Biometrics are analog (inexact) objects that
require
>>complicated pattern matching algorithms to be verified.  Regardless if it
is a machine
>>or human that is doing the pattern matching they must be in clear.

>A hash would work just fine given that you provide the complete biometric
>data apart from the certificate. You could send a Jpeg picture attached to
>your document and have a hash of the picture in the cert.
>This also have the advantage that the cert don't reveal the biometrics.

Although QCs is about the use of digital signatures, the QC spec. will affect (or it
will simply be just IGNORED) the format of authentication certificates as well.  Therefore
I think that the example you gave is not entirely valid (apart from the introduction of a non-
standard and awkward way to transfer identity information).  So may I ask:

Does your local bank clerk read hashed pictures?  Or the police?  Or the passport control?

And for those who are Directory Aficionados:  Who and when would have access to the
TRUE biometrics?   It seems awfully much simpler to let the user handle
this (how have I already described zillions of times so I won't repeat it) but actually
- this decision is outside the scope of the QC draft.

>A hash further would serve very well as a distinguisher stored in the
>dNQualifier.

This is as far from an SSN you can get as every new photo will generate
a new hash value.  But as I said earlier: if the deployer wants to do something that
you (or in this case I) consider stupid we should only comment on it as long
as the feature does not jeopardize or affect the "good", "sensible" and "politically
correct" usage.

As an analogy,  we will obviously never agree on the use of SSNs (or rather static bindings)
and we don't have to either.  I like them, you don't.  No problems!  Let the market decide!

>If you have any concrete suggestions on how to store biometrics in QC:s
>please write a proposal

Has already been posted. Tom Gindin / IBM "ASN.1-ized" my crude sample

DisplayableImage ::= SEQUENCE
    {
      mime-type PrintableString, 
      body      OctetString
  }

Note: According to Peter Gutman there already are OIDs for various multimedia types
so the above may be overkill.

My proposal is to add a few commonly used (since 50 years back or so) biometrics to
the list of standard QC attribute types.  From the draft:

Complying applications SHALL expect any subset of the following defined attribute types 
within a PersonalDataRecord:

countryName;
givenName;
surname;
pseudonym;
dNQualifier;
dateOfBirth;
placeOfBirth;
gender;
postalAddress; 
countryOfCitizenship; 
countryOfResidence;

 +

photo;                               (DisplayableImage)
handWrittenSignature;             (DisplayableImage)

 +

maybe a few other biometrics like fingerprints that are more or less standardized.

Your QC-colleague Tim Polk should be able to supply you with this information since NIST
has indeed standardized fingerprint data.

>and we will see if there is enough support within
>the community to include it. But I have my doubts.

If you by "community" refer to the IETF and the PKIX-list you are definitely off-track.
QCs are of concern far outside the scope of TLS to name an other example.

If you care to read a document in early alpha-stage on why I think it is fairly easily
to find powerful supporters for biometric data in certs, please read this:

http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

which I have prepared in great haste (pardon the grammatical errors) in order to also
give our non-ASN.1 readers a chance to see what this is all about.

BTW, has the QC task-force actually talked to FBI and immigration authorities?

Regards

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA28845 for ietf-pkix-bks; Mon, 22 Mar 1999 04:03:04 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA28840 for <[e-mail]>; Mon, 22 Mar 1999 04:03:02 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 1464D4B; Mon, 22 Mar 1999 13:10:00 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id NAA27583; Mon, 22 Mar 1999 13:10:01 +0100
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 1999 13:09:55 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
References: <v04020a09b3183998e653@[128.33.238.181]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:
> 
> Keith,
> 
> Naive question, perhaps, but if I understand you correctly, you want
> processes (or servers) to authenticate each other, irrespective of the
> "person" (if any) that may have started the process, or be at the controls.

I tend to use attribute certs in the situation described by Keith.
Attribute certs contain a DN or an ID of public key certificate.
Therefore an attribute cert binding to a "person" over DN or cert ID is
given.

I would like to consider a similar problem. What is to do if I want to
certifiy a server public key. Who is the subject? Is it the server or
the entity responsible for it? What cert extensions are commonly
recognized in server certificates?

I prefer a human being as subject. All other informations should be
contained in the cert extensions.

Has somebody seen a solution where a separation of duty scheme is mapped
to certs? I mean the case whereby two entities share the responsibility
over one signature key. Any thoughts about this problem?

Juergen

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
-------------------------------------------------------------------- 

> 
> If this is the case, why not be your own CA?  I assume you would know if
> a particular server/ethernet-address/IPAddress binding was correct or not.
> 
> Is there an independent need that these certificates be available through
> (say) Verisign or Thawte?
> 
> ___tony___
> 
> At 03:00 PM 3/19/99 -0600, Keith Johnston wrote:
> >Stephen Kent wrote:
> >
> >> Keith,
> >>
> >> >I am on a project where we want to use digital certificates to
> >> >authenticate various server processes to each other over SSL.  What we'd
> >> >like to do is define a certificate extension that has the name of the
> >> >server in it, and then have each customer create certificates with the
> >> >standard fields (organizaiton, country, etc) set to their information,
> >> >and the extension field set to the name of the server.
> >>
> >> I would stgrongly recommend against creation of an extension for this
> >> purpose. What you seem to want is a cert that identifies a user executing a
> >> process on a server.  If so, then you should issue a cert that has a
> >> subject name with sufficient info to uniquely identify the processes in
> >> question.  X.509 has a naming model that presumes that the subject name
> >> uniquely identifies the subject, period.  If the intent here is to identify
> >> the subject in the context of the server, then one should construct a
> >> subject name that does so.
> >>
> >
> >OK, I see your point - think of the server as a particular user.  And this
> >works fine if the customer has their own CA software - they would be perfectly
> >willing to sign a certificate that has a name like
> >"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
> >doesn't provide a signing service - I was mistaken there) wouldn't know how to
> >prove that you are really running ProcessFooBar on your server, or even what
> >ProcessFooBar is.  So I don't see how this works with an external CA that
> >doesn't understand what it is you are trying to do.  Sure, they can sign
> >certificates with DNS names or a persons name, but a process name?
> >
> >Another alternative we are investigating is allowing each server process to map
> >a certificate distinguished name to a process identity.  This could mean that
> >JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
> >different serial numbers.  Then each process would have a hashtable that maps
> >the serial number to the process name.  Each process could then authenticate to
> >the others.  But that's kind of annoying to have to distribute that map
> >around.  Sure, you could put it in LDAP or on some central server, but then
> >you've got a single point of failure or a complicated caching/replication
> >system.  So putting the process name in the certificate is really, really cool,
> >because all each server needs is a copy of the CA certificate.
> >
> >Thanks for your comments, I look forward to your response.
> >
> >Keith
> >
> >
> >
> 
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL

-- 

with regards


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA26255 for ietf-pkix-bks; Mon, 22 Mar 1999 02:59:45 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA26248 for <[e-mail]>; Mon, 22 Mar 1999 02:59:42 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id MAA23317; Mon, 22 Mar 1999 12:06:20 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Mar 1999 12:07:00 +0100
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: SEIS:  Certificates, Directories, and Distinguished Names
Cc: <[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 mail.proper.com id CAA26252
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

The intension is that if any name form (in Qualified Certificates) serve as
locator of a directory entry, this is the DN hold in the subject field. The
concept of distinguished name (hold in the subject field) and unmistakable
identity (hold in either the subject field or the SubjectAltName ext.) are
explained in section 2.5

Section 2.5 says:

   Distinguished name is originally defined in X.501 [X.501] as a
   representation of a directory name, defined as a construct that iden-
   tifies a particular object from among the set of all objects. An
   object can be assigned a distinguished name without being represented
   by an entry in the Directory, but this name is then the name its
   object entry would have had if it were represented in the Directory.
   In the context of qualified certificates, a distinguished name
   denotes a set of attribute values [X.501] which forms a name that is
   unambiguous within a certain domain that forms either a real or a
   virtual DIT (Directory Information Tree)[X.501]. In the case of sub-
   ject names the domain is assumed to be at least the issuing domain of
   the CA.

And section 3.1.2 continues with:

   The subject field SHALL contain a distinguished name of the subject
   (see 2.5 for definition of distinguished name)

   An unmistakable identity (see 2.5) of the subject(based on registered
   name or a pseudonym name) SHALL be present in the certificate in the
   subject field and/or the PersonalData field in the subjectAltName
   extension (see 3.2.1.)

   If the PersonalData field is empty, the unmistakable identity of the
   subject is determined by just the subject field. If the PersonalData
   field is present, it SHALL contain a complete unmistakable identity
   of the subject. In this case the subject field SHALL still contain a
   complete distinguished name.


So this means that a DN shall ALWAYS be present in the subject field.

Hope this answer your question.

/Stefan


At 03:47 PM 3/19/99 -0700, Bob Jueneman wrote:
>--- Message on the SEIS mailing list ([e-mail])
>
>[Apologies if this is a duplicate. I sent it yesterday, but
>it doesn't seem to have shown up on either list yet.]
>
>The message from Petra Gloeckner illustrates that there is an
>obvious lack of agreement about the semantics of a DN vs.
>the semantics of an alternateSubjectName.
>
>Because of the potential impact on evolving software, I'd like
>to escalate this issue to the PKIX co-chairs, Steve Kent and 
>Warwick Ford, and to the chair of X.509, Hoyt Kesterson, 
>in order to force a expeditious resolution to this issue.
>
>One of these name forms, at least, ought to be usable to 
>retrieve a certificate from a directory, whereas the others,
>although potentially candidates for inclusion in a directory,
>may not represent a real directory entry but may be for
>display purposes to RP software, or for other application 
>purposes.
>
>I believe that it is extremely important that at least one of the 
>multiple name forms that may be carried in a directory reflect
>the primary directory name used to store and retrieve such 
>certificates.  If I start searching a directory, I don't want to
>have to try every name in a certificate looking for other, related 
>certificates.
>
>(For example, I may have received a digital signature
>certificate from someone, and now I want to look up his 
>encryption certificate.  Or maybe my correspondent sent me 
>his encryption certificate, but the key length is too long for
>my US-exportable software to handle.)
>
>As a practical matter, I don't care much one way or the other
>which name form is picked as the primary one, but I very 
>much need to have it nailed down, and quickly.  I would 
>argue, however, that both historical precedent and the
>wording in the standards would argue that the DN should be the
>primary directory index name, and that other names, e.g., for display
>purposes, should be subjectAltNames.
>
>Bob
>
>
>>>> "Petra Gl÷ckner" <[e-mail]> 03/18/99 06:39AM >>>
>
>> I certainly understand that there are lots of certificates
>> containing DNs which don't correspond to entries in ANY
>> directory, much less some well-structured, as-God-intended
>> x.500 directory with X.520 DIT structure and schema.
>> 
>> My point is, and I am agreeing with you to at least a certain
>> extent, that if we continue to throw completely arbitrary
>> name constructs in the DN, we will make it increasingly difficult
>> to ever store or retrieve those certificates in or from a directory.
>> 
>> So my goal was to get people to recognize that the primary
>> purpose of the DN was to facilitate interoperation with a directory.
>> And since there may very well be a proliferation of directories with
>> incompatible DIT structures and schemas, it is necessary to
>> recognize that it is the _subscriber's_ directory that must dictate the
>> DIT structure and schema -- not the CA's, and not the recipient's.
>
>I don't think that the primary purpose of the DName is to facilitate 
>interoperation with a directory. That was the motivation when they 
>defined the X.509v3 certificates, but I think this is not valid anymore.
>
>> Other technical functions such as name subordination may or may
>> not have a role to play with respect to the DN.  They could, but
>> I suspect that it may not be terribly useful in most cases, just
>> because directory names are (unfortunately) not often organized
>> along the lines of organizational boundaries that name subordination
>> assumes.
>> 
>> I agree that when writing application software you cannot always
>> assume that the DN points to an X.500 entry, as one may never have
>> been created.  I would say that it OUGHT to, but it might not.
>> 
>> On the other hand, I believe that it would be WRONG to believe
>> that an alternateSubjectName, in particular, would always point to
>> a certificate, or even to a directory entry of any kind.  Again, perhaps
>> it ought to, but I may have chosen to express my name and organizational
>> structure in a more conventional fashion, perhaps for ease of display and
>> recognition, but without a corresponding entry in any existing directory --
>> not even an alias.
>> 
>> For example, my directory name in Novell's corporate directory in business
>> card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.
>> 
>> But what I would like to have displayed in someone's certificate viewing
>> software would be c=US, o="Novell, Inc.", ou="Network Products Division",
>> ou="Network Security Department", cn="Robert R. Jueneman"
>>
>> Since the purpose of the DN is to convey an entry in the directory, the
>> first name form clearly has to be the DN, and the second name form the
>> alternateSubjectName.  But that second name form is not an entry in the
>> Novell corporate directory,  not even an alias, and not likely to be any
time
>> soon, even if it has the form directoryName.
>
>I disagree, the directoryName of the SubjectAltName has to convey an
>entry 
>in the directory, not necessarily the subject DName. So, IMO you should
>put 
>the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
>directoryName 
>of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
>ou=Network 
>ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman" 
>in the subject DName.
> 
>> I agree that it would be quite reasonable to create an alias for such a
>> name in a directory somewhere, and I would encourage such a practice.
>> I also believe that it may be desirable to include other directory style
>> names as additional alternateSubjectNames, perhaps to support other DIT
>> structures and/or schemas, but I don't believe that the ietf-pkix group
>> is in a position to mandate that a particular alternateSubjectName reflect
>> a real entry in any particular directory.  And whether they mandate it or
>> not, it isn't likely to happen world-wide any time soon.
>> 
>> As for the additional information you may require that go beyond "name"
>> information per se, I would suggest that you make your PersonalData
>> structure a subjectDirectoryAttributes attribute extension (if someone can
>> ever figure out what the semantics of _that_ attribute are supposed to be),
>> or else simply define a new attribute extension.
>> 
>> But in general I would be rather opposed to listing much of the type of
>> information you have suggested in a certificate at all, and certainly
not in
>> a name field.
>
>The PersonalData structure shall contain as much information of a person
>as 
>necessary in order to identify him. You don't have to use all
>attributes!
>
>We have chosen the SubjectAltName instead of the
>subjectDirectoryAttributes 
>extension because the PersonalData structure contains the name of the
>person
>plus any other required identity information to make the name unique.
>But you can easily use any of the attributes defined in the QC-draft,
>which 
>are not necessary to unmistakably identify the person, within the 
>subjectDirectoryAttributes extension since the
>subjectDirectoryAttributes 
>and the PersonalData structure are both a sequence of attribute.
> 
>Petra
>
>PS.: I will be on vacation next week. I'll answer as soon I'm back at
>work.
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA26115 for ietf-pkix-bks; Mon, 22 Mar 1999 02:36:28 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA26111 for <[e-mail]>; Mon, 22 Mar 1999 02:36:26 -0800 (PST)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id LAA22963; Mon, 22 Mar 1999 11:43:11 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 22 Mar 1999 11:43:50 +0100
To: Anders Rundgren <[e-mail]>, "[e-mail]" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Biometrics in Qualified Certificates 
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 mail.proper.com id CAA26112
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

At 09:17 AM 3/19/99 +0100, Anders Rundgren wrote:
>2. Hash of biometric data?  Biometrics are analog (inexact) objects that
require
>complicated pattern matching algorithms to be verified.  Regardless if it
is a machine
>or human that is doing the pattern matching they must be in clear.

A hash would work just fine given that you provide the complete biometric
data apart from the certificate. You could send a Jpeg picture attached to
your document and have a hash of the picture in the cert.

This also have the advantage that the cert don't reveal the biometrics.
A hash further would serve very well as a distinguisher stored in the
dNQualifier.

If you have any concrete suggestions on how to store biometrics in QC:s
please write a proposal and we will see if there is enough support within
the community to include it. But I have my doubts.

/Stefan 


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA25851 for ietf-pkix-bks; Mon, 22 Mar 1999 01:51:53 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA25845 for <[e-mail]>; Mon, 22 Mar 1999 01:51:47 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id KAA12016 for <[e-mail]>; Mon, 22 Mar 1999 10:58:10 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA53413; Mon, 22 Mar 1999 10:57:01 +0100
Received: by HYDRA with Microsoft Mail id <01BE7452.CC315D00@HYDRA>; Mon, 22 Mar 1999 10:57:37 +0100
Message-ID: <01BE7452.CC315D00@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, "[e-mail]" <[e-mail]>, "'Andrew Probert'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'STEPHAN ALMQVIST'" <[e-mail]>, =?iso-8859-1?Q?=27Petra_Gl?= =?iso-8859-1?Q?=F6ckner=27?= <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Subject: QC Biometric Support.  Was: Location and Identification
Date: Mon, 22 Mar 1999 10:57:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew.
>I think the discussion at the moment is philisophically about whether to put
>some of this biometrics stuff online at all.

>In our country, the push for a national identity card was totally sunk upon
>issues of privacy.  We don't even allow so much as the US social security
>card style.  Also, the only people with fingerprint databases are the police
>and only for convicted felons.  

>I believe whilst it is technically feasible to putsome of this biometrics
>online, it is not commercially feasible or socially acceptable.

This is Australian POLITICS and not globally acknowledged FACTS.   Should IMO have
no impact on the specification of QCs.  It is a deployment issue if you use
SSNs and/or biometrics.

If you care to read a document in early alpha-stage on why I think it is fairly easily
to find powerful supporters for biometric data in certs, please read this:

http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

which I have prepared in great haste in order to also give our
non-ASN.1 readers a chance to see what it is all about.

BTW, has the QC task-force actually talked to FBI and immigration authorities?

Regards
Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA24233 for ietf-pkix-bks; Sun, 21 Mar 1999 21:34:58 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA24229 for <[e-mail]>; Sun, 21 Mar 1999 21:34:55 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA18428; Mon, 22 Mar 1999 17:41:35 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92208129503378>; Mon, 22 Mar 1999 17:41:35 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Pictures in QCs - No problems!
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 22 Mar 1999 17:41:35 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren <[e-mail]> writes:
 
>Tom Gindin wrote:
>>While Anders admittedly knows little about ASN.1, he may be onto
>>something useful here.  What would be wrong with defining a non-critical
>>extension called displayableImage with syntax
>>DisplayableImage ::= SEQUENCE {
>>     mime-type PrintableString,          -- I apologize if it's really IA5String
>>     body      OctetString
>>}
>>     and then trying to get the browsers to support it?  They don't do so
>>yet, of course, but it seems like a good idea and not incredibly difficult.
 
>STEPHEN, my reference to browsers was more to say that this data can be shown
>(rendered) in a browser but of course the certs themselves must be DECODED
>first.  The point is, DisplayableImage is a useful way to express Pictures and
>handwritten signatures in a cert.
 
I've already had to so something like this before for the MPEG-of-cat 
certificate I created (available from 
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave.der, signed by 
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave_ca.der), why not just handle 
stuff like this as an otherName?  I used the MPEG-1 OID to identify it, and 
the MPEG itself as the value.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20736 for ietf-pkix-bks; Sun, 21 Mar 1999 14:02:55 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20732 for <[e-mail]>; Sun, 21 Mar 1999 14:02:51 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <GKMRRFHF>; Mon, 22 Mar 1999 08:08:28 +1000
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A6363@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Location and Identification
Date: Mon, 22 Mar 1999 08:08:24 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my opinion, some directories can be made as secure as any other database
technology e.g. SQL.  Directories as a form of OO database, with X.500
access controls actually allow protection over trees, subtrees, object types
even down to attributes based upon the name you choose to login, including
strong auth login as well.

I think the discussion at the moment is philisophically about whether to put
some of this biometrics stuff online at all.

In our country, the push for a national identity card was totally sunk upon
issues of privacy.  We don't even allow so much as the US social security
card style.  Also, the only people with fingerprint databases are the police
and only for convicted felons.  

I believe whilst it is technically feasible to putsome of this biometrics
online, it is not commercially feasible or socially acceptable.

A more natural approach is to consider that most computer sytems have access
control mechansms.  RACF, ACF2, Unix file permissions, ACLs etc.  These are
all closed and proprietary mechansisms.  Attribute Certficates can be used
to provide open mechanisms that are analogous, for distributed systems.  I
think personal identity and access to servers that allow privilige are
technically and socially acceptable.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Bob Jueneman [SMTP:[e-mail]]
> Sent:	Saturday, March 20, 1999 6:36 AM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Location and Identification
> 
> I think Tony has some interesting points, so I'll take him up on 
> forwarding them to the list, then respond.
> 
> Bob
> 
> >>> Tony Bartoletti <[e-mail]> 03/18/99 05:47PM >>>
> Bob,
> 
> I am a bit reticent to jump into the threads with this, but I offer
> it to you to use as you wish (forward, edit, consider, whatever.)
> My thoughts here are in response to several recent threads.
>  
> I don't pretend to know the intimate details of DNs, AltNames, etc.,
> (collectively "Name-Like-Things") and the precise handling expected
> of them by X.509-conforming software.  Nor am I expert at the varied
> contents (keys, et al) that may be bound into the certificates,
> (collectively, "Ident-Challenge-Data").
> 
> I see from these discussions at least two broad and (in my ideal)
> orthogonal dimensions that people intend for them to serve:
> 
> 1.  Location (of individual/cert or their issuer)
> 
>     Ranging from Global-Public-Location to Proprietary-Location
> 
> 2.  Secured Identification (of located item.  "Ident-Challenge-Data")
> 
>     Ranging from Public/Private Keys to Biometric Data.
> 
> I think it is useful to consider this (simplified) "quad-chart"
> and characterize various schemes/applications accordingly:
> 
>   FUNCTION:    |  Object Location         | Object Identification
>   METHOD:      |  (via Name-Like-Thing)   | (via Challenge-Data)
>   ---------------------------------------------------------------
>   (subclass)   |  Global Public Locator   | Keys/Issuer-Keys
>   ---------------------------------------------------------------
>   (subclass)   |  Proprietary Locator     | Biometric Data/Hash
>   ---------------------------------------------------------------
> 
> Note:  I do not intend for these "rows" to indicate correspondence.
> That is, one could deploy a system where a "Proprietary Locator" is
> used to retrieve "Keys/Issuer-Keys" Challenge-Data, (basically, the
> current situation with key-certificates) or (God Forbid) a system
> where a "Global Public Locator" can retrieve an individual's
> Biometric Challenge Data.
> 
> Furthermore, in each possible case, one can imagine a protocol
> that either does or does not require the "data-owner" to cooperate
> in the final step of identification (say, you believe you have
> located someones challenge-data, but can only see a piece of it
> large enough to query them to release the remainder, and can
> then proceed with a full challenge if they concur.)
> 
> This is how the telephone white-pages work.  If I find (say) three
> "Bob Jueneman" I can call each one.  If I say "Are you the Bob that
> posts to the PKIX list," you can either reply with additional
> confirming data, or say "Sorry, this is Jueneman's Plumbing Supplies,
> we only carry PVC, no 'PKIX'" just to avoid me.  
> 
> If I may characterize the discussions of late, I see some threads
> hoping to elevate (?) Proprietary Locators to Global Public Locators,
> (Simon says, "Lets build the X.500 directory of Babel") and others
> to extend certified content from Keys to Biometrics, for instance.
> 
> Worse, I also see a blurring of the functions themselves, to wit,
> "Let a secure directory hold established name-hierarchies that map
> precisely to the material world, thus Existence-In-Directory
> implies Identification, (delete one challenge-response.)"
>        
> As sexy and convenient as it may seem to overload these functions,
> especially Location with Identification, such a scheme would be
> both unstable and dangerous (the ultimate bad combination).
> 
> When someone says "We can make the directories secure" I cringe.
> How secure?  For what?
> 
> The public telephone white-pages are secure enough for their purpose;
> if a hacker or insider makes malicious modifications, it is just an
> inconvenience for the most part.  If a directory holding my keys
> is compromised, more hassle, but I can revoke and be re-issued.
> 
> I don't know if nature allows a directory secure enough to house
> my biometric data, unless it is purely encrypted blobs to the
> root directory operators, and I have secure control of the keys.
> 
> A Final Thought:  I am beginning to wonder if I should start a
> global movement to have everyone capture all of their biometric
> data (fingerprints, retinals, DNA sequences, etc) and publish
> them in a giant, open public repository.  Would this not serve
> make such data effectively worthless?  The only way this data
> can be used to effectively "impersonate" me, is if there is a
> reasonable assumption on the part of the relying party that
> such information is uniquely held.  Destroy this assumption,
> and the ability to impersonate disappears, no?
> 
> ___tony___
> 
> 
>  
> 
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20725 for ietf-pkix-bks; Sun, 21 Mar 1999 14:02:14 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20721 for <[e-mail]>; Sun, 21 Mar 1999 14:02:03 -0800 (PST)
Received: from [128.33.238.110] (TC110.BBN.COM [128.33.238.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id RAA12043; Sun, 21 Mar 1999 17:08:56 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a05b31b08d38bd8@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Sun, 21 Mar 1999 15:43:45 -0500
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SEIS:  Regarding "Given names"
Cc: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

>I agree that would be possible, to issue multiple certificates and to put
>appropriate ID information into each certificate, although it may lead
>to an enormous proliferation of certificates -- one for each unique
>application, at worst.  (Of course if you sell certificates, the more the
>merrier! :-)

well,  we sell CAs to enterprises without a per-cert charge, so I ought not
be accused of bias on that basis :-).  However, we are also in the service
business, ...

>But with respect to the "additional security problems associated with
>directories," I was not referring to directories operated by some
>independent third-party, but to enterprise directories that are operated
>by the same people that administer the various applications.

My security concerns are more technical and largely applicable even if an
enterprise is operating the directory for itself.  Security problems
abound, IMHO, because of the complexity of the directory application, the
need to grant varying degree of online access, the use of OS platforms with
demonstrablyt poor security, etc.

>If I authenticate a user using one primary certificate, and then look
>up additional names forms and/or other attributes in the enterprise directory,
>that association can certainly be as trusted as the applications themselves,
>as they are probably managed by the same sets of people.

Not necssarily.  Poor security at the directory could undermine better
security for apps that rely on it, depending on how ine uses the directory.
A signed CRL is pretty safe even in a not-so-secure directoryt.  But if
someone suggests using a directory attribute to verify certificate status,
rather than performing the validation process, then things have gotten a
lot worse.

>For that matter, the same basic sets of people are probably operating the
>RA functions that are used to issue the certificates as well.

It depends.  In some cases one distributes the RA functions throughout an
organization, but centralizes (or outsources) the CA function. Those who
operate the directory may be yet another set of people.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA07013 for ietf-pkix-bks; Sat, 20 Mar 1999 00:49:41 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA07009 for <[e-mail]>; Sat, 20 Mar 1999 00:49:39 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id JAA01884 for <[e-mail]>; Sat, 20 Mar 1999 09:56:28 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA61840; Sat, 20 Mar 1999 09:56:16 +0100
Received: by HYDRA with Microsoft Mail id <01BE72B7.FD850F10@HYDRA>; Sat, 20 Mar 1999 09:56:57 +0100
Message-ID: <01BE72B7.FD850F10@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, =?iso-8859-1?Q?=27Petra_Gl=F6ckner=27?= <[e-mail]>
Subject: Pictures in QCs - No problems!
Date: Sat, 20 Mar 1999 09:56:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:
>  While Anders admittedly knows little about ASN.1, he may be onto
>  something useful here.  What would be wrong with defining a non-critical
>  extension called displayableImage with syntax
>  DisplayableImage ::= SEQUENCE {
>       mime-type PrintableString,          -- I apologize if it's really
>  IA5String
>       body      OctetString
>  }
>       and then trying to get the browsers to support it?  They don't do so
>  yet, of course, but it seems like a good idea and not incredibly difficult.

Thanx Tom for filling in the missing ASN.1!  This was of course exactly what
I meant.

A few clarifications: 

STEPHEN, my reference to browsers was more to say that this data
can be shown (rendered) in a browser but of course the certs themselves must
be DECODED first.  The point is, DisplayableImage is a useful way to express
Pictures and handwritten signatures in a cert.

TOM, the thing you mention regarding non-critical extension is though something
that I would like to do different.  I want a few common biometrics to be added to the
list of standard QC attribute types.  From the draft:

Complying applications SHALL expect any subset of the following defined attribute types 
within a PersonalDataRecord:

countryName;
givenName;
surname;
pseudonym;
dNQualifier;
dateOfBirth;
placeOfBirth;
gender;
postalAddress; 
countryOfCitizenship; 
countryOfResidence;

 +

photo;
handWrittenSignature;

 +

maybe a few other biometrics like fingerprints that are more or less standardized.


                   P  O  L  I  T  C  S  !

Regarding the political aspects of the contents of certs including SSNs and Biometrics,
and the differences in opinions on how PUBLIC Key Infrastructure should be interpreted,
and the sometimes claimed need for global directories I think that we should have this
discussion somewhere else as it must be outside the scope of IETF to judge what you
can do or not do as long as it is not technically inferior.

Politically inferior solutions are market and legislation issues.

I personally don't mind a discussion or two so feel free to mail me!

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA23206 for ietf-pkix-bks; Fri, 19 Mar 1999 18:47:33 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA23202 for <[e-mail]>; Fri, 19 Mar 1999 18:47:32 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id SAA12550; Fri, 19 Mar 1999 18:54:18 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Mar 1999 18:54:09 -0800
To: Keith Johnston <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <v04020a09b3183998e653@[128.33.238.181]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Keith,

Naive question, perhaps, but if I understand you correctly, you want
processes (or servers) to authenticate each other, irrespective of the
"person" (if any) that may have started the process, or be at the controls.

If this is the case, why not be your own CA?  I assume you would know if
a particular server/ethernet-address/IPAddress binding was correct or not.

Is there an independent need that these certificates be available through
(say) Verisign or Thawte?

___tony___

At 03:00 PM 3/19/99 -0600, Keith Johnston wrote:
>Stephen Kent wrote:
>
>> Keith,
>>
>> >I am on a project where we want to use digital certificates to
>> >authenticate various server processes to each other over SSL.  What we'd
>> >like to do is define a certificate extension that has the name of the
>> >server in it, and then have each customer create certificates with the
>> >standard fields (organizaiton, country, etc) set to their information,
>> >and the extension field set to the name of the server.
>>
>> I would stgrongly recommend against creation of an extension for this
>> purpose. What you seem to want is a cert that identifies a user executing a
>> process on a server.  If so, then you should issue a cert that has a
>> subject name with sufficient info to uniquely identify the processes in
>> question.  X.509 has a naming model that presumes that the subject name
>> uniquely identifies the subject, period.  If the intent here is to identify
>> the subject in the context of the server, then one should construct a
>> subject name that does so.
>>
>
>OK, I see your point - think of the server as a particular user.  And this
>works fine if the customer has their own CA software - they would be perfectly
>willing to sign a certificate that has a name like
>"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
>doesn't provide a signing service - I was mistaken there) wouldn't know how to
>prove that you are really running ProcessFooBar on your server, or even what
>ProcessFooBar is.  So I don't see how this works with an external CA that
>doesn't understand what it is you are trying to do.  Sure, they can sign
>certificates with DNS names or a persons name, but a process name?
>
>Another alternative we are investigating is allowing each server process to map
>a certificate distinguished name to a process identity.  This could mean that
>JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
>different serial numbers.  Then each process would have a hashtable that maps
>the serial number to the process name.  Each process could then authenticate to
>the others.  But that's kind of annoying to have to distribute that map
>around.  Sure, you could put it in LDAP or on some central server, but then
>you've got a single point of failure or a complicated caching/replication
>system.  So putting the process name in the certificate is really, really cool,
>because all each server needs is a copy of the CA certificate.
>
>Thanks for your comments, I look forward to your response.
>
>Keith
>
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17654 for ietf-pkix-bks; Fri, 19 Mar 1999 17:24:42 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA17648 for <[e-mail]>; Fri, 19 Mar 1999 17:24:40 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id RAA28368; Fri, 19 Mar 1999 17:31:27 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 19 Mar 1999 17:31:18 -0800
To: "Bob Jueneman" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Location and Identification
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:19 PM 3/19/99 -0700, Bob Jueneman wrote, in part:
>Tony, just a couple of observations.
>
[snip]
>With respect to the biometric identifiers, my assumption is that 
>if these mechanisms are to be at all useful for use at a distance
>(as opposed to at an ATM machine, for example), the biometric 
>template must be public, in the same sense that a public key is
>public.

Odd.  I think of an ATM machine as "at-a-distance", since the
local input must be compared to something stored "far away".
Perhaps your intent is to say that the "data-capture" system,
being embedded in the guts of the armored ATM machine, cannot
thus be spoofed at the point-of-capture.

My point is, I imagine 10 years from now, one could easily create
a "glove" with another persons fingerprints using photo-lithography
and latex, given the fingerprint images.  I know there are other
technologies to help prevent this (temperature, surface capilliaries)
but then just wait a few more years...

>But in order to make this at all feasible, it is ESSENTIAL that the 
>transformation from the recorded biometric indicia produce a
>one-way mapping to the template, so that the biometric 
>measurement itself cannot be compromised.  
>
>In other words, given the template, it must be computationally 
>infeasible to produce some biometric indicia, either real or
>artificially constructed, that would satisfy the template.

I'm not certain of the definition of "template" in this context.
I imagine taking a "heuristic-hash" of my thumbprint.  That is,
the "hash algorithm" is public, one certainly cannot begin with
the "hash" and thus construct "fingerprint data" (one way), and
yet slightly distorted images of my thumbprint will still yield
(effectively) the same hash.  Is this the gist of it?
 
>Although you might include a JPEG photo of the user in the 
>certificate for comparison at a point of sale terminal, you 
>certainly wouldn't want to include a JPEG copy of your
>fingerprint, nor a digitized copy of your handwritten signature,
>because of the obvious ease with which that data could be 
>extracted and used for some other purpose.
>
>Bob

Well, my fear is that it will become trivial to "lift" prints
from, say, soda cans.  If I place a poster on a bulletin
board in a supermarket, with big print that says WARNING,
followed by print underneath so small that people will have
to come up close to read it, then I can embed a tiny camera
behind a tiny hole in the poster, triggered by one of those
tiny radar-proximity chips, and thus capture retinal data.

Most important, we often seem to design systems to protect
us from the 98% of us who are already honest enough not to
cheat us, and inadvertantly strengthen the hand of those
sophisticated criminals who will spoof authentications
and thus be judged more solidly "authentic" in the process.

Out of curiosity, what do you think would happen if everyone
posted crisp images of their fingerprints and retinas to
the usenet newsgroup "alt.kill.biometrics"?

Of what use can it be to have another's fingerprints if it
is assumed that anyone can spoof them?

(There is no such newsgroup, but I might start one;)

___tony___
 
>
>>>> Tony Bartoletti <[e-mail]> 03/18/99 05:47PM >>>
>Bob,
>
>I am a bit reticent to jump into the threads with this, but I offer
>it to you to use as you wish (forward, edit, consider, whatever.)
>My thoughts here are in response to several recent threads.
> 
>I don't pretend to know the intimate details of DNs, AltNames, etc.,
>(collectively "Name-Like-Things") and the precise handling expected
>of them by X.509-conforming software.  Nor am I expert at the varied
>contents (keys, et al) that may be bound into the certificates,
>(collectively, "Ident-Challenge-Data").
>
>I see from these discussions at least two broad and (in my ideal)
>orthogonal dimensions that people intend for them to serve:
>
>1.  Location (of individual/cert or their issuer)
>
>    Ranging from Global-Public-Location to Proprietary-Location
>
>2.  Secured Identification (of located item.  "Ident-Challenge-Data")
>
>    Ranging from Public/Private Keys to Biometric Data.
>
>I think it is useful to consider this (simplified) "quad-chart"
>and characterize various schemes/applications accordingly:
>
>  FUNCTION:    |  Object Location         | Object Identification
>  METHOD:      |  (via Name-Like-Thing)   | (via Challenge-Data)
>  ---------------------------------------------------------------
>  (subclass)   |  Global Public Locator   | Keys/Issuer-Keys
>  ---------------------------------------------------------------
>  (subclass)   |  Proprietary Locator     | Biometric Data/Hash
>  ---------------------------------------------------------------
>
>Note:  I do not intend for these "rows" to indicate correspondence.
>That is, one could deploy a system where a "Proprietary Locator" is
>used to retrieve "Keys/Issuer-Keys" Challenge-Data, (basically, the
>current situation with key-certificates) or (God Forbid) a system
>where a "Global Public Locator" can retrieve an individual's
>Biometric Challenge Data.
>
>Furthermore, in each possible case, one can imagine a protocol
>that either does or does not require the "data-owner" to cooperate
>in the final step of identification (say, you believe you have
>located someones challenge-data, but can only see a piece of it
>large enough to query them to release the remainder, and can
>then proceed with a full challenge if they concur.)
>
>This is how the telephone white-pages work.  If I find (say) three
>"Bob Jueneman" I can call each one.  If I say "Are you the Bob that
>posts to the PKIX list," you can either reply with additional
>confirming data, or say "Sorry, this is Jueneman's Plumbing Supplies,
>we only carry PVC, no 'PKIX'" just to avoid me.  
>
>If I may characterize the discussions of late, I see some threads
>hoping to elevate (?) Proprietary Locators to Global Public Locators,
>(Simon says, "Lets build the X.500 directory of Babel") and others
>to extend certified content from Keys to Biometrics, for instance.
>
>Worse, I also see a blurring of the functions themselves, to wit,
>"Let a secure directory hold established name-hierarchies that map
>precisely to the material world, thus Existence-In-Directory
>implies Identification, (delete one challenge-response.)"
>       
>As sexy and convenient as it may seem to overload these functions,
>especially Location with Identification, such a scheme would be
>both unstable and dangerous (the ultimate bad combination).
>
>When someone says "We can make the directories secure" I cringe.
>How secure?  For what?
>
>The public telephone white-pages are secure enough for their purpose;
>if a hacker or insider makes malicious modifications, it is just an
>inconvenience for the most part.  If a directory holding my keys
>is compromised, more hassle, but I can revoke and be re-issued.
>
>I don't know if nature allows a directory secure enough to house
>my biometric data, unless it is purely encrypted blobs to the
>root directory operators, and I have secure control of the keys.
>
>A Final Thought:  I am beginning to wonder if I should start a
>global movement to have everyone capture all of their biometric
>data (fingerprints, retinals, DNA sequences, etc) and publish
>them in a giant, open public repository.  Would this not serve
>make such data effectively worthless?  The only way this data
>can be used to effectively "impersonate" me, is if there is a
>reasonable assumption on the part of the relying party that
>such information is uniquely held.  Destroy this assumption,
>and the ability to impersonate disappears, no?
>
>___tony___
>
>
> 
>
>Tony Bartoletti                                             LL
>Center for Information Operations and Assurance          LL LL
>Lawrence Livermore National Laboratory                LL LL LL
>PO Box 808, L - 303                                   LL LL LL
>Livermore, CA 94551-9900                              LL LL LLLLLLLL
>phone: [phone]   fax: [phone]               LL LLLLLLLL
>email: [e-mail]                                   LLLLLLLL
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06684 for ietf-pkix-bks; Fri, 19 Mar 1999 14:41:56 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA06676 for <[e-mail]>; Fri, 19 Mar 1999 14:41:55 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 19 Mar 1999 15:48:12 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 19 Mar 1999 15:47:50 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Certificates, Directories, and Distinguished Names
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 mail.proper.com id OAA06678
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Apologies if this is a duplicate. I sent it yesterday, but
it doesn't seem to have shown up on either list yet.]

The message from Petra Gloeckner illustrates that there is an
obvious lack of agreement about the semantics of a DN vs.
the semantics of an alternateSubjectName.

Because of the potential impact on evolving software, I'd like
to escalate this issue to the PKIX co-chairs, Steve Kent and 
Warwick Ford, and to the chair of X.509, Hoyt Kesterson, 
in order to force a expeditious resolution to this issue.

One of these name forms, at least, ought to be usable to 
retrieve a certificate from a directory, whereas the others,
although potentially candidates for inclusion in a directory,
may not represent a real directory entry but may be for
display purposes to RP software, or for other application 
purposes.

I believe that it is extremely important that at least one of the 
multiple name forms that may be carried in a directory reflect
the primary directory name used to store and retrieve such 
certificates.  If I start searching a directory, I don't want to
have to try every name in a certificate looking for other, related 
certificates.

(For example, I may have received a digital signature
certificate from someone, and now I want to look up his 
encryption certificate.  Or maybe my correspondent sent me 
his encryption certificate, but the key length is too long for
my US-exportable software to handle.)

As a practical matter, I don't care much one way or the other
which name form is picked as the primary one, but I very 
much need to have it nailed down, and quickly.  I would 
argue, however, that both historical precedent and the
wording in the standards would argue that the DN should be the
primary directory index name, and that other names, e.g., for display
purposes, should be subjectAltNames.

Bob


>>> "Petra Gl÷ckner" <[e-mail]> 03/18/99 06:39AM >>>

> I certainly understand that there are lots of certificates
> containing DNs which don't correspond to entries in ANY
> directory, much less some well-structured, as-God-intended
> x.500 directory with X.520 DIT structure and schema.
> 
> My point is, and I am agreeing with you to at least a certain
> extent, that if we continue to throw completely arbitrary
> name constructs in the DN, we will make it increasingly difficult
> to ever store or retrieve those certificates in or from a directory.
> 
> So my goal was to get people to recognize that the primary
> purpose of the DN was to facilitate interoperation with a directory.
> And since there may very well be a proliferation of directories with
> incompatible DIT structures and schemas, it is necessary to
> recognize that it is the _subscriber's_ directory that must dictate the
> DIT structure and schema -- not the CA's, and not the recipient's.

I don't think that the primary purpose of the DName is to facilitate 
interoperation with a directory. That was the motivation when they 
defined the X.509v3 certificates, but I think this is not valid anymore.

> Other technical functions such as name subordination may or may
> not have a role to play with respect to the DN.  They could, but
> I suspect that it may not be terribly useful in most cases, just
> because directory names are (unfortunately) not often organized
> along the lines of organizational boundaries that name subordination
> assumes.
> 
> I agree that when writing application software you cannot always
> assume that the DN points to an X.500 entry, as one may never have
> been created.  I would say that it OUGHT to, but it might not.
> 
> On the other hand, I believe that it would be WRONG to believe
> that an alternateSubjectName, in particular, would always point to
> a certificate, or even to a directory entry of any kind.  Again, perhaps
> it ought to, but I may have chosen to express my name and organizational
> structure in a more conventional fashion, perhaps for ease of display and
> recognition, but without a corresponding entry in any existing directory --
> not even an alias.
> 
> For example, my directory name in Novell's corporate directory in business
> card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.
> 
> But what I would like to have displayed in someone's certificate viewing
> software would be c=US, o="Novell, Inc.", ou="Network Products Division",
> ou="Network Security Department", cn="Robert R. Jueneman"
>
> Since the purpose of the DN is to convey an entry in the directory, the
> first name form clearly has to be the DN, and the second name form the
> alternateSubjectName.  But that second name form is not an entry in the
> Novell corporate directory,  not even an alias, and not likely to be any time
> soon, even if it has the form directoryName.

I disagree, the directoryName of the SubjectAltName has to convey an
entry 
in the directory, not necessarily the subject DName. So, IMO you should
put 
the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
directoryName 
of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
ou=Network 
ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman" 
in the subject DName.
 
> I agree that it would be quite reasonable to create an alias for such a
> name in a directory somewhere, and I would encourage such a practice.
> I also believe that it may be desirable to include other directory style
> names as additional alternateSubjectNames, perhaps to support other DIT
> structures and/or schemas, but I don't believe that the ietf-pkix group
> is in a position to mandate that a particular alternateSubjectName reflect
> a real entry in any particular directory.  And whether they mandate it or
> not, it isn't likely to happen world-wide any time soon.
> 
> As for the additional information you may require that go beyond "name"
> information per se, I would suggest that you make your PersonalData
> structure a subjectDirectoryAttributes attribute extension (if someone can
> ever figure out what the semantics of _that_ attribute are supposed to be),
> or else simply define a new attribute extension.
> 
> But in general I would be rather opposed to listing much of the type of
> information you have suggested in a certificate at all, and certainly not in
> a name field.

The PersonalData structure shall contain as much information of a person
as 
necessary in order to identify him. You don't have to use all
attributes!

We have chosen the SubjectAltName instead of the
subjectDirectoryAttributes 
extension because the PersonalData structure contains the name of the
person
plus any other required identity information to make the name unique.
But you can easily use any of the attributes defined in the QC-draft,
which 
are not necessary to unmistakably identify the person, within the 
subjectDirectoryAttributes extension since the
subjectDirectoryAttributes 
and the PersonalData structure are both a sequence of attribute.
 
Petra

PS.: I will be on vacation next week. I'll answer as soon I'm back at
work.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02582 for ietf-pkix-bks; Fri, 19 Mar 1999 13:37:22 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02578 for <[e-mail]>; Fri, 19 Mar 1999 13:37:21 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA22193; Fri, 19 Mar 1999 13:39:52 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA20544; Fri, 19 Mar 1999 13:43:32 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRA3MYZ>; Fri, 19 Mar 1999 13:43:33 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Updated Project List for Minutes
Date: Fri, 19 Mar 1999 13:43:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)
		Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
		Approved as Informational RFC
HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) 
		Approved as Proposed Standard
LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
		Approved as Proposed Standard
LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt)
		Approved as Proposed Standard
OCSP (draft-ietf-pkix-ocsp-05.txt)
		Approved as Proposed Standard
CMP (RFC 2510)
		Approved as Proposed Standard
CRMF (RFC 2511)
		Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
		Approved as Informational RFC

PKIX WORK IN PROGRESS

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
		New draft to be issued for WG last call shortly
CMC (draft-ietf-pkix-cmc-02.txt)
		Under WG review
Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
		Under WG review
Qualified Certificates (draft-ietf-santesson-qc-01.txt)
		Under WG review
CMMF (draft-ietf-pkix-cmmf-02.txt)
		This item to be dropped from the program 
Time Stamp (draft-ietf-pkix-time-stamp-00.txt) 
		Under WG review
DCS (draft-ietf-pkix-dcs-00.txt)
		Under WG review
Web-Based Integrated CA Services Protocol (draft-sakurai-pkix-icap-01.txt)
	Submitted for WG consideration

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel [phone] x225; Fax [phone]
[e-mail];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00930 for ietf-pkix-bks; Fri, 19 Mar 1999 13:13:12 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA00925 for <[e-mail]>; Fri, 19 Mar 1999 13:13:11 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 19 Mar 1999 14:19:27 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 19 Mar 1999 14:19:09 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Location and Identification
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 mail.proper.com id NAA00926
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony, just a couple of observations.

With regard to location, although there certainly will be completely
proprietary, closed-PKI systems, and probably some global-public
directories also, the most interesting cases are going to be the
in-between ones.

I can certainly imagine a case where a company has its corporate 
directory servers located inside their firewall, but certain portions of 
their directory will be replicated to public servers located outside 
the firewall.  In fact, I expect this case to be quite common within
the next few years, and that is why I've been trying to focus on 
how to find those directories.

With respect to the biometric identifiers, my assumption is that 
if these mechanisms are to be at all useful for use at a distance
(as opposed to at an ATM machine, for example), the biometric 
template must be public, in the same sense that a public key is
public.

But in order to make this at all feasible, it is ESSENTIAL that the 
transformation from the recorded biometric indicia produce a
one-way mapping to the template, so that the biometric 
measurement itself cannot be compromised.  

In other words, given the template, it must be computationally 
infeasible to produce some biometric indicia, either real or
artificially constructed, that would satisfy the template.

Although you might include a JPEG photo of the user in the 
certificate for comparison at a point of sale terminal, you 
certainly wouldn't want to include a JPEG copy of your
fingerprint, nor a digitized copy of your handwritten signature,
because of the obvious ease with which that data could be 
extracted and used for some other purpose.

Bob



>>> Tony Bartoletti <[e-mail]> 03/18/99 05:47PM >>>
Bob,

I am a bit reticent to jump into the threads with this, but I offer
it to you to use as you wish (forward, edit, consider, whatever.)
My thoughts here are in response to several recent threads.
 
I don't pretend to know the intimate details of DNs, AltNames, etc.,
(collectively "Name-Like-Things") and the precise handling expected
of them by X.509-conforming software.  Nor am I expert at the varied
contents (keys, et al) that may be bound into the certificates,
(collectively, "Ident-Challenge-Data").

I see from these discussions at least two broad and (in my ideal)
orthogonal dimensions that people intend for them to serve:

1.  Location (of individual/cert or their issuer)

    Ranging from Global-Public-Location to Proprietary-Location

2.  Secured Identification (of located item.  "Ident-Challenge-Data")

    Ranging from Public/Private Keys to Biometric Data.

I think it is useful to consider this (simplified) "quad-chart"
and characterize various schemes/applications accordingly:

  FUNCTION:    |  Object Location         | Object Identification
  METHOD:      |  (via Name-Like-Thing)   | (via Challenge-Data)
  ---------------------------------------------------------------
  (subclass)   |  Global Public Locator   | Keys/Issuer-Keys
  ---------------------------------------------------------------
  (subclass)   |  Proprietary Locator     | Biometric Data/Hash
  ---------------------------------------------------------------

Note:  I do not intend for these "rows" to indicate correspondence.
That is, one could deploy a system where a "Proprietary Locator" is
used to retrieve "Keys/Issuer-Keys" Challenge-Data, (basically, the
current situation with key-certificates) or (God Forbid) a system
where a "Global Public Locator" can retrieve an individual's
Biometric Challenge Data.

Furthermore, in each possible case, one can imagine a protocol
that either does or does not require the "data-owner" to cooperate
in the final step of identification (say, you believe you have
located someones challenge-data, but can only see a piece of it
large enough to query them to release the remainder, and can
then proceed with a full challenge if they concur.)

This is how the telephone white-pages work.  If I find (say) three
"Bob Jueneman" I can call each one.  If I say "Are you the Bob that
posts to the PKIX list," you can either reply with additional
confirming data, or say "Sorry, this is Jueneman's Plumbing Supplies,
we only carry PVC, no 'PKIX'" just to avoid me.  

If I may characterize the discussions of late, I see some threads
hoping to elevate (?) Proprietary Locators to Global Public Locators,
(Simon says, "Lets build the X.500 directory of Babel") and others
to extend certified content from Keys to Biometrics, for instance.

Worse, I also see a blurring of the functions themselves, to wit,
"Let a secure directory hold established name-hierarchies that map
precisely to the material world, thus Existence-In-Directory
implies Identification, (delete one challenge-response.)"
       
As sexy and convenient as it may seem to overload these functions,
especially Location with Identification, such a scheme would be
both unstable and dangerous (the ultimate bad combination).

When someone says "We can make the directories secure" I cringe.
How secure?  For what?

The public telephone white-pages are secure enough for their purpose;
if a hacker or insider makes malicious modifications, it is just an
inconvenience for the most part.  If a directory holding my keys
is compromised, more hassle, but I can revoke and be re-issued.

I don't know if nature allows a directory secure enough to house
my biometric data, unless it is purely encrypted blobs to the
root directory operators, and I have secure control of the keys.

A Final Thought:  I am beginning to wonder if I should start a
global movement to have everyone capture all of their biometric
data (fingerprints, retinals, DNA sequences, etc) and publish
them in a giant, open public repository.  Would this not serve
make such data effectively worthless?  The only way this data
can be used to effectively "impersonate" me, is if there is a
reasonable assumption on the part of the relying party that
such information is uniquely held.  Destroy this assumption,
and the ability to impersonate disappears, no?

___tony___


 

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00534 for ietf-pkix-bks; Fri, 19 Mar 1999 13:05:53 -0800 (PST)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00526 for <[e-mail]>; Fri, 19 Mar 1999 13:05:50 -0800 (PST)
From: [e-mail]
Subject: Cross certification message protection (RFC2510)
To: [e-mail]
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 12 1999"
Date: Fri, 19 Mar 1999 21:13:07 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Epic/Iris_at_03/19/99_04:14:47_PM" (PVCS Build (based on 165) |Mar 17 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In RFC 2510 in section 4.6.1 it clearly states that a MAC based on an
authentication code
should be used for the message authentication and integrity.

In Appendix B section B7 it states that the protectionAlg should be set to
MSG_SIG_ALG.
This does not seem consistent.  I am assuming that B7 really meant to say
MSG_MAC_ALG,
if this is not the case I have a ton of other questions ...



                              Mike





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29632 for ietf-pkix-bks; Fri, 19 Mar 1999 12:54:22 -0800 (PST)
Received: from vignette.com (mi.vignette.com [207.8.7.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29627 for <[e-mail]>; Fri, 19 Mar 1999 12:54:21 -0800 (PST)
Received: from vignette.com by  vignette.com (8.7.3/BERK-6.8.11) id PAA11978; Fri, 19 Mar 1999 15:00:34 -0600 (CST)
Message-ID: <[e-mail]>
Date: Fri, 19 Mar 1999 15:00:34 -0600
From: Keith Johnston <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Question: Using Certificate Extensions for Applications
References: <v04020a09b3183998e653@[128.33.238.181]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> Keith,
>
> >I am on a project where we want to use digital certificates to
> >authenticate various server processes to each other over SSL.  What we'd
> >like to do is define a certificate extension that has the name of the
> >server in it, and then have each customer create certificates with the
> >standard fields (organizaiton, country, etc) set to their information,
> >and the extension field set to the name of the server.
>
> I would stgrongly recommend against creation of an extension for this
> purpose. What you seem to want is a cert that identifies a user executing a
> process on a server.  If so, then you should issue a cert that has a
> subject name with sufficient info to uniquely identify the processes in
> question.  X.509 has a naming model that presumes that the subject name
> uniquely identifies the subject, period.  If the intent here is to identify
> the subject in the context of the server, then one should construct a
> subject name that does so.
>

OK, I see your point - think of the server as a particular user.  And this
works fine if the customer has their own CA software - they would be perfectly
willing to sign a certificate that has a name like
"c=us,o=MyCompany,cn=ProcessFooBar".  But Verisign or Thawte (OK - Entrust
doesn't provide a signing service - I was mistaken there) wouldn't know how to
prove that you are really running ProcessFooBar on your server, or even what
ProcessFooBar is.  So I don't see how this works with an external CA that
doesn't understand what it is you are trying to do.  Sure, they can sign
certificates with DNS names or a persons name, but a process name?

Another alternative we are investigating is allowing each server process to map
a certificate distinguished name to a process identity.  This could mean that
JoeBob could get 5 or 6 certificates from Verisign, each with the same DN, but
different serial numbers.  Then each process would have a hashtable that maps
the serial number to the process name.  Each process could then authenticate to
the others.  But that's kind of annoying to have to distribute that map
around.  Sure, you could put it in LDAP or on some central server, but then
you've got a single point of failure or a complicated caching/replication
system.  So putting the process name in the certificate is really, really cool,
because all each server needs is a copy of the CA certificate.

Thanks for your comments, I look forward to your response.

Keith



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28116 for ietf-pkix-bks; Fri, 19 Mar 1999 12:30:40 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA28109 for <[e-mail]>; Fri, 19 Mar 1999 12:30:39 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 19 Mar 1999 13:36:38 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 19 Mar 1999 13:36:29 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Location and Identification
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 mail.proper.com id MAA28111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think Tony has some interesting points, so I'll take him up on 
forwarding them to the list, then respond.

Bob

>>> Tony Bartoletti <[e-mail]> 03/18/99 05:47PM >>>
Bob,

I am a bit reticent to jump into the threads with this, but I offer
it to you to use as you wish (forward, edit, consider, whatever.)
My thoughts here are in response to several recent threads.
 
I don't pretend to know the intimate details of DNs, AltNames, etc.,
(collectively "Name-Like-Things") and the precise handling expected
of them by X.509-conforming software.  Nor am I expert at the varied
contents (keys, et al) that may be bound into the certificates,
(collectively, "Ident-Challenge-Data").

I see from these discussions at least two broad and (in my ideal)
orthogonal dimensions that people intend for them to serve:

1.  Location (of individual/cert or their issuer)

    Ranging from Global-Public-Location to Proprietary-Location

2.  Secured Identification (of located item.  "Ident-Challenge-Data")

    Ranging from Public/Private Keys to Biometric Data.

I think it is useful to consider this (simplified) "quad-chart"
and characterize various schemes/applications accordingly:

  FUNCTION:    |  Object Location         | Object Identification
  METHOD:      |  (via Name-Like-Thing)   | (via Challenge-Data)
  ---------------------------------------------------------------
  (subclass)   |  Global Public Locator   | Keys/Issuer-Keys
  ---------------------------------------------------------------
  (subclass)   |  Proprietary Locator     | Biometric Data/Hash
  ---------------------------------------------------------------

Note:  I do not intend for these "rows" to indicate correspondence.
That is, one could deploy a system where a "Proprietary Locator" is
used to retrieve "Keys/Issuer-Keys" Challenge-Data, (basically, the
current situation with key-certificates) or (God Forbid) a system
where a "Global Public Locator" can retrieve an individual's
Biometric Challenge Data.

Furthermore, in each possible case, one can imagine a protocol
that either does or does not require the "data-owner" to cooperate
in the final step of identification (say, you believe you have
located someones challenge-data, but can only see a piece of it
large enough to query them to release the remainder, and can
then proceed with a full challenge if they concur.)

This is how the telephone white-pages work.  If I find (say) three
"Bob Jueneman" I can call each one.  If I say "Are you the Bob that
posts to the PKIX list," you can either reply with additional
confirming data, or say "Sorry, this is Jueneman's Plumbing Supplies,
we only carry PVC, no 'PKIX'" just to avoid me.  

If I may characterize the discussions of late, I see some threads
hoping to elevate (?) Proprietary Locators to Global Public Locators,
(Simon says, "Lets build the X.500 directory of Babel") and others
to extend certified content from Keys to Biometrics, for instance.

Worse, I also see a blurring of the functions themselves, to wit,
"Let a secure directory hold established name-hierarchies that map
precisely to the material world, thus Existence-In-Directory
implies Identification, (delete one challenge-response.)"
       
As sexy and convenient as it may seem to overload these functions,
especially Location with Identification, such a scheme would be
both unstable and dangerous (the ultimate bad combination).

When someone says "We can make the directories secure" I cringe.
How secure?  For what?

The public telephone white-pages are secure enough for their purpose;
if a hacker or insider makes malicious modifications, it is just an
inconvenience for the most part.  If a directory holding my keys
is compromised, more hassle, but I can revoke and be re-issued.

I don't know if nature allows a directory secure enough to house
my biometric data, unless it is purely encrypted blobs to the
root directory operators, and I have secure control of the keys.

A Final Thought:  I am beginning to wonder if I should start a
global movement to have everyone capture all of their biometric
data (fingerprints, retinals, DNA sequences, etc) and publish
them in a giant, open public repository.  Would this not serve
make such data effectively worthless?  The only way this data
can be used to effectively "impersonate" me, is if there is a
reasonable assumption on the part of the relying party that
such information is uniquely held.  Destroy this assumption,
and the ability to impersonate disappears, no?

___tony___


 

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26960 for ietf-pkix-bks; Fri, 19 Mar 1999 12:13:00 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26953 for <[e-mail]>; Fri, 19 Mar 1999 12:12:56 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA06614; Fri, 19 Mar 1999 15:16:24 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a08b3182d1957a3@[128.33.238.181]>
In-Reply-To: <[e-mail]>
Date: Fri, 19 Mar 1999 12:26:59 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: CRL version field confusion
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hoyt and David,

I apologize for my hasty conclusion re the correctness of the version #
issue with respect to  non-critical extensions.  I understand the
rationale, but I doubt that, in practice, most cert and CRL procesing
software operates as you say it ought to.  Based on your comments, one
could send any v3 non-critical extensions in certs, as well as CRLs, and
not mark the cert or crl as other than version one.  i think that the PKIX
prohibition against such usage is rooted in the belief that including any
extensions in a v1 crl or v1/2 cert usually would  result in unpleasant
behavior by most cert consuming software.

I think our constraints are appropriate, but I retract my comment about
X.509 being wrong.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26684 for ietf-pkix-bks; Fri, 19 Mar 1999 12:10:00 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26673 for <[e-mail]>; Fri, 19 Mar 1999 12:09:58 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA06603; Fri, 19 Mar 1999 15:16:21 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a06b31828914726@[128.33.238.181]>
In-Reply-To: <01BE71DD.C4A79260@HYDRA>
Date: Fri, 19 Mar 1999 11:22:12 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>>Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
>>NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key
>>Infrastructure,
>>this cannot (should not at least) be interpreted as public for anybody.
>>Just to your own selection of trusted RPs.
>
>Well, if you plan on making use of a growing installed base of products
>designed for general X.509 certificate use, this assumption will not be
>true, although I agree that one COULD provide better protection with a
>different set of applications, etc.
>
>I consider current off-the shelf products as mostly intended for closed
>organizational
>PKIs.  I think that ID-card programs will in most case be made of a
>mixture of commercial
>and customized components.  Such system fortunately do not suffer from any
>installed
>base of anything currently.

Perhpas I'm not being clear.  An organizational PKI built from standard,
commercial CA, directory, and application components generally will not
offer much in the way of confidentiality for certificates, because the
standards these components are built to do not call for such security
services.

>>This is solved by only letting such certificates be fetched from the CA by
>>the OWNER using a
>>"light" certificate.  Naturally using strong authentication/encryption.
>>The private/public keys
>>can be the same for the "heavy" ID to eliminate unnecessary key distribution
>
>>From a CA?  CA's do not necessarily store certs for retrieval by clients.
>Directories do this, and I have relatively little confidence in the
>assurance of the confidentiality offered by directory products.
>
>Well, market will tell.
>IMO fetching special certs as described above from an ID CA is a VERY
>useful idea that
>is bound to happen.

Well, as CTO of a major CA service and technology provider, I can say that
we support CA export of certs and CRLs to a directory.  We don't couple the
directory too tightly to the CA, as that would often decrease the security
of the CA.  We work with directory providers to ensure compataible data
transfer, but otherwise keep the notions of CA and directory quite separate.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26658 for ietf-pkix-bks; Fri, 19 Mar 1999 12:09:47 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26653 for <[e-mail]>; Fri, 19 Mar 1999 12:09:46 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA06617; Fri, 19 Mar 1999 15:16:24 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a09b3183998e653@[128.33.238.181]>
In-Reply-To: <[e-mail]>
Date: Fri, 19 Mar 1999 13:02:06 -0500
To: Keith Johnston <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Question: Using Certificate Extensions for Applications
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Keith,

>I am on a project where we want to use digital certificates to
>authenticate various server processes to each other over SSL.  What we'd
>like to do is define a certificate extension that has the name of the
>server in it, and then have each customer create certificates with the
>standard fields (organizaiton, country, etc) set to their information,
>and the extension field set to the name of the server.

I would stgrongly recommend against creation of an extension for this
purpose. What you seem to want is a cert that identifies a user executing a
process on a server.  If so, then you should issue a cert that has a
subject name with sufficient info to uniquely identify the processes in
question.  X.509 has a naming model that presumes that the subject name
uniquely identifies the subject, period.  If the intent here is to identify
the subject in the context of the server, then one should construct a
subject name that does so.

Another approach to this problem might be to issue a single public-key
certificate to the user and then have each server be a CA and issue
attribute certs to the users, tied to the public key certs.  However,
unless I have misunderstood the scenario you are trying to support, I would
not recommend this appraoch over the one I described above.

>But the question I have is - will Verisign or Entrust (or any other
>well-known CA) sign these certificates with the extension field?  I
>don't see how they could, since they would have no way of verifying, for
>example, that the person applying for the certificate even had a copy of
>our software.

You're mixing two types of CA companies here.  VeriSign primarily issues
certs as a service and thus your question is apporpriate in that many folks
feel that a CA ought to verify all of the data in a cert before issuing it.
Entrust is a provider of CA technology, not services, and there the
question is how easily could one add a new type of extension to their CA
product to accommoadte such data.  My company, CyberTrust is both a CA
service provider and a CA technology
provider, so we might have two different answers to this question,
depending on whether you were asking us as a service provider or a
technology provider :-)

>Is there any standard way of doing this?

No, and if I understand the scenario you have in mind, there probably ought
not be one.

\Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26644 for ietf-pkix-bks; Fri, 19 Mar 1999 12:09:41 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26638 for <[e-mail]>; Fri, 19 Mar 1999 12:09:40 -0800 (PST)
Received: from [128.89.0.111] (YAKOV.BBN.COM [128.89.0.111]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA06610; Fri, 19 Mar 1999 15:16:22 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a07b3182a4fb005@[128.33.238.181]>
In-Reply-To: <01BE71E9.482A1A30@HYDRA>
Date: Fri, 19 Mar 1999 11:33:53 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
Cc: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" 	 <[e-mail]>, "'SEIS-List'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

<snip>

>I know one STANDARD that I can give you right away:
>
>Pictures (for a photo attribute and a handwritten signature attribute)
>
>A picture would be a structure (my ASN.1 is not operational yet) of
>
>    mime-type    (String)
>    pictureblob    (Binary)
>
>Every browser can support this!

Well, if there was any doubt about your knowledge of ASN.1 or certificate
extension syntax I think it has been dispelled by your example :-).
Certificate extensions are NOT MIME types, and if one were to embed a
picture as an extension, it would not just be a binary blob, but rather
would use a format such as JPEG.

More to the point, I suspect that none of the mainstream browsers would do
anything useful with such an extension, irrespective of the obviously wrong
syntax.  The software in a browser that processes certs does not know how
to display or otherwise act upon an arbitrary extension.  This software is
separate from the HTML processing engine that does use MIME types and would
know how to diaplay a JPEG or similar encoded image. In most cases, you
would not be able to display such extentions as a user, just as most
browsers do not support display of all of the fields of current
certificates.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23902 for ietf-pkix-bks; Fri, 19 Mar 1999 11:27:33 -0800 (PST)
Received: from epic.iris.com (epic.iris.com [198.112.211.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23895 for <[e-mail]>; Fri, 19 Mar 1999 11:27:30 -0800 (PST)
From: [e-mail]
Subject: Can the responder change values in a cross cert request?
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 11 1999"
Date: Fri, 19 Mar 1999 19:35:11 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Epic/Iris_at_03/19/99_02:36:25_PM" (PVCS Build (based on 165) |Mar 17 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are a lot of statement in CMP that indicate that the requester must
specify a lot of information in cross cert request:

>From 4.6:
"The ccr message must contain a "complete" certification request,
      that is, all fields (including, e.g., a BasicConstraints
      extension) must be specified by the requester CA."

>From B7:

"signingAlg            present
  -- the requesting CA must know in advance with which algorithm it
  -- wishes the certificate to be signed"

"validity              present
  -- MUST be completely specified (i.e., both fields present)"

"extensions            optionally present
  -- a requesting CA must propose values for all extensions which it
  -- requires to be in the cross-certificate"

I'm trying to figure out how to address these requirements in a freeware
reference implementation (Jonah).

It seems difficult for the requesting CA to fill in all fields accurately.
For instance, the requesting CA may not know exactly what signature
algorithms the responding CA supports (it can guess them based on the type
of signature key in the cert published for that CA). A CA may not want to
sign a cert with a notBefore in the past (because it would create trust
chains that didn't actually exist then), which would make choosing a
notBefore that's soon enough to be useful but not in the past by the time
the responding CA creates the cert tricky. And the responding CA's policy
may not allow validity durations as long as the requesting CA would like
(which maybe the requesting CA would just go along with if they knew just
what the policy was).

So, is it reasonable for the requesting CA to fill in what it must, but
allow the responding CA to make reasonable changes/additions? This might
require human review to verify that the changed cert is OK before it is
confirmed. I couldn't find any text in CMP that flat out stated that the
responding CA couldn't  make changes and cut whatever cert it likes.
Developing out of band means for the requesting CA to specify values that
don't need to be changed would make interoperability impossible. So, if
this is a reasonable strategy for meeting the letter of the law for
freeware reference code, I'd like to go with it.

Again, thanks for your time.
     Mez



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21204 for ietf-pkix-bks; Fri, 19 Mar 1999 10:45:39 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21195 for <[e-mail]>; Fri, 19 Mar 1999 10:45:35 -0800 (PST)
From: [e-mail]
Subject: PKIPublicationInfo controls in CMP
To: [e-mail]
Date: Fri, 19 Mar 1999 18:52:44 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Arista/Iris_at_03/19/99_01:52:29_PM" (Build 165 |March 2, 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The PKIPublicationInfo allows a certificate requestor to ask the CA/RA to
use a particular publication mechanism for an issued certificate, or to
leave publication to the EE.  What should a RA/CA do if it can't honor the
request?  For example, the EE may ask for publication in X.500, but the
RA/CA can't talk to an X.500 server.  Or policy may dictate that the RA or
CA always publish issued certs themselves, so an EE request for
self-publication can't be honored.

Should the CA/RA refuse to issue a cert if it can't honor the EE's
PKIPublicationInfo control, or should it go ahead and issue it anyway, and
publish it however it wants?  If the latter, how can it indicate to the EE
that the cert has been published in a different manner from that requested?

John



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19902 for ietf-pkix-bks; Fri, 19 Mar 1999 10:20:39 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19895 for <[e-mail]>; Fri, 19 Mar 1999 10:20:36 -0800 (PST)
From: [e-mail]
Subject: question about system time checking in CMP
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 11 1999"
Date: Fri, 19 Mar 1999 18:28:20 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Arista/Iris_at_03/19/99_01:27:30_PM" (Build 165 |March 2, 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Section 4.6.1 of CMP says "Upon receipt of the ccp [cross cert response]
message, the requester CA checks that its own
   system time is close to the responder CA system time, "

The information about the responder's system time seems to be in the
messageTime field of the ccp, which indicates when the message was
produced.

I'm trying to interpret and implement this check for freeware reference
code (Jonah). I have two questions.

1) Just what is this check supposed to indicate/prove?

2) So, is there some sort of reasonable check that freeware reference code
can make here? Between the time the messageTime was generated and a check
might be made, it had to transit the network, the recipient's host had to
be up, and the recipient server had to be up. If everything goes well, an
hour seems like plenty. But if there are network problems, maybe 4 hours.
And if there were host problems or host or server upgrades, which could
happen over the weekend, maybe 3 days? So, is the right check for reference
freeware 3 days? Which is what I personally incline towards, not knowing
the answer to my first question.

Thanks for any help.
     Mez



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA19694 for ietf-pkix-bks; Fri, 19 Mar 1999 10:15:49 -0800 (PST)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19685 for <[e-mail]>; Fri, 19 Mar 1999 10:15:44 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA18295; Fri, 19 Mar 1999 10:17:25 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Mar 1999 09:04:29 -0500
To: Srinivas Pandrangi <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CRL version field confusion
Cc: Ambarish Malpani <[e-mail]>, Martin Lindström <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <006001be716c$0eaa48c0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe the PKIX RFC 2459 text should be followed.  Implementations will
have problems if non-critical extensions are included in version 1 CRLs.

Russ

At 12:56 PM 3/18/99 -0800, Srinivas Pandrangi wrote:
>Ambarish,
>X.509 does seem to say that version should be v1(0) if non-critical
>crlExtensions are present. It suggests that only crlEntryExtensions (in
>revokedCertificates), and "critical" crlExtensions imply a version of v2.
>This is in contrast to PKIX which says that the presence of any extension
>implies v2.
>--Srinivas
>
>Ambarish Malpani wrote:
>
>> Actually it isn't an ambiguity. The default value for the version
>> in CRLs, is v1 (i.e. 0). So if you are encoding a version 1
>> CRL (ie. one with no extensions), you don't encode the version
>> number.
>>
>> Hope this helps,
>> Regards,
>> Ambarish
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On Behalf
>> Of Martin Lindström
>> Sent: Thursday, March 18, 1999 12:48 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: CRL version field confusion
>>
>> I think I've found an ambiguity(?) between rfc2459 and the X.509
>> in the way CRL version fields should be treated.
>>
>> X.509 says: "If any extensions included in a CertificateList are
>> defined as critical, the version element of the CertificateList
>> shall be present. If no extensions defined as critical are included,
>> the version element shall be absent"
>>
>> RFC2459 on the other hand says: "When extensions are used, as required
>> by this profile, this field MUST be present and MUST specify version 2"
>>
>> Depending on which definition I use to encode a CRL having no critical
>> extensions I get different results. Is this correct?
>>
>> /Martin
>>
>> ______________________________________
>>          Entegrity Solutions
>>
>>   Martin Lindström
>>   Senior Systems Engineer
>>
>>   Finlandsgatan 60
>>   S-164 74 Kista, Sweden
>>   Direct: [phone]
>>   Fax:    [phone]
>>   Cell:   [phone]
>> ______________________________________
>
>--
>-------------------------------------------------------------------
>Srinivas Pandrangi
>XETI Inc.
>[e-mail]
>[phone]
>-------------------------------------------------------------------
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17898 for ietf-pkix-bks; Fri, 19 Mar 1999 07:40:08 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17892 for <[e-mail]>; Fri, 19 Mar 1999 07:40:02 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id QAA20800 for <[e-mail]>; Fri, 19 Mar 1999 16:46:37 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id QAA16601; Fri, 19 Mar 1999 16:46:19 +0100
Received: by HYDRA with Microsoft Mail id <01BE7228.181DB150@HYDRA>; Fri, 19 Mar 1999 16:46:54 +0100
Message-ID: <01BE7228.181DB150@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, =?iso-8859-1?Q?=27Petra_Gl?= =?iso-8859-1?Q?=F6ckner=27?= <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: QC - there ARE biometric standards
Date: Fri, 19 Mar 1999 16:46:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
Regarding the use of biometric data in qualified certificates it is unlikely that
there ever will be a consensus but that should not exclude it from support
in the draft.

So first we have photo_attribute and handwritten_signature_attribute that
we easy can add by putting them in structures consisting of

mime-type (string)
blob   (binary)

Late-breaking news!  There are NIST-standards for fingerprints as well.

http://www.morpho.com/news_room/library/whitepapers/civil_afis.htm

Maybe there are standards for retina, DNA-fingerprinting as well?

Call the FBI, they should know!


Regards
Anders Rundgren
http://www.mobilephones-tng.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16979 for ietf-pkix-bks; Fri, 19 Mar 1999 06:47:57 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16969 for <[e-mail]>; Fri, 19 Mar 1999 06:46:57 -0800 (PST)
From: [e-mail]
Subject: Re: Question: Using Certificate Extensions for Applications
To: Keith Johnston <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes PVCS Build (based on 165)  "Mar 11 1999"
Date: Fri, 19 Mar 1999 14:53:44 GMT
Message-ID: <[e-mail]>
X-Priority: 3 (Normal)
X-MIMETrack: "Serialize_by_Router_on_Arista/Iris_at_03/19/99_09:54:37_AM" (Build 165 |March 2, 1999)
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You're right. For instance, our Jonah reference code will not sign
extensions it does not recognize, on the grounds that they could not be
meaningfully verified either by server software or by display to the CA
administrator (if that option is enabled).
     Mez



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16462 for ietf-pkix-bks; Fri, 19 Mar 1999 06:23:31 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16458 for <[e-mail]>; Fri, 19 Mar 1999 06:23:24 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id JAA29894; Fri, 19 Mar 1999 09:28:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 19 Mar 1999 09:29:20 -0500
To: Stephen Kent <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: revised charter
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I am very please to see that the PKIX WG charter has been expanded to
address Attribute Certificates.

I have no problems with the expanded draft charter, but I have suggested
some minor editorial corrections, see below. You will still need to add the
final RFC number for some of the approved documents that have not yet been
published.

Francois Rousseau
AEPOS Technologies

>Folks,
>
>The PKIX WG has been in place for about 3.5 years.  We have managed to
receive approval for most of the original PKIX documents and thus it is
time to review the status of the WG and revise the charter to reflect our
ongoing and planned work items.  The draft charter reproduced below was
presented at the WG meeting, and has been forward to the Security Area
directors for review.  I am soliciting comments on this charter, on or
before 4/1, to produce a final version for approval by the ADs.
>
>Thanks,
>
>Steve
>
>--------------
>
[clip]

The PKIX Working Group was established in the Fall of 1995 with the intent
of developing Internet standards needed to support an X.509-based PKI.
Several informational and standards track documents in support of the
original goals of the WG have been approved by the IESG.  The first of
these standards, RFC 2459, profiles the X.509 version 3 certificates and
version 2 CRLs for use in the Internet.  The Certificate Management
Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP)
(RFC xxxx), and the Certificate Request Management Format (CRMF) (RFC 2511)
have been approved, as have profiles for the use of LDAP v2 for certificate
and CRL storage (RFC xxxx) and the use of FTP and HTTP for transport of PKI
operations (RFC xxxx).  RFC 2527, an informational RFC on guidelines for
certificate policies and practices also has been published, and the IESG
has approved publication of an informational RFC on use of KEA (RFC 2528)
and ECDSA (RFC xxxx).  Work continues on a second certificate management
protocol, CMC, closely aligned with the PKCS publications and with the
cryptographic message syntax (CMS) developed for S/MIME.  A roadmap,
providing a guide to the growing set of PKIX document, is also being
developed as an informational RFC.

The working group is now embarking on additional standards work to develop
protocols that are either integral to PKI management, or that are otherwise
closely related to PKI use.  Work is ongoing on alternative certificate
revocation methods.  There also is work on conventions for certificate name
forms and extension usage for "qualified certificates", certificates
designed for use in (legally binding) non-repudiation contexts.  Finally,
work is underway on protocols for time stamping and data certification.
These protocol are designed to support non-repudiation, making use of
certificates and CRLs, and are so tightly bound to PKI use that they
warrant coverage under this working group. 

Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps, in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates.
 
New Goals and Milestones:

 July 99
     Update RFC 2459, in anticipation of progression from PROPOSED to DRAFT.
     Complete approval of CMC, qualified certificates, and time-stamp
documents.
     Initiate work on attribute certificate profile.
 
 Dec 99
     Update March/April RFCs, for progress from PROPOSED to DRAFT.
     Complete approval of data notarization document.
     Publish I-D for attribute certificate profile.

 March 00
     Complete work on attribute certificate profile.

 July 00
     Continue RFC updating process.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA11732 for ietf-pkix-bks; Fri, 19 Mar 1999 02:19:51 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA11724 for <[e-mail]>; Fri, 19 Mar 1999 02:19:45 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id LAA16656 for <[e-mail]>; Fri, 19 Mar 1999 11:26:25 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id LAA58947; Fri, 19 Mar 1999 11:26:11 +0100
Received: by HYDRA with Microsoft Mail id <01BE71FB.6356B770@HYDRA>; Fri, 19 Mar 1999 11:26:53 +0100
Message-ID: <01BE71FB.6356B770@HYDRA>
From: Anders Rundgren <[e-mail]>
To: =?iso-8859-1?Q?Petra_Gl=F6ckner?= <[e-mail]>, "'Juergen Walter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Date: Fri, 19 Mar 1999 11:26:52 +0100
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 mail.proper.com id CAA11729
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,
>"Petra Glöckner" wrote:
>> 
>> Hi Anders,
>> 
>> I never meant to cope with all different scenarios with the
>> one QC example. I just wanted to display the concept of our
>> PersonalData structure with the possibility to have multiple
>> authorities responsible for different attributes.

>But there is another concept probably more meaningful. The X.509
>standard enables multiple authorities to issue attribute certificates.
>The authorities are called attribute certification authorities. End
>entity´s attribute certificate is linked to entity´s public key
>certificate by entity´s distinguished name or certID.

That is the way to do it!  Now the "only" question is how the user is going to
get these attribute certificates that could contain non-public information.
Then you will end-up with my CyberPhone concept where you use a 
"light" ID-cert to access information that concerns only you and the RP.
Or is there another "silver bullet"?

>Is there someone who is planning to implement a personal data record
>where multiple authorities are responsible for different attributes?
>Personally, I think that your approach leads to long vehicle
>certificates of short life-time. The more attributes and different
>authorities are involved the longer the certificate and the shorter the
>lifetime. Certainly not designed for today´s smartcards.

Or as I would put it: An impossible idea unfortunately already implemented.

This is one of the reasons our ID-card project is close to a stand-still.  A personal
ID-card is not an employment card.  And vice versa.

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA07715 for ietf-pkix-bks; Fri, 19 Mar 1999 00:10:16 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA07711 for <[e-mail]>; Fri, 19 Mar 1999 00:10:06 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id JAA32581 for <[e-mail]>; Fri, 19 Mar 1999 09:16:40 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA46769; Fri, 19 Mar 1999 09:16:34 +0100
Received: by HYDRA with Microsoft Mail id <01BE71E9.482A1A30@HYDRA>; Fri, 19 Mar 1999 09:17:16 +0100
Message-ID: <01BE71E9.482A1A30@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>, =?iso-8859-1?Q?=27Petra_Gl=F6?= =?iso-8859-1?Q?ckner=27?= <[e-mail]>
Subject: Re: QC Sample Sucks (a bit) 
Date: Fri, 19 Mar 1999 09:17:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan (pardon the subject),

>Regarding biometrics:

>Anders suggests that the Qualified Certificate profile should include
>specific solutions for storing biometric data. I'm not so sure.

>First, this is already possible. You can:

>1) include biometric data or a hash of biometric data as a unique
>identifier stored in the dnQualifier.

Ooooooops!  That would be the absolutely last place in a QC where I would put
biometric data!   Why?

1. dnQualifiers will in REAL world implementations of QCs be holding a code
of some kind that uniquely identifies the person within the CA domain.
SSN, employment-code etc.

2. Hash of biometric data?  Biometrics are analog (inexact) objects that require
complicated pattern matching algorithms to be verified.  Regardless if it is a machine
or human that is doing the pattern matching they must be in clear.

>2) define a new attribute and include it in the structure.

Sure, but I am worried about the proliferation of non-standard extensions and
their interpretation.

>The problem of defining anything further in the profile is the lack of
>standards. You would anyway have to provide additional information in order
>to instruct the relying party how to use the data, so nothing would add to
>the existing possibilities.

Have you really investigated this?  Since there are quite a few products on the
market for biometric verification there may be some standards actually.

I know one STANDARD that I can give you right away:

Pictures (for a photo attribute and a handwritten signature attribute)

A picture would be a structure (my ASN.1 is not operational yet) of

    mime-type    (String)
    pictureblob    (Binary)

Every browser can support this!

>Secondly I don't believe that this widely asked for at this stage of
>evolution. Maybe something for the future when there are useful and
>standardized way to express biometrics and standardized way to make
>sensible use of the information stored in a certificate. Until then this
>will all be proprietary solutions used under locally defined conventions.

Almost every ID-card has a photo and signature and I have not heard that this has become
out of fashion.   Don't let QCs be limited by the SEIS or the German solutions, because their
solutions are their headache.

Anders
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA03926 for ietf-pkix-bks; Thu, 18 Mar 1999 22:47:30 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA03922 for <[e-mail]>; Thu, 18 Mar 1999 22:47:28 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id HAA23229 for <[e-mail]>; Fri, 19 Mar 1999 07:54:13 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA78260; Fri, 19 Mar 1999 07:54:09 +0100
Received: by HYDRA with Microsoft Mail id <01BE71DD.C4A79260@HYDRA>; Fri, 19 Mar 1999 07:54:51 +0100
Message-ID: <01BE71DD.C4A79260@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Date: Fri, 19 Mar 1999 07:54:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,
>Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
>NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key
>Infrastructure,
>this cannot (should not at least) be interpreted as public for anybody.
>Just to your own selection of trusted RPs.

Well, if you plan on making use of a growing installed base of products
designed for general X.509 certificate use, this assumption will not be
true, although I agree that one COULD provide better protection with a
different set of applications, etc.

I consider current off-the shelf products as mostly intended for closed organizational
PKIs.  I think that ID-card programs will in most case be made of a mixture of commercial
and customized components.  Such system fortunately do not suffer from any installed
base of anything currently.

>This is solved by only letting such certificates be fetched from the CA by
>the OWNER using a
>"light" certificate.  Naturally using strong authentication/encryption.
>The private/public keys
>can be the same for the "heavy" ID to eliminate unnecessary key distribution

>From a CA?  CA's do not necessarily store certs for retrieval by clients.
Directories do this, and I have relatively little confidence in the
assurance of the confidentiality offered by directory products.

Well, market will tell.
IMO fetching special certs as described above from an ID CA is a VERY useful idea that
is bound to happen. 

Anders
http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA03793 for ietf-pkix-bks; Thu, 18 Mar 1999 22:24:56 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA03789 for <[e-mail]>; Thu, 18 Mar 1999 22:24:53 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id HAA22310 for <[e-mail]>; Fri, 19 Mar 1999 07:31:37 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id HAA41398; Fri, 19 Mar 1999 07:31:26 +0100
Received: by HYDRA with Microsoft Mail id <01BE71DA.980D72E0@HYDRA>; Fri, 19 Mar 1999 07:32:08 +0100
Message-ID: <01BE71DA.980D72E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Michael Sierchio'" <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Date: Fri, 19 Mar 1999 07:32:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
> NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key Infrastructure,
> this cannot (should not at least) be interpreted as public for anybody.
> Just to your own selection of trusted RPs.

This runs counter to the very idea of a cerificate -- which is a 
verifiable credential.  That there might be opaque parts of a
certificate which are meaningful only to a verifier,  perhaps
with active participation on the part of the cert holder to
protect privacy, is another matter.  If I read the above
correctly,  you're suggesting that the ID-certficate be
encrypted? 

Sorry if I am unclear but I wrote "never be TRANSMITTED" in clear.  The RP should verify
the cert using current PKI technology.  You may know that in Europe there are many
ID-card programs in deployment phase and unfortunately few of these have addressed the
issue of access to CA directories.  IMO CA services should (unless you have a search
warrant) be restricted to publishing anonymous CRLs.


> >It notes that if capture of a biometric if not physically secure, then
> >there is a terrible risk of spoofing.

Biometric data is as sensitive as a private key -- perhaps more so,
it's harder to revoke.  It shouldn't be in a cert, which is a public
credential.

Why do you insist on PUBLIC credential?  Do I break some "holy" PKIX-rule by
saying that only the USER can give away credentials to his/hers TPs?
I am not a very religious man so I can take it :-)

This is what will happen otherwise the whole ID-card business going on in Europe
will fail hard.

A very common biometric object in ID-cards is a photo.  It can't be revoked but
is not exact either.   Such data make perfect sense if you want to verify that the holder
of the "Personal Security Device" (holding a cert) really is matching. 

You CAN put photos on the outside of a PSD if it is of reasonable size.  However,
I am working with a concept where the PSD will be "buried" within a mobile phone.
An electronic photo in the cert (one of the ID-certs you have) will be much easier
for a security officer to read on a large screen than current ID-card photos.

Anders Rundgren
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21848 for ietf-pkix-bks; Thu, 18 Mar 1999 15:49:17 -0800 (PST)
Received: from us-mta1.ma02.bull.com (us-mta1.ma02.bull.com [128.35.138.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA21844 for <[e-mail]>; Thu, 18 Mar 1999 15:49:15 -0800 (PST)
From: [e-mail]
Received: by us-mta1.ma02.bull.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 85256738.0083332F ; Thu, 18 Mar 1999 18:53:03 -0500
X-Lotus-FromDomain: BULL
To: Srinivas Pandrangi <[e-mail]>
cc: Ambarish Malpani <[e-mail]>, =?iso-8859-1?Q?Martin_Lindstr=F6m?= <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 18:26:31 -0500
Subject: Re: CRL version field confusion
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 mail.proper.com id PAA21845
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i don't know why the rfc says what it says.

we, the x.509 standard guys,  wrote the stuff in the standard to allow
maximum interoperability. under the rules of extensibility, one is supposed
to ignore fields that one does not understand.

let's suppose the verifying entity, x, that is checking the crl only
understands version 1 (the version field was introduced by defect
resolution and is to be supported by non-v2 implementations).

let's supposed that entity y is responsible for constructing a crl that can
be consumed by the largest number of verifiers possible.

if y constructs a crl that has extensions that are all non-critical, then y
can either:

1) signal that the crl is version 2; or

2) signal, or don't specify, the version number as version 1.

if the first approach is taken, the relying party x will see that the crl
is a higher version than x can accept and will go no farther.

if the second approach is taken, x  will ignore all of the extensions under
the rules of extensibility and can still use the crl. since the generator
of the crl, y, had not made any of the extensions critical, this is
acceptable

what we don't want is to have some implementation that knows nothing about
this stuff ignore critical extensions. the only way to ensure that the
verifier, e.g. x, won't ignore everything, including critical extensions,
is to have x check the version number. if the version number is greater
than 1, an old style verifier will not apply the rules of extensibility,
ignore everything (including critical), and accept the crl. that is, it
recognizes the version number field and it knows that it doesn't support
that version.

maybe the ietf group didn't care about the existence of old version
verifiers (i.e. all users of interest conform to the pkix profile). what i
can say is that the text in the standard is not an error. its phrasing was
discussed for some time. unfortunately, as in many places in the standard,
there is no explanation of why it states that.

    hoyt






Srinivas Pandrangi <[e-mail]> on 03/18/99 03:56:58 PM

To:   Ambarish Malpani <[e-mail]>
cc:   Martin Lindström <[e-mail]>, [e-mail],
      [e-mail], [e-mail] (bcc: Hoyt Kesterson/US/BULL)
Subject:  Re: CRL version field confusion




Ambarish,
X.509 does seem to say that version should be v1(0) if non-critical
crlExtensions are present. It suggests that only crlEntryExtensions (in
revokedCertificates), and "critical" crlExtensions imply a version of v2.
This is in contrast to PKIX which says that the presence of any extension
implies v2.
--Srinivas
Ambarish Malpani wrote:
> Actually it isn't an ambiguity. The default value for the version
> in CRLs, is v1 (i.e. 0). So if you are encoding a version 1
> CRL (ie. one with no extensions), you don't encode the version
> number.
>
> Hope this helps,
> Regards,
> Ambarish
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Martin Lindström
> Sent: Thursday, March 18, 1999 12:48 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: CRL version field confusion
>
> I think I've found an ambiguity(?) between rfc2459 and the X.509
> in the way CRL version fields should be treated.
>
> X.509 says: "If any extensions included in a CertificateList are
> defined as critical, the version element of the CertificateList
> shall be present. If no extensions defined as critical are included,
> the version element shall be absent"
>
> RFC2459 on the other hand says: "When extensions are used, as required
> by this profile, this field MUST be present and MUST specify version 2"
>
> Depending on which definition I use to encode a CRL having no critical
> extensions I get different results. Is this correct?
>
> /Martin
>
> ______________________________________
>          Entegrity Solutions
>
>   Martin Lindström
>   Senior Systems Engineer
>
>   Finlandsgatan 60
>   S-164 74 Kista, Sweden
>   Direct: [phone]
>   Fax:    [phone]
>   Cell:   [phone]
> ______________________________________
--
-------------------------------------------------------------------
Srinivas Pandrangi
XETI Inc.
[e-mail]
[phone]
-------------------------------------------------------------------







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18596 for ietf-pkix-bks; Thu, 18 Mar 1999 15:38:37 -0800 (PST)
Received: from vignette.com (mi.vignette.com [207.8.7.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18591 for <[e-mail]>; Thu, 18 Mar 1999 15:38:36 -0800 (PST)
Received: from vignette.com by  vignette.com (8.7.3/BERK-6.8.11) id RAA09713; Thu, 18 Mar 1999 17:44:48 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 17:44:48 -0600
From: Keith Johnston <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Question: Getting an OID for a certificate extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

How do I go about getting an OID for my own private certificate extension.
I'd like to make sure it doesn't collide with any existing OIDs.  Or perhaps
there is an existing OID that I could use.  The field I want to put into the
certificate is essentially application-specific information, identifying one
server out of many.  Seems like something that a lot of distributed
applications would need.

Any info would be appreciated.

Thanks,
Keith Johnston



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17460 for ietf-pkix-bks; Thu, 18 Mar 1999 15:00:48 -0800 (PST)
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17444 for <[e-mail]>; Thu, 18 Mar 1999 15:00:46 -0800 (PST)
Received: from zetnet (man-284.dialup.zetnet.co.uk [194.247.43.104]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id XAA27699; Thu, 18 Mar 1999 23:07:03 GMT
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Stephen Kent <[e-mail]>
Date: Thu, 18 Mar 1999 23:05:52 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: CRL version field confusion
Reply-to: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
In-reply-to: <v04020a0bb316d486093a@[128.33.238.134]>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Martin,
> 
> >I think I've found an ambiguity(?) between rfc2459 and the X.509
> >in the way CRL version fields should be treated.
> >
> >X.509 says: "If any extensions included in a CertificateList are
> >defined as critical, the version element of the CertificateList
> >shall be present. If no extensions defined as critical are included, the
> >version element shall be absent"
> >
> >RFC2459 on the other hand says: "When extensions are used, as required by
> >this profile, this field MUST be present and MUST specify version 2"
> >
> >Depending on which definition I use to encode a CRL having no critical
> >extensions I get different results. Is this correct?
> 
> I feel that RFC 2459 is correct. Even if an extension is not marked
> critical, a client that does not understand V2 CRLs might crash trying to
> parse a v2 CRL with ANY extensions.
> 

This should not happen. All clients should correctly support the rules 
for extensibility, which state that unknown elements in a SET or 
SEQUENCE should be skipped and ignored. Therefore there is no 
reason to crash (except for a faulty implementation)

David


***************************************************

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11232 for ietf-pkix-bks; Thu, 18 Mar 1999 14:16:15 -0800 (PST)
Received: from vignette.com (mi.vignette.com [207.8.7.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11228 for <[e-mail]>; Thu, 18 Mar 1999 14:16:14 -0800 (PST)
Received: from vignette.com by  vignette.com (8.7.3/BERK-6.8.11) id QAA03228; Thu, 18 Mar 1999 16:22:26 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 16:22:26 -0600
From: Keith Johnston <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Question: Using Certificate Extensions for Applications
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

I am on a project where we want to use digital certificates to
authenticate various server processes to each other over SSL.  What we'd

like to do is define a certificate extension that has the name of the
server in it, and then have each customer create certificates with the
standard fields (organizaiton, country, etc) set to their information,
and the extension field set to the name of the server.

But the question I have is - will Verisign or Entrust (or any other
well-known CA) sign these certificates with the extension field?  I
don't see how they could, since they would have no way of verifying, for

example, that the person applying for the certificate even had a copy of

our software.

Is there any standard way of doing this?

Thanks,
Keith Johnston



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09902 for ietf-pkix-bks; Thu, 18 Mar 1999 12:44:19 -0800 (PST)
Received: from xeti.com ([208.163.59.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA09898 for <[e-mail]>; Thu, 18 Mar 1999 12:44:17 -0800 (PST)
Received: from xeti.com by xeti.com (SMI-8.6/SMI-SVR4) id MAA16177; Thu, 18 Mar 1999 12:43:21 -0800
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 12:56:58 -0800
From: Srinivas Pandrangi <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: Martin =?iso-8859-1?Q?Lindstr=F6m?= <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: CRL version field confusion
References: <006001be716c$0eaa48c0$[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish,
X.509 does seem to say that version should be v1(0) if non-critical
crlExtensions are present. It suggests that only crlEntryExtensions (in
revokedCertificates), and "critical" crlExtensions imply a version of v2.
This is in contrast to PKIX which says that the presence of any extension
implies v2.
--Srinivas

Ambarish Malpani wrote:

> Actually it isn't an ambiguity. The default value for the version
> in CRLs, is v1 (i.e. 0). So if you are encoding a version 1
> CRL (ie. one with no extensions), you don't encode the version
> number.
>
> Hope this helps,
> Regards,
> Ambarish
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Martin Lindström
> Sent: Thursday, March 18, 1999 12:48 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: CRL version field confusion
>
> I think I've found an ambiguity(?) between rfc2459 and the X.509
> in the way CRL version fields should be treated.
>
> X.509 says: "If any extensions included in a CertificateList are
> defined as critical, the version element of the CertificateList
> shall be present. If no extensions defined as critical are included,
> the version element shall be absent"
>
> RFC2459 on the other hand says: "When extensions are used, as required
> by this profile, this field MUST be present and MUST specify version 2"
>
> Depending on which definition I use to encode a CRL having no critical
> extensions I get different results. Is this correct?
>
> /Martin
>
> ______________________________________
>          Entegrity Solutions
>
>   Martin Lindström
>   Senior Systems Engineer
>
>   Finlandsgatan 60
>   S-164 74 Kista, Sweden
>   Direct: [phone]
>   Fax:    [phone]
>   Cell:   [phone]
> ______________________________________

--
-------------------------------------------------------------------
Srinivas Pandrangi
XETI Inc.
[e-mail]
[phone]
-------------------------------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09314 for ietf-pkix-bks; Thu, 18 Mar 1999 12:00:35 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09310 for <[e-mail]>; Thu, 18 Mar 1999 12:00:34 -0800 (PST)
Received: from [209.32.92.156] (host145.44IETF.MR.Net [209.32.92.145]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA25369 for <[e-mail]>; Thu, 18 Mar 1999 15:07:15 -0500 (EST)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1290334668==_ma============"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a01b31705d3eab4@[128.33.238.134]>
Date: Thu, 18 Mar 1999 14:39:47 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: revised charter
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1290334668==_ma============
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=46olks,

The PKIX WG has been in place for about 3.5 years.  We have managed to
receive apoproval for most of the original PKIX documents and thus it is
time to review the status of the WG and revise the charter to reflect our
ongoing and planned work items.  The draft charter reproduced below was
presented at the WG meeting, and has been forward to the Security Area
directors for review.  I am soliciting comments on this charter, on or
before 4/1, to produce a final version for approavl by the ADs.

Thanks,

Steve

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

The PKIX Working Group was  established in the Fall of 1995 with the intent
of developing Internet standards needed to support an X.509-based PKI.
Several informational and standards track documents in support of the
original goals of the WG have been approved by the IESG. The first of these
standards, RFC 2459, profiles the X.509 version 3 certificates and version
2 CRLs for use in the Internet.  The Certificate Management Protocol (CMP,)
the Online certificate Status Protocol (OCSP), and the Certificate
Management Request Format (CRMF) have been approved, as have profiles for
the use of LDAP v2 for certificate and CRL storage and the use of FTP and
HTTP for transport of PKI operations.  An informational RFC on guidelines
for certificate policies and practices also has been published, and the
IESG has approved publication of an information RFC on use of KEA and
ECDSA.  Work continues on a second certificate management protocol, CMP,
closely aligned with the PKCS publications and with the cryptographic
message syntax (CMS) developed for S/MIME.  A roadmap, providing a guide to
the growing set of PKIX document, is also being developed as an
informational RFC.

The working group is now embarking on additional standards work to develop
protocols that are either integral to PKI management, or that are otherwise
closely related to PKI use. Work is ongoing on alternative certificate
revocation methods. There also is work on conventions for certificate name
forms and extension usage for "qualified certificates," certificates
designed for use in (legally binding) non-repudiation contexts. Finally,
work is underway on protocols for time stamping and data certification.
These protocol are designed to support non-repudiation, making use of
certificates and CRLs, and are so tightly bound to PKI use that they
warrant coverage under this working group.

Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps,  in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates.

New Goals and Milestones:

 July 99
            Update RFC 2459, in anticipation of progression from PROPOSED
to DRAFT
Complete approval of CMC, qualified certificates, and time-stamp documents
Initiate work on attribute certificate profile.

 Dec 99
	Update March/April RFCs, for progress from PROPOSED to DRAFT
	Complete approval of data notarization document
Publish I-D for attribute certificate profile

March 00
	Complete work on attribute certificate profile

July 00
	Continue RFC updating process, =8A
--============_-1290334668==_ma============
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=46olks,


The PKIX WG has been in place for about 3.5 years.  We have managed to
receive apoproval for most of the original PKIX documents and thus it
is time to review the status of the WG and revise the charter to
reflect our ongoing and planned work items.  The draft charter
reproduced below was presented at the WG meeting, and has been forward
to the Security Area directors for review.  I am soliciting comments on
this charter, on or before 4/1, to produce a final version for approavl
by the ADs.


Thanks,


Steve


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


<fontfamily><param>Times</param><bigger><bigger>The PKIX Working Group
was  established in the Fall of 1995 with the intent of developing
Internet standards needed to support an X.509-based PKI. Several
informational and standards track documents in support of the original
goals of the WG have been approved by the IESG. The first of these
standards, RFC 2459, profiles the X.509 version 3 certificates and
version 2 CRLs for use in the Internet.  The Certificate Management
Protocol (CMP,) the Online certificate Status Protocol (OCSP), and the
Certificate Management Request Format (CRMF) have been approved, as
have profiles for the use of LDAP v2 for certificate and CRL storage
and the use of FTP and HTTP for transport of PKI operations.  An
informational RFC on guidelines for certificate policies and practices
also has been published, and the IESG has approved publication of an
information RFC on use of KEA and ECDSA.  Work continues on a second
certificate management protocol, CMP, closely aligned with the PKCS
publications and with the cryptographic message syntax (CMS) developed
for S/MIME.  A roadmap, providing a guide to the growing set of PKIX
document, is also being developed as an informational RFC.


The working group is now embarking on additional standards work to
develop protocols that are either integral to PKI management, or that
are otherwise closely related to PKI use. Work is ongoing on
alternative certificate revocation methods. There also is work on
conventions for certificate name forms and extension usage for
"qualified certificates," certificates designed for use in (legally
binding) non-repudiation contexts. Finally, work is underway on
protocols for time stamping and data certification. These protocol are
designed to support non-repudiation, making use of certificates and
CRLs, and are so tightly bound to PKI use that they warrant coverage
under this working group.=20


Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps,  in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates.

=20

New Goals and Milestones:


 July 99

            Update RFC 2459, in anticipation of progression from
PROPOSED to DRAFT

Complete approval of CMC, qualified certificates, and time-stamp
documents

Initiate work on attribute certificate profile.

=20

 Dec 99

	Update March/April RFCs, for progress from PROPOSED to DRAFT

	Complete approval of data notarization document

Publish I-D for attribute certificate profile


March 00

	Complete work on attribute certificate profile


July 00

	Continue RFC updating process, =8A </bigger></bigger></fontfamily>

--============_-1290334668==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08345 for ietf-pkix-bks; Thu, 18 Mar 1999 10:19:39 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA08341 for <[e-mail]>; Thu, 18 Mar 1999 10:19:38 -0800 (PST)
Received: from host248.44ietf.mr.net (hil-c45-041-vty58.as.wcom.net [199.174.221.58]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id TAA31550 for <[e-mail]>; Thu, 18 Mar 1999 19:26:15 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 18 Mar 1999 19:40:20 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: QC Sample Sucks (a bit) 
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 mail.proper.com id KAA08342
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I disagree with the subject heading of this discussion.

The function of the example cert is to give an technical example of how the
profile is used. I don't believe that there is any "typical" ID-certificate
so I see the use of the example from the technical viewpoint. Not a guide
to how an ID should be expressed.

Regarding biometrics:

Anders suggests that the Qualified Certificate profile should include
specific solutions for storing biometric data. I'm not so sure.

First, this is already possible. You can:

1) include biometric data or a hash of biometric data as a unique
identifier stored in the dnQualifier.
2) define a new attribute and include it in the structure.

Both are valid options.

The problem of defining anything further in the profile is the lack of
standards. You would anyway have to provide additional information in order
to instruct the relying party how to use the data, so nothing would add to
the existing possibilities.

Secondly I don't believe that this widely asked for at this stage of
evolution. Maybe something for the future when there are useful and
standardized way to express biometrics and standardized way to make
sensible use of the information stored in a certificate. Until then this
will all be proprietary solutions used under locally defined conventions.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08173 for ietf-pkix-bks; Thu, 18 Mar 1999 10:04:38 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA08169 for <[e-mail]>; Thu, 18 Mar 1999 10:04:38 -0800 (PST)
Received: (qmail 25155 invoked from network); 18 Mar 1999 18:11:16 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 18 Mar 1999 18:11:16 -0000
Received: (qmail 933 invoked from network); 18 Mar 1999 18:11:06 -0000
Received: from amazon-internal.valicert.com (HELO loaner) (10.0.0.1) by internal-dns1.valicert.com with SMTP; 18 Mar 1999 18:11:06 -0000
From: "Ambarish Malpani" <[e-mail]>
To: "=?iso-8859-1?Q?Martin_Lindstr=F6m?=" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: CRL version field confusion
Date: Thu, 18 Mar 1999 10:20:52 -0800
Message-ID: <006001be716c$0eaa48c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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.2106.4
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually it isn't an ambiguity. The default value for the version
in CRLs, is v1 (i.e. 0). So if you are encoding a version 1
CRL (ie. one with no extensions), you don't encode the version
number.

Hope this helps,
Regards,
Ambarish

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf
Of Martin Lindström
Sent: Thursday, March 18, 1999 12:48 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: CRL version field confusion



I think I've found an ambiguity(?) between rfc2459 and the X.509
in the way CRL version fields should be treated.

X.509 says: "If any extensions included in a CertificateList are
defined as critical, the version element of the CertificateList
shall be present. If no extensions defined as critical are included,
the version element shall be absent"

RFC2459 on the other hand says: "When extensions are used, as required
by this profile, this field MUST be present and MUST specify version 2"

Depending on which definition I use to encode a CRL having no critical
extensions I get different results. Is this correct?

/Martin


______________________________________
         Entegrity Solutions

  Martin Lindström
  Senior Systems Engineer

  Finlandsgatan 60
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07916 for ietf-pkix-bks; Thu, 18 Mar 1999 09:40:04 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07912 for <[e-mail]>; Thu, 18 Mar 1999 09:40:03 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 0B05B3D; Thu, 18 Mar 1999 18:46:41 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id SAA17177; Thu, 18 Mar 1999 18:46:40 +0100
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 18:46:32 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: Celo communications
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Petra =?iso-8859-1?Q?Gl=F6ckner?= <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
References: <01BE7078.DB50BAC0@HYDRA> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Petra,

"Petra Glöckner" wrote:
> 
> Hi Anders,
> 
> I never meant to cope with all different scenarios with the
> one QC example. I just wanted to display the concept of our
> PersonalData structure with the possibility to have multiple
> authorities responsible for different attributes.

But there is another concept probably more meaningful. The X.509
standard enables multiple authorities to issue attribute certificates.
The authorities are called attribute certification authorities. End
entity´s attribute certificate is linked to entity´s public key
certificate by entity´s distinguished name or certID.

Is there someone who is planning to implement a personal data record
where multiple authorities are responsible for different attributes?
Personally, I think that your approach leads to long vehicle
certificates of short life-time. The more attributes and different
authorities are involved the longer the certificate and the shorter the
lifetime. Certainly not designed for today´s smartcards.

Juergen

> 
> The example doesn't say anything about which attributes are
> required. Of course a CA can only issue certificates with
> information they or any other registration authority was able
> to verify.
> 
> I'm not convinced that you need to have a fingerprint in a QC
> certificate, but of course we could define an appropriate
> attribute in our next QC version, but maybe there is already
> such an attribute definition ? Does anybody know ?
> 
> Regards - Petra
> 
> Anders Rundgren wrote:
> >
> > Hi Petra,
> > I have some comments on the QC "Sample Certificate" that contained data
> > about you.
> >
> > Although a sample is just a sample I still think that a sample should be "typical".
> >
> > I see two VERY different situations (which should be in the draft) when QCs are used:
> >
> > 1. Remote (the Relying Party has no visual or physical contact).   In that scenario
> > you cannot verify any biometrics like age, sex etc.   I.e. you should not require that
> > kind of information in a remote situation as it makes no sense for automated
> > identification purposes.   There may be exceptions when the RP needs biometrics
> > but that calls for another QC that you would use in those rare circumstances.
> >
> > 2. Physical.  RP have visual or physical contact with the subject and *could*
> > use biometrics to verify that the certificate holder seems to be matching.  In this case
> > you may need photo, fingerprint, age, sex etc in the QC itself as this data is not necessarily
> > printed on a smart card holding the QC.  The "card" could actually be a miniaturized
> > thing within a mobile phone.  ( www.mobilephones-tng.com/v100/cyberphonecards.html )
> >
> > So I urge you to make room in the QC draft for some biometrics (in a structured way) and
> > to make TWO or more samples.
> >
> > Consequence: You cannot have just one QC to cope with all possible uses!
> >
> > Regards
> > Anders Rundgren
> > Senior Internet e-commerce Architect
> > Jaybis AB
> > http://www.mobilephones-tng.com

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA07754 for ietf-pkix-bks; Thu, 18 Mar 1999 09:25:18 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07750 for <[e-mail]>; Thu, 18 Mar 1999 09:25:17 -0800 (PST)
Received: from [128.33.238.134] (TC105.BBN.COM [128.33.238.105]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA18136 for <[e-mail]>; Thu, 18 Mar 1999 12:31:55 -0500 (EST)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1290343988==_ma============"
Message-Id: <v04020a15b316e904d9f4@[128.33.238.134]>
Date: Thu, 18 Mar 1999 12:35:03 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: meeting minutes, 1st draft
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Continuing with our tradition of hot off the presses meeting minutes, I
hereby submit the minutes fro the 3/18 PKIX WG meeting to the WG list for
review and comment.  Additional info on the status of I-Ds will be included
in the final version. Please provide comments to me by 4/1, for production
of the final version of the minutes.

Steve

---------

PKIX WG Meeting 3/17/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met only once during the 44rd IETF and a approximately XXX
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX Cert/CRL Profile (draft-ietf-pkix-ipki-part1-11.txt)
Published as RFC 2459.

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt)
Published as RFC 2510.

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt)
Published as Informational RFC XXX.

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
Approved by IESG

LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
Approved by IESG?

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt)
Approved by IESG

OCSP (draft-ietf-pkix-ocsp-07.txt)
Approved by IESG.

KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt)
Approved by IESG for publication as an Informational RFC

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
Undergoing revision by authors.

CMC (draft-ietf-pkix-cmc-02.txt)
Under development.

CMMF (draft-ietf-pkix-cmmf-02.txt)
Expired, due to subsumption by CMC.


<insert more work items from Warwick>


Reports on Established Projects:

A new WG charter was presented, in draft form, which shortly will be posted to
the mailing list.  The expanded charter encompasses attribute certificates,
time stamping and notarization services, and qualified certificates.


CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
The CNC draft did not meet submission deadline, but was made available to the
list.  The D-H POP draft is undergoing revision.  CMC has been revised to
accommodate comments from Carlisle from the last meeting. Additional changes
are planned, including removal of the key archival and recovery features, and
clarification of RA operations.

PKIX Roadmap (A. Arsenault-NSA)
Missed submission deadline.  Undergoing revision to deal with terminology
inconsistencies, POP, adding a history of PKIX, new work items (e.g.,
qualified certificates and time stamping), explanation of name constraints for
alt name forms, path validation, etc.

Qualified Certificates (S. Santesson)
Goals of qualified certificates were reviewed. The fundamental thrust of this
work is the development of a new SubjectAltName type, for "unmistakable
identity" ID information. Attribute semantics represents the top-level
structure for the SubjectaltName, making it clear what form of ID is being
provided, e.g., national ID card or driver license. Also, this extension will
contain a registration authority field, as required by German law.  A pointer
to a web site for additional info was provided (http://www.accurata.se/QC/).
Suggestion was made to consider splitting this work into two document: one for
the new name form, and another (informational?) to explain the context for
which this new name form was devised. However, to the extent that a qualified
certificate imposes  constraints on other certificate fields, it is not clear

Data Certification and Time Stamping (R. Zucharetto-Entrust)
Data certification server I-D not recently updated, but will be soon, to
respond to comments, e.g., ASN.1 corrections and more explanatory text.  The
time stamping document also has not been updated recently, but will undergo
minor revisions, e.g., to allow for issuance of a time stamp without
submission of a hash.  Unfortunately, the topics of time stamping and data
certification are rife with intellectual property claims, which may interfere
with progression of these documents.  Specifically, a lawsuit has been filed
by patent holders against a company that has implemented a prior version of
this protocol. The WG chairs will work with the authors of the documents to
help resolve these issues.


Other Toics:

Progressing RFC 2459 to Draft Status (T. Polk-NIST)
Collecting inputs for (mostly) minor corrections and clarifications to this
document in anticipation of progressing this work.

OCSP Clarification (S. Kent-BBN)
Two sections of OCSP will be revised to clarify what is required of compliant
clients and servers with respect to what keys can be used to sign OCSP
responses. Specifically, an OCSP response must be signed by either the CA who
issued the certificate in question, by an entity who has been explicitly
delegated this authority by that CA (through direct issuance and inclusion of
a specified EKU extension), or by an entity who has been selected as
authoritative by the client. Compliant OCSP servers and clients MUST be able
to support all three of these options.(Satisfying the third option is largely
trivial for the server, but requires a configuration capability for clients.)

Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull)
Proposal to minimize the addition of extensions to EE certificates, by moving
as much of this sort of information to CA certificates, from EE certificates.
Examples of such extension data are pointers to OCSP responders and CRL
servers, where applicable to all certificates issued by a CA.

Attribute Certificates	(S. Farrell-SSE)
A kickoff announcement of this new work item. Providing pointers to work on
attribute certificates for use with TLS, as an example.

OCSP Interoperability Testing	(A. Malparni-ValiCert)
Reported on tests of seven independent implementations.  All made use of HTTP
and direct, DER encoding (not base 64).  Discovered some problems, e.g., in
hash computation.

Server-based Certificate Validation (A. Malparni-ValiCert)
A suggestion to explore "outsourcing" certificate validation to a server, from
a client. Proposal is to develop a protocol between a client and the
validation server, which might be attractive when the client is not
computationally capable, or to help by centralizing administration of
certificate validation management. There are security concerns here, because
of the centralization of security function in servers.

MISPC Reference Implementation (T. Polk-NIST)
CDROM contains CA, RA, and client executable code. Represents a profile of
2459, CMP, and CRMF.  Available via web site: http://crscnist.gov/pki/mispc/
--============_-1290343988==_ma============
Content-Type: text/enriched; charset="us-ascii"

Continuing with our tradition of hot off the presses meeting minutes, I
hereby submit the minutes fro the 3/18 PKIX WG meeting to the WG list
for review and comment.  Additional info on the status of I-Ds will be
included in the final version. Please provide comments to me by 4/1,
for production of the final version of the minutes.


Steve


---------


PKIX WG Meeting 3/17/99 

Edited by Steve Kent (WG co-chair)


The PKIX WG met only once during the 44rd IETF and a approximately XXX
individuals participated in these meetings. 


The meeting began with a review of the status of all of the WG
document, 

presented by Warwick Ford, WG co-chair. The following text summarizes
the 

status of the documents:


PKIX Cert/CRL Profile (draft-ietf-pkix-ipki-part1-11.txt)

Published as RFC 2459.


CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF
(draft-ietf-pkix-crmf-01.txt)

Published as RFC 2510.


Certificate Policy/Practices Guideline
(draft-ietf-pkix-ipki-part4-03.txt)

Published as Informational RFC XXX.


HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)

Approved by IESG


LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)

Approved by IESG?


LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt)

Approved by IESG


OCSP (draft-ietf-pkix-ocsp-07.txt)

Approved by IESG.


KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt)

Approved by IESG for publication as an Informational RFC


ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)

Undergoing revision by authors.


CMC (draft-ietf-pkix-cmc-02.txt)

Under development.


CMMF (draft-ietf-pkix-cmmf-02.txt)

Expired, due to subsumption by CMC.



<<insert more work items from Warwick>



Reports on Established Projects:


A new WG charter was presented, in draft form, which shortly will be
posted to 

the mailing list.  The expanded charter encompasses attribute
certificates, 

time stamping and notarization services, and qualified certificates.



CMC and Diffie-Hellman POP (J. Schaad-Microsoft)

The CNC draft did not meet submission deadline, but was made available
to the 

list.  The D-H POP draft is undergoing revision.  CMC has been revised
to 

accommodate comments from Carlisle from the last meeting. Additional
changes 

are planned, including removal of the key archival and recovery
features, and 

clarification of RA operations. 


PKIX Roadmap (A. Arsenault-NSA)

Missed submission deadline.  Undergoing revision to deal with
terminology 

inconsistencies, POP, adding a history of PKIX, new work items (e.g., 

qualified certificates and time stamping), explanation of name
constraints for 

alt name forms, path validation, etc.


Qualified Certificates (S. Santesson)

Goals of qualified certificates were reviewed. The fundamental thrust
of this 

work is the development of a new SubjectAltName type, for "unmistakable

identity" ID information. Attribute semantics represents the top-level

structure for the SubjectaltName, making it clear what form of ID is
being 

provided, e.g., national ID card or driver license. Also, this
extension will 

contain a registration authority field, as required by German law.  A
pointer 

to a web site for additional info was provided
(http://www.accurata.se/QC/). 

Suggestion was made to consider splitting this work into two document:
one for 

the new name form, and another (informational?) to explain the context
for 

which this new name form was devised. However, to the extent that a
qualified 

certificate imposes  constraints on other certificate fields, it is not
clear


Data Certification and Time Stamping (R. Zucharetto-Entrust)

Data certification server I-D not recently updated, but will be soon,
to 

respond to comments, e.g., ASN.1 corrections and more explanatory text.
 The 

time stamping document also has not been updated recently, but will
undergo 

minor revisions, e.g., to allow for issuance of a time stamp without 

submission of a hash.  Unfortunately, the topics of time stamping and
data 

certification are rife with intellectual property claims, which may
interfere 

with progression of these documents.  Specifically, a lawsuit has been
filed 

by patent holders against a company that has implemented a prior
version of 

this protocol. The WG chairs will work with the authors of the
documents to 

help resolve these issues.



Other Toics:


Progressing RFC 2459 to Draft Status (T. Polk-NIST)

Collecting inputs for (mostly) minor corrections and clarifications to
this 

document in anticipation of progressing this work.


OCSP Clarification (S. Kent-BBN)

Two sections of OCSP will be revised to clarify what is required of
compliant 

clients and servers with respect to what keys can be used to sign OCSP

responses. Specifically, an OCSP response must be signed by either the
CA who 

issued the certificate in question, by an entity who has been
explicitly 

delegated this authority by that CA (through direct issuance and
inclusion of 

a specified EKU extension), or by an entity who has been selected as 

authoritative by the client. Compliant OCSP servers and clients MUST be
able 

to support all three of these options.(Satisfying the third option is
largely 

trivial for the server, but requires a configuration capability for
clients.)


Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull)

Proposal to minimize the addition of extensions to EE certificates, by
moving 

as much of this sort of information to CA certificates, from EE
certificates. 

Examples of such extension data are pointers to OCSP responders and CRL

servers, where applicable to all certificates issued by a CA.


Attribute Certificates	(S. Farrell-SSE)

A kickoff announcement of this new work item. Providing pointers to
work on 

attribute certificates for use with TLS, as an example.


OCSP Interoperability Testing	(A. Malparni-ValiCert)

Reported on tests of seven independent implementations.  All made use
of HTTP 

and direct, DER encoding (not base 64).  Discovered some problems,
e.g., in 

hash computation.  


Server-based Certificate Validation (A. Malparni-ValiCert)

A suggestion to explore "outsourcing" certificate validation to a
server, from 

a client. Proposal is to develop a protocol between a client and the 

validation server, which might be attractive when the client is not 

computationally capable, or to help by centralizing administration of 

certificate validation management. There are security concerns here,
because 

of the centralization of security function in servers. 


MISPC Reference Implementation (T. Polk-NIST)

CDROM contains CA, RA, and client executable code. Represents a profile
of 

2459, CMP, and CRMF.  Available via web site:
http://crscnist.gov/pki/mispc/

--============_-1290343988==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07214 for ietf-pkix-bks; Thu, 18 Mar 1999 08:29:02 -0800 (PST)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07210 for <[e-mail]>; Thu, 18 Mar 1999 08:29:01 -0800 (PST)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA118298 for <[e-mail]>; Thu, 18 Mar 1999 11:35:09 -0500
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id LAA240632 for <[e-mail]>; Thu, 18 Mar 1999 11:35:11 -0500
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256738.005B1AD2 ; Thu, 18 Mar 1999 11:35:06 -0500
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 11:35:03 -0500
Subject: LDAP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anyone & Everyone,

I am new to this list so please forgive me if this question has been
answered.  I have gone through the archive pretty thoroughly and I was only
able to find half of the answer I am looking for there... and I think the
knowledge is considered "known to all" or presupposed by everyone.
Unfortunately I don't know...

The question has progressed as follows (this way you know the direction
from which I am approaching the question) starting with... How do I get
hold of a CRL from a CA distribution point?  I believe I do this via LDAP
or HTTP/FTP.  I was able to find the subjAltName extension with the URI
containing the IA5string with the URL of the distribution point inside of
it.  However, I was unable to find anything other than the directoryName
for the LDAP portion of tracking down CRL distribution points..  I looked
into that field and it looks more like the directory setup so that you
would know how to search through the specific distribution point, not the
location of the distribution point.  SO...

How do you know the location of an LDAP server for a specific CA
distribution point?  Is this an out-of-band issue? Or is there something
similar to the HTTP and FTP methods using subjAltName and the URI field?

If you need me to further extrapolate, please don't hesitate to ask for
more and I will do my best to fill this question out if needed.


Matthew DeRuyter




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07118 for ietf-pkix-bks; Thu, 18 Mar 1999 08:19:21 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-121.dialup.dnai.com [207.181.255.121]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07114 for <[e-mail]>; Thu, 18 Mar 1999 08:19:20 -0800 (PST)
Received: from dnai.com (windoze.tenebras.com [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id IAA11509; Thu, 18 Mar 1999 08:23:46 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 08:23:45 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
References: <01BE711B.65365DB0@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

> Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
> NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key Infrastructure,
> this cannot (should not at least) be interpreted as public for anybody.
> Just to your own selection of trusted RPs.

This runs counter to the very idea of a cerificate -- which is a 
verifiable credential.  That there might be opaque parts of a
certificate which are meaningful only to a verifier,  perhaps
with active participation on the part of the cert holder to
protect privacy, is another matter.  If I read the above
correctly,  you're suggesting that the ID-certficate be
encrypted?  

> This is solved by only letting such certificates be fetched from the CA by the OWNER using a
> "light" certificate.  Naturally using strong authentication/encryption.  The private/public keys
> can be the same for the "heavy" ID to eliminate unnecessary key distribution

There seems to me to be some confusion here between the notion of
Certificate and a Personal Security Device, such as a smart card,
which might carry a certificate,  and embedded private key, and
perhaps other private data (such as biometric data of the owner,
encrypted of protected).  There are systems, such as the DynaSoft
BoKS software,  which extend this notion to a "soft" PSD, which
is downloaded from a central repository (or a replica server).

> >It notes that if capture of a biometric if not physically secure, then
> >there is a terrible risk of spoofing.

Biometric data is as sensitive as a private key -- perhaps more so,
it's harder to revoke.  It shouldn't be in a cert, which is a public
credential.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07106 for ietf-pkix-bks; Thu, 18 Mar 1999 08:18:19 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07102 for <[e-mail]>; Thu, 18 Mar 1999 08:18:18 -0800 (PST)
Received: from [128.33.238.134] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA16507; Thu, 18 Mar 1999 11:23:54 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0cb316d503269e@[128.33.238.134]>
In-Reply-To: <[e-mail]>
References: Stephen Kent's message of Wed, 17 Mar 1999 17:35:05 -0500.     <v04020a02b315db7d981e@[128.33.238.103]>
Date: Thu, 18 Mar 1999 11:21:54 -0500
To: Michael Roe <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
Cc: Stephen Kent <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

I think we are in agreement on many points.  As you note, one can't easily
revoke a biometric; well, not more than 10 times for fingerprints, twice
for iris scans, ... :-).  I also agree that a biometric ought not be
assumed to be a secret in most cases.

The photograph example you gave does not fall into the class of systems I
was warning against.  The authentication function is performed by a person,
in the analog domain, under conditions that usually are viewed as providing
adequate physical security for transmission of the image from the user to
the authenticating system.

One can make use of biometrics in electronic systems, if one assumes that
the capture of the biometric is itself tamperproof, and that the
registration process is secure.  I was pointing out that even if
transmission security is afforded to a captured biometric, and even if the
templates are stored on a server (to ensure the confidentiality,
authenticity, and integrity of the reference biometric) that the system
would be flawed.

Your observations about the ease of capturning input biometrics are not
quite the same as my comments about confidentility of the reference
biometric (template). I suspect we agree that the integrity and
authenticity of the template is more critical than its confidentiality.

Finally, we are most definately in agreement re use of biometrics as keys;
it's just a bad idea.  However, a number of companies are pushing biometric
technology for use in precisely the circumstances that we all agree is a
bad idea, and so I wanted to take this opportunity to raise the issue
again.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07098 for ietf-pkix-bks; Thu, 18 Mar 1999 08:17:55 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07094 for <[e-mail]>; Thu, 18 Mar 1999 08:17:54 -0800 (PST)
Received: from [128.33.238.134] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA16483; Thu, 18 Mar 1999 11:23:47 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0ab316d1ce65d5@[128.33.238.134]>
In-Reply-To: <01BE711B.65365DB0@HYDRA>
Date: Thu, 18 Mar 1999 11:03:19 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

>>I recommend to you the discussion on use of biometrics (like fingerprints,
>>hand geometry, iris or retinal image patterns, etc.)  in open, networked
>>systems contained in the recent "Trust in Cyberspace" report from the U.S.
>>National Academy of Science.
>
>I will, although my thought applications for this was limited to
>the same situations as you use ID-cards in today.  That should NOT lead to
>severe problems.  See below:
>
>>First, certificates often are stored and transmitted without
>>confidentiality protection.
>
>Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
>NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key
>Infrastructure,
>this cannot (should not at least) be interpreted as public for anybody.
>Just to your own selection of trusted RPs.

Well, if you plan on making use of a growing installed base of products
designed for general X.509 certificate use, this assumption will not be
true, although I agree that one COULD provide better protection with a
different set of applications, etc.

>>This raises the question of how one protects
>>sensitive biometric data if it is embedded in a certificate.  Remember,
>>this data needs to available to any entity who will use it for user
>>authentication, yet it must not be made available to possible attackers,
>>for the reasons cited below.
>
>This is solved by only letting such certificates be fetched from the CA by
>the OWNER using a
>"light" certificate.  Naturally using strong authentication/encryption.
>The private/public keys
>can be the same for the "heavy" ID to eliminate unnecessary key distribution

>From a CA?  CA's do not necessarily store certs for retrieval by clients.
Directories do this, and I have relatively little confidence in the
assurance of the confidentiality offered by directory products.

>>It notes that if capture of a biometric if not physically secure, then
>>there is a terrible risk of spoofing.
>
>Absolutely, biometric capture is possible to spoof but in a PROTECTED area
>like
>in a Bank or Passport-control, the scheme I have described would work much
>better than current authentication systems.  Imagine a security officer
>that gets
>a nice high-resolution picture on his PC instead of trying to see if that
>1.5 inch
>photo really is you!
>
>And if you package the "light" cert in a CyberPhone you would just have to
>point to
>a receiver, Click Yes if you agree to be authenticated by the RP and
>that's it!

No argument here.  Under suitably controlled conditions, biometrics can be
very useful.

>>The observation is that a server
>>with biometric data will, invariably be compromised.  The result is that
>>the user biometric templates contained in the server, as well as the
>>algorithms used for matching, will be exposed.
>
>The algorithms MUST IMO be known and servers can be made secure.  If the
>staff running a CA are crooks the whole PKI idea is dead-meat so I do not
>take this in account.

If the algorithms are to be kept secret, then we are talking about a closed
system. Also note that if multiple, closed systems are built using the same
biometric basis, then compromise of ANY of them can lead to the problems I
decribe.  However, if the system is closed, the algorithm is secret, and
the certificates have to be affored a level of confidentiality not
consistent with genric X.509 products, why bother using X.509?

>>Knowledge of the templates
>>and the algorithms permits at attacker to generate bit streams that will
>>suffice to authenticate the user's whose templates were compromised. Thus,
>>unless there is very good technical and physical security for capture of
>>user biometrics, to preclude introduction of bogus bit streams that purport
>>to be real biometrics, such systems are fatally flawed.
>
>Again, the applications for biometrics are not for remote and unsecured use.

I agree that the applications SHOULD not be for such use, but at trade
shows we see many companies selling fingerprint readers that plug into PCs
for procisely that sort of use.  Hence my warnings.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07087 for ietf-pkix-bks; Thu, 18 Mar 1999 08:17:19 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07082 for <[e-mail]>; Thu, 18 Mar 1999 08:17:17 -0800 (PST)
Received: from [128.33.238.134] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA16493; Thu, 18 Mar 1999 11:23:51 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a0bb316d486093a@[128.33.238.134]>
In-Reply-To: <[e-mail]>
Date: Thu, 18 Mar 1999 11:05:48 -0500
To: Martin =?iso-8859-1?Q?Lindstr=F6m?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: CRL version field confusion
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Martin,

>I think I've found an ambiguity(?) between rfc2459 and the X.509
>in the way CRL version fields should be treated.
>
>X.509 says: "If any extensions included in a CertificateList are
>defined as critical, the version element of the CertificateList
>shall be present. If no extensions defined as critical are included,
>the version element shall be absent"
>
>RFC2459 on the other hand says: "When extensions are used, as required
>by this profile, this field MUST be present and MUST specify version 2"
>
>Depending on which definition I use to encode a CRL having no critical
>extensions I get different results. Is this correct?

I feel that RFC 2459 is correct. Even if an extension is not marked
critical, a client that does not understand V2 CRLs might crash trying to
parse a v2 CRL with ANY extensions.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07048 for ietf-pkix-bks; Thu, 18 Mar 1999 08:13:42 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07043 for <[e-mail]>; Thu, 18 Mar 1999 08:13:41 -0800 (PST)
Received: from [128.33.238.134] (TC047.BBN.COM [128.33.238.47]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA15077; Thu, 18 Mar 1999 11:20:12 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a06b316b951ec0d@[128.33.238.134]>
In-Reply-To: <05b501be7099$3476ca20$[e-mail]>
Date: Thu, 18 Mar 1999 09:11:54 -0500
To: "Sergio Tabanelli" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Signature request ?
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sergio,

The message exchange you describe sounds like a PKI application, and hence
would generally be addressed in a working group outside of PKIX. For
example, the TLS WG defines how to use certs for secure web access, S/MIME
does the same for secure e-mail, etc.  PKIX tries to focus on protocols and
associated standards that are intrinsic to a PKI.  Admittedly, we have
strayed a bit in adding time stamping and data certification to our
charter. However, the generic signature request and response protocol you
describe sounds ike something one would embed in a particular application
context.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06923 for ietf-pkix-bks; Thu, 18 Mar 1999 08:01:44 -0800 (PST)
Received: from hpsrv01.infosys.tuwien.ac.at (hpsrv01.infosys.tuwien.ac.at [128.131.172.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06919 for <[e-mail]>; Thu, 18 Mar 1999 08:01:41 -0800 (PST)
Received: from pent27.infosys.tuwien.ac.at (pent27.infosys.tuwien.ac.at [128.131.172.114]) by hpsrv01.infosys.tuwien.ac.at (8.8.6/8.8.6) with SMTP id RAA10532; Thu, 18 Mar 1999 17:08:20 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 18 Mar 1999 17:09:01 +0100
To: [e-mail]
From: Vesna Hassler <[e-mail]>
Subject: CertificateStatus in PKIX-LDAP Schema?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I hope the PKIX-LDAP Schema will be soon extended with a CertificateStatus
Attribute.

CertStatus from the OCSP is not quite suitable, I think.
My proposal is to replace "good" with "valid", meaning that
- the certificate is in the directory
- the certificate is not expired
- the certificate is not revoked,

and to add a new status called "expired" for certificates that are expired,
are not revoked, and are still available in the directory.

Thanks,
Vesna Hassler

Technical University of Vienna


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05691 for ietf-pkix-bks; Thu, 18 Mar 1999 05:56:56 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05687 for <[e-mail]>; Thu, 18 Mar 1999 05:56:53 -0800 (PST)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA10280; Thu, 18 Mar 1999 15:02:34 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 15:02:02 +0100
From: "Petra Glöckner" <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
References: <01BE7078.DB50BAC0@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Anders,

I never meant to cope with all different scenarios with the 
one QC example. I just wanted to display the concept of our
PersonalData structure with the possibility to have multiple 
authorities responsible for different attributes.

The example doesn't say anything about which attributes are 
required. Of course a CA can only issue certificates with
information they or any other registration authority was able
to verify.

I'm not convinced that you need to have a fingerprint in a QC
certificate, but of course we could define an appropriate 
attribute in our next QC version, but maybe there is already
such an attribute definition ? Does anybody know ?

Regards - Petra

Anders Rundgren wrote:
> 
> Hi Petra,
> I have some comments on the QC "Sample Certificate" that contained data
> about you.
> 
> Although a sample is just a sample I still think that a sample should be "typical".
> 
> I see two VERY different situations (which should be in the draft) when QCs are used:
> 
> 1. Remote (the Relying Party has no visual or physical contact).   In that scenario
> you cannot verify any biometrics like age, sex etc.   I.e. you should not require that
> kind of information in a remote situation as it makes no sense for automated
> identification purposes.   There may be exceptions when the RP needs biometrics
> but that calls for another QC that you would use in those rare circumstances.
> 
> 2. Physical.  RP have visual or physical contact with the subject and *could*
> use biometrics to verify that the certificate holder seems to be matching.  In this case
> you may need photo, fingerprint, age, sex etc in the QC itself as this data is not necessarily
> printed on a smart card holding the QC.  The "card" could actually be a miniaturized
> thing within a mobile phone.  ( www.mobilephones-tng.com/v100/cyberphonecards.html )
> 
> So I urge you to make room in the QC draft for some biometrics (in a structured way) and
> to make TWO or more samples.
> 
> Consequence: You cannot have just one QC to cope with all possible uses!
> 
> Regards
> Anders Rundgren
> Senior Internet e-commerce Architect
> Jaybis AB
> http://www.mobilephones-tng.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05480 for ietf-pkix-bks; Thu, 18 Mar 1999 05:34:05 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05476 for <[e-mail]>; Thu, 18 Mar 1999 05:34:02 -0800 (PST)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA09117; Thu, 18 Mar 1999 14:39:55 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 14:39:23 +0100
From: "Petra Glöckner" <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: SEIS: Re: Regarding "Given names"
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Bob,

comments inline

Bob Jueneman wrote:
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> [Resent to correct the correct address of the pkix list.]
> 
> Hi Petra,
> 
> (Someone corrected me for referring to you as "he".
> I guess I assumed that Petra was the equivalent
> of the English "Peter," but I should have caught the
> feminine ending.  I apologize.)
 
No problem ;-)

> I certainly understand that there are lots of certificates
> containing DNs which don't correspond to entries in ANY
> directory, much less some well-structured, as-God-intended
> x.500 directory with X.520 DIT structure and schema.
> 
> My point is, and I am agreeing with you to at least a certain
> extent, that if we continue to throw completely arbitrary
> name constructs in the DN, we will make it increasingly difficult
> to ever store or retrieve those certificates in or from a directory.
> 
> So my goal was to get people to recognize that the primary
> purpose of the DN was to facilitate interoperation with a directory.
> And since there may very well be a proliferation of directories with
> incompatible DIT structures and schemas, it is necessary to
> recognize that it is the _subscriber's_ directory that must dictate the
> DIT structure and schema -- not the CA's, and not the recipient's.

I don't think that the primary purpose of the DName is to facilitate 
interoperation with a directory. That was the motivation when they 
defined the X.509v3 certificates, but I think this is not valid anymore.

> Other technical functions such as name subordination may or may
> not have a role to play with respect to the DN.  They could, but
> I suspect that it may not be terribly useful in most cases, just
> because directory names are (unfortunately) not often organized
> along the lines of organizational boundaries that name subordination
> assumes.
> 
> I agree that when writing application software you cannot always
> assume that the DN points to an X.500 entry, as one may never have
> been created.  I would say that it OUGHT to, but it might not.
> 
> On the other hand, I believe that it would be WRONG to believe
> that an alternateSubjectName, in particular, would always point to
> a certificate, or even to a directory entry of any kind.  Again, perhaps
> it ought to, but I may have chosen to express my name and organizational
> structure in a more conventional fashion, perhaps for ease of display and
> recognition, but without a corresponding entry in any existing directory --
> not even an alias.
> 
> For example, my directory name in Novell's corporate directory in business
> card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.
> 
> But what I would like to have displayed in someone's certificate viewing
> software would be c=US, o="Novell, Inc.", ou="Network Products Division",
> ou="Network Security Department", cn="Robert R. Jueneman"
>
> Since the purpose of the DN is to convey an entry in the directory, the
> first name form clearly has to be the DN, and the second name form the
> alternateSubjectName.  But that second name form is not an entry in the
> Novell corporate directory,  not even an alias, and not likely to be any time
> soon, even if it has the form directoryName.

I disagree, the directoryName of the SubjectAltName has to convey an
entry 
in the directory, not necessarily the subject DName. So, IMO you should
put 
the first name "o=novell, ou=prv, ou=nsrd, cn=bjueneman" in the
directoryName 
of the SubjectAltName and the second name "c=US, o=Novell, Inc.,
ou=Network 
ProductsDivision, ou=Network Security Department, cn=Robert R. Jueneman" 
in the subject DName.
 
> I agree that it would be quite reasonable to create an alias for such a
> name in a directory somewhere, and I would encourage such a practice.
> I also believe that it may be desirable to include other directory style
> names as additional alternateSubjectNames, perhaps to support other DIT
> structures and/or schemas, but I don't believe that the ietf-pkix group
> is in a position to mandate that a particular alternateSubjectName reflect
> a real entry in any particular directory.  And whether they mandate it or
> not, it isn't likely to happen world-wide any time soon.
> 
> As for the additional information you may require that go beyond "name"
> information per se, I would suggest that you make your PersonalData
> structure a subjectDirectoryAttributes attribute extension (if someone can
> ever figure out what the semantics of _that_ attribute are supposed to be),
> or else simply define a new attribute extension.
> 
> But in general I would be rather opposed to listing much of the type of
> information you have suggested in a certificate at all, and certainly not in
> a name field.

The PersonalData structure shall contain as much information of a person
as 
necessary in order to identify him. You don't have to use all
attributes!

We have chosen the SubjectAltName instead of the
subjectDirectoryAttributes 
extension because the PersonalData structure contains the name of the
person
plus any other required identity information to make the name unique.
But you can easily use any of the attributes defined in the QC-draft,
which 
are not necessary to unmistakably identify the person, within the 
subjectDirectoryAttributes extension since the
subjectDirectoryAttributes 
and the PersonalData structure are both a sequence of attribute.
 
Petra

PS.: I will be on vacation next week. I'll answer as soon I'm back at
work.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA05257 for ietf-pkix-bks; Thu, 18 Mar 1999 05:06:22 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA05253 for <[e-mail]>; Thu, 18 Mar 1999 05:06:19 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id OAA20409 for <[e-mail]>; Thu, 18 Mar 1999 14:12:55 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id OAA11615; Thu, 18 Mar 1999 14:12:43 +0100
Received: by HYDRA with Microsoft Mail id <01BE7149.7D073C10@HYDRA>; Thu, 18 Mar 1999 14:13:25 +0100
Message-ID: <01BE7149.7D073C10@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Michael Roe'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: QC Sample Sucks (a bit) 
Date: Thu, 18 Mar 1999 14:13:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

>Nevertheless, a photo-id serves a useful authentication function. But any
>protocol that assumes that biometric data is secret is fundamentally flawed.

There is a slight but very important difference between public information and
information that is not secret. 

Neither SSNs or biometrics can be assumed to be secret but they
should not be published in such a way that anybody can access them.  A 
protocol (if we are talking "computerease") should not expose such data to 
others than the Relying Party (and under the control of the Subject).

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04620 for ietf-pkix-bks; Thu, 18 Mar 1999 04:17:02 -0800 (PST)
Received: from godzilla.ccsr.cam.ac.uk ([e-mail] [128.232.97.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA04601 for <[e-mail]>; Thu, 18 Mar 1999 04:15:12 -0800 (PST)
Received: from kamloops.ccsr.cam.ac.uk [128.232.97.7]  by godzilla.ccsr.cam.ac.uk with esmtp (Exim 1.82 #1) id 10Nbmv-0002PN-00; Thu, 18 Mar 1999 12:20:37 +0000
To: Stephen Kent <[e-mail]>
cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: QC Sample Sucks (a bit) 
In-reply-to: Stephen Kent's message of Wed, 17 Mar 1999 17:35:05 -0500. <v04020a02b315db7d981e@[128.33.238.103]> 
Date: Thu, 18 Mar 1999 12:20:37 +0000
From: Michael Roe <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In reply to Steve Kent's message:

> First, certificates often are stored and transmitted without
> confidentiality protection.  This raises the question of how one protects
> sensitive biometric data if it is embedded in a certificate.  Remember,
> this data needs to available to any entity who will use it for user
> authentication, yet it must not be made available to possible attackers,
> for the reasons cited below.

Steve,

I disagree with this view of how biometrics should be used.
They are *not* cryptographic keys, and shouldn't be used as if they were:

  * Unlike keys, biometrics cannot be revoked in the event of a compromise.

  * Unlike keys, biometrics cannot be assumed be secret

Consider a typical example of a biometric - your photograph, as used on
passports and U.S. driver's licenses. It's not a secret --- lots of people
know what you look like, and it's probably not hard for an attacker to find
another  photography of you. Furthermore, changing your apperarance (growing
a moustache etc...) would be inconvenient to say the least.

Nevertheless, a photo-id serves a useful authentication function. But any
protocol that assumes that biometric data is secret is fundamentally flawed.

Other sorts of biometrics, such as iris scans, fingerprints, and DNA samples
are not so obviously non-secret as photographs, as it's a bit harder
for an attacker to obtain them. But if any of them are routinely used
for authentication, they become public information. If you regularly let 
machines read your fingerprints (because that's what you have to do to
prove your identity) then it's likely an attacker will have ample opportunity
to obtain this information.

Protocols that use biometrics can be made to work. But you have to avoid 
falling into the trap of using biometrics like crypto keys.

There is a similar problem with identifiers (i.e. names) such as credit card
numbers and social security numbers. Protocols which treat them as if they were
secret keys for authentication purposes ("I know your SSN, therefore I am you")
are broken for similar reasons. However, such broken protocols are in common 
use.  I hope that this type of mistake is not repeated with biometrics.

Mike


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA04589 for ietf-pkix-bks; Thu, 18 Mar 1999 04:13:22 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04585 for <[e-mail]>; Thu, 18 Mar 1999 04:13:19 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id B55AD3F; Thu, 18 Mar 1999 13:19:57 +0100 (CET)
Received: from celocom.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id NAA15802; Thu, 18 Mar 1999 13:19:57 +0100
Message-ID: <[e-mail]>
Date: Thu, 18 Mar 1999 13:19:50 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: Celo communications
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>, "Jim Schaad (Exchange)" <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: New CMC Draft available
References: <01E1D01C12D7D211AFC70090273D20B104F006@sothmxs06>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to stress the initial registration procedure (section 5.3).
Thanks to the authors and contributors for CMC review and improvement.
But I have still a concern. Unless otherwise stated initial registration
protocols defined in CMC and CMP are considered. 

Supposed that the initial registration message is not encrypted,
off-line guessing attacks may appear. The weakness comes from the fact
that the input data (plaintext) for the HMac algorithm is sent together
with its cipher text. The adversary may confirm before the CA or RA
receives the message. The probability of guessing the initial
authentication key is nearly one if the adversary has enough time.

There are the following three consequences:
1) The initial authentication key is only suitable for short-term usage.
2) Supposed an adversary can intercept the connection to the CA or RA
the adversary can reformulate entity´s certificate request.
3) An adversary can apply for a certificate with changed request data
even if he is not able to intercept the connection between end entity
and CA.

The initial authentication key distribution is commonly a cost-intensive
procedure. I assume for the following that the initial authentication
key is an identifier for the individual entity. It might be a good idea
to use this initial authentication key for further off-line
authentication procedures e. g. certificate revocation request.

I consider for example that the adversary may replace entity´s public
key by its own. The following cases may be considered:

Case 1. I assume that the adversary can intercept any connection between
the certificate applicant and the CA. The CA issues a certificate that
contains applicant´s identity and adversary´s public key. The applicant
may miss his certificate but he may think that is an operational issue.
The concerned entity may phone on the CA. Consequently, cost-intensive
back office procedures have to start. CMP users are in the comfortable
position that they have to be silent when they do not confirm. In the
meantime the adversary can confirm whereby he applies the initial
authentication key again. The adversary has probably a fake certificate
for the whole validity period. (Note: If there is no control over
initial authetication key expiry in the CA domain the entity may
re-certified in addition. But the adversary has still a fake certificate
containing entity´s identity and adversary´s public key.) I propose to
add a message to both the CMP and CMC protocol that allows the applicant
to retrieve the certificate after a time-out specified by local policy.
The response then contains the issued certificate, a waiting or an error
message. Now the applicant can validate the received certificate and
send his confirmation. The validation must include a check that the
public key in entity´s
certificate matches entity´s private key. Additionally, I propose an
explicite non-confirmation message.

Case 2. I assume that the adversary is not able to intercept the
connection between the CA and the end entity. Depending on the controls
implemented by the CA no, one or two certificates will be issued. The CA
will detect the attack when it takes appropriate control over the
initial authentication key management. The initial authentication key
must be a unique and one-time password that corresponds to an individual
entity. Nevertheless the end entity must validate that the issued
certificate contains the public key matching entity´s private key.
Therefore an explicit non-confirmation message would be meaningful.

A security measure against this offline-guessing attack is the
encryption of the initial registration. Please add an appropriate
recommendation to the CMC and the CMP draft.

There are initial registration protocols that provides a higher level of
security. For example the HMac is taken over data that is not completely
known by a potential adversary. Then he is not able to verify his guess
because he does not know the complete plain text. In the case of
signature algorithms with message recovery the certificate applicant may
include a self-choosen password that is contained in HMac input as plain
text. But this password is contained in the initial registration request
as cipher text where it is encrypted by e. g. CA´s public key. The
password is not contained as plain text in the initial registration
request at all. This password chosen by the entity may serve for
authentication purposes in revocation requests. Unfortunately the schema
is not applicable for signature algorithms like DSA. It has to be
re-designed. Replace the one-directional delivery of an initial
authentication key prior to the initial registration by an out-of-band
exchange of keys or passwords i. e. the following out-of-band procedures
take place before an end entity sends his initial registration message:

CA->EE: initial authentication key, other initial data
EE->CA: password
 
This causes no additional expenses in such registration scheme where the
end entity is well-identified by some agent. Nowadays it is commonly
applied by GSM phone sellers.

I think that the current CMP and CMC draft does not support the scheme
described above. Is a support of the described scheme planned for next
CMP and CMC reviews? Is someone else interested in such scheme?

Juergen

Carlisle Adams wrote:
> 
> Hi,
> 
> > ----------
> > From:         Jim Schaad (Exchange)[SMTP:[e-mail]]
> > Sent:         Monday, March 08, 1999 1:12 PM
> > To:   IETF-PKIX (E-mail)
> > Subject:      New CMC Draft available
> >
> > A new draft of CMC (what will become draft -03) is now available on-line.
> > This draft should appear on the various IETF servers shortly after the
> > upcoming meeting in Minneapolis.  We apologize for missing the
> > internet-draft cutoff date to get the draft published on IETF servers
> > before
> > the meeting; in the meantime the draft is available in various format from
> > Brian LaMacchia's personal website at:
> >
> >       http://www.farcaster.com/cmc/
> >
> > The differences between the -02 and -03 drafts may be summarized as
> > follows:
> > 1) New Section 5.3, Linking Identity and POP information, to address the
> > potential theft/replay attack involving cert requests with NULL subject
> > DNs
> > that Carlisle Adams pointed out.
> > 2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
> > attack involving the example state-reduction technique.
> > 3) Numerous editorial changes that were made in response to comments
> > posted
> > to the list and/or delivered to the authors privately.
> 
> Congratulations to all authors and contributors on this revision; the
> improvements over the previous draft are significant!  In particular, it
> appears that the modifications to Sections 5.3 and 5.7 address my earlier
> concerns so that an entity may now be securely initialized into the PKI
> using this protocol.
> 
> I have a few additional comments but, in order to save bandwidth on the
> list, perhaps I'll send the minor editorial ones (typos, wording
> clarifications, etc.) privately to the authors.  The rest are included
> below.
> 
> Abstract:  there is not a *need* for an interface to PK certification
> products and services based on [CMS] and [PKCS10]; there is a *desire* for
> such an interface.  Nothing *needs* to be based on CMS and PKCS10
> (especially since, as noted in the conformance section, existing deployed
> software is not immediately compliant with this specification).  However,
> there is great *desire* to base the protocols on CMS and PKCS10, since these
> are familiar.  Please change "need" in bullet 1 to "desire" (and change
> "immediate needs" in the opening sentence to "immediate concerns", or
> similar).
> 
> Section 2, Section 2.1, and elsewhere:  the document sometimes uses
> "certificate authority", sometimes uses "certification authority", sometimes
> uses "Certification Authority", and so on.  Please be consistent throughout.
> [Note that "Certification Authority" is the official term in various
> Standards.]
> 
> Section 2:  this may be obvious to many, but I think that stating the
> following underlying operational assumption will help to clarify the
> operational model for this protocol.  "Underlying assumption:  every PKI
> entity will have a signing key pair and will request a verification
> certificate in its initialization message (i.e., an entity will never ask
> for an encryption certificate _only_ in its initialization message)."  [The
> reason that it might help to clarify this is that RFC 2510 does not have
> this restriction.]
> 
> Section 3.3.3.1:  "D-H private keys cannot always be used..." -- note that
> is may also be true for RSA keys that are held in a decrypt-only device, so
> you need not restrict this section to D-H.
> 
> Also, "NoSignatureValue contains the hash of the certification request." --
> why force the implementer to do an extra hash here for no purpose?  Why not
> say that NoSignatureValue "contains the value 1234", or similar?
> 
> Section 5.2 (second paragraph):  "Servers SHOULD provide this method or have
> a bilateral method..." -- I would prefer the following for interoperability
> reasons:  "Servers MUST provide this method and MAY also have a bilateral
> method...".
> 
> Section 5.7:  should note in first paragraph that PKCS10 cannot be used to
> provide this functionality.
> 
> Also, it appears (from the text in bullet 4a and the text in the second-last
> sentence of the section) that the DecryptedPOP structure should contain
> "request    TaggedRequest" rather than "bodyPartID    BodyPartID".  That is,
> the decrypted POP needs to contain the actual request itself (not just an
> ID).
> 
> Section 5.9 (last paragraph):  "the server responds with a Key Recovery
> Response containing the newly generated key." -- it doesn't really make any
> sense semantically to use a key recovery response to implement off-client
> key generation (since off-client key generation is not key recovery).  Why
> not simply define a new message ("OffClientKeyGenRep") with the same syntax
> as Key Recovery Response?
> 
> Also, "The details of the request control statement not covered in this
> document...".  This will limit the use of this protocol in some environments
> (those that mandate central key gen.).  A request message needs to be
> defined for this purpose.
> 
> Section 5.9.3:  "The ContentInfo contains the requested private key
> material." -- does it also contain the newly-created recipient (i.e., EE)
> certificate?  If not, how can this response be used for off-client key
> generation?  [Note that according to CMS, it is not clear that it's legal
> for a CA to put the EE certificate in this construct....]
> 
> Sections 5.9.4.1, 5.9.4.2, 5.9.4.3:  in each section you need to say that
> the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
> subsequently be re-encoded as an OCTET STRING (in order to fit within the
> structure defined in Section 5.9.4).
> 
> Section 5.10:  "low-end IP router that does not retain its own certificate
> in non-volatile memory".  I might prefer "low-end IP router that does not
> retain in non-volatile memory the certificates of those entities with whom
> it needs to communicate".  Entities certainly need to get the certificates
> of others in order to talk with them; do they really need to keep their own
> certificates for most of their activities?
> 
> Section 5.11:  "The fields in a GetCRL have the following meanings:  --
> issuerName is the value of the Issuer DN in the subject certificate."  This
> will not work for Indirect CRLs.  Perhaps this field should hold the name of
> the CRL issuer instead...
> 
> Section 5.12:  "it is impossible to produce a reliable digital signature."
> -- this should be clarified to "it is impossible to produce a reliable
> digital signature (prior to the certification of a new signature key pair)."
> 
> Section 5.14:  "The query pending attribute allows for a client to query a
> server about the state..." -- how does the client know when to do this?  Is
> there a time-to-check-back value included somewhere in the server's
> response?
> 
> Section 6.1:  "The request is placed in the cmsSequence if it is a full pki
> message and the reqSequence field for a simple enrollment message." -- in
> the latter case, is this still a nested message?  (I.e., what is the
> difference between a "non-nested" message with a PKCS10 in the reqSequence
> and a "nested" message with a simple enrollment message in the reqSequence?)
> 
> Sections 7.2, 7.3:  replace "BER" with "DER" since signatures are
> involved...
> 
> Section 12:  update the CRMF reference to RFC 2511 and the PKIXCERT
> reference to RFC 2459.  Also, was DH-SIG not updated to some other draft
> recently?
> 
> Finally, there is some  functionality missing in this specification that
> will be very important for some environments.
> 
> - there is currently no way for a CA/RA to provide a trust anchor (public
> key or self-signed cert) to the client during initialization.
> 
> - there is no confirmation message from the client to the CA/RA (thus, there
> is no way for a client to reject a certificate that it does not want (e.g.,
> in the case where the CA has modified some of the fields in the request)).
> 
> - cross-certification is not described.  (It appears to be possible to do
> this with the existing messages, but without a prescribed method
> interoperability is unlikely.)
> 
> - as mentioned above, off-client key generation needs to be specified (both
> request and response).  It would also be nice to be able to ask for this as
> part of the Full PKI Request message, rather than having to use separate
> req/rep messages.
> 
> - CA key rollover is not described.  (This might be considered to be
> out-of-scope of the current document, but it is very much in-scope for a
> specification on how to do comprehensive certificate management, which is
> what the title of this document suggests.)
> 
> That's all.  Aside from a few other typos, etc., the document looks great!
> 
> Carlisle.

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA24166 for ietf-pkix-bks; Thu, 18 Mar 1999 00:42:12 -0800 (PST)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA24162 for <[e-mail]>; Thu, 18 Mar 1999 00:42:10 -0800 (PST)
Received: from roger ([10.0.0.20]) by marcellus.cost.se (8.9.3/8.9.3) with SMTP id JAA11657; Thu, 18 Mar 1999 09:45:40 +0100 (MET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 18 Mar 1999 09:47:56 +0100
To: [e-mail]
From: Martin =?iso-8859-1?Q?Lindstr=F6m?= <[e-mail]>
Subject: CRL version field confusion
Cc: [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 mail.proper.com id AAA24163
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think I've found an ambiguity(?) between rfc2459 and the X.509
in the way CRL version fields should be treated.

X.509 says: "If any extensions included in a CertificateList are
defined as critical, the version element of the CertificateList
shall be present. If no extensions defined as critical are included,
the version element shall be absent"

RFC2459 on the other hand says: "When extensions are used, as required
by this profile, this field MUST be present and MUST specify version 2"

Depending on which definition I use to encode a CRL having no critical
extensions I get different results. Is this correct?

/Martin


______________________________________
         Entegrity Solutions

  Martin Lindström
  Senior Systems Engineer 

  Finlandsgatan 60 
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA22624 for ietf-pkix-bks; Wed, 17 Mar 1999 23:36:21 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA22615 for <[e-mail]>; Wed, 17 Mar 1999 23:36:19 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id IAA13869 for <[e-mail]>; Thu, 18 Mar 1999 08:42:56 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA61915; Thu, 18 Mar 1999 08:42:45 +0100
Received: by HYDRA with Microsoft Mail id <01BE711B.65365DB0@HYDRA>; Thu, 18 Mar 1999 08:43:28 +0100
Message-ID: <01BE711B.65365DB0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: QC Sample Sucks (a bit)
Date: Thu, 18 Mar 1999 08:43:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
>I recommend to you the discussion on use of biometrics (like fingerprints,
>hand geometry, iris or retinal image patterns, etc.)  in open, networked
>systems contained in the recent "Trust in Cyberspace" report from the U.S.
>National Academy of Science.

I will, although my thought applications for this was limited to
the same situations as you use ID-cards in today.  That should NOT lead to 
severe problems.  See below:

>First, certificates often are stored and transmitted without
>confidentiality protection.

Wrong, ID-certificates containing hard (SSNs, Biometrics) information should
NEVER be transmitted in clear.  Although PKI stands for PUBLIC Key Infrastructure,
this cannot (should not at least) be interpreted as public for anybody. 
Just to your own selection of trusted RPs. 

>This raises the question of how one protects
>sensitive biometric data if it is embedded in a certificate.  Remember,
>this data needs to available to any entity who will use it for user
>authentication, yet it must not be made available to possible attackers,
>for the reasons cited below.

This is solved by only letting such certificates be fetched from the CA by the OWNER using a
"light" certificate.  Naturally using strong authentication/encryption.  The private/public keys
can be the same for the "heavy" ID to eliminate unnecessary key distribution

>It notes that if capture of a biometric if not physically secure, then
>there is a terrible risk of spoofing.

Absolutely, biometric capture is possible to spoof but in a PROTECTED area like
in a Bank or Passport-control, the scheme I have described would work much
better than current authentication systems.  Imagine a security officer that gets
a nice high-resolution picture on his PC instead of trying to see if that 1.5 inch
photo really is you!

And if you package the "light" cert in a CyberPhone you would just have to point to
a receiver, Click Yes if you agree to be authenticated by the RP and that's it!

>The observation is that a server
>with biometric data will, invariably be compromised.  The result is that
>the user biometric templates contained in the server, as well as the
>algorithms used for matching, will be exposed. 

The algorithms MUST IMO be known and servers can be made secure.  If the
staff running a CA are crooks the whole PKI idea is dead-meat so I do not
take this in account.

>Knowledge of the templates
>and the algorithms permits at attacker to generate bit streams that will
>suffice to authenticate the user's whose templates were compromised. Thus,
>unless there is very good technical and physical security for capture of
>user biometrics, to preclude introduction of bogus bit streams that purport
>to be real biometrics, such systems are fatally flawed.

Again, the applications for biometrics are not for remote and unsecured use.

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA01959 for ietf-pkix-bks; Wed, 17 Mar 1999 16:17:08 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA01955 for <[e-mail]>; Wed, 17 Mar 1999 16:17:06 -0800 (PST)
Received: from [128.33.238.134] (TC134.BBN.COM [128.33.238.134]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id TAA14965; Wed, 17 Mar 1999 19:23:37 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b315db7d981e@[128.33.238.103]>
In-Reply-To: <01BE7078.DB50BAC0@HYDRA>
Date: Wed, 17 Mar 1999 17:35:05 -0500
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC Sample Sucks (a bit)
Cc: "'SEIS-List'"<[e-mail]>, "'[e-mail]'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

I recommend to you the discussion on use of biometrics (like fingerprints,
hand geometry, iris or retinal image patterns, etc.)  in open, networked
systems contained in the recent "Trust in Cyberspace" report from the U.S.
National Academy of Science.

First, certificates often are stored and transmitted without
confidentiality protection.  This raises the question of how one protects
sensitive biometric data if it is embedded in a certificate.  Remember,
this data needs to available to any entity who will use it for user
authentication, yet it must not be made available to possible attackers,
for the reasons cited below.

It notes that if capture of a biometric if not physically secure, then
there is a terrible risk of spoofing.  The observation is that a server
with biometric data will, invariably be compromised.  The result is that
the user biometric templates contained in the server, as well as the
algorithms used for matching, will be exposed.  Knowledge of the templates
and the algorithms permits at attacker to generate bit streams that will
suffice to authenticate the user's whose templates were compromised. Thus,
unless there is very good technical and physical security for capture of
user biometrics, to preclude introduction of bogus bit streams that purport
to be real biometrics, such systems are fatally flawed.


Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28873 for ietf-pkix-bks; Wed, 17 Mar 1999 10:20:11 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA28869 for <[e-mail]>; Wed, 17 Mar 1999 10:20:10 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 17 Mar 1999 10:48:15 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 17 Mar 1999 10:48:05 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: SEIS:  Regarding "Given names"
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 mail.proper.com id KAA28870
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that would be possible, to issue multiple certificates and to put
appropriate ID information into each certificate, although it may lead 
to an enormous proliferation of certificates -- one for each unique 
application, at worst.  (Of course if you sell certificates, the more the merrier! :-)

But with respect to the "additional security problems associated with
directories," I was not referring to directories operated by some 
independent third-party, but to enterprise directories that are operated
by the same people that administer the various applications.

If I authenticate a user using one primary certificate, and then look 
up additional names forms and/or other attributes in the enterprise directory,
that association can certainly be as trusted as the applications themselves,
as they are probably managed by the same sets of people.

For that matter, the same basic sets of people are probably operating the 
RA functions that are used to issue the certificates as well.

Bob



>>> Stephen Kent <[e-mail]> 03/17/99 07:43AM >>>
Bob,

>You have introduced yet another degree of freedom into to this complex
>equation.  I had been sufficiently puzzled how to manage the mapping
>between a certificate and one or more directories, i.e., the Subscriber or
>Subject's directory (presumably one operated by his employer, or possibly
>his Internet Service Provider, or maybe some government agency or third
>party); the CA's directory (or maybe some third party repository), and the
>various Relying parties directories. But now you have introduced another
>level of complexity in wanting to map directly to customer databases,
>access control lists, patient records, etc.
>
>I think this may be way too much to deal with.  Instead, those application
>should refer to the directories to look up that additional information as
>required for their purposes.

Or, we can issue multiple certificates and put appropriate ID info in each.
That way we don't embrace all of the additional security problems
associated with directories.

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28807 for ietf-pkix-bks; Wed, 17 Mar 1999 10:13:24 -0800 (PST)
Received: from postoffice.mr.net (staffinfo.MR.Net [137.192.180.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28802 for <[e-mail]>; Wed, 17 Mar 1999 10:13:10 -0800 (PST)
Received: by postoffice.mr.net (8.8.8/8.8.8) with SMTP id MAA03798 at Wed, 17 Mar 1999 12:19:32 -0600 (CST) SMTP "HELO" = balenson.44ietf.mr.net But _really_ from host167.44IETF.MR.Net [209.32.92.167] SMTP "MAIL FROM" = [e-mail] SMTP "RCPT TO" = 
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 17 Mar 1999 13:18:44 -0500
To: [e-mail]
From: "David M. Balenson" <[e-mail]>
Subject: CFP: ISOC Year 2000 Network & Distr. System Security (NDSS 2000)
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000


IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

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

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base
    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal
    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions




PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most two pages and should describe the topic, identify
  the panel chair, explain the format of the panel, and list three
  to four potential panelists.  Technical papers will appear in
  the proceedings. A description of each panel will appear in the
  proceedings, and may -- at the discretion of the panel chair --
  include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: [e-mail]
        TEL: [phone] ext 329
        FAX: [phone] 

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

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified

  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.


----------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738  USA
[e-mail]; 443-259-2358; fax [phone]
pgp fingerprints FD53 918E 097A 2579 C1A8  34F8 E05D E74F AC1D E184 (DSS/DH)
                 D43B 565B 2C0E 90F4  38BB D9EA 1454 3264 (RSA)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28737 for ietf-pkix-bks; Wed, 17 Mar 1999 10:07:20 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA28733 for <[e-mail]>; Wed, 17 Mar 1999 10:07:19 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 17 Mar 1999 10:32:14 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 17 Mar 1999 10:32:08 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: SEIS:  Regarding "Given names"
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 mail.proper.com id KAA28734
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Resent to correct the correct address of the pkix list.]

Hi Petra,

(Someone corrected me for referring to you as "he". 
I guess I assumed that Petra was the equivalent 
of the English "Peter," but I should have caught the 
feminine ending.  I apologize.)

I certainly understand that there are lots of certificates 
containing DNs which don't correspond to entries in ANY
directory, much less some well-structured, as-God-intended
x.500 directory with X.520 DIT structure and schema.

My point is, and I am agreeing with you to at least a certain 
extent, that if we continue to throw completely arbitrary
name constructs in the DN, we will make it increasingly difficult
to ever store or retrieve those certificates in or from a directory.

So my goal was to get people to recognize that the primary
purpose of the DN was to facilitate interoperation with a directory.
And since there may very well be a proliferation of directories with
incompatible DIT structures and schemas, it is necessary to 
recognize that it is the _subscriber's_ directory that must dictate the
DIT structure and schema -- not the CA's, and not the recipient's.

Other technical functions such as name subordination may or may
not have a role to play with respect to the DN.  They could, but
I suspect that it may not be terribly useful in most cases, just 
because directory names are (unfortunately) not often organized 
along the lines of organizational boundaries that name subordination
assumes.

I agree that when writing application software you cannot always 
assume that the DN points to an X.500 entry, as one may never have
been created.  I would say that it OUGHT to, but it might not.

On the other hand, I believe that it would be WRONG to believe
that an alternateSubjectName, in particular, would always point to
a certificate, or even to a directory entry of any kind.  Again, perhaps
it ought to, but I may have chosen to express my name and organizational 
structure in a more conventional fashion, perhaps for ease of display and 
recognition, but without a corresponding entry in any existing directory --
not even an alias.

For example, my directory name in Novell's corporate directory in business 
card format (top to bottom) is o=novell, ou=prv, ou=nsrd, cn=bjueneman.

But what I would like to have displayed in someone's certificate viewing 
software would be c=US, o="Novell, Inc.", ou="Network Products Division",
ou="Network Security Department", cn="Robert R. Jueneman"

Since the purpose of the DN is to convey an entry in the directory, the
first name form clearly has to be the DN, and the second name form the
alternateSubjectName.  But that second name form is not an entry in the 
Novell corporate directory,  not even an alias, and not likely to be any time 
soon, even if it has the form directoryName.

I agree that it would be quite reasonable to create an alias for such a 
name in a directory somewhere, and I would encourage such a practice.
I also believe that it may be desirable to include other directory style 
names as additional alternateSubjectNames, perhaps to support other DIT
structures and/or schemas, but I don't believe that the ietf-pkix group 
is in a position to mandate that a particular alternateSubjectName reflect
a real entry in any particular directory.  And whether they mandate it or
not, it isn't likely to happen world-wide any time soon.

As for the additional information you may require that go beyond "name"
information per se, I would suggest that you make your PersonalData
structure a subjectDirectoryAttributes attribute extension (if someone can 
ever figure out what the semantics of _that_ attribute are supposed to be),
or else simply define a new attribute extension.

But in general I would be rather opposed to listing much of the type of 
information you have suggested in a certificate at all, and certainly not in
a name field.  

A certificate is supposed to be a certificate, not a dossier.

I'm glad we are finally having this discussion.  I just wish we had concluded
it, rather than leaving it up in the air, when it began six or seven years ago.

Bob


>>> "Petra Gl÷ckner" <[e-mail]> 03/16/99 09:59AM >>>
Hi Bob,

if you look at existing PKIs you will see that it's quite common to
use Subject DNames which are no entries in a X.500 Directory. These
names are simply used to select certificates or CRLs which are stored 
locally. In former times(PEM) DNames have been additionally used for 
realizing name subordination. So a DName can serve for more than one 
technical purpose. Nowadays with X.509v3 you don't need the DName 
anymore for certificate chaining etc, but that's the way how still 
a lot of software works.
Writing application software you cannot assume that the DName points 
to an X.500 entry, but if there is an AltName extension containg a 
directoryName than you can be sure that you will find a certificate 
there.

We don't require a person's name to be his birth certificate, passport, 
library card, fingerprint card or DNA record. What a person's name is 
has to be defined by national law or policy, and this of course will 
differ. But whatever the definition will be, the required information 
should be put in the PersonalData structure of the subjectAltName 
extension - that's what we propose.

Best regards - Petra (she)

Bob Jueneman wrote:
> 
> Petra said "We recommend to use the respective AltName extension(directoryName) to point to the X.500 Directory entry instead of using the Subject DName." I'm not quite sure what he meant, but I don't think I would agree with him. The Subject DN's one and only purpose, I believe , should be to define the subject's name, i.e., entry reference, in a directory. I would tend to disagree with including an e-mail address or other  superfluous "technical" information in the certificate at all, and especially in a name field.
> 
> I agree that the Subject's "real" name should be contained in the subjectAlternateName field. However, I am not nearly as certain as to the extent to which this represents the "unmistakable identity of the certificate subject" if by that is meant that the name must be globally unambiguous, and in particular if it has to carry all of the other baggage that has been proposed.  A person's name should not be required to be his birth certificate, passport, library card, fingerprint card and DNA record all rolled up into one.
> 
> Regards,
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail] 
> 1-801-861-7387
> 


> Subject: SEIS: Re: Given names
> Resent-Date: Mon, 15 Mar 1999 10:02:35 +0100 (MET)
> Resent-From: [e-mail] 
> Date: Mon, 15 Mar 1999 10:03:40 +0100
> From: "Petra Glöckner" <[e-mail]>
> To: [e-mail] 
> References: <[e-mail]>
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> Writing the Qualified Certficate and the German certificate
> specification we had a long discussion on this naming issue.
> We finally came to the conclusion that the best way to solve
> this problem is to have TWO KINDS of names in a certificate:
> 
> TECHNICAL NAME(S):
> The Subject DName and the SubjectAltName extension will contain
> one or more technical names, to be used for certificate chaining,
> to identify the respective X.500 directory entry or to carry the
> email address or any other technical information.
> We recommend to use the respective AltName extension(directoryName)
> to point to the X.500 Directory entry instead of using the Subject
> DName.
> 
> OFFICIAL/LEGAL NAME:
> We defined a new data structure to be used in the SubjectAltName
> extension(otherName). This new data structure PersonalData has
> to contain the unmistakable identity of the certificate subject
> according to the respective law or policy.
> Please note: the Qualified Certficate and the German certificate
> specification still differ in the PersonalData definition. Once
> the Qualified Certficate draft is settled we will adjust the German
> specification.
> 
> Regards - Petra
> 

> >
> > 2. Please note that the Distinguished Name in the certificate has nothing to
> > do with how/where the certificate is stored in the directory. They just
> > happen to use the same RDN syntax :-)
> > I may for example have a National EID-card with C=SE, CN=Hans Nilsson
> > SN=123456. This is then stored at C=SE, O=iD2, CN=...
> > It took me some time before I understood this, and I have now seen that this
> > difference is explicitly pointed out in the German certificate
> > specification.
> >
> > Regards
> > Hans
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28144 for ietf-pkix-bks; Wed, 17 Mar 1999 09:05:14 -0800 (PST)
Received: from fep01-svc.tin.it (mta01-acc.tin.it [212.216.176.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28140 for <[e-mail]>; Wed, 17 Mar 1999 09:05:11 -0800 (PST)
Received: from squalo ([208.164.5.201]) by fep01-svc.tin.it (InterMail v4.0 201-221-105) with SMTP id <19990317171100.XWJR2097.fep01-svc@squalo> for <[e-mail]>; Wed, 17 Mar 1999 18:11:00 +0100
Message-ID: <05b501be7099$3476ca20$[e-mail]>
From: "Sergio Tabanelli" <[e-mail]>
To: <[e-mail]>
Subject: Signature request ?
Date: Wed, 17 Mar 1999 18:11:25 +0100
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Excuse me if this is an out of topic question.
Working in  the development of a PKI for the public administration and
related services, I am involved in the definition of new PKI messages used
for the management of request and response between two End Entity that need
to exchange signature request (documents to be signed on request) and
signature response (signed documents on response), we call them "sign
request" and "sign response".
Considering the increasing activity of the EU and its Member States
concerning Digital
Signature directives and specifications, I think that this maybe an
inportant issue for the
development of Digital Signature. So I am asking if PKIX or someone else are
actually
involved or plan to involve on this topic.

Sergio Tabanelli
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA24896 for ietf-pkix-bks; Wed, 17 Mar 1999 04:13:08 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24892 for <[e-mail]>; Wed, 17 Mar 1999 04:13:04 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA31701 for <[e-mail]>; Wed, 17 Mar 1999 13:19:30 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA102181; Wed, 17 Mar 1999 13:19:14 +0100
Received: by HYDRA with Microsoft Mail id <01BE7078.DB50BAC0@HYDRA>; Wed, 17 Mar 1999 13:19:59 +0100
Message-ID: <01BE7078.DB50BAC0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: =?iso-8859-1?Q?=27Petra_Gl=F6ckner=27?= <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, "'SEIS-List'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: QC Sample Sucks (a bit)
Date: Wed, 17 Mar 1999 13:19:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Petra,
I have some comments on the QC "Sample Certificate" that contained data
about you.

Although a sample is just a sample I still think that a sample should be "typical".

I see two VERY different situations (which should be in the draft) when QCs are used:

1. Remote (the Relying Party has no visual or physical contact).   In that scenario
you cannot verify any biometrics like age, sex etc.   I.e. you should not require that
kind of information in a remote situation as it makes no sense for automated
identification purposes.   There may be exceptions when the RP needs biometrics 
but that calls for another QC that you would use in those rare circumstances.

2. Physical.  RP have visual or physical contact with the subject and *could* 
use biometrics to verify that the certificate holder seems to be matching.  In this case
you may need photo, fingerprint, age, sex etc in the QC itself as this data is not necessarily
printed on a smart card holding the QC.  The "card" could actually be a miniaturized
thing within a mobile phone.  ( www.mobilephones-tng.com/v100/cyberphonecards.html )

So I urge you to make room in the QC draft for some biometrics (in a structured way) and
to make TWO or more samples.

Consequence: You cannot have just one QC to cope with all possible uses!

Regards
Anders Rundgren
Senior Internet e-commerce Architect
Jaybis AB
http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21291 for ietf-pkix-bks; Wed, 17 Mar 1999 00:36:20 -0800 (PST)
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21263; Wed, 17 Mar 1999 00:34:31 -0800 (PST)
Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5)  with ESMTP id JAA17405; Wed, 17 Mar 1999 09:40:04 +0100 (MET)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 17 Mar 1999 09:40:04 +0100 (MET)
From: "CMS'99" <[e-mail]>
To: [e-mail]
Subject: Communications and Multimedia Security '99
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Apologies if you receive this more than once]

NEW DEADLINE FOR THE CMS'99 CONFERENCE: 

April 2nd, 1999

The call for papers can be found at 
http://www.esat.kuleuven.ac.be/cosic/cms99/





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21158 for ietf-pkix-bks; Wed, 17 Mar 1999 00:28:10 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21152 for <[e-mail]>; Wed, 17 Mar 1999 00:28:07 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id JAA05106 for <[e-mail]>; Wed, 17 Mar 1999 09:34:35 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA77914; Wed, 17 Mar 1999 09:34:00 +0100
Received: by HYDRA with Microsoft Mail id <01BE7059.5BD30970@HYDRA>; Wed, 17 Mar 1999 09:34:30 +0100
Message-ID: <01BE7059.5BD30970@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "[e-mail]" <[e-mail]>, "'Michael Crerar'" <[e-mail]>
Subject: RE: X.509 Attribute Certificates extensions in PKIX Certificates?
Date: Wed, 17 Mar 1999 09:34:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,
Michael Crerar wrote:
I haven't seen a reaction to this message and I am also interested in
the state of PKIX standards regarding attribute certificates.  Do any of
the current PKIX standards describe the format of an attribute
certificate and the role of the entity issuing attribute certificates? 
Or is the attribute certificate only a concept that has yet to be
formalized?

I think that the closest you can get is this IETF draft:

http://www.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt

A "slight" problem is how to use attribute certificates and the link below
contains a suggestion that could be applied to practically any PKI:

http://www.mobilephones-tng.com/v100/dynamiccerts.html

I would VERY MUCH APPRECIATE your (entire PKIX-list) comments to this!

Regards
Anders Rundgren
Senior Internet e-commerce Architect
Jaybis AB
+46   70 - 627 74 37
http://www.mobilephones-tng.com





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27352 for ietf-pkix-bks; Tue, 16 Mar 1999 15:01:43 -0800 (PST)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27348 for <[e-mail]>; Tue, 16 Mar 1999 15:01:41 -0800 (PST)
Received: from host248.44ietf.mr.net (host127.44IETF.MR.Net [209.32.92.127]) by popmail.inbox.se (8.8.7/8.8.7) with SMTP id AAA10794 for <[e-mail]>; Wed, 17 Mar 1999 00:08:10 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 17 Mar 1999 00:22:04 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Information site for Qualified certificates progress
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 mail.proper.com id PAA27349
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Just before the PKIX meeting tomorrow in Minneapolis I have finalized an
informational web-site for the Qualified Certificates work item.

URL:  http://www.accurata.se/QC/

This site will continuously be updated during the work process. Here you
will find both settled and unsettled topics and se how the editors has
responded to the discussions.

If you disagree to any of the conclusions or miss any information here,
please let me now.

For those of you who are in Minneapolis I will be at the PKIX meeting
presenting the work.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23982 for ietf-pkix-bks; Tue, 16 Mar 1999 10:04:56 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23977 for <[e-mail]>; Tue, 16 Mar 1999 10:04:52 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id NAA06547; Tue, 16 Mar 1999 13:08:55 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
X-Priority: 2 (High)
Date: Tue, 16 Mar 1999 13:10:00 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: RE: X.509 Attribute Certificates extensions in PKIX Certificates?
Cc: [e-mail], [e-mail]
In-Reply-To: <1364A0D05FB8D111BD970000F8775F100CAF50@DVNET2>
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 mail.proper.com id KAA23979
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The only mention of Attribute Certificates in PKIX standards that I am
aware is at the end of Section 2 of PKIX Part 1 (RFC 2459) where is
indicated that:

   As supplemental authorization and attribute management tools emerge,
   such as attribute certificates, it may be appropriate to limit the
   authenticated attributes that are included in a certificate.  These
   other management tools may provide more appropriate methods of
   conveying many authenticated attributes.

The current PKIX standards do not define the format of an Attribute
Certificate and the role of the entity issuing Attribute Certificates. Work
is still ongoing under the ISO Directory Group (i.e. PDAM 1 to X.509(97))
to define Attribute Certificate's extensions. These extensions will be
necessary to control the delegation of privileges contained in Attribute
Certificates.

Current PKIX standards will need to be expanded to support Attribute
Certificates. For example, the template for a certificate content request
(i.e. CertTemplate), which is defined in CRMF (RFC 2511), is not meant for
Attribute Certificates since the owner and subject fields of an Attribute
Certificate have a different syntax than in a public-key certificate. In
addition, the CertTemplate does not contain a field to request attributes
that will contained in an Attribute Certificate, although these could be
added under a new control type in the CertRequest.

Francois Rousseau
AEPOS Technologies

At 09:53 AM 16/03/99 -0500, you wrote:
>I haven't seen a reaction to this message and I am also interested in
>the state of PKIX standards regarding attribute certificates.  Do any of
>the current PKIX standards describe the format of an attribute
>certificate and the role of the entity issuing attribute certificates? 
>Or is the attribute certificate only a concept that has yet to be
>formalized?
> 
>=================================== 
>Michael Crerar 
>Cryptographer, Diversinet Corp. 
>http://www.dvnet.com/
>e-mail:  [e-mail] =================================== 
>
>-----Original Message-----
>From: Zahid Ahmed [mailto:[e-mail]]
>Sent: Friday, March 12, 1999 11:35 AM
>To: [e-mail]
>Subject: X.509 Attribute Certificates extensions in PKIX Certificates?
>
>
>Is there currently any support to generate X.509 Attribute Certificates
>in 
>PKIX?
> 
>1. If not, how can we extend and/or generate such a certificate using 
>PKIX for organizations/groups/roles? The thing is that an attribute
>certificate 
>does not have a public key associated with it. Hence, it can not, e.g., 
>extend public key Certificate structure. (Or, if does, we are really 
>associating a public key with a group or organization which 
>is not compatible, I believe, with PKIX X.509 end-entity identity 
>X.509 certs).
> 
>How can one create a X.509 Attribute Certificate using current PKIX?
> 
>2. Also, I want to be able to include multiple attribute certificate in
>a 
>X.509Certiifcate which is an extension of
>java.security.cert.certificate. 
>How can we add such an extension to X.509Certificate class?
> 
>Please provide recommendation of how this can be done for allowing 
>groups and roles to be associated with an end-entity X.509 certificates.
>I know, e.g., there will be S/MIME and SSL clients that can take
>advantage 
>of such additional auth information about the subject. 
> 
>Zahid Ahmed                     Commerce One, Inc.
>Commerce Security Architect
>email: [e-mail]
>v: (650)-623-2814
>fax: [phone] 
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23326 for ietf-pkix-bks; Tue, 16 Mar 1999 09:18:10 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23322 for <[e-mail]>; Tue, 16 Mar 1999 09:18:07 -0800 (PST)
Received: from [128.33.238.103] (TC103.BBN.COM [128.33.238.103]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA09455; Tue, 16 Mar 1999 12:24:20 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a00b3141fe2e36f@[128.33.238.179]>
In-Reply-To: <01be6f06$05747e00$[e-mail]>
Date: Tue, 16 Mar 1999 10:02:31 -0500
To: "Zahid Ahmed" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Regarding "Given names"
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Zahid,


>However, I think it is going to valuable if we can include in we can
>link the basic user object, as viewed and managed from the
>enterprise security standpoint, to the application-level user object,
>i.e., the customer user object. Internet applications must have
>reliable and consistent user management frameworks.

The focus of qualified certificates is identification suitable for
non-rtepudiable, legal signatures.  Many applications do not require such
certificates, so it may not be reasonable, or necessary, to find a way to
universally link name forms in these qualified certs to name forms employed
by a wide range of applications.  However, I do agree with the basic
principle you cite here, i.e., close matching of name forms between certs
and applications.  My general suggestion of how to achieve this is by
issuing multiple certs to users, each with a name form managed by an
application (or closely releated set of applications).

> I don't see in PKIX any thing clearly defined to bridge the gap between
>primitive, secuirty-centric, user Objects (based on X.509) and
>application-level user object that clients are going to initialize
>routinely.

Well, it depends on the applications.  For example, RFC 2459 encourages use
of the rfc822Name AltSubjectName for S/MIME users.  That's a good example
of a nice, close mapping.  In the IPsec context, appropriate name forms
include IP addresses, DNS names, and rfc822 names, all of which are
supported in X.509 certs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21849 for ietf-pkix-bks; Tue, 16 Mar 1999 06:40:00 -0800 (PST)
Received: from dvnet2.dvnet.com ([209.121.31.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21845 for <[e-mail]>; Tue, 16 Mar 1999 06:39:59 -0800 (PST)
Received: by DVNET2 with Internet Mail Service (5.5.1960.3) id <FXAZW1LN>; Tue, 16 Mar 1999 09:53:26 -0500
Message-ID: <1364A0D05FB8D111BD970000F8775F100CAF50@DVNET2>
From: Michael Crerar <[e-mail]>
To: [e-mail]
Subject: RE: X.509 Attribute Certificates extensions in PKIX Certificates?
Date: Tue, 16 Mar 1999 09:53:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA21846
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I haven't seen a reaction to this message and I am also interested in
the state of PKIX standards regarding attribute certificates.  Do any of
the current PKIX standards describe the format of an attribute
certificate and the role of the entity issuing attribute certificates? 
Or is the attribute certificate only a concept that has yet to be
formalized?
 
=================================== 
Michael Crerar 
Cryptographer, Diversinet Corp. 
http://www.dvnet.com/
e-mail:  [e-mail] =================================== 

-----Original Message-----
From: Zahid Ahmed [mailto:[e-mail]]
Sent: Friday, March 12, 1999 11:35 AM
To: [e-mail]
Subject: X.509 Attribute Certificates extensions in PKIX Certificates?


Is there currently any support to generate X.509 Attribute Certificates
in 
PKIX?
 
1. If not, how can we extend and/or generate such a certificate using 
PKIX for organizations/groups/roles? The thing is that an attribute
certificate 
does not have a public key associated with it. Hence, it can not, e.g., 
extend public key Certificate structure. (Or, if does, we are really 
associating a public key with a group or organization which 
is not compatible, I believe, with PKIX X.509 end-entity identity 
X.509 certs).
 
How can one create a X.509 Attribute Certificate using current PKIX?
 
2. Also, I want to be able to include multiple attribute certificate in
a 
X.509Certiifcate which is an extension of
java.security.cert.certificate. 
How can we add such an extension to X.509Certificate class?
 
Please provide recommendation of how this can be done for allowing 
groups and roles to be associated with an end-entity X.509 certificates.
I know, e.g., there will be S/MIME and SSL clients that can take
advantage 
of such additional auth information about the subject. 
 
Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: [e-mail]
v: (650)-623-2814
fax: [phone] 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21770 for ietf-pkix-bks; Tue, 16 Mar 1999 06:33:12 -0800 (PST)
Received: from host5.janus.sec.nl ([e-mail] [192.87.0.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21762 for <[e-mail]>; Tue, 16 Mar 1999 06:33:10 -0800 (PST)
Received: from sec.nl (host2.janus.sec.nl [192.87.0.19]) by host5.janus.sec.nl (8.8.7/8.8.7) with ESMTP id OAA25635; Tue, 16 Mar 1999 14:04:46 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 Mar 1999 15:43:44 +0100
From: Janus Liebregts <[e-mail]>
Organization: SURFnet ExpertiseCentrum bv
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: rfc2527 implementations
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

has anyone made an implementation of rfc2527 or
draft-ietf-pkix-ipki-part4-03 into a CPS?

We are implementing a CPS according to the rfc and could use some ideas
;)

regards,
Janus Liebregts
SURFnet ExpertiseCentrum bv
The Netherlands


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20727 for ietf-pkix-bks; Tue, 16 Mar 1999 05:14:52 -0800 (PST)
Received: from e5.ijs.si ([e-mail] [193.138.1.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20723 for <[e-mail]>; Tue, 16 Mar 1999 05:14:48 -0800 (PST)
From: [e-mail]
Received: (qmail 27630 invoked by uid 1021); 16 Mar 1999 13:21:02 -0000
Message-ID: <[e-mail]>
Subject: Equivalent policies in path validation procedure
To: [e-mail]
Date: Tue, 16 Mar 1999 14:21:02 +0100 (MET)
X-Mailer: ELM [version 2.4 PL0]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

perhaps I am missing some obvious points, but reading the basic path
validation procedure in RFC 2459, I could not see how equivalent policies were 
used. Can someone please give me a hint? Since the new value of the acceptable 
policy set is obtained as the intersection of the old value and critically
marked policies extension, should policies (P1 in the following example)
automatically be switched with equivalent policies in this set? Or should
equivalent policies be added to the set in step (e-2)? Policies extensions 
in the example are marked critical, there are no policy constraints, and 
USER1 is trying to validate the path from MT CA to USER2. Is this a valid 
example? Also, should USER1 really know in advance all the policies that are 
equivalent to P1?
 

       MT CA (most trusted CA)
	 |
      P1 |
	CA1 --- CA2   (P1 equiv. to P2; CA certificate with non-critical 
	 |	 |     policy mappings extension)
      P1 |       | P2
	CA3	CA4
	 |       |
      P1 |	 | P2
       USER1   USER2


Regards, 

Tomaz


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA08787 for ietf-pkix-bks; Tue, 16 Mar 1999 00:42:48 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA08772 for <[e-mail]>; Tue, 16 Mar 1999 00:42:45 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id JAA27647 for <[e-mail]>; Tue, 16 Mar 1999 09:49:04 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA22687 for <[e-mail]>; Tue, 16 Mar 1999 09:49:01 +0100
Received: by HYDRA with Microsoft Mail id <01BE6F92.54831E20@HYDRA>; Tue, 16 Mar 1999 09:49:48 +0100
Message-ID: <01BE6F92.54831E20@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Regarding "Given names"
Date: Tue, 16 Mar 1999 09:49:47 +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 mail.proper.com id AAA08781
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,
>Gunnar,
>You have introduced yet another degree of freedom into to this complex equation. 
snip
>I think this may be way too much to deal with.  Instead, those application should refer to >the directories to look up that additional information as required for their purposes.

I agree that there is no point in making the name issue extremely sophisticated as this
will just lead to new problems with interpretation and use.  To use directories for additional
names and information though assumes that the requesting party has access to other
data concerning the person which effectively limits such a scheme to Intranets or to
genuinely public information [such as...].

Another solution is that a CA issues ID-certificates with other data (Picture, Fingerprint,
Names according to local laws etc.) and let the user [only] access those by authentication with
his/hers "Commerce ID" certificate (which would as you suggest not necessarily contain a
globally unique, always legal name but a unique number within the directory).
All ID-certificates for a certain user and CA could have the same public/private keys to
avoid further key distribution and keep private key operations local. 
Then the control and privacy is in the hands of the user. 
 
Alternatively attribute certificates can be accessed using the scheme above.

Regards

Anders Rundgren
Senior Internet e-commerce Architect

http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18588 for ietf-pkix-bks; Mon, 15 Mar 1999 17:03:52 -0800 (PST)
Received: from mail.veosystems.com (davinci.veosystems.com [209.130.191.171]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA18584 for <[e-mail]>; Mon, 15 Mar 1999 17:03:51 -0800 (PST)
Received: (qmail 12602 invoked from network); 16 Mar 1999 01:10:10 -0000
Received: from cerberus-dmz.veosystems.com (HELO veosystems.com) (209.130.191.169) by davinci.veosystems.com with SMTP; 16 Mar 1999 01:10:10 -0000
Received: (qmail 11500 invoked from network); 16 Mar 1999 01:10:10 -0000
Received: from cassatt.veosystems.com (HELO cassatt) (10.0.0.32) by archimedes.veosystems.com with SMTP; 16 Mar 1999 01:10:10 -0000
From: "Zahid Ahmed" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Regarding "Given names"
Date: Mon, 15 Mar 1999 09:05:26 -0800
Message-ID: <01be6f06$05747e00$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_1771_01BE6EC2.F7513E00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_1771_01BE6EC2.F7513E00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

 I agree we want to limit the scope of naming attribute to a minimum
set so that the mapping between certificates and directories can be
administered easily and reliably.

However, I think it is going to valuable if we can include in we can
link the basic user object, as viewed and managed from the
enterprise security standpoint, to the application-level user object,
i.e., the customer user object. Internet applications must have
reliable and consistent user management frameworks.

 I don't see in PKIX any thing clearly defined to bridge the gap between
primitive, secuirty-centric, user Objects (based on X.509) and
application-level user object that clients are going to initialize
routinely.


Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: [e-mail]
v: (650)-623-2814
fax: [phone]
-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Monday, March 15, 1999 4:05 PM
Subject: Regarding "Given names"


(Because I believe the subject is important, I am cross-posting this to the
ietf-pkix list as well. Apologies for any duplicates.)

Gunnar,

You have introduced yet another degree of freedom into to this complex
equation.  I had been sufficiently puzzled how to manage the mapping between
a certificate and one or more directories, i.e., the Subscriber or Subject's
directory (presumably one operated by his employer, or possibly his Internet
Service Provider, or maybe some government agency or third party); the CA's
directory (or maybe some third party repository), and the various Relying
parties directories. But now you have introduced another level of complexity
in wanting to map directly to customer databases, access control lists,
patient records, etc.

I think this may be way too much to deal with.  Instead, those application
should refer to the directories to look up that additional information as
required for their purposes.

I am increasingly inclined to try to reduce these very complex naming
problems down to two different forms of names, and in this regard I believe
that I am in fairly close agreement with Petra Gloeckner's position
reflected by his attached message.

The first, which is the single Distinguished Name, is the name by which the
Subject is known to the Subject's own, primary directory, with a prefix if
necessary to specify which directory that is and where it can be found. In
addition to defining how to access that directory, the prefix name/location
of the directory itself may be necessary to define the scope of names issue
in order to make the DN globally unambiguous.  In this directory-oriented
name structure, it is perfectly acceptable if the name is not particularly
human readable or relevant, or tied to physical location, geopolitical
boundaries, or organizational structures.  In those countries where a
universal serial number is defined and considered acceptable for use (which
the US Social Security Number is not, despite its widespread use and abuse),
such an ID number could be used.  Otherwise, a unique number within the
scope of that directory can be used.

The second name should be the subject's own current chosen name form.  The
extent to which that name must conform to "official" registered names may be
controlled by law or custom, but should not be presumed.  The name in this
case is not necessarily globally unambiguous. The inclusion of additional
information in the name, such as current residence or organizational
information may be helpful in making it globally unambiguous, but should not
be required or presumed.  Instead, additional attributes that are not part
of the name per se may supply that information if that is desired, but there
may be complex privacy issues that would arise in that case.

Those of us in the US are frequently guilty of assuming that our own legal
and cultural customs are universal, and of course they are not.  But I would
also caution my European colleagues that the reverse may be true, and this
applies in particular to the issue of "official" names.  There is a wide gap
between the practices in many of the civil law countries regarding the
acceptable composition of names, and how they are officially registered, vs.
the common law countries such as the US, the UK, and others.  And I'm not
even going to speculate about some of the African and Asian countries.
That's why I suggest that the Subject's own name be considered to be up to
the Subject, with few if any presumptions being made as to how "official"
that name is (with the exclusion of deliberate fraud.).

Of course it would be presumptuous of me to tell the German government or
any other government how to write their laws or regulations, but the
Internet essentially knows no boundaries, and codifying particular
assumptions into law when they aren't universally warranted is likely to
result in the law being ignored as unhelpful.

A case in point regarding Gunnar's description of alias names would be my
father, who in his 87 years has gone through several names that are
technically.  Born in 1911 of second generation Germanic heritage, his birth
certificate lists his name as Frederick Reade Juenemann, and as a boy he was
sometimes called Fritz. But his father was a US Army medical doctor and
officer, and when my father started school in a succession of schools on
Army posts, World War I had started in Europe, and shortly afterwards the US
entered the war against Germany.  Having an obviously Germanic surname and
nickname probably didn't make his life any easier, and so without any formal
or official process, he dropped the final 'n' and nickname, and registered
his name in that form all the way through college.

Sometime during World War II, while serving in the Philippines, he decided
that "Frederick" was too much, since everyone called him Fred.  So again,.
without going through any formal change of name process, he simply dropped
the Frederick Reade and became Fred R. Jueneman, and was registered to vote,
etc., under that name from then on.  But in his will, which he signs as Fred
R., he is careful to list as "A.K.A." (also known as) aliases the other two
name forms.

Now, I suppose if he were so inclined he might request a certificate that
contained those alternate names, but I can't imagine why he would want to,
or what legitimate purpose might be served by requiring them.

By and large, then, the governing principle for a subject's name should be
whatever the Subject prefers.  In my case, that would be "Robert R.
Jueneman", not Bob Jueneman (although that's the name I use in spoken
conversation or casual written correspondence), and certainly not "Jueneman,
Robert R." or "ROBERT Jueneman."  However, if I were to use my middle name
as my familiar name, either R. Reade Jueneman or Robert READE Jueneman might
be convenient. but it ought to be my choice.

Now that's what my NAME is, and given the existing definitions and what the
various software programs are likely to support, that should almost
certainly be encoded in the alternateSubjectName, and what should be
displayed to any human user or relying party.

My name is NOT [e-mail], although that happens to be one or my
e-mail addresses, and I would be rather irritated if I were required to have
that as an alternate subject name.  I don't change my identity just because
I change e-mail service providers.

However, since the directory that would be most likely to publish my
certificate is owned by Novell, I would have no objection to o=Novell,
ou=PRV, ou=NSRD, cN=bjueneman or a context name in NDS terms of
bjueneman.nsrd.prv.novell, even though "novell" isn't qualified by c=US and
isn't as legally correct as "Novell, Inc." would be.  (And prv is really
Provo, which isn't an organizational unit in the technical sense at all, and
nsrd was an abbreviation for an organizational unit name that disappeared
several reorganizations ago, but still lives on in the directory space.)

But for anyone else to use that directory, a better DN might be
ldap://directory.novell.com/o=Novell,ou=prv,ou=nsrd,cn=bjueneman.

Alternatively, although I would prefer to include the directory location
within the DN itself as some sort of prefix, it would be acceptable for the
DN to be simply o=novell,ou=prv,ou=nsrd,cn=bjueneman, with the directory
location, protocol type(s), and port number(s) being provided using the
Authority Information Attribute.

Petra said "We recommend to use the respective AltName
extension(directoryName) to point to the X.500 Directory entry instead of
using the Subject DName." I'm not quite sure what he meant, but I don't
think I would agree with him. The Subject DN's one and only purpose, I
believe , should be to define the subject's name, i.e., entry reference, in
a directory. I would tend to disagree with including an e-mail address or
other  superfluous "technical" information in the certificate at all, and
especially in a name field.

I agree that the Subject's "real" name should be contained in the
subjectAlternateName field. However, I am not nearly as certain as to the
extent to which this represents the "unmistakable identity of the
certificate subject" if by that is meant that the name must be globally
unambiguous, and in particular if it has to carry all of the other baggage
that has been proposed.  A person's name should not be required to be his
birth certificate, passport, library card, fingerprint card and DNA record
all rolled up into one.

Regards,

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> "Gunnar Klein" <[e-mail]> 03/14/99 10:46PM >>>
--- Message on the SEIS mailing list ([e-mail])

Dear all,

The discussion on given names must continue. It is not an easy task.

I think it is important what Hans says that we must distinguish between RDNs
of Directories and those of certificates. Only had the world been simpler
could they have been identical. However, also in directories do we have the
problem of finding people using given names and should then not use caps
with a meaning, I understand from Magnus.

But my main concern is how we match certificate DNs with those
names/identifiers used in all sorts of other systems, customer databases,
access control lists, patient records etc. For these purposes it may be an
advantage if the certificate can contain more than one "common name".

Let me make it clear that the structure from the CEN work was not
specifically made for certificates and has not been used for it. YET. But it
was designed for all sorts of messages where persons identified in one
system should be matched with persons identified in another system. The
difference of identifying specific attributes for "maiden name", "married
name", "name at birth" etc compared to just saying alternative name is that
you get an identification of what type of name this "alternative" is. These
are all officially registered names at some point in time. Names denoted as
aliases can be defined only very privately.

Gunnar
--------------------------
Reply from Magnus


>Gunnar,
>
>There are several things I agree with you on. In particular, as you
>say, names are made unique in SS 614331 by the 'serialNumber'
>attribute, not the name itself. It would also probably have been
>better to allow for several attribute types in each relative
>distinguished name; by doing so one could have combined surnames and
>given names into one RDN and perhaps gotten a more natural directory
>structure. I also agree with you that in general it is not a good idea
>to put a long string consisting of several logical parts in one ASN.1
>string value, and then expect matching to work.
>
>Furthermore, another thing which perhaps deserves some attention here
>is the matching rules for these names. The attributes defined in SS
>614331 are all of the type 'Directorystring', with matching rule
>'caseIgnoreMatch' (ISO/IEC 9594-6). This means that 'HANS gunnar' will
>be equal to 'hans Gunnar' when doing Directory matching, i.e. it is
>not possible for a Directory agent to differentiate between these
>names, unless non-standard matching is employed. IETF RFC 2459
>(PKIX-1) does specify matching rules that do take case into account,
>but only if the associated ASN.1 types are different from
>'PrintableString'. However, 'PrintableString' is the preferred choice
>in SS 6143331.
>
>I fail however to understand the structures defined in the CEN/TC
>251/N98-083 work; perhaps this partly is due to my unfamiliarity with
>this work, but am I correct in interpreting this as: "An individual
>may be known under several names, e.g. name at birth ('NameatBirth'),
>maiden name ('MaidenName'), etc, and each name may consist of any of
>the following parts: title ('Title'), preferred given name
>'PreferredGivenName', etc." ??
>
>If so, and in the context of Directories, IMHO it would be
>preferable, in the interest of interoperability, to use existing
>structures (e.g. 'Name' in the ISO/IEC 9594-2 sense), with aliases
>and/or alternative names (as defined in ISO/IEC 9594-8) when an
>individual needs to be known under several names, and to define a few
>more ASN.1 ATTRIBUTEs. The 'preferredGivenName' and
>'preferredSurName' seems to be useful additions in this respect.
>
>(BTW, the ASN.1 needs several fixes, but I guess this was just an
>outline)
>
>Best regards,
>-- Magnus
>
>Magnus Nyström            Email: [e-mail]
>
>------------------------------------------------------------
>On Fri, 12 Mar 1999, Gunnar Klein wrote:
>
>[...]
>> Definition of Name from CEN/TC 251/N98-083
>>
>> Names ::= SET of Name{
>> NameatBirth      [0],
>> MaidenName       [1],
>> MarriedName      [2],
>> PreviousName     [3],
>> ProfessionalName [4],
>> Alias            [5]}
>>
>>
>> Name ::= SET

>>     Title                     [0] OCTET STRING (SIZE(3)) OPTIONAL,
>>     L-GivenNames              [1] SEQUENCE (SIZE(1..4)) NameElement
OPTIONAL,
>>     PreferredGivenName        [2] NameElement OPTIONAL
>>     Initials                  [3] OCTET STRING (SIZE(1..6)) OPTIONAL,
>>     SurnamePrefix             [4] OCTET STRING (SIZE(1..10))OPTIONAL,
>>     L-Surnames                [5] SEQUENCE (SIZE(1..4)) NameElement
>>     PreferredSurname          [6] NameElement OPTIONAL,
>>     SurnameSufix              [7] OCTET STRING (SIZE(1..10 )) OPTIONAL,
>>     QualificationDistinctions [8] OCTET STRING (SIZE( 1..20))OPTIONAL,
>>     UnstructuredName          [9] OCTET STRING (SIZE(1..1000))OPTIONAL
>> }
>>
>> NameElement ::= OCTET STRING (SIZE(1..35))
>> -------------------------------
>>
>> Maybe this contains too many optional and not highly needed elements
>> generally though they were included in this proposal taken from a
>> study on names and numbers as personal identifiers (attached). The
>> core thing is that you allow objects of both surname and Given names
>> and give the possibility of unanmbigously pointing out which one is
>> preferred. Some reasons why the proposals suggested by Hans within
>> the "standard GivenNames" are not quite sufficient could easily be
>> pointed out. Unfortunately spaces are included in what is logically
>> to be regarded as one name in some situations both for Surnames and
>> Given names. In some situations they are instead linked indicated by
>> a Hyphen such as Hans-Olof BUT according to the preference of the
>> subject and as allowed in our culture it could be that this should
>> be written without hyphen and yet be distinguished from somebody who
>> has two names "Hans" and "Olof" It is even more complicated and
>> important when considering certain surnames. I do not remember a good
>> example now but they exist. Placing preferred name part first has
>> been suggested by many, but is not sufficient since the registered
>> (or traditionally used) order has a significance different from
>> preferred if only one is to be presented.  Capitalization is a
>> possibility that may be an excellent suggestion within the current
>> standard but not really good since Capitals should be included
>> sometimes within name words and has a meaning at least to include
>> readability eg. McLauren.I think it is time to design computer
>> applications that meet the cultural requirements (and when moving
>> towards the replacement of handwritten signatures for non-repudiation
>> this becomes even more important. I had hoped that gone where the
>> days when we in Europe had to accept that all names where spelled
>> with A-Z and in upper case only.
>
>> Kind regards Gunnar Klein
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [e-mail]
>
>


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]


------=_NextPart_000_1771_01BE6EC2.F7513E00
Content-Type: text/x-vcard;
	name="Zahid N. Ahmed.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Zahid N. Ahmed.vcf"

BEGIN:VCARD
N:Ahmed;Zahid;N.
FN:Zahid N. Ahmed
EMAIL;PREF;INTERNET:[e-mail]
END:VCARD

------=_NextPart_000_1771_01BE6EC2.F7513E00--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17721 for ietf-pkix-bks; Mon, 15 Mar 1999 15:41:37 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA17717 for <[e-mail]>; Mon, 15 Mar 1999 15:41:36 -0800 (PST)
Received: 	id PAA05862; Mon, 15 Mar 1999 15:44:16 -0800
Received: by gateway id <G4CAWHMM>; Mon, 15 Mar 1999 18:46:25 -0500
Message-ID: <01E1D01C12D7D211AFC70090273D20B104F006@sothmxs06>
From: Carlisle Adams <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: New CMC Draft available
Date: Mon, 15 Mar 1999 18:41:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:[e-mail]]
> Sent: 	Monday, March 08, 1999 1:12 PM
> To: 	IETF-PKIX (E-mail)
> Subject: 	New CMC Draft available
> 
> A new draft of CMC (what will become draft -03) is now available on-line.
> This draft should appear on the various IETF servers shortly after the
> upcoming meeting in Minneapolis.  We apologize for missing the
> internet-draft cutoff date to get the draft published on IETF servers
> before
> the meeting; in the meantime the draft is available in various format from
> Brian LaMacchia's personal website at:
> 
> 	http://www.farcaster.com/cmc/
> 
> The differences between the -02 and -03 drafts may be summarized as
> follows:
> 1) New Section 5.3, Linking Identity and POP information, to address the
> potential theft/replay attack involving cert requests with NULL subject
> DNs
> that Carlisle Adams pointed out.
> 2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
> attack involving the example state-reduction technique.
> 3) Numerous editorial changes that were made in response to comments
> posted
> to the list and/or delivered to the authors privately.
 
Congratulations to all authors and contributors on this revision; the
improvements over the previous draft are significant!  In particular, it
appears that the modifications to Sections 5.3 and 5.7 address my earlier
concerns so that an entity may now be securely initialized into the PKI
using this protocol.

I have a few additional comments but, in order to save bandwidth on the
list, perhaps I'll send the minor editorial ones (typos, wording
clarifications, etc.) privately to the authors.  The rest are included
below.


Abstract:  there is not a *need* for an interface to PK certification
products and services based on [CMS] and [PKCS10]; there is a *desire* for
such an interface.  Nothing *needs* to be based on CMS and PKCS10
(especially since, as noted in the conformance section, existing deployed
software is not immediately compliant with this specification).  However,
there is great *desire* to base the protocols on CMS and PKCS10, since these
are familiar.  Please change "need" in bullet 1 to "desire" (and change
"immediate needs" in the opening sentence to "immediate concerns", or
similar).

Section 2, Section 2.1, and elsewhere:  the document sometimes uses
"certificate authority", sometimes uses "certification authority", sometimes
uses "Certification Authority", and so on.  Please be consistent throughout.
[Note that "Certification Authority" is the official term in various
Standards.]

Section 2:  this may be obvious to many, but I think that stating the
following underlying operational assumption will help to clarify the
operational model for this protocol.  "Underlying assumption:  every PKI
entity will have a signing key pair and will request a verification
certificate in its initialization message (i.e., an entity will never ask
for an encryption certificate _only_ in its initialization message)."  [The
reason that it might help to clarify this is that RFC 2510 does not have
this restriction.]

Section 3.3.3.1:  "D-H private keys cannot always be used..." -- note that
is may also be true for RSA keys that are held in a decrypt-only device, so
you need not restrict this section to D-H.

Also, "NoSignatureValue contains the hash of the certification request." --
why force the implementer to do an extra hash here for no purpose?  Why not
say that NoSignatureValue "contains the value 1234", or similar?

Section 5.2 (second paragraph):  "Servers SHOULD provide this method or have
a bilateral method..." -- I would prefer the following for interoperability
reasons:  "Servers MUST provide this method and MAY also have a bilateral
method...".

Section 5.7:  should note in first paragraph that PKCS10 cannot be used to
provide this functionality.

Also, it appears (from the text in bullet 4a and the text in the second-last
sentence of the section) that the DecryptedPOP structure should contain
"request    TaggedRequest" rather than "bodyPartID    BodyPartID".  That is,
the decrypted POP needs to contain the actual request itself (not just an
ID).

Section 5.9 (last paragraph):  "the server responds with a Key Recovery
Response containing the newly generated key." -- it doesn't really make any
sense semantically to use a key recovery response to implement off-client
key generation (since off-client key generation is not key recovery).  Why
not simply define a new message ("OffClientKeyGenRep") with the same syntax
as Key Recovery Response?

Also, "The details of the request control statement not covered in this
document...".  This will limit the use of this protocol in some environments
(those that mandate central key gen.).  A request message needs to be
defined for this purpose.

Section 5.9.3:  "The ContentInfo contains the requested private key
material." -- does it also contain the newly-created recipient (i.e., EE)
certificate?  If not, how can this response be used for off-client key
generation?  [Note that according to CMS, it is not clear that it's legal
for a CA to put the EE certificate in this construct....]

Sections 5.9.4.1, 5.9.4.2, 5.9.4.3:  in each section you need to say that
the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
subsequently be re-encoded as an OCTET STRING (in order to fit within the
structure defined in Section 5.9.4).

Section 5.10:  "low-end IP router that does not retain its own certificate
in non-volatile memory".  I might prefer "low-end IP router that does not
retain in non-volatile memory the certificates of those entities with whom
it needs to communicate".  Entities certainly need to get the certificates
of others in order to talk with them; do they really need to keep their own
certificates for most of their activities?

Section 5.11:  "The fields in a GetCRL have the following meanings:  --
issuerName is the value of the Issuer DN in the subject certificate."  This
will not work for Indirect CRLs.  Perhaps this field should hold the name of
the CRL issuer instead...

Section 5.12:  "it is impossible to produce a reliable digital signature."
-- this should be clarified to "it is impossible to produce a reliable
digital signature (prior to the certification of a new signature key pair)."

Section 5.14:  "The query pending attribute allows for a client to query a
server about the state..." -- how does the client know when to do this?  Is
there a time-to-check-back value included somewhere in the server's
response?

Section 6.1:  "The request is placed in the cmsSequence if it is a full pki
message and the reqSequence field for a simple enrollment message." -- in
the latter case, is this still a nested message?  (I.e., what is the
difference between a "non-nested" message with a PKCS10 in the reqSequence
and a "nested" message with a simple enrollment message in the reqSequence?)

Sections 7.2, 7.3:  replace "BER" with "DER" since signatures are
involved...

Section 12:  update the CRMF reference to RFC 2511 and the PKIXCERT
reference to RFC 2459.  Also, was DH-SIG not updated to some other draft
recently?


Finally, there is some  functionality missing in this specification that
will be very important for some environments.

- there is currently no way for a CA/RA to provide a trust anchor (public
key or self-signed cert) to the client during initialization.

- there is no confirmation message from the client to the CA/RA (thus, there
is no way for a client to reject a certificate that it does not want (e.g.,
in the case where the CA has modified some of the fields in the request)).

- cross-certification is not described.  (It appears to be possible to do
this with the existing messages, but without a prescribed method
interoperability is unlikely.)

- as mentioned above, off-client key generation needs to be specified (both
request and response).  It would also be nice to be able to ask for this as
part of the Full PKI Request message, rather than having to use separate
req/rep messages.

- CA key rollover is not described.  (This might be considered to be
out-of-scope of the current document, but it is very much in-scope for a
specification on how to do comprehensive certificate management, which is
what the title of this document suggests.)



That's all.  Aside from a few other typos, etc., the document looks great!

Carlisle.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16842 for ietf-pkix-bks; Mon, 15 Mar 1999 14:02:34 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA16838 for <[e-mail]>; Mon, 15 Mar 1999 14:02:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 15 Mar 1999 14:58:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Mon, 15 Mar 1999 14:57:57 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Regarding "Given names"
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_590E8F68.F59445D0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_590E8F68.F59445D0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

(Because I believe the subject is important, I am cross-posting this to =
the ietf-pkix list as well. Apologies for any duplicates.)

Gunnar,

You have introduced yet another degree of freedom into to this complex =
equation.  I had been sufficiently puzzled how to manage the mapping =
between a certificate and one or more directories, i.e., the Subscriber or =
Subject's directory (presumably one operated by his employer, or possibly =
his Internet Service Provider, or maybe some government agency or third =
party); the CA's directory (or maybe some third party repository), and the =
various Relying parties directories. But now you have introduced another =
level of complexity in wanting to map directly to customer databases, =
access control lists, patient records, etc.

I think this may be way too much to deal with.  Instead, those application =
should refer to the directories to look up that additional information as =
required for their purposes.

I am increasingly inclined to try to reduce these very complex naming =
problems down to two different forms of names, and in this regard I =
believe that I am in fairly close agreement with Petra Gloeckner's =
position reflected by his attached message.

The first, which is the single Distinguished Name, is the name by which =
the Subject is known to the Subject's own, primary directory, with a =
prefix if necessary to specify which directory that is and where it can be =
found. In addition to defining how to access that directory, the prefix =
name/location of the directory itself may be necessary to define the scope =
of names issue in order to make the DN globally unambiguous.  In this =
directory-oriented name structure, it is perfectly acceptable if the name =
is not particularly human readable or relevant, or tied to physical =
location, geopolitical boundaries, or organizational structures.  In those =
countries where a universal serial number is defined and considered =
acceptable for use (which the US Social Security Number is not, despite =
its widespread use and abuse), such an ID number could be used.  Otherwise,=
 a unique number within the scope of that directory can be used.

The second name should be the subject's own current chosen name form.  The =
extent to which that name must conform to "official" registered names may =
be controlled by law or custom, but should not be presumed.  The name in =
this case is not necessarily globally unambiguous. The inclusion of =
additional information in the name, such as current residence or organizati=
onal information may be helpful in making it globally unambiguous, but =
should not be required or presumed.  Instead, additional attributes that =
are not part of the name per se may supply that information if that is =
desired, but there may be complex privacy issues that would arise in that =
case.

Those of us in the US are frequently guilty of assuming that our own legal =
and cultural customs are universal, and of course they are not.  But I =
would also caution my European colleagues that the reverse may be true, =
and this applies in particular to the issue of "official" names.  There is =
a wide gap between the practices in many of the civil law countries =
regarding the acceptable composition of names, and how they are officially =
registered, vs. the common law countries such as the US, the UK, and =
others.  And I'm not even going to speculate about some of the African and =
Asian countries.  That's why I suggest that the Subject's own name be =
considered to be up to the Subject, with few if any presumptions being =
made as to how "official" that name is (with the exclusion of deliberate =
fraud.).

Of course it would be presumptuous of me to tell the German government or =
any other government how to write their laws or regulations, but the =
Internet essentially knows no boundaries, and codifying particular =
assumptions into law when they aren't universally warranted is likely to =
result in the law being ignored as unhelpful.=20

A case in point regarding Gunnar's description of alias names would be my =
father, who in his 87 years has gone through several names that are =
technically.  Born in 1911 of second generation Germanic heritage, his =
birth certificate lists his name as Frederick Reade Juenemann, and as a =
boy he was sometimes called Fritz. But his father was a US Army medical =
doctor and officer, and when my father started school in a succession of =
schools on Army posts, World War I had started in Europe, and shortly =
afterwards the US entered the war against Germany.  Having an obviously =
Germanic surname and nickname probably didn't make his life any easier, =
and so without any formal or official process, he dropped the final 'n' =
and nickname, and registered his name in that form all the way through =
college.

Sometime during World War II, while serving in the Philippines, he decided =
that "Frederick" was too much, since everyone called him Fred.  So again,. =
without going through any formal change of name process, he simply dropped =
the Frederick Reade and became Fred R. Jueneman, and was registered to =
vote, etc., under that name from then on.  But in his will, which he signs =
as Fred R., he is careful to list as "A.K.A." (also known as) aliases the =
other two name forms.

Now, I suppose if he were so inclined he might request a certificate that =
contained those alternate names, but I can't imagine why he would want to, =
or what legitimate purpose might be served by requiring them.

By and large, then, the governing principle for a subject's name should be =
whatever the Subject prefers.  In my case, that would be "Robert R. =
Jueneman", not Bob Jueneman (although that's the name I use in spoken =
conversation or casual written correspondence), and certainly not =
"Jueneman, Robert R." or "ROBERT Jueneman."  However, if I were to use my =
middle name as my familiar name, either R. Reade Jueneman or Robert READE =
Jueneman might be convenient. but it ought to be my choice.

Now that's what my NAME is, and given the existing definitions and what =
the various software programs are likely to support, that should almost =
certainly be encoded in the alternateSubjectName, and what should be =
displayed to any human user or relying party.

My name is NOT [e-mail], although that happens to be one or my =
e-mail addresses, and I would be rather irritated if I were required to =
have that as an alternate subject name.  I don't change my identity just =
because I change e-mail service providers.

However, since the directory that would be most likely to publish my =
certificate is owned by Novell, I would have no objection to o=3DNovell, =
ou=3DPRV, ou=3DNSRD, cN=3Dbjueneman or a context name in NDS terms of =
bjueneman.nsrd.prv.novell, even though "novell" isn't qualified by c=3DUS =
and isn't as legally correct as "Novell, Inc." would be.  (And prv is =
really Provo, which isn't an organizational unit in the technical sense at =
all, and nsrd was an abbreviation for an organizational unit name that =
disappeared several reorganizations ago, but still lives on in the =
directory space.)

But for anyone else to use that directory, a better DN might be ldap://dire=
ctory.novell.com/o=3DNovell,ou=3Dprv,ou=3Dnsrd,cn=3Dbjueneman. =20

Alternatively, although I would prefer to include the directory location =
within the DN itself as some sort of prefix, it would be acceptable for =
the DN to be simply o=3Dnovell,ou=3Dprv,ou=3Dnsrd,cn=3Dbjueneman, with the =
directory location, protocol type(s), and port number(s) being provided =
using the Authority Information Attribute.

Petra said "We recommend to use the respective AltName extension(directoryN=
ame) to point to the X.500 Directory entry instead of using the Subject =
DName." I'm not quite sure what he meant, but I don't think I would agree =
with him. The Subject DN's one and only purpose, I believe , should be to =
define the subject's name, i.e., entry reference, in a directory. I would =
tend to disagree with including an e-mail address or other  superfluous =
"technical" information in the certificate at all, and especially in a =
name field.

I agree that the Subject's "real" name should be contained in the =
subjectAlternateName field. However, I am not nearly as certain as to the =
extent to which this represents the "unmistakable identity of the =
certificate subject" if by that is meant that the name must be globally =
unambiguous, and in particular if it has to carry all of the other baggage =
that has been proposed.  A person's name should not be required to be his =
birth certificate, passport, library card, fingerprint card and DNA record =
all rolled up into one.

Regards,

Bob



Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> "Gunnar Klein" <[e-mail]> 03/14/99 10:46PM >>>
--- Message on the SEIS mailing list ([e-mail])

Dear all,

The discussion on given names must continue. It is not an easy task.=20

I think it is important what Hans says that we must distinguish between =
RDNs of Directories and those of certificates. Only had the world been =
simpler could they have been identical. However, also in directories do we =
have the problem of finding people using given names and should then not =
use caps with a meaning, I understand from Magnus.

But my main concern is how we match certificate DNs with those names/identi=
fiers used in all sorts of other systems, customer databases, access =
control lists, patient records etc. For these purposes it may be an =
advantage if the certificate can contain more than one "common name".=20

Let me make it clear that the structure from the CEN work was not =
specifically made for certificates and has not been used for it. YET. But =
it was designed for all sorts of messages where persons identified in one =
system should be matched with persons identified in another system. The =
difference of identifying specific attributes for "maiden name", "married =
name", "name at birth" etc compared to just saying alternative name is =
that you get an identification of what type of name this "alternative" is. =
These are all officially registered names at some point in time. Names =
denoted as aliases can be defined only very privately.

Gunnar
--------------------------
Reply from Magnus


>Gunnar,
>
>There are several things I agree with you on. In particular, as you
>say, names are made unique in SS 614331 by the 'serialNumber'
>attribute, not the name itself. It would also probably have been
>better to allow for several attribute types in each relative
>distinguished name; by doing so one could have combined surnames and
>given names into one RDN and perhaps gotten a more natural directory
>structure. I also agree with you that in general it is not a good idea
>to put a long string consisting of several logical parts in one ASN.1
>string value, and then expect matching to work.
>
>Furthermore, another thing which perhaps deserves some attention here
>is the matching rules for these names. The attributes defined in SS
>614331 are all of the type 'Directorystring', with matching rule
>'caseIgnoreMatch' (ISO/IEC 9594-6). This means that 'HANS gunnar' will
>be equal to 'hans Gunnar' when doing Directory matching, i.e. it is
>not possible for a Directory agent to differentiate between these
>names, unless non-standard matching is employed. IETF RFC 2459
>(PKIX-1) does specify matching rules that do take case into account,
>but only if the associated ASN.1 types are different from
>'PrintableString'. However, 'PrintableString' is the preferred choice
>in SS 6143331.
>
>I fail however to understand the structures defined in the CEN/TC
>251/N98-083 work; perhaps this partly is due to my unfamiliarity with
>this work, but am I correct in interpreting this as: "An individual
>may be known under several names, e.g. name at birth ('NameatBirth'),
>maiden name ('MaidenName'), etc, and each name may consist of any of
>the following parts: title ('Title'), preferred given name
>'PreferredGivenName', etc." ??=20
>
>If so, and in the context of Directories, IMHO it would be
>preferable, in the interest of interoperability, to use existing
>structures (e.g. 'Name' in the ISO/IEC 9594-2 sense), with aliases
>and/or alternative names (as defined in ISO/IEC 9594-8) when an
>individual needs to be known under several names, and to define a few
>more ASN.1 ATTRIBUTEs. The 'preferredGivenName' and
>'preferredSurName' seems to be useful additions in this respect.
>
>(BTW, the ASN.1 needs several fixes, but I guess this was just an
>outline)
>
>Best regards,
>-- Magnus
>
>Magnus Nystr=F6m            Email: [e-mail]=20
>
>------------------------------------------------------------
>On Fri, 12 Mar 1999, Gunnar Klein wrote:
>
>[...]
>> Definition of Name from CEN/TC 251/N98-083
>>
>> Names ::=3D SET of Name{
>> NameatBirth      [0],
>> MaidenName       [1],
>> MarriedName      [2],
>> PreviousName     [3],
>> ProfessionalName [4],
>> Alias            [5]}
>>
>>=20
>> Name ::=3D SET {=20
>>     Title                     [0] OCTET STRING (SIZE(3)) OPTIONAL,
>>     L-GivenNames              [1] SEQUENCE (SIZE(1..4)) NameElement =
OPTIONAL,
>>     PreferredGivenName        [2] NameElement OPTIONAL
>>     Initials                  [3] OCTET STRING (SIZE(1..6)) OPTIONAL,
>>     SurnamePrefix             [4] OCTET STRING (SIZE(1..10))OPTIONAL,
>>     L-Surnames                [5] SEQUENCE (SIZE(1..4)) NameElement
>>     PreferredSurname          [6] NameElement OPTIONAL,
>>     SurnameSufix              [7] OCTET STRING (SIZE(1..10 )) OPTIONAL,
>>     QualificationDistinctions [8] OCTET STRING (SIZE( 1..20))OPTIONAL,
>>     UnstructuredName          [9] OCTET STRING (SIZE(1..1000))OPTIONAL
>> }
>>=20
>> NameElement ::=3D OCTET STRING (SIZE(1..35))
>> -------------------------------
>>
>> Maybe this contains too many optional and not highly needed elements
>> generally though they were included in this proposal taken from a
>> study on names and numbers as personal identifiers (attached). The
>> core thing is that you allow objects of both surname and Given names
>> and give the possibility of unanmbigously pointing out which one is
>> preferred. Some reasons why the proposals suggested by Hans within
>> the "standard GivenNames" are not quite sufficient could easily be
>> pointed out. Unfortunately spaces are included in what is logically
>> to be regarded as one name in some situations both for Surnames and
>> Given names. In some situations they are instead linked indicated by
>> a Hyphen such as Hans-Olof BUT according to the preference of the
>> subject and as allowed in our culture it could be that this should
>> be written without hyphen and yet be distinguished from somebody who
>> has two names "Hans" and "Olof" It is even more complicated and
>> important when considering certain surnames. I do not remember a good
>> example now but they exist. Placing preferred name part first has
>> been suggested by many, but is not sufficient since the registered
>> (or traditionally used) order has a significance different from
>> preferred if only one is to be presented.  Capitalization is a
>> possibility that may be an excellent suggestion within the current
>> standard but not really good since Capitals should be included
>> sometimes within name words and has a meaning at least to include
>> readability eg. McLauren.I think it is time to design computer
>> applications that meet the cultural requirements (and when moving
>> towards the replacement of handwritten signatures for non-repudiation
>> this becomes even more important. I had hoped that gone where the
>> days when we in Europe had to accept that all names where spelled
>> with A-Z and in upper case only.=20
>
>> Kind regards Gunnar Klein
>
>
>----------------- SEIS mailing list ([e-mail])
>Info about this list: http://www.nc-forum.com/seis=20
>SEIS Contact: [e-mail]=20
>
>


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis=20
SEIS Contact: [e-mail]=20

--=_590E8F68.F59445D0
Content-Type: message/rfc822

Received: from prv1-mx.provo.novell.com
	by prv-mail25.provo.novell.com; Mon, 15 Mar 1999 02:12:26 -0700
Received: from ns.webway.se
	by prv1-mx.provo.novell.com; Mon, 15 Mar 1999 02:13:53 -0700
Received: (from kpk-list@localhost) by ns.webway.se (8.8.8/8.7) id KAA18022
Resent-Date: Mon, 15 Mar 1999 10:02:35 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 15 Mar 1999 10:03:40 +0100
From: "Petra Glöckner" <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"Jc20MC.A.TZE.qyM72"@ns>
Resent-From: [e-mail]
X-listadress: [e-mail]
X-Mailing-List: <[e-mail]> archive/latest/261
X-Loop: [e-mail]
Precedence: list
Resent-Sender: [e-mail]
X-From: SEIS-listan <[e-mail]>
Subject: SEIS: Re: Given names
Content-Transfer-Encoding: 7bit

--- Message on the SEIS mailing list ([e-mail])

Writing the Qualified Certficate and the German certificate 
specification we had a long discussion on this naming issue.
We finally came to the conclusion that the best way to solve 
this problem is to have TWO KINDS of names in a certificate:

TECHNICAL NAME(S):
The Subject DName and the SubjectAltName extension will contain 
one or more technical names, to be used for certificate chaining, 
to identify the respective X.500 directory entry or to carry the 
email address or any other technical information.
We recommend to use the respective AltName extension(directoryName) 
to point to the X.500 Directory entry instead of using the Subject 
DName.

OFFICIAL/LEGAL NAME:
We defined a new data structure to be used in the SubjectAltName 
extension(otherName). This new data structure PersonalData has
to contain the unmistakable identity of the certificate subject 
according to the respective law or policy.
Please note: the Qualified Certficate and the German certificate 
specification still differ in the PersonalData definition. Once
the Qualified Certficate draft is settled we will adjust the German
specification.

Regards - Petra

Hans Nilsson wrote:
> 
> --- Message on the SEIS mailing list ([e-mail])
> 
> Two comments:
> 
> 1. You should look at Stefan's draft for Qualified Certficates, which is
> very much related to this discussion.
> 
> 2. Please note that the Distinguished Name in the certificate has nothing to
> do with how/where the certificate is stored in the directory. They just
> happen to use the same RDN syntax :-)
> I may for example have a National EID-card with C=SE, CN=Hans Nilsson
> SN=123456. This is then stored at C=SE, O=iD2, CN=...
> It took me some time before I understood this, and I have now seen that this
> difference is explicitly pointed out in the German certificate
> specification.
> 
> Regards
> Hans
> 
> ----------------- SEIS mailing list ([e-mail])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [e-mail]


----------------- SEIS mailing list ([e-mail])
Info about this list: http://www.nc-forum.com/seis
SEIS Contact: [e-mail]


--=_590E8F68.F59445D0--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16527 for ietf-pkix-bks; Mon, 15 Mar 1999 13:22:52 -0800 (PST)
Received: from usenix.ORG (usenix-gw.usenix.ORG [131.106.1.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16523 for <[e-mail]>; Mon, 15 Mar 1999 13:22:51 -0800 (PST)
Received: (from barnett@localhost) by usenix.ORG (8.8.5/8.8.5) id NAA05109; Mon, 15 Mar 1999 13:31:25 -0800 (PST)
Date: Mon, 15 Mar 1999 13:31:24 -0800 (PST)
From: Linda Barnett <[e-mail]>
To: [e-mail]
Subject: High-level Technical Workshop on Smart Cards
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For Researchers, Product Developers and Smart Card Deployers

USENIX WORKSHOP ON SMARTCARD TECHNOLOGY
May 10-11, 1999
McCormick Place South
Chicago, Illinois USA
-----------------------------------------------------------
Review the full program and register online at
http://www.usenix.org/events/smartcard99/
Save when registering before Friday, April 16, 1999
-----------------------------------------------------------
Advanced Technical Program
Peer-reviewed papers and selected presenters from around the world.  You'll
hear reports of the latest research, developments, and deployments in:
* smart card hardware
* smart card software
* system issues
* strengths and weaknesses of smart cards
* smart cards' role in operating systems
* smart cards as a base technology in cryptographic systems

First of Its Kind in North America
Authoritative how-to and who's doing what in smart card systems and
technologies--Join researchers and practitioners for peer-reviewed reports
of what is possible today, and on the drawing boards for tomorrow.

Free Admission to the Largest Card & Security Exhibition
Attend the USENIX Workshop on Smart Card Technology and enjoy visiting the
CardTech/SecureTech '99 Exhibition, May 12-14, 1999, co-located in
McCormick Place South, Chicago. For more details, go to http://www.ctst.com

Sponsored by The USENIX Association
USENIX is an international society of scientists, engineers, and systems
administrators working on the cutting edge of systems and software. Since
1975, USENIX conferences and workshops have been recognized for bridging
research, innovation and the practical.  Excellence is assured by peer
review.  The open exchange of technical ideas and solutions prevails,
unfettered by commercialism or stodginess.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA20274 for ietf-pkix-bks; Fri, 12 Mar 1999 16:33:35 -0800 (PST)
Received: from mail.veosystems.com (davinci.veosystems.com [209.130.191.171]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA20270 for <[e-mail]>; Fri, 12 Mar 1999 16:33:34 -0800 (PST)
Received: (qmail 3489 invoked from network); 13 Mar 1999 00:39:37 -0000
Received: from cerberus-dmz.veosystems.com (HELO veosystems.com) (209.130.191.169) by davinci.veosystems.com with SMTP; 13 Mar 1999 00:39:37 -0000
Received: (qmail 19965 invoked from network); 13 Mar 1999 00:39:37 -0000
Received: from cassatt.veosystems.com (HELO cassatt) (10.0.0.32) by archimedes.veosystems.com with SMTP; 13 Mar 1999 00:39:37 -0000
From: "Zahid Ahmed" <[e-mail]>
To: <[e-mail]>
Subject: X.509 Attribute Certificates extensions in PKIX Certificates?
Date: Fri, 12 Mar 1999 08:34:49 -0800
Message-ID: <01be6ca6$3f254290$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_11DF_01BE6C63.31020290"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_11DF_01BE6C63.31020290
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_11E0_01BE6C63.31020290"


------=_NextPart_001_11E0_01BE6C63.31020290
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is there currently any support to generate X.509 Attribute Certificates =
in=20
PKIX?
=20
1. If not, how can we extend and/or generate such a certificate using=20
PKIX for organizations/groups/roles? The thing is that an attribute =
certificate=20
does not have a public key associated with it. Hence, it can not, e.g.,=20
extend public key Certificate structure. (Or, if does, we are really=20
associating a public key with a group or organization which=20
is not compatible, I believe, with PKIX X.509 end-entity identity=20
X.509 certs).
=20
How can one create a X.509 Attribute Certificate using current PKIX?
=20
2. Also, I want to be able to include multiple attribute certificate in =
a=20
X.509Certiifcate which is an extension of =
java.security.cert.certificate.=20
How can we add such an extension to X.509Certificate class?
=20
Please provide recommendation of how this can be done for allowing=20
groups and roles to be associated with an end-entity X.509 certificates.
I know, e.g., there will be S/MIME and SSL clients that can take =
advantage=20
of such additional auth information about the subject.=20

Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: [e-mail]
v: (650)-623-2814
fax: [phone]

------=_NextPart_001_11E0_01BE6C63.31020290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D2>Is there currently any support to generate X.509 =
Attribute=20
Certificates in </FONT></DIV>
<DIV><FONT size=3D2>PKIX?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1. If not, how can we extend and/or generate such a=20
certificate using </FONT></DIV>
<DIV><FONT size=3D2>PKIX for organizations/groups/roles? The thing is =
that an=20
attribute certificate </FONT></DIV>
<DIV><FONT size=3D2>does not have a public</FONT> <FONT size=3D2>key =
associated with=20
it. Hence, it can not, e.g., </FONT></DIV>
<DIV><FONT size=3D2>extend public key Certificate structure. </FONT>(Or, =
if does,=20
we are really </DIV>
<DIV>associating a public key with a group or organization which </DIV>
<DIV>is not compatible, I believe, with PKIX X.509 end-entity identity =
</DIV>
<DIV>X.509 certs).</DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>How can one create a X.509 Attribute =
Certificate=20
using current PKIX?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>2. Also, I want to be able to include multiple =
attribute=20
certificate in a </FONT></DIV>
<DIV><FONT size=3D2>X.509Certiifcate which is an extension of=20
java.security.cert.certificate.</FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>How can we add such an extension to X.509Certificate =

class?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Please provide </FONT><FONT size=3D2>recommendation =
of how this=20
can be done for allowing </FONT></DIV>
<DIV><FONT size=3D2>groups and roles </FONT><FONT size=3D2>to be =
associated with an=20
end-entity X.509 certificates.</FONT></DIV>
<DIV><FONT size=3D2>I know, e.g., there will be S/MIME and SSL clients =
that can=20
take advantage</FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>of such additional auth information about the=20
subject.</FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>Zahid=20
Ahmed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Commerce One, Inc.<BR>Commerce Security Architect<BR>email: <A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR>v:=20
(650)-623-2814<BR>fax: [phone]</FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_11E0_01BE6C63.31020290--

------=_NextPart_000_11DF_01BE6C63.31020290
Content-Type: text/x-vcard;
	name="Zahid N. Ahmed.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Zahid N. Ahmed.vcf"

BEGIN:VCARD
N:Ahmed;Zahid;N.
FN:Zahid N. Ahmed
EMAIL;PREF;INTERNET:[e-mail]
END:VCARD

------=_NextPart_000_11DF_01BE6C63.31020290--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11368 for ietf-pkix-bks; Thu, 11 Mar 1999 10:10:53 -0800 (PST)
Received: from nexus.webmatic.de (nexus.webmatic.de [195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11364 for <[e-mail]>; Thu, 11 Mar 1999 10:10:51 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 909C73C; Thu, 11 Mar 1999 19:16:56 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id TAA23442; Thu, 11 Mar 1999 19:16:57 +0100
Message-ID: <[e-mail]>
Date: Thu, 11 Mar 1999 19:16:40 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sergio Tabanelli <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Questions on Root CA key Update in rfc2510 (CMP)
References: <037301be6bca$236ffc20$[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sergio,

Sergio Tabanelli wrote:
> 
> I am sure I am missing something. Reading 2.4.1 "Ca operator actions"
> of the rfc2510 (CMP), a big question comes into my mind.
> 
> How is it possible to verify with the NEW CA CERTIFICATE an EE certificate
> signed with the OLD CA KEY  when the OLDWITHNEW certificate has expired
> (I understand from 2.4.1 that the validity period of OLDWITHNEW ends
> "at the expiry date of the old public key", i.e. at the same time as OLD.
> What does exactly mean "correct" and "check" in 2.4.2.2?

I think the RFC is correct in this point. When the old CA´s KEY expires
then all EE certificates signed with the old key become invalid. All EE
who have a certificate signed with the old CA´s key need a new
certificate prior to expiration date of the old CA´s key.

Following figure may help. Hopefully it will be received well formated
:-)

I---OLDwithOLD---I I---NEWwithNEW---------I   )   
             I---OLDwithNEW---I               ) CA certificates
             I---NEWwithOLD---I               )
                    
                              I               ) date of CA´s old key
expiration
             I                                ) date of CA´s new key
generation
                      
                    I---EE2withNEW---I        )
      I---EE1withOLD---I                      ) EE certificates
                       I---EE1withNEW---I
Note there is a difference between OLDwithOLD certificate´s expiration
and CA´s old KEY expiration. Furthermore the CA has two keys during a
certain period.

> 
> "2. Verify that this is correct ......... 3. If correct, check the signer's
> certificate using the old CA"
> Is the EE Certificate verification a normal path validation as explained in
> rfc2459?

Note the "Bug in rfc2459" discussion recently on this mailing list.
Personally, I tend to incorrect certificate path validation defined by
RFC 2459.

> 
> Thanks for any answer.
> Sergio Tabanelli
> [e-mail]

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA08976 for ietf-pkix-bks; Thu, 11 Mar 1999 06:13:15 -0800 (PST)
Received: from fep01-svc.tin.it (mta01-acc.tin.it [212.216.176.32]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA08972 for <[e-mail]>; Thu, 11 Mar 1999 06:13:13 -0800 (PST)
Received: from squalo ([208.164.5.201]) by fep01-svc.tin.it (InterMail v4.0 201-221-105) with SMTP id <19990311141839.TVBH2097.fep01-svc@squalo> for <[e-mail]>; Thu, 11 Mar 1999 15:18:39 +0100
Message-ID: <037301be6bca$236ffc20$[e-mail]>
From: "Sergio Tabanelli" <[e-mail]>
To: <[e-mail]>
Subject: Questions on Root CA key Update in rfc2510 (CMP)
Date: Thu, 11 Mar 1999 15:19:05 +0100
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am sure I am missing something. Reading 2.4.1 "Ca operator actions"
of the rfc2510 (CMP), a big question comes into my mind.

How is it possible to verify with the NEW CA CERTIFICATE an EE certificate
signed with the OLD CA KEY  when the OLDWITHNEW certificate has expired
(I understand from 2.4.1 that the validity period of OLDWITHNEW ends
"at the expiry date of the old public key", i.e. at the same time as OLD.
What does exactly mean "correct" and "check" in 2.4.2.2?

"2. Verify that this is correct ......... 3. If correct, check the signer's
certificate using the old CA"
Is the EE Certificate verification a normal path validation as explained in
rfc2459?

Thanks for any answer.
Sergio Tabanelli
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07838 for ietf-pkix-bks; Wed, 10 Mar 1999 20:17:04 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA07444; Wed, 10 Mar 1999 20:13:26 -0800 (PST)
Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA27909; Wed, 10 Mar 1999 20:18:56 -0800 (PST)
Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id UAA15042; Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Date: Wed, 10 Mar 1999 20:18:55 -0800 (PST)
Message-Id: <[e-mail]>
From: Clifford Neuman <[e-mail]>
To: [e-mail]
Subject: Workshop on Countering Cyber-Terrorism
Reply-to: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

		      Countering Cyber-Terrorism
			      June 22-23
		      Marina del Rey, California
      A workshop sponsored by the Information Sciences Institute
	       of the University of Southern California

			Call for Participation

Recent studies warn of Cyber-Terrorism and the vulnerability of our
computer systems and infrastructure to attack. These reports identify
damage that determined, knowledgeable, and well-financed adversaries
could inflict on commercial, government, and military systems.  Such
attacks would have severe consequences for the public, and in
particular the economy, which has become dependant on computers and
communications infrastructure.

The objective of this workshop is to identify things that should be
done to improve our ability to detect, protect against, contain,
neutralize, mitigate the effects of, and recover from cyber-terrorist
attacks.  Participants are sought from the computer security,
electronic commerce and banking, network infrastructure, military, and
counter-terrorism communities, as well as those with experience of
cyber-terrorist attacks.  Recommendations may suggest research and
development or operational measures that can be taken.  The workshop
is NOT a forum for presentation of the latest security systems,
protocols or algorithms.  The workshop will address the strategies,
framework, and infrastructure required to combine and incrementally
deploy such technologies to counter the cyber-terrorist threat.

Attendance will be limited to approximately 25 participants.
Participants will be selected on the basis of submitted position
papers that raise issues for the workshop to discuss, identify threats
or countermeasures, or propose strategies or infrastructure to counter
the threat of cyber-terrorism. Position papers should be four pages or
less in length.  Submissions should be sent in e-mail in Word or PDF
format, or as ASCII text to [e-mail].

Please check the web page http://www.isi.edu/cctws for more
information, including a position paper from the organizers which will
be available two weeks prior to the submission deadline.

Important Dates:

  Organizer's Paper Available              April  5, 1999
  Position Papers Due                      April 19, 1999
  Notification of Acceptance               May 1, 1999
  Revised Position Papers Due              May 28, 1999
  Position Papers Available on Web         June 9
  Workshop Dates                           June 22-23

Organizing Committee:

   Bob Balzer, Information Sciences Institute, [e-mail]
   Thomas Longstaff, CERT Coordination Center, [e-mail]
   Don Faatz, the MITRE Corporation, [e-mail] 
   Clifford Neuman, Information Sciences Institute, [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA29977 for ietf-pkix-bks; Wed, 10 Mar 1999 03:52:49 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA29973 for <[e-mail]>; Wed, 10 Mar 1999 03:52:45 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GPDX91F1>; Wed, 10 Mar 1999 22:58:36 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0CBEE1@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: relational searching over distributed directories
Date: Wed, 10 Mar 1999 22:58:34 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Deat all - we have been working on the subject line issue- a white paper
is available fyi

http://www.opendirectory.com/Whitepapers/OD-Dir-relate.html

We will be providing input to the LDAPext and X.500 standards to upgrade
the matching rule approaches. 

The use of this distributed - relational approach to trees of directory
information can greatly enhances the design and efficiency of DEN, F510,
CAs (eg. Cross Domain working) and other directory applications,

Comments are welcome
regards alan


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13432 for ietf-pkix-bks; Mon, 8 Mar 1999 14:04:04 -0800 (PST)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA13428 for <[e-mail]>; Mon, 8 Mar 1999 14:03:58 -0800 (PST)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id OAA01094; Mon, 8 Mar 1999 14:09:49 -0800
Message-ID: <051201be69af$d3699d60$954bffd0@brick>
From: "Todd S. Glassey" <[e-mail]>
To: <[e-mail]>
Subject: Netx ABA ISC meeting announcement
Date: Mon, 8 Mar 1999 14:05:48 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all -
I didn't see one go by so here is the  first announcement of the next
American Bar Association Information Security Committee meeting. The
upcoming meeting will be held from Wednesday, April 7, 1999 through Friday,
April 9, 1999, at the Patent & Trademark Office University in Crystal City,
Virginia.

The IS Committee will continue its advancement of the legal and control
issues for managing public key infrastructure (PKI). This session's efforts
will include further work on the evaluation/accreditation certification
authorities, commercial key recovery guidelines, PKI agreements and
evidentiary issues, certificate policy, and liability, among other matters.
In this upcoming session, we will focus considerable attention on resolving
remaining architectural issues as well as an enhanced focus upon “consumer
issues” brought to light our work in the PKI Evaluation Guidelines (PEG).

Day 2 of the meeting (Thursday, April 8th) will consist of a Special
Workshop on Consumers and PKI.  This pioneering workshop will include a
distinguished panel of regulators and experts on consumer law and PKI.
Participation in this workshop is open to the public, space permitting.

Membership
-----------------
Consistent with Section policy, (except for the open admission to the
Special Workshop on April 8th), ISC meeting participants must be members of
both the ABA and the ABA Section of Science and Technology. For membership
information, please contact Ann Kowalsky, Manager for the Section of Science
& Technology, at ABA headquarters in Chicago by phone: [phone], fax:
+1 312.988.5628, or email: <[e-mail]>.

You can become a paid member of the ABA and the ISC at the meeting.
Associate membership in both the ABA and the Section of Science and
Technology is available for non-lawyers (Associates) at a cost of $125 per
year.  Meeting details appear below.

More info
-------------
If you need a copy of the full schedule or announcement, I have it in MS
Word and RTF - the whole package is 5 pages. Please send me mail directly
rather than to the list. - [e-mail] and I will send them to
you.

Thanks,
Todd Glassey




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11548 for ietf-pkix-bks; Mon, 8 Mar 1999 10:43:57 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA11542 for <[e-mail]>; Mon, 8 Mar 1999 10:43:56 -0800 (PST)
Received: (qmail 29411 invoked from network); 8 Mar 1999 18:49:46 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 8 Mar 1999 18:49:46 -0000
Received: (qmail 12148 invoked from network); 8 Mar 1999 18:49:35 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 8 Mar 1999 18:49:35 -0000
Message-ID: <022501be6984$3b3cc330$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
Date: Mon, 8 Mar 1999 10:53:43 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have got a clear opinion from the list. Unless there
are further points, Ill leave the topic with this:


  >> Therefore, noone should code  up their ASN.1 compilers with
>> ASN.1 value constraints which impose the value conditions
>> of 2459's text (e.g. rejecting a cert with a  critical
>> AKI criticality bit, say, during type/value checking).
>
>What does a C compiler do when it encounters non-ANSI-conforming
>code?  It may provide a warning, or it may fail to compile, depending
>on the wishes of the human operator.  I wouldn't suggest that either
>C compilers or RP validation software not have the capability to
>lint-check their input.  The user sitting at the User Agent, or
>his security administrator, should have the ability to specify
>the actions taken when a PKIX CA-conformance failure is detected
>during path validation.

ASN.1 value constraints control "processing-time" type/value
checking, not compile-time checking. It can be used
to help implement ITSEC-style high-assurance requirements: that
an implementation does what the spec says, and nothing more,
as latitude represents potential insecurity.

In some Internet-ready certification profiles (ie. SET), the ASN.1
processing eliminates the non-conforming transactions, designating
them invalid for syntax, profile conformance and other similar reasons;
the security  procedure fails consequently; payment is not performed; goods
are not ordered.

PKIX is just more liberal. Validity is in the eye of the beholder, by
design.
Courts can choose to trust the opinion of certain beholders more than
others, presumably, where they can rationalize their procedures
for validation.

This thread  suggests we need to move ahead on the Entrust-led
notary work ASAP, so PKIX becomes useful to higher-value
commercial apps where standardized validity(s) is/are required.
 http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11204 for ietf-pkix-bks; Mon, 8 Mar 1999 10:07:35 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11200 for <[e-mail]>; Mon, 8 Mar 1999 10:07:35 -0800 (PST)
Received: by dfssl.dns.microsoft.com with Internet Mail Service (5.5.2448.0) id <GM1BPTVB>; Mon, 8 Mar 1999 10:13:00 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5D89@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: New CMC Draft available
Date: Mon, 8 Mar 1999 10:12:48 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A new draft of CMC (what will become draft -03) is now available on-line.
This draft should appear on the various IETF servers shortly after the
upcoming meeting in Minneapolis.  We apologize for missing the
internet-draft cutoff date to get the draft published on IETF servers before
the meeting; in the meantime the draft is available in various format from
Brian LaMacchia's personal website at:

	http://www.farcaster.com/cmc/

The differences between the -02 and -03 drafts may be summarized as follows:
1) New Section 5.3, Linking Identity and POP information, to address the
potential theft/replay attack involving cert requests with NULL subject DNs
that Carlisle Adams pointed out.
2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
attack involving the example state-reduction technique.
3) Numerous editorial changes that were made in response to comments posted
to the list and/or delivered to the authors privately.

In the new Section 5.3, CMC now specifies a mechanism for linking the POP
information contained within each signed PKCS#10/CRMF message to the
identity information derived from the one-time token carried in the Full PKI
Request message.   The basic idea is to force the client to sign another
value cryptographically-derived from the shared secret into each and every
cert request contained within the Full PKI Request message.  More
specifically, the client publishes a random string in the Full PKI Request
header and then signs HMAC(shared secret, random string) into every cert
request.  In order to successfully carry out a theft/replay attack the
attacker would have to either know the shared secret or be able to generate
an HMAC collision.  (That is, if Bob steals a cert request from Alice, Bob
needs to find random_bob such that HMAC(shared secret_bob, random_bob) ==
the HMAC signed into the request.)

In the revised Section 5.7, we now hash the entire cert request instead of
hashing just the public key.  With the changes in 5.3 the cert request can't
be copied & used in another enrollment transaction.  However, by hashing in
the cert request we now require the client to return, on the second request,
the exact same PKCS#10/CRMF that he submitted originally.

Finally, on a procedural note, as of this draft I am taking over Barb Fox's
authorship position on CMC.

Jim 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10359 for ietf-pkix-bks; Mon, 8 Mar 1999 08:31:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10355 for <[e-mail]>; Mon, 8 Mar 1999 08:31:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02482; Mon, 8 Mar 1999 11:36:03 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP to Proposed Standard
Date: Mon, 08 Mar 1999 11:36:03 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP'
<draft-ietf-pkix-ocsp-07.txt> as a Proposed Standard.  This document is
the product of the Public-Key Infrastructure (X.509) Working Group.
The IESG contact persons are Jeffrey Schiller and Marcus Leech.


Technical Summary
 
 This document defines an on-line protocol for verifying the validity
  of X.509 Certificates by contacting the issuing Certifying Authority
  (or their authorized designee). It provides an alternative to the
  more traditional approach of having Certifying Authority publish
  Certificate Revocation Lists (CRLs).

Working Group Summary

  The working group reached consensus on this proposal

Protocol Quality

  Jeffrey I. Schiller reviewed this document for the IESG.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA09207 for ietf-pkix-bks; Mon, 8 Mar 1999 07:28:14 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA09201 for <[e-mail]>; Mon, 8 Mar 1999 07:28:13 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01153; Mon, 8 Mar 1999 10:33:00 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure LDAPv2 Schema to Proposed Standard
Date: Mon, 08 Mar 1999 10:33:00 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure LDAPv2 Schema' <draft-ietf-pkix-ldapv2-schema-02.txt> as
a Proposed Standard.  This document is the product of the Public-Key
Infrastructure (X.509) Working Group.  The IESG contact persons are
Jeff Schiller and Marcus Leech.
 
 
Technical Summary
 
  This document defines a minimal schema to support PKIX in an LDAPv2
  environment, as defined in draft-ietf-pkix-ipki2opp-08.txt. Only
  PKIX-specific components are specified.

Working Group Summary

  The working group reached consensus on this proposal

Protocol Quality

  Jeffrey I. Schiller reviewed this document for the IESG.

Note to RFC Editor:
In draft-ietf-pkix-ldapv2-schema-02.txt replace all of section

7 Patent Statements

with:

7  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07518 for ietf-pkix-bks; Mon, 8 Mar 1999 06:09:34 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07514 for <[e-mail]>; Mon, 8 Mar 1999 06:09:33 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29004; Mon, 8 Mar 1999 09:14:21 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP to Proposed Standard
Date: Mon, 08 Mar 1999 09:14:21 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP'
<draft-ietf-pkix-opp-ftp-http-04.txt> as a Proposed Standard.  This
document is the product of the Public-Key Infrastructure (X.509)
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

 
 
Technical Summary
 
  This document proposes mechanisms for transporting X.509 Certificates
  and Certificate Revocation Lists (CRLs) via HTTP or FTP. For HTTP it
  defines two new MIME types (application/pkix-cert and
  application/pkix-crl) for tagging these data types.

Working Group Summary

  The working group reached consensus on this proposal

Protocol Quality

  Jeffrey I. Schiller reviewed this document for the IESG.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07513 for ietf-pkix-bks; Mon, 8 Mar 1999 06:09:26 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07509 for <[e-mail]>; Mon, 8 Mar 1999 06:09:25 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA21686 for <[e-mail]>; Mon, 8 Mar 1999 09:15:16 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA21682 for <[e-mail]>; Mon, 8 Mar 1999 09:15:15 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id JAA22953 for <[e-mail]>; Mon, 8 Mar 1999 09:13:51 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id JAA10655 for <[e-mail]>; Mon, 8 Mar 1999 09:13:09 -0500 (EST)
Message-Id: <[e-mail]>
Date: Mon, 8 Mar 1999 09:13:09 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: zxjFa4hrLq91ONLe+iWzGw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Abstracting, the general rule is, then, if a relying party system
> detects that a CA is non-conforming with PKIX
> in matters of cert format, extension schema, criticality, etc, this fact
> is not a basis by PKIX-implementors to designate 
> such a certificate as invalid, nor designate
> the chain on which it is a member as similarly invalid, 
> nor affect  the security protocol event which
> is relying on the cert path (such as an SSL connection
> handshake, or S/MIME signature verification).

I would be ecstatic if the minimum path validation procedures
in section 6 were followed by all RP software.  The end goal is
to do more than the minimum, but lets concentrate on the
mandatory requirements first.


> Therefore, noone should code  up their ASN.1 compilers with
> ASN.1 value constraints which impose the value conditions
> of 2459's text (e.g. rejecting a cert with a  critical
> AKI criticality bit, say, during type/value checking).

What does a C compiler do when it encounters non-ANSI-conforming
code?  It may provide a warning, or it may fail to compile, depending
on the wishes of the human operator.  I wouldn't suggest that either
C compilers or RP validation software not have the capability to
lint-check their input.  The user sitting at the User Agent, or
his security administrator, should have the ability to specify
the actions taken when a PKIX CA-conformance failure is detected
during path validation.


> If anyone doing 2459 detects SKI != AKI, they should not reject
> the cert path.
>
> Agreed?

They should detect the condition. They should then silently ignore
it, noisily accept it, or reject it at the option of the RP.

In the specific case of SKI != AKI, it is likely that path development
software will not be able to construct an otherwise valid path in the
first place.  The AKI extension is a hint; it would take more
sophisticated software and more execution time to produce a valid path
where the hint is incorrect or absent than where it is correct.  Given
the current state of the art, it would be prudent to assume that if
CAs issue certs with incorrect AKI extensions, sender and recipient
software will not be able to use them in cases where the issuer
DN is used with more than one signing key.  Problems may first show
up when the CA is first rekeyed and certs with both the old and new
keys are valid during the rollover period.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA02719 for ietf-pkix-bks; Sun, 7 Mar 1999 23:19:53 -0800 (PST)
Received: from stax05.cubis.de (wks1.cubis.de [194.112.101.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA02707; Sun, 7 Mar 1999 23:18:24 -0800 (PST)
Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id IAA25676; Mon, 8 Mar 1999 08:13:00 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 08 Mar 1999 08:10:05 +0000
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[e-mail]>
Organization: Secunet GmbH - The Trust Company
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Call for Papers: CQRE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAB02708
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(As some of you have problems with the html-version of the CFP
you will find the full version below. Sorry for this inconvenience.)


***************************************************************
                     Call for Papers
            CQRE [Secure] Congress & Exhibition
       Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving economic
processes.
---------------------------------------------------------------
 Deadline for submission of extended abstracts: May 14, 1999
website: http://www.secunet.de/forum/cqre.html
mailing-list: send mailto:[e-mail] 
(where the subject is "subscribe" without paranthesis)
***************************************************************

The "CQRE - secure networking" provides a new international
forum giving a close-up view on information security in the context
of rapidly evolving economic processes. The unprecedented
reliance on computer technology transformed the previous technical
side- issue "information security'' to a management problem
requiring decisions of strategic importance. Hence, the targeted
audience represents decision makers from government, industry,
commercial, and academic communities. If you are developing
solutions to problems relating to the protection of your country’s
information infrastructure or a commercial enterprise, consider
submitting a paper to the "CQRE - secure networking" conference.

We are looking for papers and panel discussions covering:
. electronic commerce
 - new business processes
 - secure business transactions
 - online merchandising
 - electronic payment / banking
 - innovative applications

. network security
 - virtual private networks
 - security aspects in internet utilization
 - security aspects in multimedia-
   applications
- intrusion detection systems

. legal aspects
 - digital signatures acts
 - privacy and anonymity
 - crypto regulation
 - liability

. corporate security
 - access control
 - secure teleworking
 - enterprise key management
 - IT-audit
 - risk / disaster management
 - security awareness and training
 - implementation, accreditation, and
   operation of secure systems in a
   government, business, or industry
   environment

. security technology
 - cryptography
 - public key infrastructures
 - chip card technology
 - biometrics

. trust management
 - evaluation of products and systems
 - international harmonization of security
   evaluation criterias
. standardization
. future perspectives

Any other contribution addressing the involvement of IT security in
economic processes will be welcome. Authors are invited to submit
an extended abstract of their contribution to the program chair.
The submissions should be original research results, survey
articles or ``high quality'' case studies and position papers.
Product advertisements are welcome for presentation, but will not
be considered for the proceedings. Manuscripts must be in English,
and not more than 2.000 words. The extended abstracts should be in
a form suitable for anonymous review, with no author names,
affiliations, acknowledgements or obvious references. Contributions
must not be submitted in parallel to any conference or workshop
that has proceedings. Separately, an abstract of the paper with no
more than 200 words and with title, name and addresses (incl. an
E-mail address) of the authors shall be submitted. In the case of
multiple authors the contacting author must be clearly identified.
We strongly encourage electronic submission in Postscript format.
The submissions must be in 11pt format, use standard fonts or
include the necessary fonts. Proposals for panel discussions should
also be sent to the program chair. Panels of interest include those
that present alternative/controversial viewpoints or those that
encourage lively discussions of relevant issues. Panels that are
collections of unrefereed papers will not be considered. Panel
proposals should be a minimum of one page describing the subject
matter, the appropriateness of the panel for this conference and
should identify participants and their respective viewpoints.

mailing list/ web-site:
-----------------------
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to
[e-mail]. You will find this call for papers and further
information at http://www.secunet.de/forum/cqre.html .

important dates:
----------------
deadline for submission of extended abstracts May 14, 1999
deadline for submission of panel proposals    June 1, 1999
notification of acceptance                   June 25, 1999
deadline for submission of complete papers   July 30, 1999

program chair:
--------------
secunet - Security Networks GmbH
c/o Rainer Baumgart 
Weidenauer Str. 223 - 225
57076 Siegen
Germany
Tel.: [phone]
Fax:  [phone]
[e-mail]


program committee:
------------------
Johannes Buchmann   (TU Darmstadt)
Dirk Fox            (Secorvo)
Walter Fumy         (Siemens)
Rüdiger Grimm       (GMD)
Helena Handschuh    (ENST/Gemplus)
Thomas Hoeren       (Uni Muenster)
Pil Joong Lee       (POSTECH)
Alfred Menezes      (U.o.Waterloo/Certicom)
David Naccache      (Gemplus)
Clifford Neumann    (USC)
Mike Reiter         (Bell Labs)
Matt Robshaw        (RSA)
Richard Schlechter  (EU-comm.)
Bruce Schneier      (Counterpane)
Tsuyoshi Takagi     (NTT)
Yiannis Tsiounis    (GTE Labs)
Michael Waidner     (IBM)
Moti Yung           (CERTCO)
Robert Zuccherato   (Entrust)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21884 for ietf-pkix-bks; Sun, 7 Mar 1999 05:17:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21880 for <[e-mail]>; Sun, 7 Mar 1999 05:17:27 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GPDX9DYF>; Mon, 8 Mar 1999 00:23:07 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0CBEA7@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'David P. Kemp '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'Peter Williams '" <[e-mail]>
Subject: RE: PKIX Path determination/construction/processing and AKIpointe r hanging
Date: Mon, 8 Mar 1999 00:23:05 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My thoughts are - is that the CA path processing theory is fine - as
theory but in operational systems - domain based validation, policy
based validation (and revocation), etc will be used - ie. there will
other  (policy based) information objects used that determine the path,
its validation process, its revocation process and provide some degree
of fault tollerance. These could be part of a CAs information model.  


It strikes me that all one needs to do - in the theoretical model of
cert path validation is to spam the OCSP server or CA as defined in the
AKI..eg. send it PDUs of 100gigs.
Not the way to go I think.

I think talking compliance to cert path processing - when it is a
theoretical model may not be too useful.

regards alan  

----------
From: Peter Williams
To: David P. Kemp; [e-mail]
Sent: 3/5/99 2:58:11 AM
Subject: Re: PKIX Path determination/construction/processing and
AKIpointer hanging


-----Original Message-----
From: David P. Kemp <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Thursday, March 04, 1999 11:00 AM
Subject: Re: PKIX Path determination/construction/processing and
AKIpointer
hanging


>
>> From: "Peter Williams" <[e-mail]>
>>
>> QUESTION: If a certificate path chosen by a relying party contains at
>> least one certificate whose authority key id backpointer does
>> NOT resolve to a certificate in that path or any certificate
>> known to the relying party, can one designate otherwise normal
>> processing of  that chain as conforming to PKIX 2459?
>>
>> My answer to the question is yes. Does anyone disagree?
>
>
>If I understand the question correctly, I disagree.  Restating
>the question as I understand it:
>
>  If a certificate path chosen by a relying party is not
>  a continuous chain between the certificate being validated
>  and a certificate trusted by the relying party, can one designate
>  otherwise normal processing of that chain as conforming to RFC 2459?



David,

There have been a couple of responses. Let my query your
analysis to find out what is driving you to try to disagree with
a simple technical assertion concerning hanging backpointers
(marked critical, or otherwise):

You seem to have invented a technical term "continuous chain."

What is a "continuous chain"?

"  If a certificate path chosen by a relying party is not
  a continuous chain between the certificate being validated
  and a certificate trusted by the relying party, can one designate
  otherwise normal processing of that chain as conforming to RFC 2459?"

Does a cert path which has hanging AKI backpointers constitute
a continuous chain (all things about the chain or the RP's locally
trusted
authority
being otherwise acceptable/valid to the relying party
and 2459 descriptive formalisms)?

 >I interpret "This text assumes ..." to mean that if the assumption
>is not met, then the results are undefined, and that if the results
>are undefined, then there is no meaningful conformance.

Its fine for a relying party to define its own notion of conformance.
Indeed, it is necessary.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21407 for ietf-pkix-bks; Sun, 7 Mar 1999 04:38:27 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21403 for <[e-mail]>; Sun, 7 Mar 1999 04:38:24 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GPDX9DYB>; Sun, 7 Mar 1999 23:44:02 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0CBEA3@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Martin Smith '" <[e-mail]>
Cc: "''PKIX list ' '" <[e-mail]>
Subject: RE: Cert binding to ?
Date: Sun, 7 Mar 1999 23:43:59 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 
Oh dear...
The reason why LDAP "succeded" was that directory vendors including
those who supply X.500 directory services adopted it. It just now that
people are realising that single non distributed LDAP servers are just a
good as a traditional database approach ie highly limited - and that all
that has happend is that in this case people have swapped SQL for LDAP -
wow!
When one has to replicate everything to everywhere with LDAP only
systems - they be come a nonsense.

Anyway we provide directory services that permuit LDAP access and LDAP
servers to be connected as subordinate servers. Its just that we do
distribution part - the complex part - the essential part - and many
other things that make a distributed information system work - including
LDAP.

LDAP is -- an access protocol - to what?


X.500 defines that.


I often think that if I stood in the street and tried to sell car doors
- people would think I was strange. But if I say LDAP does it all - then
that makes me an industry leader! :-)

regards alan

PS we are using X.500 as back ends for DNS/DHCP and RADIUS servers so
that the ISPs using them can scale their operations - ie there is a bit
of a dependency here with ISPs and X.500.


----------
From: Martin Smith
To: Alan Lloyd
Cc: 'PKIX list '
Sent: 3/5/99 12:13:19 PM
Subject: Re: Cert binding to ?

It seems to me that the problem with the X-standards was not that they
were
too complex, but that they were being run by the wrong people.  It's
been
observed more than once that the "lightweight" in LDAP is fast
disappearing.
And why not, with RAM at $1/meg and disk at $100/gig?  The reason LDAP
succeeds is "running code and rough concensus."

Alan Lloyd wrote:
snip

> the directory service of usage of DNs does not mean that the system is
> geopolitical. Its just many have seen X.500 as too big (12 mb) DAP as
> too big (130 kb), that X.500 is THE global directory not A directory
> service, one of many) and that PKI roots = directory roots, etc.

> snip



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10415 for ietf-pkix-bks; Fri, 5 Mar 1999 17:45:00 -0800 (PST)
Received: from oe8.briank.com (oe8.briank.com [209.133.59.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA10410 for <[e-mail]>; Fri, 5 Mar 1999 17:44:56 -0800 (PST)
Received: from cs.stanford.edu (blatz.briank.com [209.133.59.212]) by oe8.briank.com (8.8.8/8.8.8) with ESMTP id RAA07066; Fri, 5 Mar 1999 17:50:16 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 1999 17:50:30 -0800
From: Brian Korver <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: PKIX Path determination/construction/processing and AKIpointer  hanging
References: <016a01be6751$c1f08590$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Williams wrote:
[snip]
> If anyone doing 2459 detects SKI != AKI, they should not reject
> the cert path.
> 
> Agreed?
>

Agreed.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08900 for ietf-pkix-bks; Fri, 5 Mar 1999 15:38:00 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA08896 for <[e-mail]>; Fri, 5 Mar 1999 15:37:59 -0800 (PST)
Received: (qmail 24633 invoked from network); 5 Mar 1999 23:43:36 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 5 Mar 1999 23:43:35 -0000
Received: (qmail 24421 invoked from network); 5 Mar 1999 23:39:08 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 5 Mar 1999 23:39:07 -0000
Message-ID: <016a01be6751$c1f08590$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
Date: Fri, 5 Mar 1999 15:47:24 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 >Now, what do you mean by a hanging AKI backpointer?  If a cert contains
>an AKI extension and its parent cert does not contain an SKI extension
>with the same value, then the CA is not in conformance with Section
>4.2.1.x.  That is a serious error on the part of the CA, and calls into
>question the CA's competence and attention to detail.  But if despite
>the bad or missing information in the key identifier extensions, the RP
>is able to find (perhaps by trial and error) an issuer cert which can
>be used to verify the signature on the issued cert, then I agree that
>an otherwise valid path may still be considered valid.
>

 

Abstracting, the general rule is, then, if a relying party system
detects that a CA is non-conforming with PKIX
in matters of cert format, extension schema, criticality, etc, this fact
is not a basis by PKIX-implementors to designate 
such a certificate as invalid, nor designate
the chain on which it is a member as similarly invalid, 
nor affect  the security protocol event which
is relying on the cert path (such as an SSL connection
handshake, or S/MIME signature verification).

Therefore, noone should code  up their ASN.1 compilers with
ASN.1 value constraints which impose the value conditions
of 2459's text (e.g. rejecting a cert with a  critical
AKI criticality bit, say, during type/value checking).

If anyone doing 2459 detects SKI != AKI, they should not reject
the cert path.

Agreed?

Peter.

NB. I indicated to Bob, one set of PKIX-QC thoughts which
flowed from this issue. The other issue is one
of assumptions: ValiCert is a validation authority (that is, 
one who does authoritative certificate validation, as
defined in the X.509 PDAM). We cannot assume
that PKIX-conforming chains will get sent to us, by
any means. Neither should we, in minimal
PKIX service quality mode, necessarily limit 
our path discovery services to paths produced
using certs from conforming CAs, unless
the relying party customer so designates 
PKIX conformance as part of its risk factor screen.

 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08216 for ietf-pkix-bks; Fri, 5 Mar 1999 14:37:40 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA08212 for <[e-mail]>; Fri, 5 Mar 1999 14:37:39 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 05 Mar 1999 15:42:46 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 05 Mar 1999 15:42:30 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing andAKIpointer hanging
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 mail.proper.com id OAA08213
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

The scenario I was describing was one where the signer's self-signed root is A, A signs B, and B signs C's certificate. C, the end user, then signs a document.

The relying party's root is X, which signs Y, which signs Z, which is the RP's own certificate if anyone cares.

Now  X, or Y, or Z, can unilaterally create a unidirectional cross-certificate by signing A, or B, or C's public key and filling in the other information as desired.  

All they have to know is the public key of A, B, or C.

How they know to trust A, B, or C is their business, and is handled out of band, as is the trustworthy conveyance of the various public keys.

Bob

>>> "David P. Kemp" <[e-mail]> 03/05/99 03:02PM >>>

> From: "Peter Williams" <[e-mail]>
> 
> Bob,
> 
> I like much of your thinking. It seems suited to the general Internet
> culture.
> 
> If a cert path has two certs (A & B) , and the second (B) has an authority
> key identifier pointer to its parent, can the chain be valid
> it the identified parent is specifically NOT A, according to PKIX?
> 
> This situation happens when, as per your example, unidirectional, unilateral
> cross-certification (without policy mapping, say) occurs into a
> hierarchical,
> policy-oriented PKI domain which has pre-established AKI backpointers.


Aha, now I understand the question.  But I still don't understand the
issue.

The second cert (B) contains a signature value which was generated
by its parent, call it C.  B contains an AKI pointing to C.

If the cert path A->B passes the signature verification, then A's
public key must be able to verify a signature created by C's private
key.  AFAIK, that can happen only if A knows C's private key.

Are you asking if RFC 2459 allows unilateral unidirectional
cross-certification by means of private key sharing?  Perhaps it
does, but the very idea seems imprudent, to say the least.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08092 for ietf-pkix-bks; Fri, 5 Mar 1999 14:18:38 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA08088 for <[e-mail]>; Fri, 5 Mar 1999 14:18:36 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 05 Mar 1999 15:09:14 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 05 Mar 1999 15:08:57 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing andAKIpointer hanging
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 mail.proper.com id OAA08089
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

The thought of making the AKI CRITICAL hadn't occurred to me,
but I can see one particular application where it might be put
to good use.

Generally speaking, a Relying Party should only have to answer 
to itself regarding the criteria it uses for path validation. After all,
the RP is perfectly free to take the risk of no signature and 
no certificate chain being present at all, depending on the value 
of the transaction and the risk the RP wishes to take.

However, there are some cases where the terms and conditions
of a particular Closed PKI group are such that the sponsor 
of the closed PKI is distinctly unwilling to act as a root of an open PKI,
or even to assert any compliance with its terms and conditions 
regarding lower-level CAs and end-users, perhaps because of liability 
concerns.

In that case, making the AKI critical would accomplish that goal, at
least as far as standards compliant processing is concerned.

It still doesn't PREVENT the relying party from relying on whatever
it chooses to, but it would presumably be a strong indicator in case 
of a dispute that reliance on the certificate chain outside of the 
chosen trusted root/path should not be considered commercially 
reasonable.

Bob

>>> "Peter Williams" <[e-mail]> 03/05/99 11:38AM >>>
Bob,

I like much of your thinking. It seems suited to the general Internet
culture.

If a cert path has two certs (A & B) , and the second (B) has an authority
key identifier pointer to its parent, can the chain be valid
it the identified parent is specifically NOT A, according to PKIX?

This situation happens when, as per your example, unidirectional, unilateral
cross-certification (without policy mapping, say) occurs into a
hierarchical,
policy-oriented PKI domain which has pre-established AKI backpointers.

My thoughts are, assuming what I thought was a simple question is answered
positively for the 2459 case, that PKIX-QC might establish that a
critical flag on the AKI would make this situation INVALID, in contrast.
And, therefore, enable the well-controlled PKI domain to signal that
inward, unilateral  cross-certification is not supported - as
enforced by 2459-conforming relying parties who require the
assurances of the PKIX-QC interoperability policy.

Peter.



-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail] 
<[e-mail]>
Date: Thursday, March 04, 1999 3:04 PM
Subject: Re: PKIX Path determination/construction/processing andAKIpointer
hanging


>Peter and
>Peter and David,
>
>I'm not sure that I understand the argument -- maybe I wasn't paying
attention earlier.
>
>maybe peter can clarify what he means.
>
>I have in mind a model where I as the relying party have a certificate
chain that starts at some CA that I trust, and may descend top down from
Issuer to Subject, probably ending with my own certificate.
>
>In addition, there is a chain of certificates sent to me (or otherwise made
available) by the originator or signer of some document, which I process
bottom up, chaining from Subject to Issuer.  Unfortunately, if I follow that
certificate chain all the way to the originators "top" I may never encounter
a certificate that I trust.
>
>So in addition to the normal, bidirectionally link chain of certificates in
my own hierarchical tree, I have some cross-certification certificates that
may very well by unidirectional.  In other words, at any particular node in
my own hierarchy, that CA may have issued a cross-certificate which includes
the public key of some node in the originator's chain of certificates.
>
>So the path processing algorithm proceeds as follows:
>
>1.  Start at the root of my (the RP) hierarchy, and process all of the CA
certificates top down, keeping a cache of all of the public keys (key IDs).
>
>(1a.  Repeat for any additional trusted hierarchies, including any
certificates added by the relying party on his own authority, e.g., his
sister's end user certificate, or a CA or subordinate CA issued by a company
that they are partnered with, regardless of the fact that they don't
necessarily trust that company's top-level CA.)
>
>2.  Start at the bottom of the signer's certificate chain and process
bottom up.
>
>3.  At each step of the way, query the cache of public keys to determine
whether that key has been seen before, and hence is considered trusted. If
so, then the path extends from the RP's own trusted root down his chain to
the cross certificate, and then continues down the originators chain from
that point on to the end.
>
>4.  If the public key in question has not been processed previously and
therefore know to be trusted, then continue climbing the signer's tree
bottom-up, following the Issuer chain.  (How you find these certificates is
of course a different issue -- I'm only addressing the chain of trust.
>
>5.  If you reach a self-signed certificate (indicating the top of a chain)
without having encountered a key that is trusted, then the path is not
trusted and you have to decide to do with it -- reject the whole chain, ask
the user whether to add the certificate on a one-time basis, or whatever.
>
>6.  Once you have blazed a trail through the woods, chopping a notch on
every tree (key) that you trust until you get back to your own top, then
(and only then, I believe) have you identified the path, and are prepared to
process the entire chain from top down, this time omitting the signature
validation but doing
>all of the validity checking, CRL checking, constraint checking, etc.  It
could be argued that you could validate the date range on the first pass
through the  certificates. maybe you could argue that you should check the
CRLs at that time also, but that may be a more expensive process, and
perhaps you ought to validate the chain as it stands before going elsewhere
to check the status.
>
>Now, Peter, does what I have suggested fit the path establishment model you
were proposing?  If not, could you describe yours more completely, because
the above is the only one I've been able to convince myself really works.
>
>Bob
>
>
>
>>>> "David P. Kemp" <[e-mail]> 03/04/99 08:07AM >>>
>
>> From: "Peter Williams" <[e-mail]>
>>
>> QUESTION: If a certificate path chosen by a relying party contains at
>> least one certificate whose authority key id backpointer does
>> NOT resolve to a certificate in that path or any certificate
>> known to the relying party, can one designate otherwise normal
>> processing of  that chain as conforming to PKIX 2459?
>>
>> My answer to the question is yes. Does anyone disagree?
>
>
>If I understand the question correctly, I disagree.  Restating
>the question as I understand it:
>
>  If a certificate path chosen by a relying party is not
>  a continuous chain between the certificate being validated
>  and a certificate trusted by the relying party, can one designate
>  otherwise normal processing of that chain as conforming to RFC 2459?
>
>If the relying party has no notion of a trusted public key, or has
>an implementation which returns a "success" answer when given a path
>not terminating in a trusted public key, then RFC2459 is irrelevant.
>Frobbing the bits in accordance with section 6 may increase the entropy
>of the relying party's immediate environment (generate some heat and
>waste some time), but it has no other useful effect.
>
>RFC2459 says "This text assumes that all valid paths begin with
>certificates issued by a single 'most trusted CA'." (and then goes
>on to discuss extended path validation where paths may begin with
>one of several trusted CAs).
>
>I interpret "This text assumes ..." to mean that if the assumption
>is not met, then the results are undefined, and that if the results
>are undefined, then there is no meaningful conformance.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07904 for ietf-pkix-bks; Fri, 5 Mar 1999 14:00:31 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA07899 for <[e-mail]>; Fri, 5 Mar 1999 14:00:29 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 05 Mar 1999 14:57:52 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 05 Mar 1999 14:57:44 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
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 mail.proper.com id OAA07900
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

You have a certain point.

It would be sufficient to find the certificate to have 
Issuer name plus serial number, or authorityKeyId, 
if you know where to look for that information. 
Obviously a hash alone would also work, again 
if you know where to look.

It may come down to what information is most readily available 
in the particular S/MIME, IKE, signed document, or whatever,
and perhaps someone who is more familiar with the Cryptographic 
Message Syntax specs could help out here.

My admittedly unfounded assumption was that if the 
"payload" does not include the E-E certificate, that it is
at least quite likely to include the signer/user's name in
some form, probably more or less in the form of a DN,
perhaps an RFC822 name, but not necessarily.

That's why I was trying to use the DN more or less 
"as is", and to attach a prefix that would indicate 
where to look (and maybe how to look) for the directory
or repository.

Bob


>>> "David P. Kemp" <[e-mail]> 03/05/99 12:40PM >>>
> From: "Bob Jueneman" <[e-mail]>
> 
> David,
> 
> Flat is not necessarily bad, although the performance of 
> typical directory implementations may be a concern.
> 
> But hashing the certificate or public key a la SPKI is 
> in my opinion NOT the way to go, for reasons that were 
> argued extensively on that list (even if Carl Ellison 
> remains unconvinced).
> 
> I wouldn't mind such a technique as an alias, if aliases 
> weren't such a headache, but I don't think it would be 
> acceptable as the primary DN, because people want to be
> able to look up lots of other things about someone than
> their certificate, and they want to be able to do so for a 
> very long period of time.


I see two different scenarios for looking up certificates:

1) I receive an S/MIME message (or an IPSEC/IKE connection request)
containing only an EE cert or (preferably) no cert at all, just a
certID.  I look for the issuer cert path (and perhaps also the EE cert)
in my local ram cache and my local disk cache. If they aren't cached, I
do a repository fetch, which chains as required from my company's or
ISP's directory cache on up to the Internet Root.  For this purpose, a
certID should be an "address" (i.e. something meaningless and
politically non-controversial like a hash) with the sole purpose of
enabling the fetching to occur.

2) I have a "name" of someone I want to communicate with and don't
already have any information about him (such as a certID, DN, or cert)
in my address book.  For that, I need a white pages directory.

The first "repository" scenario is the one I'm addressing.
It is easy to solve, and the IETF should solve it by defining
the protocols and standing up the infrastructure root, because
it is purely a technical engineering exercise.

The second "directory" scenario is too hard.  People were
arguing about directories and naming schemes before I was born
and will be doing so after I'm gone. More importantly, directories
should IMHO be regarded as layered *on top of* repositories,
providing metadata about the repository's contents, but not
being necessesary for the repository to operate.  Just as if
DNS fails I can make a TCP connection to a dotted-quad IP address,
if "The Directory" fails or is never established or information owners
filter what it is allowed to reveal, I should still be able to
fetch a cert by ID.

I'm not signing up to the SPKI philosophy that the cert itself
needs no name.  I'm just saying that the cert should be retrievable
by an ID that is not necessarily a name.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07892 for ietf-pkix-bks; Fri, 5 Mar 1999 13:59:11 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07888 for <[e-mail]>; Fri, 5 Mar 1999 13:59:10 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id RAA15098 for <[e-mail]>; Fri, 5 Mar 1999 17:04:48 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id RAA15094 for <[e-mail]>; Fri, 5 Mar 1999 17:04:47 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id RAA18913 for <[e-mail]>; Fri, 5 Mar 1999 17:03:23 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id RAA10089 for <[e-mail]>; Fri, 5 Mar 1999 17:02:46 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 5 Mar 1999 17:02:46 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing andAKIpointer hanging
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /un/dKGfFkUutJC8cNsl0A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Peter Williams" <[e-mail]>
> 
> Bob,
> 
> I like much of your thinking. It seems suited to the general Internet
> culture.
> 
> If a cert path has two certs (A & B) , and the second (B) has an authority
> key identifier pointer to its parent, can the chain be valid
> it the identified parent is specifically NOT A, according to PKIX?
> 
> This situation happens when, as per your example, unidirectional, unilateral
> cross-certification (without policy mapping, say) occurs into a
> hierarchical,
> policy-oriented PKI domain which has pre-established AKI backpointers.


Aha, now I understand the question.  But I still don't understand the
issue.

The second cert (B) contains a signature value which was generated
by its parent, call it C.  B contains an AKI pointing to C.

If the cert path A->B passes the signature verification, then A's
public key must be able to verify a signature created by C's private
key.  AFAIK, that can happen only if A knows C's private key.

Are you asking if RFC 2459 allows unilateral unidirectional
cross-certification by means of private key sharing?  Perhaps it
does, but the very idea seems imprudent, to say the least.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07686 for ietf-pkix-bks; Fri, 5 Mar 1999 13:33:50 -0800 (PST)
Received: from mail.veosystems.com (davinci.veosystems.com [209.130.191.171]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA07682 for <[e-mail]>; Fri, 5 Mar 1999 13:33:49 -0800 (PST)
Received: (qmail 6965 invoked from network); 5 Mar 1999 21:38:42 -0000
Received: from cerberus-dmz.veosystems.com (HELO veosystems.com) (209.130.191.169) by davinci.veosystems.com with SMTP; 5 Mar 1999 21:38:42 -0000
Received: (qmail 16461 invoked from network); 5 Mar 1999 21:38:41 -0000
Received: from cassatt.veosystems.com (HELO cassatt) (10.0.0.32) by archimedes.veosystems.com with SMTP; 5 Mar 1999 21:38:41 -0000
From: "Zahid Ahmed" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
Date: Fri, 5 Mar 1999 05:33:50 -0800
Message-ID: <01be670c$ce17d750$[e-mail]>
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.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that is should be retrievable via ID that is not a name.
But I don't understand what this is ID to fetch the cert 
should be? and how we will include this in exisiting
X.509 certificates? what extensions will work with
exisiting X.509 certs?

-----Original Message----- 
From: David P. Kemp <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Friday, March 05, 1999 1:29 PM
Subject: Re: Qualified Certificates draft - Country name


>> From: "Bob Jueneman" <[e-mail]>
>> 
>> David,
>> 
>> Flat is not necessarily bad, although the performance of 
>> typical directory implementations may be a concern.
>> 
>> But hashing the certificate or public key a la SPKI is 
>> in my opinion NOT the way to go, for reasons that were 
>> argued extensively on that list (even if Carl Ellison 
>> remains unconvinced).
>> 
>> I wouldn't mind such a technique as an alias, if aliases 
>> weren't such a headache, but I don't think it would be 
>> acceptable as the primary DN, because people want to be
>> able to look up lots of other things about someone than
>> their certificate, and they want to be able to do so for a 
>> very long period of time.
>
>
>I see two different scenarios for looking up certificates:
>
>1) I receive an S/MIME message (or an IPSEC/IKE connection request)
>containing only an EE cert or (preferably) no cert at all, just a
>certID.  I look for the issuer cert path (and perhaps also the EE cert)
>in my local ram cache and my local disk cache. If they aren't cached, I
>do a repository fetch, which chains as required from my company's or
>ISP's directory cache on up to the Internet Root.  For this purpose, a
>certID should be an "address" (i.e. something meaningless and
>politically non-controversial like a hash) with the sole purpose of
>enabling the fetching to occur.
>
>2) I have a "name" of someone I want to communicate with and don't
>already have any information about him (such as a certID, DN, or cert)
>in my address book.  For that, I need a white pages directory.
>
>The first "repository" scenario is the one I'm addressing.
>It is easy to solve, and the IETF should solve it by defining
>the protocols and standing up the infrastructure root, because
>it is purely a technical engineering exercise.
>
>The second "directory" scenario is too hard.  People were
>arguing about directories and naming schemes before I was born
>and will be doing so after I'm gone. More importantly, directories
>should IMHO be regarded as layered *on top of* repositories,
>providing metadata about the repository's contents, but not
>being necessesary for the repository to operate.  Just as if
>DNS fails I can make a TCP connection to a dotted-quad IP address,
>if "The Directory" fails or is never established or information owners
>filter what it is allowed to reveal, I should still be able to
>fetch a cert by ID.
>
>I'm not signing up to the SPKI philosophy that the cert itself
>needs no name.  I'm just saying that the cert should be retrievable
>by an ID that is not necessarily a name.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07529 for ietf-pkix-bks; Fri, 5 Mar 1999 13:03:32 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07525 for <[e-mail]>; Fri, 5 Mar 1999 13:03:30 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA12621 for <[e-mail]>; Fri, 5 Mar 1999 16:09:08 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA12606 for <[e-mail]>; Fri, 5 Mar 1999 16:09:06 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA12117 for <[e-mail]>; Fri, 5 Mar 1999 16:07:42 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA10080 for <[e-mail]>; Fri, 5 Mar 1999 16:07:05 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 5 Mar 1999 16:07:05 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: t8XbnM2JnyLaQ6IhwnGFpQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Peter Williams" <[e-mail]>
>
> David,
> 
> You seem to have invented a technical term "continuous chain."
> 
> What is a "continuous chain"?
> 
> "  If a certificate path chosen by a relying party is not
>   a continuous chain between the certificate being validated
>   and a certificate trusted by the relying party, can one designate
>   otherwise normal processing of that chain as conforming to RFC 2459?"
> 
> Does a cert path which has hanging AKI backpointers constitute
> a continuous chain (all things about the chain or the RP's locally trusted
> authority
> being otherwise acceptable/valid to the relying party
> and 2459 descriptive formalisms)?


A (properly formed) continuous chain obeys the RFC 2459 Section 6.1
"path processing actions" item (a)(4): the subject and issuer names
chain correctly.

Section 4.2.1.1 says that conforming CAs MUST include the key identifier
field in the AKI extension, which MUST be non-critical.

Section 4.2.1.2 says that the SKI extension MUST appear in conforming
CA certificates, that the SKI value must match the value of AKI in the 
subordinate certificates, and that the SKI extension MUST be non-critical.


Now, what do you mean by a hanging AKI backpointer?  If a cert contains
an AKI extension and its parent cert does not contain an SKI extension
with the same value, then the CA is not in conformance with Section
4.2.1.x.  That is a serious error on the part of the CA, and calls into
question the CA's competence and attention to detail.  But if despite
the bad or missing information in the key identifier extensions, the RP
is able to find (perhaps by trial and error) an issuer cert which can
be used to verify the signature on the issued cert, then I agree that
an otherwise valid path may still be considered valid.

I am sorry, but I had trouble understanding what you meant by the
previous posting.  On the one hand you seemed to be discussing a
separation of "trust" and mechanical processing, and on the other hand
you seemed to be discussing the purely mechanical processing of key
identifier extensions.  In the latter case, my answer to the question
is yes, I agree.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07289 for ietf-pkix-bks; Fri, 5 Mar 1999 12:29:15 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA07285 for <[e-mail]>; Fri, 5 Mar 1999 12:29:13 -0800 (PST)
Received: (qmail 23960 invoked from network); 5 Mar 1999 20:34:49 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 5 Mar 1999 20:34:49 -0000
Received: (qmail 17176 invoked from network); 5 Mar 1999 20:30:23 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 5 Mar 1999 20:30:23 -0000
Message-ID: <010101be6737$64087290$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing andAKIpointer hanging
Date: Fri, 5 Mar 1999 12:38:40 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

I like much of your thinking. It seems suited to the general Internet
culture.

If a cert path has two certs (A & B) , and the second (B) has an authority
key identifier pointer to its parent, can the chain be valid
it the identified parent is specifically NOT A, according to PKIX?

This situation happens when, as per your example, unidirectional, unilateral
cross-certification (without policy mapping, say) occurs into a
hierarchical,
policy-oriented PKI domain which has pre-established AKI backpointers.

My thoughts are, assuming what I thought was a simple question is answered
positively for the 2459 case, that PKIX-QC might establish that a
critical flag on the AKI would make this situation INVALID, in contrast.
And, therefore, enable the well-controlled PKI domain to signal that
inward, unilateral  cross-certification is not supported - as
enforced by 2459-conforming relying parties who require the
assurances of the PKIX-QC interoperability policy.

Peter.



-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Thursday, March 04, 1999 3:04 PM
Subject: Re: PKIX Path determination/construction/processing andAKIpointer
hanging


>Peter and
>Peter and David,
>
>I'm not sure that I understand the argument -- maybe I wasn't paying
attention earlier.
>
>maybe peter can clarify what he means.
>
>I have in mind a model where I as the relying party have a certificate
chain that starts at some CA that I trust, and may descend top down from
Issuer to Subject, probably ending with my own certificate.
>
>In addition, there is a chain of certificates sent to me (or otherwise made
available) by the originator or signer of some document, which I process
bottom up, chaining from Subject to Issuer.  Unfortunately, if I follow that
certificate chain all the way to the originators "top" I may never encounter
a certificate that I trust.
>
>So in addition to the normal, bidirectionally link chain of certificates in
my own hierarchical tree, I have some cross-certification certificates that
may very well by unidirectional.  In other words, at any particular node in
my own hierarchy, that CA may have issued a cross-certificate which includes
the public key of some node in the originator's chain of certificates.
>
>So the path processing algorithm proceeds as follows:
>
>1.  Start at the root of my (the RP) hierarchy, and process all of the CA
certificates top down, keeping a cache of all of the public keys (key IDs).
>
>(1a.  Repeat for any additional trusted hierarchies, including any
certificates added by the relying party on his own authority, e.g., his
sister's end user certificate, or a CA or subordinate CA issued by a company
that they are partnered with, regardless of the fact that they don't
necessarily trust that company's top-level CA.)
>
>2.  Start at the bottom of the signer's certificate chain and process
bottom up.
>
>3.  At each step of the way, query the cache of public keys to determine
whether that key has been seen before, and hence is considered trusted. If
so, then the path extends from the RP's own trusted root down his chain to
the cross certificate, and then continues down the originators chain from
that point on to the end.
>
>4.  If the public key in question has not been processed previously and
therefore know to be trusted, then continue climbing the signer's tree
bottom-up, following the Issuer chain.  (How you find these certificates is
of course a different issue -- I'm only addressing the chain of trust.
>
>5.  If you reach a self-signed certificate (indicating the top of a chain)
without having encountered a key that is trusted, then the path is not
trusted and you have to decide to do with it -- reject the whole chain, ask
the user whether to add the certificate on a one-time basis, or whatever.
>
>6.  Once you have blazed a trail through the woods, chopping a notch on
every tree (key) that you trust until you get back to your own top, then
(and only then, I believe) have you identified the path, and are prepared to
process the entire chain from top down, this time omitting the signature
validation but doing
>all of the validity checking, CRL checking, constraint checking, etc.  It
could be argued that you could validate the date range on the first pass
through the  certificates. maybe you could argue that you should check the
CRLs at that time also, but that may be a more expensive process, and
perhaps you ought to validate the chain as it stands before going elsewhere
to check the status.
>
>Now, Peter, does what I have suggested fit the path establishment model you
were proposing?  If not, could you describe yours more completely, because
the above is the only one I've been able to convince myself really works.
>
>Bob
>
>
>
>>>> "David P. Kemp" <[e-mail]> 03/04/99 08:07AM >>>
>
>> From: "Peter Williams" <[e-mail]>
>>
>> QUESTION: If a certificate path chosen by a relying party contains at
>> least one certificate whose authority key id backpointer does
>> NOT resolve to a certificate in that path or any certificate
>> known to the relying party, can one designate otherwise normal
>> processing of  that chain as conforming to PKIX 2459?
>>
>> My answer to the question is yes. Does anyone disagree?
>
>
>If I understand the question correctly, I disagree.  Restating
>the question as I understand it:
>
>  If a certificate path chosen by a relying party is not
>  a continuous chain between the certificate being validated
>  and a certificate trusted by the relying party, can one designate
>  otherwise normal processing of that chain as conforming to RFC 2459?
>
>If the relying party has no notion of a trusted public key, or has
>an implementation which returns a "success" answer when given a path
>not terminating in a trusted public key, then RFC2459 is irrelevant.
>Frobbing the bits in accordance with section 6 may increase the entropy
>of the relying party's immediate environment (generate some heat and
>waste some time), but it has no other useful effect.
>
>RFC2459 says "This text assumes that all valid paths begin with
>certificates issued by a single 'most trusted CA'." (and then goes
>on to discuss extended path validation where paths may begin with
>one of several trusted CAs).
>
>I interpret "This text assumes ..." to mean that if the assumption
>is not met, then the results are undefined, and that if the results
>are undefined, then there is no meaningful conformance.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06848 for ietf-pkix-bks; Fri, 5 Mar 1999 11:36:48 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06844 for <[e-mail]>; Fri, 5 Mar 1999 11:36:46 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA03915 for <[e-mail]>; Fri, 5 Mar 1999 14:42:23 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA03911 for <[e-mail]>; Fri, 5 Mar 1999 14:42:23 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id OAA01663 for <[e-mail]>; Fri, 5 Mar 1999 14:40:59 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id OAA10063 for <[e-mail]>; Fri, 5 Mar 1999 14:40:22 -0500 (EST)
Message-Id: <[e-mail]>
Date: Fri, 5 Mar 1999 14:40:22 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: j/al73/0ZfaEWrrx3Sk8dw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Bob Jueneman" <[e-mail]>
> 
> David,
> 
> Flat is not necessarily bad, although the performance of 
> typical directory implementations may be a concern.
> 
> But hashing the certificate or public key a la SPKI is 
> in my opinion NOT the way to go, for reasons that were 
> argued extensively on that list (even if Carl Ellison 
> remains unconvinced).
> 
> I wouldn't mind such a technique as an alias, if aliases 
> weren't such a headache, but I don't think it would be 
> acceptable as the primary DN, because people want to be
> able to look up lots of other things about someone than
> their certificate, and they want to be able to do so for a 
> very long period of time.


I see two different scenarios for looking up certificates:

1) I receive an S/MIME message (or an IPSEC/IKE connection request)
containing only an EE cert or (preferably) no cert at all, just a
certID.  I look for the issuer cert path (and perhaps also the EE cert)
in my local ram cache and my local disk cache. If they aren't cached, I
do a repository fetch, which chains as required from my company's or
ISP's directory cache on up to the Internet Root.  For this purpose, a
certID should be an "address" (i.e. something meaningless and
politically non-controversial like a hash) with the sole purpose of
enabling the fetching to occur.

2) I have a "name" of someone I want to communicate with and don't
already have any information about him (such as a certID, DN, or cert)
in my address book.  For that, I need a white pages directory.

The first "repository" scenario is the one I'm addressing.
It is easy to solve, and the IETF should solve it by defining
the protocols and standing up the infrastructure root, because
it is purely a technical engineering exercise.

The second "directory" scenario is too hard.  People were
arguing about directories and naming schemes before I was born
and will be doing so after I'm gone. More importantly, directories
should IMHO be regarded as layered *on top of* repositories,
providing metadata about the repository's contents, but not
being necessesary for the repository to operate.  Just as if
DNS fails I can make a TCP connection to a dotted-quad IP address,
if "The Directory" fails or is never established or information owners
filter what it is allowed to reveal, I should still be able to
fetch a cert by ID.

I'm not signing up to the SPKI philosophy that the cert itself
needs no name.  I'm just saying that the cert should be retrievable
by an ID that is not necessarily a name.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29808 for ietf-pkix-bks; Fri, 5 Mar 1999 01:07:42 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA29803 for <[e-mail]>; Fri, 5 Mar 1999 01:07:31 -0800 (PST)
Received: from darmstadt.gmd.de (aberger@pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id KAA25510; Fri, 5 Mar 1999 10:10:22 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 1999 10:10:22 +0100
From: Andreas Berger <[e-mail]>
Organization: GMD Darmstadt
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'Bob Jueneman '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: A web of directories - Finding PKIX Servers
References: <D1A949D4508DD1119C8100400533BEDC0C4E14@DSG1>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:
> 
> Can I write a similar message to what was written in the X.500 / 509
> standards 11 years ago. That X.509 is part of X.500 and for most people
> working with 509 and PKI - part of the system design is to use directory
> services as the information infrastructure on which 509 services are
> used. It strikes me that if 509 is used without directories, then one
> has to create mappings, strange names, extensions, domain names,
> gateways, human configuration etc. If X.509 is the wheel - its best to
> use it with a car - otherwise one has to carry it everywhere - and the
> ride just aint the same :-)
> 
> I just do not understand why so much effort is going into "getting round
> " directory services - when so many organisations are putting 509 and
> directories together as part of their major authenticated - distributed
> information infrastructure system designs.
> 
> regards alan
Alan,

it is not that I am living in a purely IP/DNS world and that I think
that X.500 is likely to fail or whatever. Many project we do tend to -
sooner or later - have a directory server, but mostly inside
organizations. This is fine.

But it seems that the "cost of entry" to deploying an external server is
usually avoided by these organizations. So they don´t set one up (also
because almost nobody will use them, the chicken and egg problem).

So why shouldn´t we probpose a simple, light weight alternative for the
short term to medium term , doing the "root" lookup of X.500 via DNS and
wait for the public to recognize that directory servers are useful. Then
we can connect those servers and get rid of the "hack" or provide the
information of the hack via the global directory in the interim.

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA20974 for ietf-pkix-bks; Thu, 4 Mar 1999 18:35:44 -0800 (PST)
Received: from lux.tenebras.com (dnai-207-181-255-101.dialup.dnai.com [207.181.255.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA20970 for <[e-mail]>; Thu, 4 Mar 1999 18:35:42 -0800 (PST)
Received: from dnai.com (windoze.tenebras.com [192.168.100.122]) by lux.tenebras.com (8.8.8/8.8.8) with ESMTP id QAA20258; Thu, 4 Mar 1999 16:51:28 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Disposition-Notification-To: Michael Sierchio <[e-mail]>
Date: Thu, 04 Mar 1999 16:51:30 -0800
From: Michael Sierchio <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Please reply
X-Priority: 1 (Highest)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[apologies if you receive duplicates of this msg.  I have some
 duplicate entries in my address book. -M]

Sorry about this message,  but if you're a recipient, 
we've had some correspondence in the last several years.  I
am trying to determine which of my address book entries are
stale, and which belong to people with whom my contact has
been so brief that my name doesn't ring a bell. ;-)

Please reply if:

        1)      this reaches you, and;

        2)      you remember me.


Thanks,

Michael Sierchio
1563 Solano Ave Ste 123
Berkeley CA 94707
[phone]
[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA20744 for ietf-pkix-bks; Thu, 4 Mar 1999 18:13:54 -0800 (PST)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA20739 for <[e-mail]>; Thu, 4 Mar 1999 18:13:42 -0800 (PST)
Received: from erols.com (207-172-113-154.s154.tnt5.ann.va.dialup.rcn.com [207.172.113.154]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id VAA02050; Thu, 4 Mar 1999 21:22:00 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 04 Mar 1999 21:13:19 -0500
From: Martin Smith <[e-mail]>
Organization: USITC
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'PKIX list '" <[e-mail]>
Subject: Re: Cert binding to ?
References: <D1A949D4508DD1119C8100400533BEDC0C4E08@DSG1>
Content-Type: multipart/mixed; boundary="------------CBEC496AEB0C86808EB138A8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------CBEC496AEB0C86808EB138A8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It seems to me that the problem with the X-standards was not that they were
too complex, but that they were being run by the wrong people.  It's been
observed more than once that the "lightweight" in LDAP is fast disappearing.
And why not, with RAM at $1/meg and disk at $100/gig?  The reason LDAP
succeeds is "running code and rough concensus."

Alan Lloyd wrote:
snip

> the directory service of usage of DNs does not mean that the system is
> geopolitical. Its just many have seen X.500 as too big (12 mb) DAP as
> too big (130 kb), that X.500 is THE global directory not A directory
> service, one of many) and that PKI roots = directory roots, etc.

> snip

--------------CBEC496AEB0C86808EB138A8
Content-Type: text/x-vcard; charset=us-ascii;
 name="mfsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Martin Smith
Content-Disposition: attachment;
 filename="mfsmith.vcf"

begin:vcard 
n:Smith;Martin
x-mozilla-html:TRUE
org:US International Trade Commission
adr:;;500 E Street SW;Washington;DC;20436;USA
version:2.1
email;internet:[e-mail]
title:Director, Information Services
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-cpt:;0
fn:Martin Smith
end:vcard

--------------CBEC496AEB0C86808EB138A8--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA19405 for ietf-pkix-bks; Thu, 4 Mar 1999 15:51:13 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA19400 for <[e-mail]>; Thu, 4 Mar 1999 15:51:12 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA03296; Thu, 4 Mar 1999 15:52:41 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA10914; Thu, 4 Mar 1999 15:56:15 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRAMD6A>; Thu, 4 Mar 1999 15:56:15 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Date: Thu, 4 Mar 1999 15:56:14 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

There's no requirement that the accessMethod be protocol-specific.  This
level of specificity can be derived from the chosen name form in
GeneralName.  In the case of OCSP, the spec establishes that the URI name
form MAY be used.

Since URIs can be prefixed with a variety of protocol methods (e.g. http://,
ftp://, ldap://), we wrote Appendix A.1 to provide implementation guidance
for OCSP over HTTP and so ensure at least one method of establishing
interoperability.

These are minimum interoperability requirements.  Environments with more
specialized needs are of course free to assert additional requirements in a
forum and manner of their choice, just as they do today with certificate
extensions.  In particular, the spec purposefully has no language
establishing that {URI, HTTP} is the ONLY mechanism for id-ad-ocsp.

Mike




> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Thursday, March 04, 1999 10:31 AM
> To: [e-mail]; [e-mail]
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Mike,
> 
> Sorry if I misunderstood.
> 
> You said that
> 
> >AuthorityInfoAccessSyntax  ::=
>         SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
> >AccessDescription  ::=  SEQUENCE {
>         accessMethod          OBJECT IDENTIFIER,
>         accessLocation        GeneralName  }
> 
> >The OCSP OID would simply identify the URI used for that 
> particular method.
> 
> I was interpreting the accessMethod OBJECT IDENTIFIER to 
> refer to say LDAP, DAP, HTTP, or whatever, regardless of 
> what use they might be put to.
> 
> Are you saying that the accessMethod OID is particularized to mean
> "LDAP for OCSP", " LDAP for CRLs", or 
> "LDAP for certificate lookup in a directory", etc?
> 
> Have particular OIDs defined for those semantics, at least 
> in the case of OCSP? 
> 
> (My apologies if all of this is well known to everyone else -- 
> I just don't have the time to and understand read every RFC 
> that comes out in the required amount of detail.)
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17673 for ietf-pkix-bks; Thu, 4 Mar 1999 12:28:50 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA17662 for <[e-mail]>; Thu, 4 Mar 1999 12:27:28 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 12:04:09 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 12:04:02 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
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 mail.proper.com id MAA17664
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

Flat is not necessarily bad, although the performance of 
typical directory implementations may be a concern.

But hashing the certificate or public key a la SPKI is 
in my opinion NOT the way to go, for reasons that were 
argued extensively on that list (even if Carl Ellison 
remains unconvinced).

I wouldn't mind such a technique as an alias, if aliases 
weren't such a headache, but I don't think it would be 
acceptable as the primary DN, because people want to be
able to look up lots of other things about someone than
their certificate, and they want to be able to do so for a 
very long period of time.

The only problem I have with using an employee number
as the primary index is the tendency to use a master dossier
index such as the SSN for that purpose -- a privacy concern.

Even if we used a SHA-1 hash of a canonical form of the 
employee's birth certificate (which would be a perfectly 
lousy "name"), it might still become a dossier locator.

Employee ID is probably about the best that can be done, but it 
should not be global in scope, but rather unique only within the
naming organization.

Maybe we partition the employee ID space for efficiency,
perhaps by including the first letter of the (original) name,
or something similar. 

Bob (J.1234567)

>>> "David P. Kemp" <[e-mail]> 03/04/99 08:42AM >>>
> From: [e-mail] (Arnoud "Galactus" Engelfriet)
> 
> The number of .com domains is now well over 3 million. It's hardly
> a meaningful top-level domain anymore.

Au contraire.  What is meaningful about it is that those 3 million
domains are registered in a single place, and as a result a given
name can be resolved unambiguously.

The longer I look at naming heirarchies, the more my goodness metric
becomes "the flatter, the better".  It would be fine with me if
certificates were indexed by hash value (as stored in AKI), and
one could find every certificate on the Internet by looking it up
in The Directory by that value.

Bob, that's my suggestion for your magic bullet.  Efficiency may demand
CIDR-style partitioning of the AKI space (or something along the lines
of Tony's a.b.c.d prefix, applied to AKI instead of DN), but that could
work by migrating certificates to the appropriate directory server(s)
by prefix WITHOUT any pre-arranged AKI partitioning of CAs.
EE certs could be referred to by "cert hash" instead of (or in addition
to) Issuer/Serial, and retrieved from the Directory the same way.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17625 for ietf-pkix-bks; Thu, 4 Mar 1999 12:23:45 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA17621 for <[e-mail]>; Thu, 4 Mar 1999 12:23:43 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 12:01:20 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 11:48:24 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: A web of directories - Finding PKIX Servers
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 mail.proper.com id MAA17622
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No, not really.  As I've said before, e-mail is NOT the only 
way of communicating either signed or encrypted documents,
or even certificates, and I am trying to come up with a 
method that would be universal.

In addition, if he sends you a signed message, that may only include
the certificate for his signature key, and not his encryption key.
and it is even less likely to include additional certificates for RSA,
DH/DSS, elliptic curves, etc.

FYI, a recent RFC has been posted that would allow S/MIME to 
describe their crypto capabilities in a directory entry.

Bob

>>> Marc Jadoul <[e-mail]> 03/04/99 11:05AM >>>
Hi,

I really find acceptable to send an email to the person i want to
contact and wait for his signed reply. Don't you ?

I do not know how s/mime work, but it seems also the only way to know if
the program he use is able to do strong crypto or even negotiate other
need parameter to initiate a secure communication. Isn't it ?

Marc Jadoul



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17535 for ietf-pkix-bks; Thu, 4 Mar 1999 12:15:55 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA17531 for <[e-mail]>; Thu, 4 Mar 1999 12:15:54 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 11:31:26 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 11:31:18 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Access
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 mail.proper.com id MAA17532
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Sorry if I misunderstood.

You said that

>AuthorityInfoAccessSyntax  ::=
        SEQUENCE SIZE (1..MAX) OF AccessDescription

>AccessDescription  ::=  SEQUENCE {
        accessMethod          OBJECT IDENTIFIER,
        accessLocation        GeneralName  }

>The OCSP OID would simply identify the URI used for that 
particular method.

I was interpreting the accessMethod OBJECT IDENTIFIER to 
refer to say LDAP, DAP, HTTP, or whatever, regardless of 
what use they might be put to.

Are you saying that the accessMethod OID is particularized to mean
"LDAP for OCSP", " LDAP for CRLs", or 
"LDAP for certificate lookup in a directory", etc?

Have particular OIDs defined for those semantics, at least 
in the case of OCSP? 

(My apologies if all of this is well known to everyone else -- 
I just don't have the time to and understand read every RFC 
that comes out in the required amount of detail.)

Bob

>>> Michael Myers <[e-mail]> 03/04/99 10:42AM >>>
Bob,

I've seen AIA working as most other OID-based mechanisms work.  One defines
and OID and the semantics associated with it.  The OCSP draft does this for
this one particular method of accessing this one particular type of
authority information using one particular transport--with the underlying
assumption that there is only one value of id-ad-ocsp in the AIA SEQUENCE.

Other AIA accessMethod OIDs can be defined for other purposes and so
disambiguate the cases you cite.  Perhaps this is a subject for an I-D that
identifies and defines additional standard methods and semantics of AIA use.

I can say with certainty that OCSP does not "think" is somehow owns the
entire scope of semantics that AIA establishes.

Mike

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]] 
> Sent: Thursday, March 04, 1999 8:43 AM
> To: [e-mail]; [e-mail] 
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Michael,
> 
> I understand that AIA is multiply-valued, so I can put in 
> multiple URLs.
> 
> The question, as is the case all too often, is what are the 
> SEMANTICS of those various URLs?
> 
> So I put in one LDAP, one DAP, and one HTTP, or maybe just 
> three LDAPs.
> 
> Is OCSP going to assume that each and every one of those URLs 
> point to an OCSP server, and maybe it should make a random 
> choice?  What if one refers to the originator's directory 
> that contains his certificate, one refers to the CA's 
> directory which can be used to look up certificates by Issuer 
> name and serial and NOT by DN, and one points to a directory 
> of CRLs and/or OCSP providers that do NOT maintain a list of 
> certificate or other potentially useful information?
> 
> I believe that my original thought was correct -- that OCSP 
> thinks it has exclusive ownership of the AIA attribute?
> 
> Bob
> 
> >>> Michael Myers <[e-mail]> 03/04/99 08:57AM >>>
> Bob,
> 
> AIA is multiply-valued, so you can put in other info:
> 
> AuthorityInfoAccessSyntax  ::=
>         SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
> AccessDescription  ::=  SEQUENCE {
>         accessMethod          OBJECT IDENTIFIER,
>         accessLocation        GeneralName  }
> 
> The OCSP OID would simply identify the URI used for that 
> particular method.
> 
> Mike
> 
> > -----Original Message-----
> > From: Bob Jueneman [mailto:[e-mail]] 
> > Sent: Wednesday, March 03, 1999 5:43 PM
> > To: [e-mail]; [e-mail] 
> > Subject: RE: OCSP Service Locator and RFC2459's Authority 
> Information
> > Access
> > 
> > 
> > Michael, is the AIA in that case presumed to apply uniquely 
> > to the OCSP provider -- i.e., has OCSP highjacked that field?
> > 
> > Or can other uses be provided as well, using multiple URIs or 
> > whatever?
> > 
> > Bob
> > 
> > >>> Michael Myers <[e-mail]> 03/03/99 05:00PM >>>
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] 
> > > 
> > > This brings up a new question: why is there no OCSP AIA 
> > > AccessDescription
> > > defined?  :) All we need is an OID and a URIName of type 
> > > IA5STRING.  Is it
> > > too late to add this to the current draft?  Does it belong 
> > > here, or does it
> > > more like a cert profile item?  Because of its "dual 
> > nature" should it
> > > perhaps
> > > be written up separately, anyway? (Probably not, since the 
> > > OID base will end
> > > up
> > 
> > 
> > Rick,
> > 
> > It's already in there:
> > 
> > "4.1  Certificate Content
> > 
> >    In order to convey to OCSP clients a well-known point of 
> > information
> >    access, CAs SHALL provide the capability to include the
> >    AuthorityInfoAccess extension (defined in [PKIX1], 
> section 4.2.2.1)
> >    in certificates that can be checked using OCSP.  
> Alternatively, the
> >    accessLocation for the OCSP provider may be configured 
> > locally at the
> >    OCSP client.
> > 
> >    CAs that support an OCSP service, either hosted locally 
> or provided
> >    by an Authorized Responder, MAY provide a value for a
> >    uniformResourceIndicator (URI) accessLocation and the 
> OID value id-
> >    ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> > 
> >    The value of the accessLocation field in the subject certificate
> >    defines the transport (e.g. HTTP) used to access the 
> OCSP responder
> >    and may contain other transport dependent information 
> > (e.g. a URL)."
> > 
> > 
> > Mike
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17446 for ietf-pkix-bks; Thu, 4 Mar 1999 12:07:58 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA17426 for <[e-mail]>; Thu, 4 Mar 1999 12:06:35 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 11:21:41 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 11:21:31 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Certificate mapping (was: Re: Qualified Certificates draft - Country name)
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 mail.proper.com id MAA17428
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>I think one really wants partitioning along organizational lines, not the
arbitrary lines that the CIDR-like approach would imply.  Organizational
responsibility for maintenance of directories has worked well for the DNS,
and if one were to create a PKI tied to the DNS, e.g., based on DNs that
employ only DC attributes, then I think we would want to make use of the
record types already defined for storage of X.509 certs.

>Steve

I don't agree, at least if you are suggesting that PKI names MUST be
tied to a DNS structure.

The problem is that lots of servers do not have DNS name, 
but only IP addresses, and that doesn't include servers that use 
other forms of addressing such as Novell's IPX,  older Mac systems, 
etc.  They are not necessarily mapped to an IP address at all, and 
may not even be connected to the IP-Internet.

When it comes to end-users, I believe that the IETF mantra is that
we are still assuming only limited connectivity to the Internet.  Granted,
as the Internet becomes increasingly ubiquitous it may be appropriate
for the IETF to formally revisit that basic assumption, but at least as of this
moment, I do NOT believe that we should assume that every user even
HAS a DNS name, in his e-mail address or elsewhere, or even that 
he has an e-mail address, much less that he is connected,
or that his e-mail provider necessarily has anything to do with his 
organization or his personal life, etc.  

A few years ago, when telecommuting from home, I used Frontier 
Technologies' e-mail package, which included both an 
SMTP client and server on my workstation, in order to avoid 
some of the problems with POP mail and sometimes unreliable 
servers and occasionally interrupted connectivity. When I did 
have connectivity, which I wanted to be restored without my 
intervention, I wanted to have all of my mail downloaded and 
processed without my having to go out and tell the server that 
I was now ready to read my mail, and then have to sit there and 
wait. That system met my needs, but my "ISP" was my company, 
and neither they nor I would  have been prepared to host a 
directory service at that time. Instead, had I really needed one, 
I might have contracted out that function, but probably to 
someone with a completely unrelated DNS name.

There are lots of other ways that I can exchange digitally signed
information, including sneaker-net and Federal Express, and 
tying something as fundamental as a certificate lookup
process to a particular network connectivity and/or e-mail 
processing model would be simply wrong.  An RFC 822 mail address
is an interesting and perhaps useful factoid, as is an X.400 name, as is
my organizational person X.520 style name, as is my geopolitical 
residential person name, but NONE of these may happen to correspond
to the way that my chosen (or company-dictated) directory provider wants
to organize their directory to optimize their particular value proposition.

If they choose to use a flat name space that doesn't even include 
a country code, such as o=XYZ, employeeID=1234567, then so 
be it -- they may have perfectly valid reasons for that, including 
tracking employee benefits across marriage and other name 
changes, rank changes (in the military), periodic organizational 
realignments, operations in multiple countries with employees 
who routinely transfer between countries, etc., for a 40 year 
career plus retirement.

The fact that a PKI certificate is issued with a one to three year 
validity is certainly NOT sufficient reason to force a directory provider 
to change the way they organize their business.  It's a variant of the 
Golden Rule -- "he who has the gold, rules," and in this case the "gold" 
is the directory in which certificates are to be placed so others can
find them.

This leads me to what I now believe is a fundamental 
principle, and one that has taken me a long time to arrive at.

I believe that we must recognize that the DN in the certificate was 
originally intended to directly reflect the primary name of the entity 
in the directory, in this case the directory  in which the subscriber 
chooses to publish his certificates, and the DN in the 
certificate should continue to be used for that 
purpose exclusively. If your CA won't support your directory's
choice of DIT and schema, at least with respect to the DN, 
then find another CA.  And don't assume that all directories are 
ever going to be globally interconnected or have a common
DIT structure or schema -- they won't, ever.

Other names and/or forms of identification that can be used to 
LOCATE someone should be relegated to alternateSubjectNames, 
and browsers and other forms of relying party software MUST be 
required to be able to display and/or otherwise process such 
information, regardless of multiple language support issues, etc.

On the other hand, information that cannot be used to locate 
someone but instead is merely used confirm their identity once 
they have been found, including the infamous MPEG movie of me 
playing with my cat, or my fingerprint template, retinal scan,
voice print, photograph, or DNS profile, etc., should be 
carried in other certificate attributes, as they are not "names."

Likewise, attributes which convey rights, privileges, restrictions, 
etc., should not be contained in either the DN or alternate
names either, as they are not names either.  (I might relent a 
little in the case of a role, which might be considered a form
of name, but only if the directory supports it.)

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17120 for ietf-pkix-bks; Thu, 4 Mar 1999 11:28:43 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA17110 for <[e-mail]>; Thu, 4 Mar 1999 11:27:22 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 10:43:16 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 10:20:59 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
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 mail.proper.com id LAA17111
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter and 
Peter and David,

I'm not sure that I understand the argument -- maybe I wasn't paying attention earlier.

maybe peter can clarify what he means.

I have in mind a model where I as the relying party have a certificate chain that starts at some CA that I trust, and may descend top down from Issuer to Subject, probably ending with my own certificate.

In addition, there is a chain of certificates sent to me (or otherwise made available) by the originator or signer of some document, which I process bottom up, chaining from Subject to Issuer.  Unfortunately, if I follow that certificate chain all the way to the originators "top" I may never encounter a certificate that I trust.

So in addition to the normal, bidirectionally link chain of certificates in my own hierarchical tree, I have some cross-certification certificates that may very well by unidirectional.  In other words, at any particular node in my own hierarchy, that CA may have issued a cross-certificate which includes the public key of some node in the originator's chain of certificates.

So the path processing algorithm proceeds as follows:

1.  Start at the root of my (the RP) hierarchy, and process all of the CA certificates top down, keeping a cache of all of the public keys (key IDs).

(1a.  Repeat for any additional trusted hierarchies, including any certificates added by the relying party on his own authority, e.g., his sister's end user certificate, or a CA or subordinate CA issued by a company that they are partnered with, regardless of the fact that they don't necessarily trust that company's top-level CA.)

2.  Start at the bottom of the signer's certificate chain and process bottom up.

3.  At each step of the way, query the cache of public keys to determine whether that key has been seen before, and hence is considered trusted. If so, then the path extends from the RP's own trusted root down his chain to the cross certificate, and then continues down the originators chain from that point on to the end.

4.  If the public key in question has not been processed previously and therefore know to be trusted, then continue climbing the signer's tree bottom-up, following the Issuer chain.  (How you find these certificates is of course a different issue -- I'm only addressing the chain of trust.

5.  If you reach a self-signed certificate (indicating the top of a chain) without having encountered a key that is trusted, then the path is not trusted and you have to decide to do with it -- reject the whole chain, ask the user whether to add the certificate on a one-time basis, or whatever.

6.  Once you have blazed a trail through the woods, chopping a notch on every tree (key) that you trust until you get back to your own top, then (and only then, I believe) have you identified the path, and are prepared to process the entire chain from top down, this time omitting the signature validation but doing
all of the validity checking, CRL checking, constraint checking, etc.  It could be argued that you could validate the date range on the first pass through the  certificates. maybe you could argue that you should check the CRLs at that time also, but that may be a more expensive process, and perhaps you ought to validate the chain as it stands before going elsewhere to check the status.

Now, Peter, does what I have suggested fit the path establishment model you were proposing?  If not, could you describe yours more completely, because the above is the only one I've been able to convince myself really works.

Bob



>>> "David P. Kemp" <[e-mail]> 03/04/99 08:07AM >>>

> From: "Peter Williams" <[e-mail]>
> 
> QUESTION: If a certificate path chosen by a relying party contains at
> least one certificate whose authority key id backpointer does
> NOT resolve to a certificate in that path or any certificate
> known to the relying party, can one designate otherwise normal
> processing of  that chain as conforming to PKIX 2459?
> 
> My answer to the question is yes. Does anyone disagree?


If I understand the question correctly, I disagree.  Restating
the question as I understand it:

  If a certificate path chosen by a relying party is not
  a continuous chain between the certificate being validated
  and a certificate trusted by the relying party, can one designate
  otherwise normal processing of that chain as conforming to RFC 2459?

If the relying party has no notion of a trusted public key, or has
an implementation which returns a "success" answer when given a path
not terminating in a trusted public key, then RFC2459 is irrelevant.
Frobbing the bits in accordance with section 6 may increase the entropy
of the relying party's immediate environment (generate some heat and
waste some time), but it has no other useful effect.

RFC2459 says "This text assumes that all valid paths begin with
certificates issued by a single 'most trusted CA'." (and then goes
on to discuss extended path validation where paths may begin with
one of several trusted CAs).

I interpret "This text assumes ..." to mean that if the assumption
is not met, then the results are undefined, and that if the results
are undefined, then there is no meaningful conformance.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16995 for ietf-pkix-bks; Thu, 4 Mar 1999 11:17:40 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16991 for <[e-mail]>; Thu, 4 Mar 1999 11:17:37 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GHVLPJ8K>; Fri, 5 Mar 1999 06:22:53 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0C4E16@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail] '" <[e-mail]>
Subject: RE: Qualified Certificates draft - Country name
Date: Fri, 5 Mar 1999 06:22:51 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For my two bobs worth - I think that making the global business
community comply to an RFC that dictates the global positioning and
representation of its information system names into a business market is
a nonsense.

What stops organisations like Pepsi, Msoft, Ford, etc spending billions
on an IT a directory/509/transaction infrastructure - applying global
org names and putting services and products all over it and giving their
customers loyalty based certficates to use such service/products.
Absolutely nothing !

And if such a company asked a huge IT orgainsation to build it - would
they go kicking and screeming that a country name must be used... NO


One cannot force names on business organisations through the use of RFCs
or standards .... remember GOSIP !

regards alan 
PS Country names just HAVE to be optional.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16915 for ietf-pkix-bks; Thu, 4 Mar 1999 11:05:47 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA16900 for <[e-mail]>; Thu, 4 Mar 1999 11:04:26 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id LAA11318; Thu, 4 Mar 1999 11:06:42 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 04 Mar 1999 11:05:51 -0800
To: Stephen Kent <[e-mail]>, "David P. Kemp" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
Cc: [e-mail]
In-Reply-To: <v04020a08b30462003a07@[128.89.0.110]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:57 AM 3/4/99 -0500, Stephen Kent wrote, in part:

>I think one really wants partitioning along organizational lines, not the
>arbitrary lines that the CIDR-like approach would imply.  Organizational
>respobsibility for maintenance of directories has worked well for the DNS,
>and if one were to create a PKI tied to the DNS, e.g., based on DNs that
>employ only DC attributes, then I think we would want to make use of the
>record types already defined for storage of X.509 certs.

Stephen,

I see how "arbitrary partitioning" presents problems for distributed
responsibility of directory maintenance.  But these problems are rooted
in the nature of information the directories are designed to hold, and
begs the question "Why were they designed to hold such information."

As you say, organizational partitioning has worked well for DNS, but
then there is little of privacy concern over data in a DNS database,
and the naming scheme is almost arbitrary.  One should "trust" DNS
only as far as one might trust the entries in a phone book.  If I were
to look up a supposed building contractor from a phone book, I would
still require futher credentials (valid licence, no pending judgements)
before commiting to services.  If the entry in the phone book is bogus,
it is only a minor inconvenience, assuming I exercise diligence.

Certificate and Issuer look-up directories should do no more than this.
They should represent pointers to "tests for trust" and not be trusted
in themselves.  The "best practice" would be to automate multiple tests
through look-ups of independently managed directories, and use a form
of "majority rule" in making determinations of accuracy.

I am concerned about both the fragility and sensitivity of "trusted
directory services" which intend to globalize "meat-space" parameters,
especially geographic, country, state, address, etc.  I ask myself
"What is the worst someone could do, who has access to all of this
information?"

Apologies for not having enough details to make more specific comments.

___tony___






Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16837 for ietf-pkix-bks; Thu, 4 Mar 1999 10:55:54 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16833 for <[e-mail]>; Thu, 4 Mar 1999 10:55:46 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GHVLPJ8H>; Fri, 5 Mar 1999 06:00:51 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0C4E14@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Bob Jueneman '" <[e-mail]>, "'Andreas Berger '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: A web of directories - Finding PKIX Servers
Date: Fri, 5 Mar 1999 06:00:43 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA16834
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Can I write a similar message to what was written in the X.500 / 509
standards 11 years ago. That X.509 is part of X.500 and for most people
working with 509 and PKI - part of the system design is to use directory
services as the information infrastructure on which 509 services are
used. It strikes me that if 509 is used without directories, then one
has to create mappings, strange names, extensions, domain names,
gateways, human configuration etc. If X.509 is the wheel - its best to
use it with a car - otherwise one has to carry it everywhere - and the
ride just aint the same :-)

I just do not understand why so much effort is going into "getting round
" directory services - when so many organisations are putting 509 and
directories together as part of their major authenticated - distributed
information infrastructure system designs.


regards alan 

----------
From: Andreas Berger
To: Bob Jueneman
Cc: [e-mail]; [e-mail]; [e-mail]
Sent: 3/4/99 10:47:46 PM
Subject: Re: A web of directories - Finding PKIX Servers

Hello all,

I wrote a similar message about a year ago but it was mostly ignored...

Anyway, it seems that wa all have a problem here.

The problem, in my opinion, is that we simply do not have a global X.500
service deployed (for whatever reason) but we use X.500 identifiers
(DNs) in our systems. So whenever I need the entry for a particular DN,
I have no method to find the server serving this information. X.500
would do this.

The basic lookup processes we have are:

- resolve an eMail address into a certificate for encryption.
- resolve a DN into a certificate (looking up a CA certificate)
- resolve a DN into a CRL (looking up a CA´s CRL)
- find other services (OCSP) based on a DN

I suggest the following:

In order allow independet deployment of PKIX "directoy servers" we
should follow the Mail Model: A company puts a service on the net,
announcing the availiability using DNS. I find it perfectly reasonable
to have my company, GMD in Germany, to offer an external LDAP service
for their employees, under (e.g.) ldap.gmd.de.

The problem now is how to resolve the X.500 DN (O=GMD Forschungszentrum
Informationstechnik GmbH, c=DE) into the DNS domain (gmd.de).

The first method for a user would be to contact any official LDAP
gateway to X.500 and look up the entry for GMD. This may work if GMD has
set up a proper X.500 server. Then two cases exist: GMD has set up only
one entry for its name or it has set up a complete X.500 system. The
second case is easy, it the X.500 model. In the first case, we could
hope that the domain name is contained as an attribute in the X.500
entry.

Now I have a DNS domain name, gmd.de, which could then be queries via
DNS and optionally SRV records (e.g. I can first ask for an SRV record
for a specific protocol that the user´s client understands like LDAP).
If that does not work, the client could try ldap.gmd.de and get the
server´s name.

Now let´s suppose a case where the organization does not have an X.500
entry. One idea would be to use the IssuerAlternativeName to supply the
"root" DNS name inside the certificate. A good solution in my opinion.

Another idea would be to have a special DNS tree assocatiated and look
up the Distinguished name:

e.g. In the case of a non-existent X.500 entry or unavailibility of an
X.500 server AND no DNS name in the alternative name, try to hash the
DER encoded distinguished name, encode it in HEX or BASE64 and look up:

  abcd1234fdea8765abcd1234fdea8765.x500.org

or split the x500 DNS even more, x500.de or de.x500.org to allow a
distributed management. It *IS* a hack, but it may work until we have
X.500 deployed at least for CAs.

The problem of resolving an eMail address can be solved similarily via
SRV records, deriving the domain name from the host address part of the
eMail, a similar technique for the MX records (and also proposed during
LDAP development with the DX record).


Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16777 for ietf-pkix-bks; Thu, 4 Mar 1999 10:50:12 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA16753 for <[e-mail]>; Thu, 4 Mar 1999 10:48:52 -0800 (PST)
Received: (qmail 18458 invoked from network); 4 Mar 1999 18:54:22 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 4 Mar 1999 18:54:22 -0000
Received: (qmail 2375 invoked from network); 4 Mar 1999 18:49:56 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 4 Mar 1999 18:49:55 -0000
Message-ID: <006701be6660$2fb42020$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
Date: Thu, 4 Mar 1999 10:58:11 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: David P. Kemp <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Thursday, March 04, 1999 11:00 AM
Subject: Re: PKIX Path determination/construction/processing and AKIpointer
hanging


>
>> From: "Peter Williams" <[e-mail]>
>>
>> QUESTION: If a certificate path chosen by a relying party contains at
>> least one certificate whose authority key id backpointer does
>> NOT resolve to a certificate in that path or any certificate
>> known to the relying party, can one designate otherwise normal
>> processing of  that chain as conforming to PKIX 2459?
>>
>> My answer to the question is yes. Does anyone disagree?
>
>
>If I understand the question correctly, I disagree.  Restating
>the question as I understand it:
>
>  If a certificate path chosen by a relying party is not
>  a continuous chain between the certificate being validated
>  and a certificate trusted by the relying party, can one designate
>  otherwise normal processing of that chain as conforming to RFC 2459?



David,

There have been a couple of responses. Let my query your
analysis to find out what is driving you to try to disagree with
a simple technical assertion concerning hanging backpointers
(marked critical, or otherwise):

You seem to have invented a technical term "continuous chain."

What is a "continuous chain"?

"  If a certificate path chosen by a relying party is not
  a continuous chain between the certificate being validated
  and a certificate trusted by the relying party, can one designate
  otherwise normal processing of that chain as conforming to RFC 2459?"

Does a cert path which has hanging AKI backpointers constitute
a continuous chain (all things about the chain or the RP's locally trusted
authority
being otherwise acceptable/valid to the relying party
and 2459 descriptive formalisms)?

 >I interpret "This text assumes ..." to mean that if the assumption
>is not met, then the results are undefined, and that if the results
>are undefined, then there is no meaningful conformance.

Its fine for a relying party to define its own notion of conformance.
Indeed, it is necessary.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16522 for ietf-pkix-bks; Thu, 4 Mar 1999 10:22:00 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16518 for <[e-mail]>; Thu, 4 Mar 1999 10:21:58 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA11639; Thu, 4 Mar 1999 19:27:26 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 4 Mar 1999 19:27:25 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA15191; Thu, 4 Mar 1999 19:27:25 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA19699; Thu, 4 Mar 1999 19:27:24 +0100
Date: Thu, 4 Mar 1999 19:27:24 +0100
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> AIA is multiply-valued, so you can put in other info:
> 
> AuthorityInfoAccessSyntax  ::=
>         SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
> AccessDescription  ::=  SEQUENCE {
>         accessMethod          OBJECT IDENTIFIER,
>         accessLocation        GeneralName  }
> 
> The OCSP OID would simply identify the URI used for that particular method.
> 
> Mike
> 
Question 
Part 1 (version 11) says

   Each entry in the sequence AuthorityInfoAccessSyntax describes the
   format and location of additional information about the CA who issued
   the certificate in which this extension appears.  The type and format
   of the information is specified by the accessMethod field; the
   accessLocation field specifies the location of the information.  The
   retrieval mechanism may be implied by the accessMethod or specified
   by accessLocation.

The text doesn't say whether you can have DIFFERENT AIAs in certs issued by the
same CA. In fact, the text does not bind the AIA to the cert, it talks
only about the CA. As a result one could imagine that except in rollover
periods, a particular AccessDescription would be always identical in
all certs signed by the CA (if the AIA exists). Or in other words, if
I have ONE cert that has a desired Accessdescription, then I know something
about the CA in general, and not only something about the combination
cert/CA. As a consequence you only need ONE cert with an AccessDescription.

In early drafts there were also SubjectInfoaccess and CAInfoaccess
extensions with a similar syntax. They no longer exist and in fact they
are not necessary.

First both extensions basically mean the same thing, they talk about
informationaccess about the SUBJECT, the distinction of SubjectInfo in
EEs and CAinfo in CAcerts is superfluous. 

Furthermore none of them is actually necessary: If I would want some
AccessDescription pointing to the Subject, I would just put it directly
as an extension. Or, the other way around, the AIA is needed to encapsulate
an extension to tell that it refers to the Issuer and not to the
subject.

If the previous makes sense, then the text in OCSP is slightly misleading.

In fact, I would like to see that in the situation of an OCSP provider
cert signed by ITS authority have an AIA, and maybe the CA cert has
just the ocsp location as a direct extension.
And in case where the CA is directly the server, then the CA cert would
indicate that it is its OWN ocsp server *AND* maybe have an AIA pointing
to another ocsp service (the one of the issuer). 



have fun
Peter Sylvester



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16327 for ietf-pkix-bks; Thu, 4 Mar 1999 10:02:58 -0800 (PST)
Received: from raptor.globalsign.net (unknown-195-207.eunet.be [195.207.49.1] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16323 for <[e-mail]>; Thu, 4 Mar 1999 10:02:56 -0800 (PST)
Received: from globalsign.net (unverified [195.238.22.143]) by raptor.globalsign.net (Rockliffe SMTPRA 2.1.7) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 04 Mar 1999 18:02:45 +0000
Message-ID: <[e-mail]>
Date: Thu, 04 Mar 1999 19:05:16 +0100
From: Marc Jadoul <[e-mail]>
Organization: BelSign NV/SA
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.2 i686)
X-Accept-Language: fr, en, nl
MIME-Version: 1.0
To: [e-mail]
Subject: Re: A web of directories - Finding PKIX Servers
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I really find acceptable to send an email to the person i want to
contact and wait for his signed reply. Don't you ?

I do not know how s/mime work, but it seems also the only way to know if
the program he use is able to do strong crypto or even negotiate other
need parameter to initiate a secure communication. Isn't it ?

Marc Jadoul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16037 for ietf-pkix-bks; Thu, 4 Mar 1999 09:37:12 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16033 for <[e-mail]>; Thu, 4 Mar 1999 09:37:11 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA22146; Thu, 4 Mar 1999 09:38:39 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA27226; Thu, 4 Mar 1999 09:42:12 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRAMBHT>; Thu, 4 Mar 1999 09:42:13 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], Michael Myers <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Date: Thu, 4 Mar 1999 09:42:11 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

I've seen AIA working as most other OID-based mechanisms work.  One defines
and OID and the semantics associated with it.  The OCSP draft does this for
this one particular method of accessing this one particular type of
authority information using one particular transport--with the underlying
assumption that there is only one value of id-ad-ocsp in the AIA SEQUENCE.

Other AIA accessMethod OIDs can be defined for other purposes and so
disambiguate the cases you cite.  Perhaps this is a subject for an I-D that
identifies and defines additional standard methods and semantics of AIA use.

I can say with certainty that OCSP does not "think" is somehow owns the
entire scope of semantics that AIA establishes.

Mike

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Thursday, March 04, 1999 8:43 AM
> To: [e-mail]; [e-mail]
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Michael,
> 
> I understand that AIA is multiply-valued, so I can put in 
> multiple URLs.
> 
> The question, as is the case all too often, is what are the 
> SEMANTICS of those various URLs?
> 
> So I put in one LDAP, one DAP, and one HTTP, or maybe just 
> three LDAPs.
> 
> Is OCSP going to assume that each and every one of those URLs 
> point to an OCSP server, and maybe it should make a random 
> choice?  What if one refers to the originator's directory 
> that contains his certificate, one refers to the CA's 
> directory which can be used to look up certificates by Issuer 
> name and serial and NOT by DN, and one points to a directory 
> of CRLs and/or OCSP providers that do NOT maintain a list of 
> certificate or other potentially useful information?
> 
> I believe that my original thought was correct -- that OCSP 
> thinks it has exclusive ownership of the AIA attribute?
> 
> Bob
> 
> >>> Michael Myers <[e-mail]> 03/04/99 08:57AM >>>
> Bob,
> 
> AIA is multiply-valued, so you can put in other info:
> 
> AuthorityInfoAccessSyntax  ::=
>         SEQUENCE SIZE (1..MAX) OF AccessDescription
> 
> AccessDescription  ::=  SEQUENCE {
>         accessMethod          OBJECT IDENTIFIER,
>         accessLocation        GeneralName  }
> 
> The OCSP OID would simply identify the URI used for that 
> particular method.
> 
> Mike
> 
> > -----Original Message-----
> > From: Bob Jueneman [mailto:[e-mail]] 
> > Sent: Wednesday, March 03, 1999 5:43 PM
> > To: [e-mail]; [e-mail] 
> > Subject: RE: OCSP Service Locator and RFC2459's Authority 
> Information
> > Access
> > 
> > 
> > Michael, is the AIA in that case presumed to apply uniquely 
> > to the OCSP provider -- i.e., has OCSP highjacked that field?
> > 
> > Or can other uses be provided as well, using multiple URIs or 
> > whatever?
> > 
> > Bob
> > 
> > >>> Michael Myers <[e-mail]> 03/03/99 05:00PM >>>
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] 
> > > 
> > > This brings up a new question: why is there no OCSP AIA 
> > > AccessDescription
> > > defined?  :) All we need is an OID and a URIName of type 
> > > IA5STRING.  Is it
> > > too late to add this to the current draft?  Does it belong 
> > > here, or does it
> > > more like a cert profile item?  Because of its "dual 
> > nature" should it
> > > perhaps
> > > be written up separately, anyway? (Probably not, since the 
> > > OID base will end
> > > up
> > 
> > 
> > Rick,
> > 
> > It's already in there:
> > 
> > "4.1  Certificate Content
> > 
> >    In order to convey to OCSP clients a well-known point of 
> > information
> >    access, CAs SHALL provide the capability to include the
> >    AuthorityInfoAccess extension (defined in [PKIX1], 
> section 4.2.2.1)
> >    in certificates that can be checked using OCSP.  
> Alternatively, the
> >    accessLocation for the OCSP provider may be configured 
> > locally at the
> >    OCSP client.
> > 
> >    CAs that support an OCSP service, either hosted locally 
> or provided
> >    by an Authorized Responder, MAY provide a value for a
> >    uniformResourceIndicator (URI) accessLocation and the 
> OID value id-
> >    ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> > 
> >    The value of the accessLocation field in the subject certificate
> >    defines the transport (e.g. HTTP) used to access the 
> OCSP responder
> >    and may contain other transport dependent information 
> > (e.g. a URL)."
> > 
> > 
> > Mike
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15571 for ietf-pkix-bks; Thu, 4 Mar 1999 08:54:03 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15567 for <[e-mail]>; Thu, 4 Mar 1999 08:54:02 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA22864; Thu, 4 Mar 1999 11:59:31 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a08b30462003a07@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Thu, 4 Mar 1999 11:57:51 -0500
To: "David P. Kemp" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

>> The number of .com domains is now well over 3 million. It's hardly
>> a meaningful top-level domain anymore.
>
>Au contraire.  What is meaningful about it is that those 3 million
>domains are registered in a single place, and as a result a given
>name can be resolved unambiguously.

The Jan 99 survey suggests that the number is even bigger, about 12
million.  However, that is just the .COM entries, not all the hosts
registerted under each of the .COM domains, nor the folks in all the other
country domains, etc. .COM represents about 30% of the (accessible) DNS
entries, and that percentage may shrink as more TLDs are created, as more
hosts are registered in other countries, etc.

>The longer I look at naming heirarchies, the more my goodness metric
>becomes "the flatter, the better".  It would be fine with me if
>certificates were indexed by hash value (as stored in AKI), and
>one could find every certificate on the Internet by looking it up
>in The Directory by that value.

But we know this does not scale well.

>Bob, that's my suggestion for your magic bullet.  Efficiency may demand
>CIDR-style partitioning of the AKI space (or something along the lines
>of Tony's a.b.c.d prefix, applied to AKI instead of DN), but that could
>work by migrating certificates to the appropriate directory server(s)
>by prefix WITHOUT any pre-arranged AKI partitioning of CAs.
>EE certs could be referred to by "cert hash" instead of (or in addition
>to) Issuer/Serial, and retrieved from the Directory the same way.

I think one really wants partitioning along organizational lines, not the
arbitrary lines that the CIDR-like approach would imply.  Organizational
respobsibility for maintenance of directories has worked well for the DNS,
and if one were to create a PKI tied to the DNS, e.g., based on DNs that
employ only DC attributes, then I think we would want to make use of the
record types already defined for storage of X.509 certs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15492 for ietf-pkix-bks; Thu, 4 Mar 1999 08:42:58 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA15488 for <[e-mail]>; Thu, 4 Mar 1999 08:42:57 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 04 Mar 1999 09:47:56 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 04 Mar 1999 09:43:08 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Access
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 mail.proper.com id IAA15489
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

I understand that AIA is multiply-valued, so I can put in multiple URLs.

The question, as is the case all too often, is what are the SEMANTICS of those various URLs?

So I put in one LDAP, one DAP, and one HTTP, or maybe just three LDAPs.

Is OCSP going to assume that each and every one of those URLs point to an OCSP server, and maybe it should make a random choice?  What if one refers to the originator's directory that contains his certificate, one refers to the CA's directory which can be used to look up certificates by Issuer name and serial and NOT by DN, and one points to a directory of CRLs and/or OCSP providers that do NOT maintain a list of certificate or other potentially useful information?

I believe that my original thought was correct -- that OCSP thinks it has exclusive ownership of the AIA attribute?

Bob

>>> Michael Myers <[e-mail]> 03/04/99 08:57AM >>>
Bob,

AIA is multiply-valued, so you can put in other info:

AuthorityInfoAccessSyntax  ::=
        SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription  ::=  SEQUENCE {
        accessMethod          OBJECT IDENTIFIER,
        accessLocation        GeneralName  }

The OCSP OID would simply identify the URI used for that particular method.

Mike

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]] 
> Sent: Wednesday, March 03, 1999 5:43 PM
> To: [e-mail]; [e-mail] 
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Michael, is the AIA in that case presumed to apply uniquely 
> to the OCSP provider -- i.e., has OCSP highjacked that field?
> 
> Or can other uses be provided as well, using multiple URIs or 
> whatever?
> 
> Bob
> 
> >>> Michael Myers <[e-mail]> 03/03/99 05:00PM >>>
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > 
> > This brings up a new question: why is there no OCSP AIA 
> > AccessDescription
> > defined?  :) All we need is an OID and a URIName of type 
> > IA5STRING.  Is it
> > too late to add this to the current draft?  Does it belong 
> > here, or does it
> > more like a cert profile item?  Because of its "dual 
> nature" should it
> > perhaps
> > be written up separately, anyway? (Probably not, since the 
> > OID base will end
> > up
> 
> 
> Rick,
> 
> It's already in there:
> 
> "4.1  Certificate Content
> 
>    In order to convey to OCSP clients a well-known point of 
> information
>    access, CAs SHALL provide the capability to include the
>    AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
>    in certificates that can be checked using OCSP.  Alternatively, the
>    accessLocation for the OCSP provider may be configured 
> locally at the
>    OCSP client.
> 
>    CAs that support an OCSP service, either hosted locally or provided
>    by an Authorized Responder, MAY provide a value for a
>    uniformResourceIndicator (URI) accessLocation and the OID value id-
>    ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> 
>    The value of the accessLocation field in the subject certificate
>    defines the transport (e.g. HTTP) used to access the OCSP responder
>    and may contain other transport dependent information 
> (e.g. a URL)."
> 
> 
> Mike
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA15448 for ietf-pkix-bks; Thu, 4 Mar 1999 08:39:21 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA15444 for <[e-mail]>; Thu, 4 Mar 1999 08:39:21 -0800 (PST)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.0.1460.8) id <17YTZLAX>; Thu, 4 Mar 1999 11:46:12 -0500
Message-ID: <5BC81EFAA1C3D21190230008C7F450FD0511B5@EXCHNG-FAIRFAX>
From: WHenry <[e-mail]>
To: "'Martin Smith'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Cert binding to ?
Date: Thu, 4 Mar 1999 11:46:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

 This is an interesting concept. However, tying a cert to something "meaty"
like a fingerprint doesn't preclude the fact that a relying party still
trusts a 3rd party (the CA) to create the binding between a user and a
public key.

 How can I be sure that a cert issued by CA "X" for Bill Henry is in fact
Bill Henry (even with a fingerprint association)? Nothing prevents a corrupt
CA from issuing certs to users with falsified fingerprint info. Unless I
have access to a national fingerprint database, I'm still trusting the CA's
representation of who Bill Henry is.

 Bill Henry
 Performance Engineering Corporation
 Fairfax, VA

> -----Original Message-----
> From:	Martin Smith [SMTP:[e-mail]]
> Sent:	Tuesday, March 02, 1999 10:06 PM
> To:	PKIX list
> Subject:	Cert binding to ?
> 
> Please excuse the naive and perhaps slightly off-topic intervention, but
> I can't shake the feeling that more thought needs to be given to what a
> certificate is being bound to.  I have become thoroughly disenchanted
> with DNs, or names for that matter, in any namespace scheme.  Consider
> the increasing irrelevance of political boundaries; the transience of
> employment status, not to mention the rise of self-employment.  After
> all, the idea of an heirarchcal namespace seems to have been a device
> simply to assure uniqueness under distributed management. What a lot of
> baggage for that end!
> 
> Leaving aside the naming issue, it seems that the heart of what PKI
> should be about (if it is to make the cost/benefit cut) is binding an
> assertion or value to a key.  The commonest "assertion" of interest
> seems to be identity.  But what is identity?  As a guy named "Smith", I
> have to tell you it's not enough to know my name to know who I am or to
> find me.  Cutting to the chase: binding to identity comes down to
> "binding to the meat".  In the end, identity binding means I anticipate
> the need to apply physical compulsion to the object of my interest.  I
> want to be able to put him in jail, or ship him out of the country.  The
> obvious binding for identity is therefore to a (digitized) physiological
> characteristic: fingerprint, retinal scan, DNA.  And by the way:
> uniqueness is pretty much taken care of, too.  No problem to add a
> handle for user-friendliness.  Mine's Mike Smith and this is my partner,
> Jane Doe.
> 
> The other bindings of interest are to attributes:  a Swiss account
> number; a surety bond; a role (supervisor; treasurer; judge.)  These may
> often be attached to a meat binding, but not necessarily.  Why not be
> able to open an account anonomously, receive a key for that account, and
> present the key to make a withdrawal.  The DEA might care who you are,
> but the banker should not. And why should a role be bound to a person?
> Why not to a process?
> 
> Moving right along, what does this line of thinking imply for the matter
> of transitive trust (cross-certificates?)  Most of the time I hear
> people (who are actual or prospective CAs/RAs) talking about trusting a
> foreign certificate they mean they trust that the other CA has made
> reasonably sure the holder is (or recently was) an employee of the other
> CA's company.  Generally the name is not meaningful (to the local CA;
> perhaps it is to the ultimate relying party if it's an e-mail
> correspondence.)  And generally other attributes (like: is the person an
> employee, or just a contractor?  Cleared for SECRET?; authorized to make
> purchases?) are not known.  To do real business (not supported by a web
> of other, non-electronic information) you need the attribute bindings.
> Most certainly making inferences from a DN is hazardous.  My only point
> here is that for a given transaction, you will typically need a cluster
> of bindings, and that those bindings will have different trust paths
> leading to CA's that are in charge of (that is, they warrant with
> effective recourse for the relying party) different assertions or
> values.  In other words, fussing about naming schemes is is distraction.
> 
> Martin Smith (or not)
>  << File: Card for Martin Smith >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15003 for ietf-pkix-bks; Thu, 4 Mar 1999 07:53:03 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14999 for <[e-mail]>; Thu, 4 Mar 1999 07:53:02 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA18102; Thu, 4 Mar 1999 07:54:29 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA22797; Thu, 4 Mar 1999 07:58:00 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRAMAJK>; Thu, 4 Mar 1999 07:58:00 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail], Michael Myers <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Date: Thu, 4 Mar 1999 07:57:59 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

AIA is multiply-valued, so you can put in other info:

AuthorityInfoAccessSyntax  ::=
        SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription  ::=  SEQUENCE {
        accessMethod          OBJECT IDENTIFIER,
        accessLocation        GeneralName  }

The OCSP OID would simply identify the URI used for that particular method.

Mike

> -----Original Message-----
> From: Bob Jueneman [mailto:[e-mail]]
> Sent: Wednesday, March 03, 1999 5:43 PM
> To: [e-mail]; [e-mail]
> Subject: RE: OCSP Service Locator and RFC2459's Authority Information
> Access
> 
> 
> Michael, is the AIA in that case presumed to apply uniquely 
> to the OCSP provider -- i.e., has OCSP highjacked that field?
> 
> Or can other uses be provided as well, using multiple URIs or 
> whatever?
> 
> Bob
> 
> >>> Michael Myers <[e-mail]> 03/03/99 05:00PM >>>
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > 
> > This brings up a new question: why is there no OCSP AIA 
> > AccessDescription
> > defined?  :) All we need is an OID and a URIName of type 
> > IA5STRING.  Is it
> > too late to add this to the current draft?  Does it belong 
> > here, or does it
> > more like a cert profile item?  Because of its "dual 
> nature" should it
> > perhaps
> > be written up separately, anyway? (Probably not, since the 
> > OID base will end
> > up
> 
> 
> Rick,
> 
> It's already in there:
> 
> "4.1  Certificate Content
> 
>    In order to convey to OCSP clients a well-known point of 
> information
>    access, CAs SHALL provide the capability to include the
>    AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
>    in certificates that can be checked using OCSP.  Alternatively, the
>    accessLocation for the OCSP provider may be configured 
> locally at the
>    OCSP client.
> 
>    CAs that support an OCSP service, either hosted locally or provided
>    by an Authorized Responder, MAY provide a value for a
>    uniformResourceIndicator (URI) accessLocation and the OID value id-
>    ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
> 
>    The value of the accessLocation field in the subject certificate
>    defines the transport (e.g. HTTP) used to access the OCSP responder
>    and may contain other transport dependent information 
> (e.g. a URL)."
> 
> 
> Mike
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14901 for ietf-pkix-bks; Thu, 4 Mar 1999 07:39:49 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14897 for <[e-mail]>; Thu, 4 Mar 1999 07:39:47 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA20392; Thu, 4 Mar 1999 10:44:58 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA20388; Thu, 4 Mar 1999 10:44:57 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA19719; Thu, 4 Mar 1999 10:43:34 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA09595; Thu, 4 Mar 1999 10:42:59 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 4 Mar 1999 10:42:59 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Ahp2HYBZTXA4seQu2C4ILQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail] (Arnoud "Galactus" Engelfriet)
> 
> The number of .com domains is now well over 3 million. It's hardly
> a meaningful top-level domain anymore.

Au contraire.  What is meaningful about it is that those 3 million
domains are registered in a single place, and as a result a given
name can be resolved unambiguously.

The longer I look at naming heirarchies, the more my goodness metric
becomes "the flatter, the better".  It would be fine with me if
certificates were indexed by hash value (as stored in AKI), and
one could find every certificate on the Internet by looking it up
in The Directory by that value.

Bob, that's my suggestion for your magic bullet.  Efficiency may demand
CIDR-style partitioning of the AKI space (or something along the lines
of Tony's a.b.c.d prefix, applied to AKI instead of DN), but that could
work by migrating certificates to the appropriate directory server(s)
by prefix WITHOUT any pre-arranged AKI partitioning of CAs.
EE certs could be referred to by "cert hash" instead of (or in addition
to) Issuer/Serial, and retrieved from the Directory the same way.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14619 for ietf-pkix-bks; Thu, 4 Mar 1999 07:03:31 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14615 for <[e-mail]>; Thu, 4 Mar 1999 07:03:30 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA18219 for <[e-mail]>; Thu, 4 Mar 1999 10:09:02 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA18215 for <[e-mail]>; Thu, 4 Mar 1999 10:09:01 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA15597 for <[e-mail]>; Thu, 4 Mar 1999 10:07:38 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.56.12]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA09586 for <[e-mail]>; Thu, 4 Mar 1999 10:07:03 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 4 Mar 1999 10:07:03 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /TuW+2lPtknHWVPC43sCXA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Peter Williams" <[e-mail]>
> 
> QUESTION: If a certificate path chosen by a relying party contains at
> least one certificate whose authority key id backpointer does
> NOT resolve to a certificate in that path or any certificate
> known to the relying party, can one designate otherwise normal
> processing of  that chain as conforming to PKIX 2459?
> 
> My answer to the question is yes. Does anyone disagree?


If I understand the question correctly, I disagree.  Restating
the question as I understand it:

  If a certificate path chosen by a relying party is not
  a continuous chain between the certificate being validated
  and a certificate trusted by the relying party, can one designate
  otherwise normal processing of that chain as conforming to RFC 2459?

If the relying party has no notion of a trusted public key, or has
an implementation which returns a "success" answer when given a path
not terminating in a trusted public key, then RFC2459 is irrelevant.
Frobbing the bits in accordance with section 6 may increase the entropy
of the relying party's immediate environment (generate some heat and
waste some time), but it has no other useful effect.

RFC2459 says "This text assumes that all valid paths begin with
certificates issued by a single 'most trusted CA'." (and then goes
on to discuss extended path validation where paths may begin with
one of several trusted CAs).

I interpret "This text assumes ..." to mean that if the assumption
is not met, then the results are undefined, and that if the results
are undefined, then there is no meaningful conformance.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA13399 for ietf-pkix-bks; Thu, 4 Mar 1999 03:44:57 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA13395 for <[e-mail]>; Thu, 4 Mar 1999 03:44:49 -0800 (PST)
Received: from darmstadt.gmd.de (aberger@pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA07229; Thu, 4 Mar 1999 12:47:46 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 04 Mar 1999 12:47:46 +0100
From: Andreas Berger <[e-mail]>
Organization: GMD Darmstadt
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: A web of directories - Finding PKIX Servers
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

I wrote a similar message about a year ago but it was mostly ignored...

Anyway, it seems that wa all have a problem here.

The problem, in my opinion, is that we simply do not have a global X.500
service deployed (for whatever reason) but we use X.500 identifiers
(DNs) in our systems. So whenever I need the entry for a particular DN,
I have no method to find the server serving this information. X.500
would do this.

The basic lookup processes we have are:

- resolve an eMail address into a certificate for encryption.
- resolve a DN into a certificate (looking up a CA certificate)
- resolve a DN into a CRL (looking up a CA´s CRL)
- find other services (OCSP) based on a DN

I suggest the following:

In order allow independet deployment of PKIX "directoy servers" we
should follow the Mail Model: A company puts a service on the net,
announcing the availiability using DNS. I find it perfectly reasonable
to have my company, GMD in Germany, to offer an external LDAP service
for their employees, under (e.g.) ldap.gmd.de.

The problem now is how to resolve the X.500 DN (O=GMD Forschungszentrum
Informationstechnik GmbH, c=DE) into the DNS domain (gmd.de).

The first method for a user would be to contact any official LDAP
gateway to X.500 and look up the entry for GMD. This may work if GMD has
set up a proper X.500 server. Then two cases exist: GMD has set up only
one entry for its name or it has set up a complete X.500 system. The
second case is easy, it the X.500 model. In the first case, we could
hope that the domain name is contained as an attribute in the X.500
entry.

Now I have a DNS domain name, gmd.de, which could then be queries via
DNS and optionally SRV records (e.g. I can first ask for an SRV record
for a specific protocol that the user´s client understands like LDAP).
If that does not work, the client could try ldap.gmd.de and get the
server´s name.

Now let´s suppose a case where the organization does not have an X.500
entry. One idea would be to use the IssuerAlternativeName to supply the
"root" DNS name inside the certificate. A good solution in my opinion.

Another idea would be to have a special DNS tree assocatiated and look
up the Distinguished name:

e.g. In the case of a non-existent X.500 entry or unavailibility of an
X.500 server AND no DNS name in the alternative name, try to hash the
DER encoded distinguished name, encode it in HEX or BASE64 and look up:

  abcd1234fdea8765abcd1234fdea8765.x500.org

or split the x500 DNS even more, x500.de or de.x500.org to allow a
distributed management. It *IS* a hack, but it may work until we have
X.500 deployed at least for CAs.

The problem of resolving an eMail address can be solved similarily via
SRV records, deriving the domain name from the host address part of the
eMail, a similar technique for the MX records (and also proposed during
LDAP development with the DX record).


Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA29212 for ietf-pkix-bks; Wed, 3 Mar 1999 22:41:19 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA29190 for <[e-mail]>; Wed, 3 Mar 1999 22:41:08 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <GHVLPJ6R>; Thu, 4 Mar 1999 17:46:19 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0C4E08@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'PKIX list '" <[e-mail]>, "'Martin Smith '" <[e-mail]>
Subject: RE: Cert binding to ?
Date: Thu, 4 Mar 1999 17:46:18 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some thoughts

Its a fact of life that service uses have to be bound to service
providers by something (eg phone numbers, amex cards, visa , frequent
flier numbers, etc, The names that one gets for using the service has to
comply to the engineering ideology and investment of that used by the
service provider.

In the case of X.509 certs - it is part of the directory standards -
which is a name based transaction system. However, the names one uses is
that as determined by the service provider who wants to bill you at some
stage.

the directory service of usage of DNs does not mean that the system is
geopolitical. Its just many have seen X.500 as too big (12 mb) DAP as
too big (130 kb), that X.500 is THE global directory not A directory
service, one of many) and that PKI roots = directory roots, etc.

I am sure if one presented the requirements of flexible name policies
for certificates eg cert attributes, then the technology could
accommodate them some how.


But that is up to the service provider concerned of course.
regards alan 

----------
From: Martin Smith
To: PKIX list
Sent: 3/3/99 2:05:45 PM
Subject: Cert binding to ?

Please excuse the naive and perhaps slightly off-topic intervention, but
I can't shake the feeling that more thought needs to be given to what a
certificate is being bound to.  I have become thoroughly disenchanted
with DNs, or names for that matter, in any namespace scheme.  Consider
the increasing irrelevance of political boundaries; the transience of
employment status, not to mention the rise of self-employment.  After
all, the idea of an heirarchcal namespace seems to have been a device
simply to assure uniqueness under distributed management. What a lot of
baggage for that end!

Leaving aside the naming issue, it seems that the heart of what PKI
should be about (if it is to make the cost/benefit cut) is binding an
assertion or value to a key.  The commonest "assertion" of interest
seems to be identity.  But what is identity?  As a guy named "Smith", I
have to tell you it's not enough to know my name to know who I am or to
find me.  Cutting to the chase: binding to identity comes down to
"binding to the meat".  In the end, identity binding means I anticipate
the need to apply physical compulsion to the object of my interest.  I
want to be able to put him in jail, or ship him out of the country.  The
obvious binding for identity is therefore to a (digitized) physiological
characteristic: fingerprint, retinal scan, DNA.  And by the way:
uniqueness is pretty much taken care of, too.  No problem to add a
handle for user-friendliness.  Mine's Mike Smith and this is my partner,
Jane Doe.

The other bindings of interest are to attributes:  a Swiss account
number; a surety bond; a role (supervisor; treasurer; judge.)  These may
often be attached to a meat binding, but not necessarily.  Why not be
able to open an account anonomously, receive a key for that account, and
present the key to make a withdrawal.  The DEA might care who you are,
but the banker should not. And why should a role be bound to a person?
Why not to a process?

Moving right along, what does this line of thinking imply for the matter
of transitive trust (cross-certificates?)  Most of the time I hear
people (who are actual or prospective CAs/RAs) talking about trusting a
foreign certificate they mean they trust that the other CA has made
reasonably sure the holder is (or recently was) an employee of the other
CA's company.  Generally the name is not meaningful (to the local CA;
perhaps it is to the ultimate relying party if it's an e-mail
correspondence.)  And generally other attributes (like: is the person an
employee, or just a contractor?  Cleared for SECRET?; authorized to make
purchases?) are not known.  To do real business (not supported by a web
of other, non-electronic information) you need the attribute bindings.
Most certainly making inferences from a DN is hazardous.  My only point
here is that for a given transaction, you will typically need a cluster
of bindings, and that those bindings will have different trust paths
leading to CA's that are in charge of (that is, they warrant with
effective recourse for the relying party) different assertions or
values.  In other words, fussing about naming schemes is is distraction.

Martin Smith (or not)




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA23849 for ietf-pkix-bks; Wed, 3 Mar 1999 18:33:33 -0800 (PST)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA23825 for <[e-mail]>; Wed, 3 Mar 1999 18:33:14 -0800 (PST)
Received: from erols.com (207-172-50-199.s199.tnt15.ann.va.dialup.rcn.com [207.172.50.199]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id VAA11774; Wed, 3 Mar 1999 21:41:57 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 03 Mar 1999 21:33:13 -0500
From: Martin Smith <[e-mail]>
Organization: USITC
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: PKIX list <[e-mail]>
Subject: Re: Cert binding to ?
References: <v04020a05b30373862f95@[128.89.0.110]>
Content-Type: multipart/mixed; boundary="------------B72BB33E1F77D6B02292CE8D"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------B72BB33E1F77D6B02292CE8D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well, OK.  If PKI is about achieving the same level of trust we enjoy in
meatspace, then maybe a lot of rigor is too much. A lot of money is spent in
restaurants where you hand your credit card to a waiter who disappears, or at
catalog stores where you give a card number to someone over the phone.   The
weakness of that argument, however, is that PKI is liable to be pretty
expensive (who's paying all those new CAs and RAs?) so if it doesn't do
something significantly better than SSL with challenge/response (which is how
many of us do securities trades) , why bother????  (Apart from the fun of
really neat technology.)  <g>

Martin

PS--My attitude comes from a couple of years running an "X.400 users group."

Stephen Kent wrote:

> Martin,
>
> Identities often are not universal, so the almost philosophical issues you
> raise need noty apply. Identities asserted in well-defined contexts are
> very useful, and characteristic of many of the relationships we experience
> in the physical world.  If certs merely allow us to recreate these
> relationships in cyberspace, they will be of great value.

snip

--------------B72BB33E1F77D6B02292CE8D
Content-Type: text/x-vcard; charset=us-ascii;
 name="mfsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Martin Smith
Content-Disposition: attachment;
 filename="mfsmith.vcf"

begin:vcard 
n:Smith;Martin
x-mozilla-html:TRUE
org:US International Trade Commission
adr:;;500 E Street SW;Washington;DC;20436;USA
version:2.1
email;internet:[e-mail]
title:Director, Information Services
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-cpt:;0
fn:Martin Smith
end:vcard

--------------B72BB33E1F77D6B02292CE8D--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20087 for ietf-pkix-bks; Wed, 3 Mar 1999 17:38:45 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA20074 for <[e-mail]>; Wed, 3 Mar 1999 17:38:43 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Mar 1999 18:43:35 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 03 Mar 1999 18:42:34 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Access
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 mail.proper.com id RAA20075
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael, is the AIA in that case presumed to apply uniquely to the OCSP provider -- i.e., has OCSP highjacked that field?

Or can other uses be provided as well, using multiple URIs or whatever?

Bob

>>> Michael Myers <[e-mail]> 03/03/99 05:00PM >>>

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> 
> This brings up a new question: why is there no OCSP AIA 
> AccessDescription
> defined?  :) All we need is an OID and a URIName of type 
> IA5STRING.  Is it
> too late to add this to the current draft?  Does it belong 
> here, or does it
> more like a cert profile item?  Because of its "dual nature" should it
> perhaps
> be written up separately, anyway? (Probably not, since the 
> OID base will end
> up


Rick,

It's already in there:

"4.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MAY provide a value for a
   uniformResourceIndicator (URI) accessLocation and the OID value id-
   ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL)."


Mike


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15858 for ietf-pkix-bks; Wed, 3 Mar 1999 16:05:33 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15853 for <[e-mail]>; Wed, 3 Mar 1999 16:05:32 -0800 (PST)
From: [e-mail]
Received: from smtp.ma.certco.com (smtp.ma.certco.com [10.200.200.11]) by fwma1.certco.com (Postfix) with ESMTP id DA75815533; Wed,  3 Mar 1999 19:11:00 -0500 (EST)
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id TAA13659; Wed, 3 Mar 1999 19:11:00 -0500 (EST)
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Date: Wed, 3 Mar 1999 19:10:49 -0500
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 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>It's already in there.

Oops.

Two reading mistakes in two days.  Mea culpa.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15546 for ietf-pkix-bks; Wed, 3 Mar 1999 15:55:23 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15542 for <[e-mail]>; Wed, 3 Mar 1999 15:55:22 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA03756; Wed, 3 Mar 1999 15:57:00 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA07048; Wed, 3 Mar 1999 16:00:34 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <FXRAL8ZK>; Wed, 3 Mar 1999 16:00:34 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Acce ss
Date: Wed, 3 Mar 1999 16:00:33 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> 
> This brings up a new question: why is there no OCSP AIA 
> AccessDescription
> defined?  :) All we need is an OID and a URIName of type 
> IA5STRING.  Is it
> too late to add this to the current draft?  Does it belong 
> here, or does it
> more like a cert profile item?  Because of its "dual nature" should it
> perhaps
> be written up separately, anyway? (Probably not, since the 
> OID base will end
> up


Rick,

It's already in there:

"4.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MAY provide a value for a
   uniformResourceIndicator (URI) accessLocation and the OID value id-
   ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL)."


Mike


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA14088 for ietf-pkix-bks; Wed, 3 Mar 1999 15:34:11 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA14084 for <[e-mail]>; Wed, 3 Mar 1999 15:34:10 -0800 (PST)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id SAA15484; Wed, 3 Mar 1999 18:39:26 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a05b30373862f95@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Wed, 3 Mar 1999 18:36:23 -0500
To: Martin Smith <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Cert binding to ?
Cc: PKIX list <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Martin,

Identities often are not universal, so the almost philosophical issues you
raise need noty apply. Identities asserted in well-defined contexts are
very useful, and characteristic of many of the relationships we experience
in the physical world.  If certs merely allow us to recreate these
relationships in cyberspace, they will be of great value.

For example, an identity can be a name and account number with a merchant,
a name and employee number, ...   Many certs will be used in transactions
where one does not require the sort of extreme binding to a physical
instance of a person that you cite.  Also note that, in many instances, the
globally unique IDs that one can imagine have the property that they are
not meaningful to the many individuals and institutions which whom we
interact.  So, don't get hung up on the notion of binding DNA,
fingerprints, et.c into certs.

Finally, cross certs are not about transitive trust, if properly done.  A
cross cert with a NameConstraints extsnsion will generally PREVENT, not
enable, transitive cert validation.  Cross certs are a great means of
achieving pairwise bindings in which one CA recognizes the authority of
anther CA for a given name space.


Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13143 for ietf-pkix-bks; Wed, 3 Mar 1999 15:03:14 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13138 for <[e-mail]>; Wed, 3 Mar 1999 15:03:13 -0800 (PST)
From: [e-mail]
Received: from smtp.ma.certco.com (smtp.ma.certco.com [10.200.200.11]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id F283515533; Wed,  3 Mar 1999 18:08:40 -0500 (EST)
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id SAA13228 for <[e-mail]>; Wed, 3 Mar 1999 18:08:40 -0500 (EST)
To: <[e-mail]>
Subject: RE: OCSP Service Locator and RFC2459's Authority Information Access
Date: Wed, 3 Mar 1999 18:08:29 -0500
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 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Is there any reason to use the OCSP "Service Locator", (Draft 7,
> > Section 5.4.6) instead of defining an Authority Information Access
> > AccessDescription for the OCSP service (RFC2459, Section 4.2.2.1)?
> > Is it just a case of parallel efforts duplicating work, or is there
> > a subtlety I'm missing?

Thanks to Rich Ankney for reminding me that since the whole cert isn't
sent in the OCSP request you can't use an OCSP AIA AccessDescription.
However, if one were defined, you could cut&paste it into the Service
Locator.

This brings up a new question: why is there no OCSP AIA AccessDescription
defined?  :) All we need is an OID and a URIName of type IA5STRING.  Is it
too late to add this to the current draft?  Does it belong here, or does it
more like a cert profile item?  Because of its "dual nature" should it
perhaps
be written up separately, anyway? (Probably not, since the OID base will end
up
"directing" the user/reader/implementor to OCSP specs anyway.)
	/r$





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09568 for ietf-pkix-bks; Wed, 3 Mar 1999 12:07:18 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09564 for <[e-mail]>; Wed, 3 Mar 1999 12:07:17 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA04416; Wed, 3 Mar 1999 12:12:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 03 Mar 1999 12:11:48 -0800
To: Martin Smith <[e-mail]>, PKIX list <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Cert binding to ?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Martin,

I am in violent agreement.

At foundation, a certificate binds a key to a "bag-of-bytes" (the cert
contents) and any confidence that those bytes represent anything of
meaning (or accuracy) is thus pointed to indirectly (e.g., CPS).

I fear that, as it stands, current commercial PKI efforts are really
designed to obey my "98% rule".  It helps serve to keep the 98% of us
who are honest, honest.  But we need protection from the 2% who are
criminal.  These are the characters who will forge bogus identities,
provide bogus credentials and bogus references, be they passports,
drivers licences, whatever.  All that the current PKI (QCs included)
will serve to do is further legitimize these fake credentials, to our
detriment.

Certifying the 98% who are honest would be of great value, if the
purpose was simply to provide convenient exchange of public keys
in the support of privacy (end-to-end encryption,) but it is of
little value if the goal is end-to-end authentication.  That is
where the 2% become critical.

I think the idea of a global namespace is actually dangerous, and is
more of a threat than an enhancement to security, especially if its
contents (path components) are assumed to carry semantic worth.

They should exist, if at all, as a means to locate the tests by which
authentication or trust can be assessed, and never as the trust in and
of themselves.  The subsequent "tests" should involve parallel paths
and methods, and rely upon coherence in the determination of accuracy.

The current eggs-in-one-basket approach is certainly attractive from
a central-control viewpoint, however.

___tony___


At 10:05 PM 3/2/99 -0500, Martin Smith wrote:
>Please excuse the naive and perhaps slightly off-topic intervention, but
>I can't shake the feeling that more thought needs to be given to what a
>certificate is being bound to.  I have become thoroughly disenchanted
>with DNs, or names for that matter, in any namespace scheme.  Consider
>the increasing irrelevance of political boundaries; the transience of
>employment status, not to mention the rise of self-employment.  After
>all, the idea of an heirarchcal namespace seems to have been a device
>simply to assure uniqueness under distributed management. What a lot of
>baggage for that end!
>
>Leaving aside the naming issue, it seems that the heart of what PKI
>should be about (if it is to make the cost/benefit cut) is binding an
>assertion or value to a key.  The commonest "assertion" of interest
>seems to be identity.  But what is identity?  As a guy named "Smith", I
>have to tell you it's not enough to know my name to know who I am or to
>find me.  Cutting to the chase: binding to identity comes down to
>"binding to the meat".  In the end, identity binding means I anticipate
>the need to apply physical compulsion to the object of my interest.  I
>want to be able to put him in jail, or ship him out of the country.  The
>obvious binding for identity is therefore to a (digitized) physiological
>characteristic: fingerprint, retinal scan, DNA.  And by the way:
>uniqueness is pretty much taken care of, too.  No problem to add a
>handle for user-friendliness.  Mine's Mike Smith and this is my partner,
>Jane Doe.
>
>The other bindings of interest are to attributes:  a Swiss account
>number; a surety bond; a role (supervisor; treasurer; judge.)  These may
>often be attached to a meat binding, but not necessarily.  Why not be
>able to open an account anonomously, receive a key for that account, and
>present the key to make a withdrawal.  The DEA might care who you are,
>but the banker should not. And why should a role be bound to a person?
>Why not to a process?
>
>Moving right along, what does this line of thinking imply for the matter
>of transitive trust (cross-certificates?)  Most of the time I hear
>people (who are actual or prospective CAs/RAs) talking about trusting a
>foreign certificate they mean they trust that the other CA has made
>reasonably sure the holder is (or recently was) an employee of the other
>CA's company.  Generally the name is not meaningful (to the local CA;
>perhaps it is to the ultimate relying party if it's an e-mail
>correspondence.)  And generally other attributes (like: is the person an
>employee, or just a contractor?  Cleared for SECRET?; authorized to make
>purchases?) are not known.  To do real business (not supported by a web
>of other, non-electronic information) you need the attribute bindings.
>Most certainly making inferences from a DN is hazardous.  My only point
>here is that for a given transaction, you will typically need a cluster
>of bindings, and that those bindings will have different trust paths
>leading to CA's that are in charge of (that is, they warrant with
>effective recourse for the relying party) different assertions or
>values.  In other words, fussing about naming schemes is is distraction.
>
>Martin Smith (or not)


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA07253 for ietf-pkix-bks; Wed, 3 Mar 1999 07:10:32 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA07228; Wed, 3 Mar 1999 07:09:24 -0800 (PST)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAB19668; Wed, 3 Mar 1999 07:14:20 -0800
Received: from basilisk.Eng.Sun.COM (basilisk.Eng.Sun.COM [129.144.153.121]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id HAA13412; Wed, 3 Mar 1999 07:14:18 -0800 (PST)
Received: from JaffaGate by basilisk.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id HAA03755; Wed, 3 Mar 1999 07:14:06 -0800
Message-ID: <003301be6589$67bb36c0$e83c9c81@JaffaGate>
Reply-To: "Yahya Al-Salqan" <[e-mail]>
From: "Yahya Al-Salqan" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: 1999 WET-ICE Enterprise Security Workshop
Date: Wed, 3 Mar 1999 07:20:34 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.0518.4
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4
X-MIME-Autoconverted: from 8bit to quoted-printable by Eng.Sun.COM id HAA13412
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA07229
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear Colleague,

This mail is to remind you of the upcomming deadline for submissions
the Fourth International Workshop on Enterprise Security, to be held
as a part of IEEE WET-ICE '99 on June 16-18, 1999 at Stanford
University, California, USA. Deadline for paper submissions is March
22, 1999.

Electronic submissions are accepted. Please see the workshop web
page http://www.ida.liu.se/conferences/WETICE/SECWK/ for more
details.

Please accept my apologies if you receive this message more than once.

Enclosed is the Call For Papers. Your help in distributing the
CFP to interested parties would be greatly appreciated.


Sincerely,

Nahid Shahmehri
Program Co-Chair

Dept. of Computer and Information Science
Linköping University
SE-581 83 Linköping
Sweden

-Cut here--------------------------------------------------------------

     FINAL CALL FOR  PAPERS

      Submission deadline: March 22, 1999

      Fourth International Workshop on Enterprise Security
     a WET-ICE '99 workshop
June 16-18, 1999
      Stanford University, California, USA

    Sponsored by the IEEE Computer Society and CERC at West
Virginia University. Hosted by the Center for Design Research,
      Stanford University.


    This document is also available in HTML,
PostScript and PDF formats from

http://www.ida.liu.se/conferences/WETICE/SECWK/




Enterprises are becoming increasingly dependent on their information
systems to support their business and workflow activities.  There is a
need for universal electronic connectivity to support interaction and
cooperation between multiple organizations. This makes enterprise
security and confidentiality more important but at the same time more
difficult to achieve, as the multiple organizations may have
differences in their security policies and may have to interact via an
insecure Internet.

These inter-organizational enterprise systems may be very large.
Efficient tools, techniques and methodologies are therefore needed to
support the specification, analysis and implementation of security.

This workshop will focus on the problems and challenges relating to
enterprise security in inter-organizational systems. We aim to bring
together principal players from both the internetwork and the
enterprise security community and will provide plenty of time for
discussion.

Topics to be discussed include:
-------------------------------
Internet security:
* Security protocols for the Internet
* The work and efforts of IETF security groups
* Global key infrastructures

Distribution:
* Distributed database security
* Secure transactions
* Inter- and intra-organizational security
* Security of collaborative applications

Secure infrastructures:
* Secure applications and environments
* Object-oriented and CORBA Security
* Secure enterprise infrastructures
* Security algorithms
* Public key infrastructures

Security management:
* Role-based access control
* Enterprise security policies
* Security in workflow processes

The program committee welcomes both papers and panel proposals
covering these topics.


SUBMISSIONS
-----------

Authors should submit six copies of an original paper (not submitted
or published elsewhere) to one of the Program Co-Chairs. Electronic
submissions are also accepted via the World Wide Web. Instructions
and forms are available at http://mir7.ida.liu.se:8080/SECWK/ .

Submissions should include the title of the paper, the name and
affiliation of each author, a 150-word abstract, and no more than 8
keywords. Submissions should not exceed 3000 words in length.  The
name, position, address, telephone number, and if possible, fax number
and e-mail address of the author responsible for correspondence must
be included.

A representative selection of accepted papers will published in the
workshop post-proceedings. Papers accepted for publication in the
proceedings are limited to six pages (about 2000-2500 words) in IEEE
format (two columns, single spaced, 10pt Times). Authors are strongly
encouraged to adhere to this format also when submitting
papers. Detailed information on the IEEE format (together with some
templates) is available at http://www.computer.org/cspress/instruct.htm


PANEL PROPOSALS
---------------

Send six copies of panel proposals to the General Chair. Include a
title, a 150-word scope statement, proposed session chair and
panelists and their affiliations, the organizer's affiliation,
address, telephone and fax number, and e-mail address.


GENERAL CHAIR
-------------

Yahya Al-Salqan
Sun Microsystems
901 San Antonio Rd
Palo Alto, CA 94303
USA
E-mail: [e-mail]


PROGRAM CO-CHAIRS
-----------------

Nahid Shahmehri
Dept. of Computer Science
Linköping University
S-581 83 Linköping
SWEDEN
E-mail: [e-mail]

Mourad Debbabi
Computer Science Department
Laval University
Ste-Foy, Quebec, G1K 7P4
CANADA
E-mail: [e-mail]




WORKSHOP PROGRAM COMMITTEE
--------------------------

Dominique Bolignano, INRIA, France
Germano Caronni, ETH-Zentrum, Switzerland
Michael Geva, Java Security Group, USA
Jean Goubault, Gie Dyade, France
Dima Hamad, Birzeit University, West Bank
Douglas Maughan, National Security Agency, USA
Steve Lloyd, Entrust, Canada
Gary McGraw, Reliable Software Technologies Inc., USA
Aravindan Ranganathan, Sun Microsystems, USA
Sumitra Reddy, CERC, West Virginia University, USA
Vipin Samar, Oracle, USA
Bill Soley, Sun Microsystems, USA
Robert Thomys, BSI, Germany
Mark Vandenwauver, K.U. Leuven, Belgium
Wu Wen, NASA Ames Research Center, USA
Tatu Ylönen, SSH Communications Security, Finland
Nick Zhang, Trans Enterprise Technologies Inc., USA
Qun Zhong, HP Extend Enterprise Lab, USA



IMPORTANT DATES
---------------

Papers and panel proposals due  March 22, 1999
Authors notified of acceptance  April 26, 1999
Workshop                        June 16-18, 1999
Camera ready manuscripts due    June 30, 1999



INQUIRIES
---------

For further information, please contact one of the Chairs,
or visit the workshop web pages:
  http://www.ida.liu.se/conferences/WETICE/SECWK/

For inquires regarding WET ICE in general, contact
[e-mail] or call (U.S.) [phone], or
visit
  http://www.ida.liu.se/conferences/WETICE/










Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA01625 for ietf-pkix-bks; Tue, 2 Mar 1999 21:22:54 -0800 (PST)
Received: from mailserver ([202.54.106.237]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA01620 for <[e-mail]>; Tue, 2 Mar 1999 21:22:48 -0800 (PST)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for <[e-mail]> at Wed, 3 Mar 99  10:46:49 +0530
Received: from proxy1.ba.best.com ([e-mail] [206.184.139.12]) by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id SAA10767 for <[e-mail]>; Tue, 2 Mar 1999 18:52:47 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by proxy1.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id SAA05263; Tue, 2 Mar 1999 18:49:29 -0800 (PST)
Received: by ietf.org (8.9.1a/8.9.1a) id VAA29329 for [e-mail]; Tue, 2 Mar 1999 21:45:01 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16242; Tue, 2 Mar 1999 18:15:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-00.txt
Date: Tue, 02 Mar 1999 18:15:32 -0500
X-Rcpt-To: [e-mail]
X-UIDL: bd4275c8579e9fefcb0ea68b057ed60f
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-00.txt
	Pages		: 9
	Date		: 01-Mar-99
	
  This document describes two methods for producing a signature from a
  Diffie-Hellman key pair.  This behavior is needed for such operations
  as creating a signature of a PKCS #10 certification request.  These
  algorithms are designed to provide a proof-of-possession rather than
  general purpose signing.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dhpop-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dhpop-00.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01405 for ietf-pkix-bks; Tue, 2 Mar 1999 20:59:23 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA01401 for <[e-mail]>; Tue, 2 Mar 1999 20:59:20 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <FG5JKV8J>; Wed, 3 Mar 1999 16:02:52 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A633E@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Martin Smith'" <[e-mail]>, PKIX list <[e-mail]>
Subject: RE: Cert binding to ?
Date: Wed, 3 Mar 1999 16:02:48 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, there is the school of thought that Certficates are largely anonymous
e.g. the Issuer is known but that the certificiate contains a unique but
quite arbitrary name.

Bindings are accomplished by Attribute certficates, countersigned by CAs to
impart privileges, they can contain private data specific to each CA /
business purpose, but if necessary are never transmitted / seen by the world
at large.

Is this a better mapping to ecommerce where one currently has a hand-written
signature, which is forensically provable, but privileges imparted are
specific to each organisation / purpose!

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Martin Smith [SMTP:[e-mail]]
> Sent:	Wednesday, March 03, 1999 2:06 PM
> To:	PKIX list
> Subject:	Cert binding to ?
> 
> Please excuse the naive and perhaps slightly off-topic intervention, but
> I can't shake the feeling that more thought needs to be given to what a
> certificate is being bound to.  I have become thoroughly disenchanted
> with DNs, or names for that matter, in any namespace scheme.  Consider
> the increasing irrelevance of political boundaries; the transience of
> employment status, not to mention the rise of self-employment.  After
> all, the idea of an heirarchcal namespace seems to have been a device
> simply to assure uniqueness under distributed management. What a lot of
> baggage for that end!
> 
> Leaving aside the naming issue, it seems that the heart of what PKI
> should be about (if it is to make the cost/benefit cut) is binding an
> assertion or value to a key.  The commonest "assertion" of interest
> seems to be identity.  But what is identity?  As a guy named "Smith", I
> have to tell you it's not enough to know my name to know who I am or to
> find me.  Cutting to the chase: binding to identity comes down to
> "binding to the meat".  In the end, identity binding means I anticipate
> the need to apply physical compulsion to the object of my interest.  I
> want to be able to put him in jail, or ship him out of the country.  The
> obvious binding for identity is therefore to a (digitized) physiological
> characteristic: fingerprint, retinal scan, DNA.  And by the way:
> uniqueness is pretty much taken care of, too.  No problem to add a
> handle for user-friendliness.  Mine's Mike Smith and this is my partner,
> Jane Doe.
> 
> The other bindings of interest are to attributes:  a Swiss account
> number; a surety bond; a role (supervisor; treasurer; judge.)  These may
> often be attached to a meat binding, but not necessarily.  Why not be
> able to open an account anonomously, receive a key for that account, and
> present the key to make a withdrawal.  The DEA might care who you are,
> but the banker should not. And why should a role be bound to a person?
> Why not to a process?
> 
> Moving right along, what does this line of thinking imply for the matter
> of transitive trust (cross-certificates?)  Most of the time I hear
> people (who are actual or prospective CAs/RAs) talking about trusting a
> foreign certificate they mean they trust that the other CA has made
> reasonably sure the holder is (or recently was) an employee of the other
> CA's company.  Generally the name is not meaningful (to the local CA;
> perhaps it is to the ultimate relying party if it's an e-mail
> correspondence.)  And generally other attributes (like: is the person an
> employee, or just a contractor?  Cleared for SECRET?; authorized to make
> purchases?) are not known.  To do real business (not supported by a web
> of other, non-electronic information) you need the attribute bindings.
> Most certainly making inferences from a DN is hazardous.  My only point
> here is that for a given transaction, you will typically need a cluster
> of bindings, and that those bindings will have different trust paths
> leading to CA's that are in charge of (that is, they warrant with
> effective recourse for the relying party) different assertions or
> values.  In other words, fussing about naming schemes is is distraction.
> 
> Martin Smith (or not)
>  << File: Card for Martin Smith >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA27199 for ietf-pkix-bks; Tue, 2 Mar 1999 19:05:55 -0800 (PST)
Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA27194 for <[e-mail]>; Tue, 2 Mar 1999 19:05:51 -0800 (PST)
Received: from erols.com (207-172-56-64.s64.tnt12.ann.erols.com [207.172.56.64]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id WAA21461 for <[e-mail]>; Tue, 2 Mar 1999 22:11:05 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 02 Mar 1999 22:05:45 -0500
From: Martin Smith <[e-mail]>
Organization: USITC
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX list <[e-mail]>
Subject: Cert binding to ?
Content-Type: multipart/mixed; boundary="------------1F37B64C914717F041FF95A4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------1F37B64C914717F041FF95A4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Please excuse the naive and perhaps slightly off-topic intervention, but
I can't shake the feeling that more thought needs to be given to what a
certificate is being bound to.  I have become thoroughly disenchanted
with DNs, or names for that matter, in any namespace scheme.  Consider
the increasing irrelevance of political boundaries; the transience of
employment status, not to mention the rise of self-employment.  After
all, the idea of an heirarchcal namespace seems to have been a device
simply to assure uniqueness under distributed management. What a lot of
baggage for that end!

Leaving aside the naming issue, it seems that the heart of what PKI
should be about (if it is to make the cost/benefit cut) is binding an
assertion or value to a key.  The commonest "assertion" of interest
seems to be identity.  But what is identity?  As a guy named "Smith", I
have to tell you it's not enough to know my name to know who I am or to
find me.  Cutting to the chase: binding to identity comes down to
"binding to the meat".  In the end, identity binding means I anticipate
the need to apply physical compulsion to the object of my interest.  I
want to be able to put him in jail, or ship him out of the country.  The
obvious binding for identity is therefore to a (digitized) physiological
characteristic: fingerprint, retinal scan, DNA.  And by the way:
uniqueness is pretty much taken care of, too.  No problem to add a
handle for user-friendliness.  Mine's Mike Smith and this is my partner,
Jane Doe.

The other bindings of interest are to attributes:  a Swiss account
number; a surety bond; a role (supervisor; treasurer; judge.)  These may
often be attached to a meat binding, but not necessarily.  Why not be
able to open an account anonomously, receive a key for that account, and
present the key to make a withdrawal.  The DEA might care who you are,
but the banker should not. And why should a role be bound to a person?
Why not to a process?

Moving right along, what does this line of thinking imply for the matter
of transitive trust (cross-certificates?)  Most of the time I hear
people (who are actual or prospective CAs/RAs) talking about trusting a
foreign certificate they mean they trust that the other CA has made
reasonably sure the holder is (or recently was) an employee of the other
CA's company.  Generally the name is not meaningful (to the local CA;
perhaps it is to the ultimate relying party if it's an e-mail
correspondence.)  And generally other attributes (like: is the person an
employee, or just a contractor?  Cleared for SECRET?; authorized to make
purchases?) are not known.  To do real business (not supported by a web
of other, non-electronic information) you need the attribute bindings.
Most certainly making inferences from a DN is hazardous.  My only point
here is that for a given transaction, you will typically need a cluster
of bindings, and that those bindings will have different trust paths
leading to CA's that are in charge of (that is, they warrant with
effective recourse for the relying party) different assertions or
values.  In other words, fussing about naming schemes is is distraction.

Martin Smith (or not)


--------------1F37B64C914717F041FF95A4
Content-Type: text/x-vcard; charset=us-ascii;
 name="mfsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Martin Smith
Content-Disposition: attachment;
 filename="mfsmith.vcf"

begin:vcard 
n:Smith;Martin
x-mozilla-html:TRUE
org:US International Trade Commission
adr:;;500 E Street SW;Washington;DC;20436;USA
version:2.1
email;internet:[e-mail]
title:Director, Information Services
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-cpt:;0
fn:Martin Smith
end:vcard

--------------1F37B64C914717F041FF95A4--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26138 for ietf-pkix-bks; Tue, 2 Mar 1999 17:04:18 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA26134 for <[e-mail]>; Tue, 2 Mar 1999 17:04:16 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 02 Mar 1999 18:09:09 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 02 Mar 1999 18:08:52 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Mapping certificate to directories
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 mail.proper.com id RAA26135
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Succinctly put."  Can I quote you on that?  That's certainly 
not what most people would say about me, I'm afraid! :-)

I want to think about the rest of your comments some more.  

I do increasingly like the concept of either applying or stripping 
a directory prefix, and not insisting on everything in the 
certificate matching the directory, all of the way up to the root.

Otherwise, I think that the answer that people will settle on is
a very flat file of employee numbers, SSNs, etc., which concerns me
from both a performance and a dossier/privacy standpoint.

 I certainly agree that we should have standardized on SOME 
kind of a schema, clear back in the PEM days.  Not to have
one by now is nearly inexcusable.  If we did have such a set of
preferred attributes and a strongly suggested directory tree, I 
might even give up on my MPEG-movie-of-my-cat attribute in
my DN.  :-)

And I agree that organizations will not publish all of the directory
content externally. However, and perhaps unfortunately, it won't be 
the case that they will allow some entire subtree to be published.
Instead, only certain attributes across the entire tree will be extracted.


>>> Andrew Probert <[e-mail]> 03/02/99 03:45PM >>>
Succintly put.

I had a busy few years promoting electronic mail gateways that did
translational mapping between MSMail, ccMail, Notes, X.400, SMTP ad
infinitum.  We had extensive rules for address matching / mapping between
proprietary name spaces to a common representation (X.400 / SMTP).  These
products are still out there and organsations that have a lot of
administrative baggage / systems must continue to buy and implement them
because its cheaper than alternatives of renaming all users.

But at the end of the day, the whole concept is *broken* and people should
bite the bullet on rationalising namespaces, to not do so only defers the
inevitable and results in kudge upon kludge until you get to where you are
hamstrung by your naming and architectures..

N.B.  Directories can be established to systematically apply Prefixes to
namespaces, which masks the problem.

<snip>


> 1. At present, we don't even have an agreed to method of finding
> where a directory  that contains a certificate, etc., might be located.
> and once we do find such a directory, we don't know what the DIT 
> or the schema looks like.
> 
	[Andrew Probert]  The DIT should not be relevant if the certificate
is in that directory system, you simply do a read by presenting the
distinguished name of the certficate to the directory.  It will return a
certificate anywhere from within the DIT.  

	There should be enough standardised schema to get back critical
data.  Auxilliary items etc could be ignored.

> 2.  Without attempting to predict what will happen in the future,
> we must observe that for today, at least, there is no widely-agreed to
> standard for how directory trees should be constructed, and in general
> every organization that implements a directory tends do to it differently.
> (I believe I've mentioned before that once in a talk I mentioned our
> own tree internal structure (e.g., bjueneman.nsrd.prv.novell) as an 
> example of that fact, only to have someone remark that they did
> the same thing -- all their NetWare systems used "novell" as the 
> top leaf in the tree.  Presumably they had other directory systems which 
> ended in "microsoft".  Arrgh!)
> 
	[Andrew Probert]  Sympathies.  But DIT structure is not the issue.
Naming and prefixes is.

> 3.  The problem will probably get worse before it gets better, if that 
> ever happens.  If I am running my e-mail system while sitting on an 
> airplane, I would probably look for certificates in my own personal
> directory or cache, which might or might not be organized in accordance 
> with my company's corporate directory.  If I don't find what I am looking
> for
> there, I would next check the corporate directory, and if that doesn't
> work,
> I would want to try to search in either the originator's directory, if
> possible,
> or in the CA's directory (if they maintain one), or in some repository
> that either
> the originator or I might happen to have a contract with for such
> purposes.
> 
	[Andrew Probert]  By convention most products out there seem to be
handling this with a 
	local representation  Nickname -> Real Address / Certs / Other data.
As per a previous posting by Alan Lloyd and interesting suggestion is to
have a local LDAP cache.  Of course size and currency and numerous other
issues arise.

> 4.  It is entirely conceivable that every single one of these directories 
> will have a completely different DIT structure, and probably a different 
> schema for what attributes are allowed in a DN as well.
> 
	[Andrew Probert]  Yep. That's why PKIX should put a stake in the
ground about some of this.

> 5. It is important to remember that existing directory structures are 
> created for the convenience of their administrators, primarily, and 
> reflect design properties that are strongly influenced by delegation
> of authority and geographical and/or organizational proximity.  This is,
> the top-level system administrator will own something like our DS-ROOT,
> and will closely guard who has write privileges into that tree.  Then he
> will delegate subtree rights to other sub-administrators, most often on
> a geographical basis (Provo, San Jose, Bangalore). Sub-sub-administrators
> may then create additional nodes in the tree, sometimes on a 
> organizational basis and perhaps more often on a geographical basis 
> that more or less mirrors the router connectivity.  I guess it should be 
> obvious that this structure doesn't break down neatly on geopolitical
> or even organizational lines.
> 
	[Andrew Probert]  .... and in general organisations will not publish
*all* of their internal directory to the outside world.  More likely it will
be a subset of people allowed to talk to the outside world....

> 6.  In general, system administrators haven't made any kind of 
> systematic provision for external users or organizations outside their 
> own organization. If they had, they might well have adopted 
> a structure closer to the X.400/X.520 model, but since directories are 
> normally rolled out for internal purposes long before people start
> thinking 
> about integrating them with other organizations, it is often too late
> to change them in any kind of systematic or organized way.
> 
	[Andrew Probert]  ... Lifecycle cost of maintenance, generally means
that they will pay in the end for deferring the problem.  One could adopt
the approach of saying there aren't a lot of certificates in use yet out
there.  So, as each user requires a certficate, lets sort the naming out as
we go, then rationalisation becomes a ongoing process not a single massive
event?


> 8. At present, we are between a rock and a hard place.  We have 
> implemented certificates using the DN construct to contain
> information that is usually intended to be displayed and hence 
> considered reasonably meaningful (although we don't even have
> a standard for that means), yet the DN was really supposed to 
> be the primary search index into a directory that contains that 
> certificate. But the directories aren't built that way, in general,
> and probably aren't going to change, and in the meantime very
> few products display alternate names at all, and the path 
> processing for alternate names rather than the DN is something 
> that I don't even want to think about.
> 
	[Andrew Probert]  .. consider Alias processing in directories, then
the server side does this, not a client responsibility.

> I have the direct responsibility for trying to resolve this architectural 
> issue within Novell, including integrating both our NDS and our 
> PKI products, and I confess that I am just about stumped as to what to
> recommend. I don't like ANY of the alternatives very much.
> 
> I am beginning to think that it may be necessary to recommend to 
> customers that they graft on a subtree to their DIT, maybe called 
> something like CertificateIssuer, and then file all certificate issued by
> a given CA under that CertificateIssuer node, and hope and pray 
> that the CA has enforced some kind of common tree structure 
> on the certificates they issue. Then regardless of what the 
> certificate specifies as a DN, it would be filed under the 
> CertificateIssuer node, as though CertificateIssuer had been 
> an implicit top-level RDN.
> 
	[Andrew Probert]  Again, you could do this by fabricating Alias
entries as pointers into the actual Directory Information Base.  This could
be done systematically, by extracting cert contents.

> Unfortunately, I'm not at all confident that every CA in the world has
> been completely consistent -- they may have issued certificates containing
> 
> whatever DN the requestor requested, regardless of whether it
> complied with a common DIT for that CA or not.  I don't know.
> anyone want to take a guess?
> 
	[Andrew Probert]  Some I know have flat namespaces e.g. every
domestic citizen in the one arc [double-arrgh!]
> If someone has a magic bullet solution to this problem, I'd certainly 
> like to hear it.
> 
	[Andrew Probert]  No magic bullets, but 
> Bob
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail] 
> 1-801-861-7387
> 
> >>> Paul Koning <[e-mail]> 03/02/99 08:33AM >>>
> >>>>> "tgindin" == tgindin  <[e-mail]> writes:
> 
>  tgindin> I think that country name should be made mandatory.  If
>  tgindin> country name is made optional, how is the number of
>  tgindin> first-level entries in the global directory tree going to be
>  tgindin> held down to navigable levels?...
>  tgindin> Does anyone know of an alternative attribute that
>  tgindin> organizations could be made subordinate to?
> 
>  tgindin> Tom Gindin ([e-mail])
>                                      ^^^
> It seems to me you have an existence proof right there that it's not
> at all necessary to subordinate names to countries.
> 
> 	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA25915 for ietf-pkix-bks; Tue, 2 Mar 1999 16:49:16 -0800 (PST)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA25911 for <[e-mail]>; Tue, 2 Mar 1999 16:49:15 -0800 (PST)
From: [e-mail]
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp7.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id TAA88392; Tue, 2 Mar 1999 19:53:54 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id TAA111464; Tue, 2 Mar 1999 19:54:05 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256729.00030376 ; Tue, 2 Mar 1999 19:32:54 -0500
X-Lotus-FromDomain: IBMUS
To: Stefan Santesson <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 2 Mar 1999 19:34:33 -0500
Subject: RE: Qualified Certificates draft - Country name
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=SHoMKsPrQTFOqQM8Lo42hcSLPtev9Y9P8VdGYNegtlU8SoYvBzOJAwZ4"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=SHoMKsPrQTFOqQM8Lo42hcSLPtev9Y9P8VdGYNegtlU8SoYvBzOJAwZ4
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Does this consensus apply to issuer name as well as to subject name?
Certificate verifiers are expected to perform real-time retrieval of CRL's
with no information other than the issuer name when the
CRLDistributionPoint extension is not used.  Most of the discussion on this
thread seems equally applicable to issuer names and to subject names.
     While there is no absolute relation between subject attributes and
directory entries, a certificate is usually expected to be found in no
other directory entry than that whose name matches the subject.  While the
policy or CPS could provide information about the semantic usage of
country, it is not intended to point to the physical directory.

          Tom Gindin



Stefan Santesson <[e-mail]> on 03/02/99 01:09:54 PM

To:   [e-mail]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Qualified Certificates draft - Country name




--0__=SHoMKsPrQTFOqQM8Lo42hcSLPtev9Y9P8VdGYNegtlU8SoYvBzOJAwZ4
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



I interpret the ruff consensus to be that countryName should NOT be
mandatory.

I have seen many reasons presented on why it would be wise to use the
country name (I agree to many of them). What I try to figure out is if =
it
would be any problem for those using countryName if it also would be
allowed not to.

I can't find any such problems, espesially not when there is no absolut=
e
relation between attributes in the subject field and the location of a
certificate in a directory. Further the policy/CPS may provide semantic=
s
which otherwise would be unclear due to an absent countryName value.


If any one else can find real problems, I would like to know, otherwise=
 I
suggest that we remove the mandatory requirement.

/Stefan


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systems=E4kerhet AB
Lotsgatan 27 D                  Tel. [phone]
216 42  Malm=F6                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
=

--0__=SHoMKsPrQTFOqQM8Lo42hcSLPtev9Y9P8VdGYNegtlU8SoYvBzOJAwZ4--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA24911 for ietf-pkix-bks; Tue, 2 Mar 1999 15:10:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24907 for <[e-mail]>; Tue, 2 Mar 1999 15:10:22 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16242; Tue, 2 Mar 1999 18:15:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-00.txt
Date: Tue, 02 Mar 1999 18:15:32 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
of the IETF.

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-00.txt
	Pages		: 9
	Date		: 01-Mar-99
	
  This document describes two methods for producing a signature from a
  Diffie-Hellman key pair.  This behavior is needed for such operations
  as creating a signature of a PKCS #10 certification request.  These
  algorithms are designed to provide a proof-of-possession rather than
  general purpose signing.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-dhpop-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dhpop-00.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA24689 for ietf-pkix-bks; Tue, 2 Mar 1999 14:42:05 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24685 for <[e-mail]>; Tue, 2 Mar 1999 14:41:56 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <FG5JKV7C>; Wed, 3 Mar 1999 09:45:23 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A633A@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Bob Jueneman'" <[e-mail]>, [e-mail]
Subject: RE: Mapping certificate to directories
Date: Wed, 3 Mar 1999 09:45:16 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Succintly put.

I had a busy few years promoting electronic mail gateways that did
translational mapping between MSMail, ccMail, Notes, X.400, SMTP ad
infinitum.  We had extensive rules for address matching / mapping between
proprietary name spaces to a common representation (X.400 / SMTP).  These
products are still out there and organsations that have a lot of
administrative baggage / systems must continue to buy and implement them
because its cheaper than alternatives of renaming all users.

But at the end of the day, the whole concept is *broken* and people should
bite the bullet on rationalising namespaces, to not do so only defers the
inevitable and results in kudge upon kludge until you get to where you are
hamstrung by your naming and architectures..

N.B.  Directories can be established to systematically apply Prefixes to
namespaces, which masks the problem.

<snip>


> 1. At present, we don't even have an agreed to method of finding
> where a directory  that contains a certificate, etc., might be located.
> and once we do find such a directory, we don't know what the DIT 
> or the schema looks like.
> 
	[Andrew Probert]  The DIT should not be relevant if the certificate
is in that directory system, you simply do a read by presenting the
distinguished name of the certficate to the directory.  It will return a
certificate anywhere from within the DIT.  

	There should be enough standardised schema to get back critical
data.  Auxilliary items etc could be ignored.

> 2.  Without attempting to predict what will happen in the future,
> we must observe that for today, at least, there is no widely-agreed to
> standard for how directory trees should be constructed, and in general
> every organization that implements a directory tends do to it differently.
> (I believe I've mentioned before that once in a talk I mentioned our
> own tree internal structure (e.g., bjueneman.nsrd.prv.novell) as an 
> example of that fact, only to have someone remark that they did
> the same thing -- all their NetWare systems used "novell" as the 
> top leaf in the tree.  Presumably they had other directory systems which 
> ended in "microsoft".  Arrgh!)
> 
	[Andrew Probert]  Sympathies.  But DIT structure is not the issue.
Naming and prefixes is.

> 3.  The problem will probably get worse before it gets better, if that 
> ever happens.  If I am running my e-mail system while sitting on an 
> airplane, I would probably look for certificates in my own personal
> directory or cache, which might or might not be organized in accordance 
> with my company's corporate directory.  If I don't find what I am looking
> for
> there, I would next check the corporate directory, and if that doesn't
> work,
> I would want to try to search in either the originator's directory, if
> possible,
> or in the CA's directory (if they maintain one), or in some repository
> that either
> the originator or I might happen to have a contract with for such
> purposes.
> 
	[Andrew Probert]  By convention most products out there seem to be
handling this with a 
	local representation  Nickname -> Real Address / Certs / Other data.
As per a previous posting by Alan Lloyd and interesting suggestion is to
have a local LDAP cache.  Of course size and currency and numerous other
issues arise.

> 4.  It is entirely conceivable that every single one of these directories 
> will have a completely different DIT structure, and probably a different 
> schema for what attributes are allowed in a DN as well.
> 
	[Andrew Probert]  Yep. That's why PKIX should put a stake in the
ground about some of this.

> 5. It is important to remember that existing directory structures are 
> created for the convenience of their administrators, primarily, and 
> reflect design properties that are strongly influenced by delegation
> of authority and geographical and/or organizational proximity.  This is,
> the top-level system administrator will own something like our DS-ROOT,
> and will closely guard who has write privileges into that tree.  Then he
> will delegate subtree rights to other sub-administrators, most often on
> a geographical basis (Provo, San Jose, Bangalore). Sub-sub-administrators
> may then create additional nodes in the tree, sometimes on a 
> organizational basis and perhaps more often on a geographical basis 
> that more or less mirrors the router connectivity.  I guess it should be 
> obvious that this structure doesn't break down neatly on geopolitical
> or even organizational lines.
> 
	[Andrew Probert]  .... and in general organisations will not publish
*all* of their internal directory to the outside world.  More likely it will
be a subset of people allowed to talk to the outside world....

> 6.  In general, system administrators haven't made any kind of 
> systematic provision for external users or organizations outside their 
> own organization. If they had, they might well have adopted 
> a structure closer to the X.400/X.520 model, but since directories are 
> normally rolled out for internal purposes long before people start
> thinking 
> about integrating them with other organizations, it is often too late
> to change them in any kind of systematic or organized way.
> 
	[Andrew Probert]  ... Lifecycle cost of maintenance, generally means
that they will pay in the end for deferring the problem.  One could adopt
the approach of saying there aren't a lot of certificates in use yet out
there.  So, as each user requires a certficate, lets sort the naming out as
we go, then rationalisation becomes a ongoing process not a single massive
event?


> 8. At present, we are between a rock and a hard place.  We have 
> implemented certificates using the DN construct to contain
> information that is usually intended to be displayed and hence 
> considered reasonably meaningful (although we don't even have
> a standard for that means), yet the DN was really supposed to 
> be the primary search index into a directory that contains that 
> certificate. But the directories aren't built that way, in general,
> and probably aren't going to change, and in the meantime very
> few products display alternate names at all, and the path 
> processing for alternate names rather than the DN is something 
> that I don't even want to think about.
> 
	[Andrew Probert]  .. consider Alias processing in directories, then
the server side does this, not a client responsibility.

> I have the direct responsibility for trying to resolve this architectural 
> issue within Novell, including integrating both our NDS and our 
> PKI products, and I confess that I am just about stumped as to what to
> recommend. I don't like ANY of the alternatives very much.
> 
> I am beginning to think that it may be necessary to recommend to 
> customers that they graft on a subtree to their DIT, maybe called 
> something like CertificateIssuer, and then file all certificate issued by
> a given CA under that CertificateIssuer node, and hope and pray 
> that the CA has enforced some kind of common tree structure 
> on the certificates they issue. Then regardless of what the 
> certificate specifies as a DN, it would be filed under the 
> CertificateIssuer node, as though CertificateIssuer had been 
> an implicit top-level RDN.
> 
	[Andrew Probert]  Again, you could do this by fabricating Alias
entries as pointers into the actual Directory Information Base.  This could
be done systematically, by extracting cert contents.

> Unfortunately, I'm not at all confident that every CA in the world has
> been completely consistent -- they may have issued certificates containing
> 
> whatever DN the requestor requested, regardless of whether it
> complied with a common DIT for that CA or not.  I don't know.
> anyone want to take a guess?
> 
	[Andrew Probert]  Some I know have flat namespaces e.g. every
domestic citizen in the one arc [double-arrgh!]
> If someone has a magic bullet solution to this problem, I'd certainly 
> like to hear it.
> 
	[Andrew Probert]  No magic bullets, but 
> Bob
> 
> 
> Robert R. Jueneman
> Security Architect
> Network Security Development
> Novell, Inc.
> 122 East 1700 South
> Provo, UT 84606
> [e-mail]
> 1-801-861-7387
> 
> >>> Paul Koning <[e-mail]> 03/02/99 08:33AM >>>
> >>>>> "tgindin" == tgindin  <[e-mail]> writes:
> 
>  tgindin> I think that country name should be made mandatory.  If
>  tgindin> country name is made optional, how is the number of
>  tgindin> first-level entries in the global directory tree going to be
>  tgindin> held down to navigable levels?...
>  tgindin> Does anyone know of an alternative attribute that
>  tgindin> organizations could be made subordinate to?
> 
>  tgindin> Tom Gindin ([e-mail])
>                                      ^^^
> It seems to me you have an existence proof right there that it's not
> at all necessary to subordinate names to countries.
> 
> 	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22950 for ietf-pkix-bks; Tue, 2 Mar 1999 12:09:57 -0800 (PST)
Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22946 for <[e-mail]>; Tue, 2 Mar 1999 12:09:56 -0800 (PST)
Received: from [e-mail] [131.155.209.37] by mailhost.tue.nl (8.9.0) for <[e-mail]> id VAA13205 (SMTP). Tue, 2 Mar 1999 21:15:11 +0100 (MET)
From: [e-mail] (Arnoud "Galactus" Engelfriet)
Newsgroups: list.ietf.pkix
To: [e-mail]
Subject: Re: Qualified Certificates draft - Country name
Date: Tue, 02 Mar 1999 21:01:33 +0100
Organization: MCGV STACK, Eindhoven, The Netherlands
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Lines: 34
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In article <[e-mail]>,
Paul Koning <[e-mail]> wrote:
> >>>>> "tgindin" == tgindin  <[e-mail]> writes:
> 
>  tgindin> I think that country name should be made mandatory.  If
>  tgindin> country name is made optional, how is the number of
>  tgindin> first-level entries in the global directory tree going to be
>  tgindin> held down to navigable levels?...
>  tgindin> Does anyone know of an alternative attribute that
>  tgindin> organizations could be made subordinate to?
> 
>  tgindin> Tom Gindin ([e-mail])
>                                      ^^^
> It seems to me you have an existence proof right there that it's not
> at all necessary to subordinate names to countries.

The number of .com domains is now well over 3 million. It's hardly
a meaningful top-level domain anymore. The adoption of new top-level
domains has been planned for several years, but there's still no
sign of them coming into effect anytime soon.

So, yes, it's not necesssary to use country names as top-level/
first-level entries, but if you want something else, you're pretty
much on your own with the definition of the classification.

Greetings,

Arnoud

-- 
\/  Arnoud "Galactus" Engelfriet - [e-mail]              This space
    5th year Business & Computing Science student                 left blank
    URL: http://www.stack.nl/~galactus/  PGP: 0x416A1A35      intentionally.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21786 for ietf-pkix-bks; Tue, 2 Mar 1999 10:38:06 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA21782 for <[e-mail]>; Tue, 2 Mar 1999 10:38:05 -0800 (PST)
Received: (qmail 12141 invoked from network); 2 Mar 1999 18:43:26 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 2 Mar 1999 18:43:26 -0000
Received: (qmail 18492 invoked from network); 2 Mar 1999 18:38:59 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 2 Mar 1999 18:38:59 -0000
Message-ID: <00ad01be64cc$511020b0$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Mike Smith" <[e-mail]>, <[e-mail]>
Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging
Date: Tue, 2 Mar 1999 10:47:10 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

I try not to speak to sound business practice on this list, except
in the context of PKIX-QC, given it has a high-trust-level mission
to achieve, meeting "legally-valid" requirements. PKIX-QC, in
adressing legal validity, is but one of the applications or
environments that PKIX standards can now attack to engender
open-vendor, interoperable deployments. Seperating the technical
conformance standard from the policy-based interoperability rules
was definitely a good step for PKIX to have taken (assuming
the QC effort can steer clear of the naming chasm).

The only actionable aspect of trust addressed by PKIX's 2459
is the selection of trust-points - public-keys (or "roots") accepted by
relying-parties as reliable authentication information bound to
a given entity using procedures not involving (generally) the
use or reliance on certificates.

PKIX conformance does require a set of "non-trust" actions. These
actions "data process" cert paths, according to the technical requirements
of 2459.  Conforming processing is sensibly required, so processing
of a given trust path by vendor P's software produces the same result
as vendor Q's.

Perhaps my point was not made clearly, yesterday. Let me restate
it as an issue and a question:

ISSUE: PKIX gives a relying party discretion to choose trust-points, and
construct the certificate path used to validate a user certificate. That
path
will be made up of cert values issued by one or more certificate
management domains (such as the VeriSign Trust Network). Within
a hierarchical domain, the authority key id backpointers (in those
certificate of the path issued under the policies of that domain) will
normally point to the parent certificate.

QUESTION: If a certificate path chosen by a relying party contains at
least one certificate whose authority key id backpointer does
NOT resolve to a certificate in that path or any certificate
known to the relying party, can one designate otherwise normal
processing of  that chain as conforming to PKIX 2459?

My answer to the question is yes. Does anyone disagree?

Peter.


-----Original Message-----
From: Mike Smith <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Tuesday, March 02, 1999 10:41 AM
Subject: Re: PKIX Path determination/construction/processing and AKIpointer
hanging


>Whether sound business practice or not, the options allow four options to
the relying party for selection of trust domains:
>1.  Trust all CAs whether local or outside the local domain of trust (i.e.,
don't validate paths)
>2.  Trust your domain (search upwards from relying party's issuer until
finding an issuer at a high enough level to include the foreign certifcate
in the relying party's trust domain)
>3.  Trust the sending party's domain of trust, building a path from the
included cert, its CA, the CA's CA, etc., acquiring all of the associated CA
certs, CRLs, ARLs and CKLs, then parse and process on the client
>4.  Go to a trusted third party to see if they will vouch for the sender's
CA and the relying party's CA to build the bridge between the sender's and
relying party's trust domains.
>
>Options 2 and 4 imply some business relationship between the relying party
and the trust domain source, but 4 could be the same self-assumed risk as
option 1.
>
>Other options that do not rely on path building begin at the local domain
of trust (relying party's CA) and provides that the local CA do all of the
contracts, chaining, bridging or assumption of risk on behalf of the relying
party and returns an official "okey dokey" or other status on the single
cert that the relying party (or their software systems) is verifying
validity.  (this system may even return some "rights" or other attrubutes,
such as "the cert is still valid, but do not rely on it for any purchases
over USD$5"
>
>Have I missed something here?
>
>Michael
>
>
>
>>>> "Peter Williams" <[e-mail]> 03/01 10:23 AM >>>
>Preamble
>
>Consider the following quotation from our RFC, and envisage
>the demo path situation in which one has an signed email quoting
>a user certificate from a VeriSign Class 3 organizational CA.
>Futhermore, envision that the various user and authority
>certificates in the VeriSign hierarchy link backwards
>to identify their parent certificates or self-signed public-
>key registered by the VeriSign Root registration authority.
>
>" (a) Certification paths may start with a public key of a CA in a
>      user's own domain, or with the public key of the top of a
>      hierarchy.  Starting with the public key of a CA in a user's own
>      domain has certain advantages.  In some environments, the local
>      domain is the most trusted. "[RFC2459]
>
>Following the option of 2459, the certification path selected by a
>validating
>user may commence with the users own private CA; which, issues
>a private-usage interdomain certificate for ANY of the various VeriSign
>authority certificates. Let us say it issues the interdomain
>certificate for the lowest VeriSign operated CA (the one
>that manages the enterprise-operated CAs in the VeriSign domain).
>
>Issue:
>
>When our relying party performs conforming path processing,
>authority identifiers,  which are marked critical for the user and say the
>enterprise authority certs, the  authority key id pointer in the enterprise
>cert will be left "hanging".
>
>That is, the parties path validation software would presumably
>not enforce presence or knowlege or well-identifiedness
>of other VerISign authority certificates. Instead it would
>apply processing based on its local trust delegation
>mechanisms. Said software, will ensure that the interdomain certificate
>issued by the relying parties CA to to thge enterpise CA's public
>key validly introduces the user certificate to the local environment.
>
>Apparent Rule:
>
>PKIX-QC might restrict valid path processing to the chain implied
>by authority pointers, so that fixed and CA-managed policy
>controls are enforced.
>
>In general PKIX, and with any non-legalistic policies, relying party
>domain rules governing path processing/validation are free to leave chain
>pointers hanging, providing that they have local-CA mechanisms
>such as that suggested in 2459 to discover/determine/proces
>the locally-required trust path.
>
>Question:
>
>Any major disagreement with what seems to be PKIX-conforming process,
>and suggestions for the PKIX-QC document?
>
>Peter.
>
>
>NB: The same issues goes for CRL(DP) and OCSP certification paths.
>
>.
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21609 for ietf-pkix-bks; Tue, 2 Mar 1999 10:27:34 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21603 for <[e-mail]>; Tue, 2 Mar 1999 10:27:32 -0800 (PST)
Received: from fionn.es.net (localhost [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id KAA03487; Tue, 2 Mar 1999 10:32:54 -0800 (PST)
Message-Id: <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
cc: [e-mail]
Reply-to: [e-mail]
Subject: Re: A web of directories 
In-reply-to: Your message of "Tue, 02 Mar 1999 09:20:42 MST." <[e-mail]> 
Date: Tue, 02 Mar 1999 10:32:54 -0800
From: Michael Helm <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Bob Jueneman" writes:
> 1.  How widely is the SRV function deployed?  Is it standardized
> (RFC ?), what vendors support it,

> 	It was deployed in the Vixie BIND code about 3 years back.

It's certainly in bind 8.x.
Also, it is essential for NT 5 / Windows 2000 so it must be in
microsoft's DNS.

(from the rfc index)

2052 A DNS RR for specifying the location of services (DNS SRV). A.
     Gulbrandsen, P. Vixie. October 1996. (Format: TXT=19257 bytes)
     (Status: EXPERIMENTAL)

http://www.es.net/pub/rfcs/rfc2052.txt
& the usual places


> 2.  Can the SRV deal with multiple protocols?  If it doesn't
> already, could it be extended? In particular, for what I am trying to
> negotiate what directory access protocol they use, e.g., LDAP, DAP,
> NDAP (NDS), HTTP, FTP, or whatever.  Would this work?  

Absolutely -- at least according to the spec.  See the rfc.
Don't have any practical experience with it.


Some examples from the RFC:

   Here is the format of the SRV RR, whose DNS type code is 33:
 
        Service.Proto.Name TTL Class SRV Priority Weight Port Target

Introductory example
 
   When a SRV-cognizant web-browser wants to retrieve
 
      http://www.asdf.com/
 
   it does a lookup of
 
      http.tcp.www.asdf.com

More complex ones in the RFC itself.   Obviously your client application
would have to handle sorting thru whatever the SRV returned if 
you get multiple hits for a protocol, somewhat like the way MX
records are handled.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21271 for ietf-pkix-bks; Tue, 2 Mar 1999 10:04:04 -0800 (PST)
Received: from maila.telia.com ([e-mail] [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21266 for <[e-mail]>; Tue, 2 Mar 1999 10:03:58 -0800 (PST)
Received: from stefan2 (t4o68p29.telia.com [62.20.139.149]) by maila.telia.com (8.8.8/8.8.8) with SMTP id TAA02486 for <[e-mail]>; Tue, 2 Mar 1999 19:09:16 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 02 Mar 1999 19:09:54 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: Qualified Certificates draft - Country name
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 mail.proper.com id KAA21268
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I interpret the ruff consensus to be that countryName should NOT be mandatory.

I have seen many reasons presented on why it would be wise to use the
country name (I agree to many of them). What I try to figure out is if it
would be any problem for those using countryName if it also would be
allowed not to.

I can't find any such problems, espesially not when there is no absolute
relation between attributes in the subject field and the location of a
certificate in a directory. Further the policy/CPS may provide semantics
which otherwise would be unclear due to an absent countryName value.


If any one else can find real problems, I would like to know, otherwise I
suggest that we remove the mandatory requirement.

/Stefan


-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. [phone]              
216 42  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20894 for ietf-pkix-bks; Tue, 2 Mar 1999 09:34:04 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA20890 for <[e-mail]>; Tue, 2 Mar 1999 09:34:03 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 02 Mar 1999 10:38:55 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 02 Mar 1999 10:38:44 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Mapping certificate to directories
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 mail.proper.com id JAA20891
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well at long last, we are beginning to address the 
extremely complex issue of mapping between the contents 
of a certificate, and in particular the "distinguished name,"
and the structure and schema that might reasonably be used
to contain such certificates, CRLs, and other useful information.

Here are a couple of things to keep in mind:

1. At present, we don't even have an agreed to method of finding
where a directory  that contains a certificate, etc., might be located.
and once we do find such a directory, we don't know what the DIT 
or the schema looks like.

2.  Without attempting to predict what will happen in the future,
we must observe that for today, at least, there is no widely-agreed to
standard for how directory trees should be constructed, and in general
every organization that implements a directory tends do to it differently.
(I believe I've mentioned before that once in a talk I mentioned our
own tree internal structure (e.g., bjueneman.nsrd.prv.novell) as an 
example of that fact, only to have someone remark that they did
the same thing -- all their NetWare systems used "novell" as the 
top leaf in the tree.  Presumably they had other directory systems which 
ended in "microsoft".  Arrgh!)

3.  The problem will probably get worse before it gets better, if that 
ever happens.  If I am running my e-mail system while sitting on an 
airplane, I would probably look for certificates in my own personal
directory or cache, which might or might not be organized in accordance 
with my company's corporate directory.  If I don't find what I am looking for
there, I would next check the corporate directory, and if that doesn't work,
I would want to try to search in either the originator's directory, if possible,
or in the CA's directory (if they maintain one), or in some repository that either
the originator or I might happen to have a contract with for such purposes.

4.  It is entirely conceivable that every single one of these directories 
will have a completely different DIT structure, and probably a different 
schema for what attributes are allowed in a DN as well.

5. It is important to remember that existing directory structures are 
created for the convenience of their administrators, primarily, and 
reflect design properties that are strongly influenced by delegation
of authority and geographical and/or organizational proximity.  This is,
the top-level system administrator will own something like our DS-ROOT,
and will closely guard who has write privileges into that tree.  Then he
will delegate subtree rights to other sub-administrators, most often on
a geographical basis (Provo, San Jose, Bangalore). Sub-sub-administrators
may then create additional nodes in the tree, sometimes on a 
organizational basis and perhaps more often on a geographical basis 
that more or less mirrors the router connectivity.  I guess it should be 
obvious that this structure doesn't break down neatly on geopolitical
or even organizational lines.

6.  In general, system administrators haven't made any kind of 
systematic provision for external users or organizations outside their 
own organization. If they had, they might well have adopted 
a structure closer to the X.400/X.520 model, but since directories are 
normally rolled out for internal purposes long before people start thinking 
about integrating them with other organizations, it is often too late
to change them in any kind of systematic or organized way.

7.  All of this has of course nothing whatsoever to do with legal names
or other niceties, especially those that might be expected to show up 
in some relying party's browser or e-mail program, where the user or RP
might reasonably expect to see a name that bears some reasonably 
correspondence to SOMETHING that he recognizes in the "real world,"
whether that is an e-mail address, physical (postal) address, or 
organizational structure (business card like).

8. At present, we are between a rock and a hard place.  We have 
implemented certificates using the DN construct to contain
information that is usually intended to be displayed and hence 
considered reasonably meaningful (although we don't even have
a standard for that means), yet the DN was really supposed to 
be the primary search index into a directory that contains that 
certificate. But the directories aren't built that way, in general,
and probably aren't going to change, and in the meantime very
few products display alternate names at all, and the path 
processing for alternate names rather than the DN is something 
that I don't even want to think about.

I have the direct responsibility for trying to resolve this architectural 
issue within Novell, including integrating both our NDS and our 
PKI products, and I confess that I am just about stumped as to what to recommend. I don't like ANY of the alternatives very much.

I am beginning to think that it may be necessary to recommend to 
customers that they graft on a subtree to their DIT, maybe called 
something like CertificateIssuer, and then file all certificate issued by
a given CA under that CertificateIssuer node, and hope and pray 
that the CA has enforced some kind of common tree structure 
on the certificates they issue. Then regardless of what the 
certificate specifies as a DN, it would be filed under the 
CertificateIssuer node, as though CertificateIssuer had been 
an implicit top-level RDN.

Unfortunately, I'm not at all confident that every CA in the world has
been completely consistent -- they may have issued certificates containing 
whatever DN the requestor requested, regardless of whether it
complied with a common DIT for that CA or not.  I don't know.
anyone want to take a guess?

If someone has a magic bullet solution to this problem, I'd certainly 
like to hear it.

Bob


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> Paul Koning <[e-mail]> 03/02/99 08:33AM >>>
>>>>> "tgindin" == tgindin  <[e-mail]> writes:

 tgindin> I think that country name should be made mandatory.  If
 tgindin> country name is made optional, how is the number of
 tgindin> first-level entries in the global directory tree going to be
 tgindin> held down to navigable levels?...
 tgindin> Does anyone know of an alternative attribute that
 tgindin> organizations could be made subordinate to?

 tgindin> Tom Gindin ([e-mail])
                                     ^^^
It seems to me you have an existence proof right there that it's not
at all necessary to subordinate names to countries.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20102 for ietf-pkix-bks; Tue, 2 Mar 1999 08:40:17 -0800 (PST)
Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA20098 for <[e-mail]>; Tue, 2 Mar 1999 08:40:16 -0800 (PST)
Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Tue, 02 Mar 1999 09:37:55 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Mon, 01 Mar 1999 15:56:00 -0700
From: Mike Smith <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX Path determination/construction/processing and AKI pointer hanging
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Whether sound business practice or not, the options allow four options to the relying party for selection of trust domains:
1.  Trust all CAs whether local or outside the local domain of trust (i.e., don't validate paths)
2.  Trust your domain (search upwards from relying party's issuer until finding an issuer at a high enough level to include the foreign certifcate in the relying party's trust domain)
3.  Trust the sending party's domain of trust, building a path from the included cert, its CA, the CA's CA, etc., acquiring all of the associated CA certs, CRLs, ARLs and CKLs, then parse and process on the client
4.  Go to a trusted third party to see if they will vouch for the sender's CA and the relying party's CA to build the bridge between the sender's and relying party's trust domains.

Options 2 and 4 imply some business relationship between the relying party and the trust domain source, but 4 could be the same self-assumed risk as option 1.

Other options that do not rely on path building begin at the local domain of trust (relying party's CA) and provides that the local CA do all of the contracts, chaining, bridging or assumption of risk on behalf of the relying party and returns an official "okey dokey" or other status on the single cert that the relying party (or their software systems) is verifying validity.  (this system may even return some "rights" or other attrubutes, such as "the cert is still valid, but do not rely on it for any purchases over USD$5"

Have I missed something here?

Michael



>>> "Peter Williams" <[e-mail]> 03/01 10:23 AM >>>
Preamble

Consider the following quotation from our RFC, and envisage
the demo path situation in which one has an signed email quoting
a user certificate from a VeriSign Class 3 organizational CA.
Futhermore, envision that the various user and authority
certificates in the VeriSign hierarchy link backwards
to identify their parent certificates or self-signed public-
key registered by the VeriSign Root registration authority.

" (a) Certification paths may start with a public key of a CA in a
      user's own domain, or with the public key of the top of a
      hierarchy.  Starting with the public key of a CA in a user's own
      domain has certain advantages.  In some environments, the local
      domain is the most trusted. "[RFC2459]

Following the option of 2459, the certification path selected by a
validating
user may commence with the users own private CA; which, issues
a private-usage interdomain certificate for ANY of the various VeriSign
authority certificates. Let us say it issues the interdomain
certificate for the lowest VeriSign operated CA (the one
that manages the enterprise-operated CAs in the VeriSign domain).

Issue:

When our relying party performs conforming path processing,
authority identifiers,  which are marked critical for the user and say the
enterprise authority certs, the  authority key id pointer in the enterprise
cert will be left "hanging".

That is, the parties path validation software would presumably
not enforce presence or knowlege or well-identifiedness
of other VerISign authority certificates. Instead it would
apply processing based on its local trust delegation
mechanisms. Said software, will ensure that the interdomain certificate
issued by the relying parties CA to to thge enterpise CA's public
key validly introduces the user certificate to the local environment.

Apparent Rule:

PKIX-QC might restrict valid path processing to the chain implied
by authority pointers, so that fixed and CA-managed policy
controls are enforced.

In general PKIX, and with any non-legalistic policies, relying party
domain rules governing path processing/validation are free to leave chain
pointers hanging, providing that they have local-CA mechanisms
such as that suggested in 2459 to discover/determine/proces
the locally-required trust path.

Question:

Any major disagreement with what seems to be PKIX-conforming process,
and suggestions for the PKIX-QC document?

Peter.


NB: The same issues goes for CRL(DP) and OCSP certification paths.

.

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20069 for ietf-pkix-bks; Tue, 2 Mar 1999 08:38:58 -0800 (PST)
Received: from stax05.cubis.de (wks1.cubis.de [194.112.101.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19997; Tue, 2 Mar 1999 08:34:01 -0800 (PST)
Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id RAA09899; Tue, 2 Mar 1999 17:26:55 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 02 Mar 1999 17:24:10 +0000
From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" <[e-mail]>
Organization: Secunet GmbH - The Trust Company
X-Mailer: Mozilla 4.03 [en] (WinNT; I)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Call For Papers: CQRE [Secure]
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<HTML>
(Sorry if you receive multiple mailings)

<P>***********************************************
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CQRE [Secure] Congress &amp; Exhibition
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Duesseldorf, Germany, Nov. 30
- Dec. 2 1999
<BR>---------------------------------------------------------------
<BR>provides a new international forum covering most aspects of
<BR>information security with a special focus to the role of
<BR>information security in the context of rapidly evolving economic
<BR>processes.
<BR>---------------------------------------------------------------
<BR>&nbsp;Deadline for submission of extended abstracts: May 14, 1999
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<A HREF="http://www.secunet.de/forum/cqre.html">http://www.secunet.de/forum/cqre.html</A>
<BR>***********************************************

<P>If you are interested in receiving subsequent CFP's, registration-
<BR>and exhibitor-information, you may subscribe to the
<BR>&nbsp;<A HREF="mailto:[e-mail]?subject=subscribe">CQRE-Mailing-List</A>&nbsp;
.

<P>Please distribute this mail to interested collegues.

<P>Best regards
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Detlef Huehnlein
<BR>&nbsp;&nbsp;&nbsp;&nbsp; CQRE-team
<BR>&nbsp;
<BR>&nbsp;</HTML>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19810 for ietf-pkix-bks; Tue, 2 Mar 1999 08:16:17 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA19803 for <[e-mail]>; Tue, 2 Mar 1999 08:16:14 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 02 Mar 1999 09:21:03 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 02 Mar 1999 09:20:42 -0700
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: A web of directories
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 mail.proper.com id IAA19805
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phillip,

Please pardon my ignorance regarding DNS, but perhaps you could answer some questions:

1.  How widely is the SRV function deployed?  Is it standardized (RFC ?), what vendors support it, etc., etc?

2.  Can the SRV deal with multiple protocols?  If it doesn't already, could it be extended? In particular, for what I am trying to do to implement a web of directories, I would like to supply a DNS name for a directory, and allow the clients to find out and/or negotiate what directory access protocol they use, e.g., LDAP, DAP, NDAP (NDS), HTTP, FTP, or whatever.   Would this work?

Bob


>>> "Phillip M Hallam-Baker" <[e-mail]> 03/01/99 09:08AM >>>
Steve,

	That is exactly what the SRV record that I have been going 
on about for a year now does.

	It was deployed in the Vixie BIND code about 3 years back.

		Phill

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Stephen Kent
> Sent: Wednesday, February 24, 1999 12:24 PM
> To: Larry Layten
> Cc: Bob Jueneman; [e-mail] 
> Subject: RE: A web of directories
> 
> 
> Larry,
> 
> >For e-mail certificates, can't you use the domain from
> >the internet e-mail address to point you to a DNS server
> >And can't that in turn point you to the correct LDAP directory.
> 
> One can certainly look up the user's DNS server based on e-mail address,
> but we don't have a record format in the DNS that points to an LDAP
> directory as a result.  One could define such a record type, though.
> 
> Steve
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA19296 for ietf-pkix-bks; Tue, 2 Mar 1999 07:29:37 -0800 (PST)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA19292 for <[e-mail]>; Tue, 2 Mar 1999 07:29:35 -0800 (PST)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgeuw21704; Tue, 2 Mar 1999 10:33:54 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18142; Tue, 2 Mar 99 10:30:17 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA14544; Tue, 2 Mar 1999 10:33:53 -0500
Date: Tue, 2 Mar 1999 10:33:53 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: RE: Qualified Certificates draft - Country name
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "tgindin" == tgindin  <[e-mail]> writes:

 tgindin> I think that country name should be made mandatory.  If
 tgindin> country name is made optional, how is the number of
 tgindin> first-level entries in the global directory tree going to be
 tgindin> held down to navigable levels?...
 tgindin> Does anyone know of an alternative attribute that
 tgindin> organizations could be made subordinate to?

 tgindin> Tom Gindin ([e-mail])
                                     ^^^
It seems to me you have an existence proof right there that it's not
at all necessary to subordinate names to countries.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA15533 for ietf-pkix-bks; Tue, 2 Mar 1999 03:05:02 -0800 (PST)
Received: from nexus.webmatic.de ([195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA15386 for <[e-mail]>; Tue, 2 Mar 1999 03:04:59 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 09DB031; Tue, 02 Mar 1999 12:10:17 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id MAA10014; Tue, 2 Mar 1999 12:10:14 +0100
Message-ID: <[e-mail]>
Date: Tue, 02 Mar 1999 12:13:55 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Miklos, Sue A." <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Qualified Certificates draft - Country name
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The current QC draft defines
"The subject field SHALL include one of the following choices of sets
   of mandatory attributes:

      Choice  I:  countryName commonName
      Choice II:  countryName givenName surname"

The subject´s countryName is MANDATED. Furthermore, the usage is defined
by setting a general context for the remaining subject (?) attributes.
Is this right?

I propose that the countryName specification should be changed to
OPTIONAL.

 
with regards

--------------------------------------------------------------------
Juergen Walter                  
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
-------------------------------------------------------------------- 

> "Miklos, Sue A." wrote:
> 
> I would like to request that the country field remain optional.
> Sandi Miklos
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Saturday, February 27, 1999 10:52 AM
> To: Bob Jueneman; [e-mail]
> Cc: [e-mail]; ietf-pkix; Stephen Kent
> Subject: RE: Qualified Certificates draft - Country name
> 
> All,
> 
> I would like to clarify the scope of the draft.
> 
> It is NOT the intent of the draft to specify how a meaningful identity
> 
> should be composed.
> 
> Period.
> 
> It is though the intent of the draft to specify a well defined
> structure
> within which any useful identity information could be expressed
> according
> to the issuers and the key holders preferences.
> 
> The qualified certificate has two different compartments for subject
> identity information.
> 1) The subject field
> 2) The PersonalData field (stored in subjextAltName extension as a new
> 
> information construct stored under otherNames.)
> 
> The main purpose of the subject field is to hold a "technical name"
> fulfilling all technical requirements that might be imposed on the
> certificate with respect to presence of a unique X.500 type of name.
> This
> name may or may not be suitable as the subjects preferred legal name
> (unmistakable identity).
> 
> The optional PersonalData field has the main purpose of providing
> means to
> express a legal name in cases where the subject field is not
> sufficient for
> this purpose. The advantage of this approach is to free the subject
> field
> of strange attributes and semantics necessary for expressing the legal
> name.
> 
> So, this debate is about whether the countryName attribute in the
> subject
> field (the technical name)shall be mandatory or optional. Keep in mind
> that
> any country information as part of the legal name can be handled in
> the
> PersonalData field regardless of what is done in the subject field.
> 
> This gives the conclusion that what we decide in the subject field (as
> 
> mandatory or not), should only be based on technical requirements from
> 
> X.500 directory systems and similar, not from requirements on legal
> name
> forming.
> 
> Based on this presumption I would appreciate a consensus in this
> subject.
> 
> /Stefan
> 
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: [phone]
Email: [e-mail]            Fax:  [phone]
--------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA16481 for ietf-pkix-bks; Mon, 1 Mar 1999 18:25:33 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA16477 for <[e-mail]>; Mon, 1 Mar 1999 18:25:32 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id SAA29916; Mon, 1 Mar 1999 18:30:46 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 01 Mar 1999 18:29:57 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: Qualified Certificates draft - Country name
Cc: Stefan Santesson <[e-mail]>, "Bob Jueneman" <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:45 PM 3/1/99 -0500, [e-mail] wrote:

[I (Tony) wrote]
>Hence if "Atomic Elements" were the established top-level names,
>a CA could select one at random and assign it as the first
>identifying "element" in my certificate (if the goal were simply
>to make directories "navigable".)
>
>Why, exactly, is there a need to have THESE names correspond to
>anything in the "real world"?  As long as an entity can be uniquely
>defined, it would be the corresponding CA who should hold whatever
>information about the entity that might reveal the qualified
>"real-world" attributes.
>
>[Tom Gindin]   The problem I see is that a client performing a verification
>needs to find the issuing CA (not just its own CA) itself.  The main reason
>to have these names correspond to something sizable in the real world is to
>keep the number of top-level names manageable, and to have a defensible
>basis for allowing certain entities to be at the top level and others not.
>Since the set of major industries is roughly as stable as that of
>countries, if assignment authorities for them could be as clearly
>determined, they would be reasonable candidates for top-level entries - if
>somebody could impose a lower bound on what is a "major industry".

I understand that there need be a pre-arranged, limited number
of top-level (and why not second and third level) names to afford
efficient directory navigation.

But I cannot see why the directory-search hierarchy should have ANY
relationship to a possible real-world identification "taxonomy".
That is just asking for headaches, and security-related problems.

If I entered into a transaction with you, online or off, and you need
to determine the authenticity of my credentials, I MUST cooperate to
some degree.  If you do not know my "country", for instance, then a
directory with "country name" at the top is of no use to you.

In order for you to find my "issuer", I must supply you with some
information.  It will either be sufficient information for you to
locate my issuer, or it will not.  Once you know that my issuer is
(say) VeriSign, you can validate my QC and be satisfied.

I find the concept of having the directory hierarchy itself mirror
my "identification taxonomy" to be disturbing.  It appears designed
less for "leaf location" and more for "opportunistic trawling".

(I know her name, she lives in Germany, and works for XYZ GMBH.
Let's see if we can locate her QC and find out more about her...)

I know its late in the game, but since it is MY issuing CA who
must vouch for my QC, all they need is to ensure they can place
its location in the directory unambiguously, while the directory
is structured so that inefficient "clumping" does not occur.

If the top 4 levels of the directory were organized according to
4 arbitrary "bytes", then "P.Q.R.S.VeriSign.whatever-else" would
be sufficient to locate my issuer and validate my QC.  The fact
that my neighbor (same street, same country, same organization)
has a QC located by "E.R.G.B.VeriSign.whatever-else" should pose
no problem at all.  Now, any CA can simply generate 4 random bytes
and assign them as the top-level "names" for the cert.  After all,
it serves to point back to the CA, who must vouch for that cert's
"whatever-else" information.

Why should they always be the same, just because they are the
same CA, or for next-door neighbors, or whatever else might be
similar?  

By this scheme, the top-levels of the directory are ALWAYS fixed
and manageable.  And what more defensible basis for allowing "who"
gets to be at the top-levels?  Simply bytes.  They cannot argue,
and no one "owns" them.

The "Cert-Recipient" (Relying Party) needs to have the top-level
name (and more!) in any case, in order to use the directory.
Where are they expected to get this information?  They will
certainly not be making blind-guesses (and you don't want them
to try.)  Either they have a "name" to apply, or they do not.

Am I missing something critical? (wouldn't be the first time;)

___tony___




Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15954 for ietf-pkix-bks; Mon, 1 Mar 1999 16:54:06 -0800 (PST)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15950 for <[e-mail]>; Mon, 1 Mar 1999 16:54:05 -0800 (PST)
From: [e-mail]
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id TAA51202; Mon, 1 Mar 1999 19:59:45 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by southrelay02.raleigh.ibm.com (8.8.7/NCO v1.8) with SMTP id TAA80554; Mon, 1 Mar 1999 19:58:39 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256728.00041343 ; Mon, 1 Mar 1999 19:44:30 -0500
X-Lotus-FromDomain: IBMUS
To: Tony Bartoletti <[e-mail]>
cc: Stefan Santesson <[e-mail]>, "Bob Jueneman" <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 1 Mar 1999 19:45:58 -0500
Subject: RE: Qualified Certificates draft - Country name
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     My responses are indicated with my name in brackets.


Tony Bartoletti <[e-mail]> on 03/01/99 06:55:38 PM

To:   Tom Gindin/Watson/IBM, Stefan Santesson <[e-mail]>
cc:   "Bob Jueneman" <[e-mail]>, [e-mail],
      ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
Subject:  RE: Qualified Certificates draft - Country name





At 05:30 PM 3/1/99 -0500, [e-mail] wrote:
>     I think that country name should be made mandatory.  If country name
>is made optional, how is the number of first-level entries in the global
>directory tree going to be held down to navigable levels?  I would have no
>objection to defining the mandatory attribute superior to organization as
a
>choice between country name and international assignment authority, but to
>allow any organization that wishes to assign itself as a first-level entry
>in the tree to do so will produce a situation in which there is no entity
>with a complete list of first-level entries.  That would probably make it
>permanently impossible for client systems to navigate the tree.
>     One problem with country name, however, is that it implicitly assumes
>a "Westphalia model" of countries and makes no provision for such things
as
>the EU.  Does anyone know of an alternative attribute that organizations
>could be made subordinate to?

Signs of the Zodiac?  Elements of the Periodic Table? ...

Pardon for being flip, and perhaps a bit mystified by the urge to
subordinate
all things to "countries".  I think of the Balkans, or other areas of the
world
where maps and countries seems to transform themselves on a regular basis.

[Tom Gindin]   No argument here - I was thinking more about the multiple
levels of government than about their stability, though.

Client systems required to navigate a global directory must be pre-armed
with
information sufficient to locate a unique "leaf" in the tree.  Since the
only
real "naming" authority becomes the CA (in negotiation with the certified
party)
it would seem they can be free to select any top-level name from some set
of
pre-established "top-level" names (pre-established for reasons of
efficiency
only).  Hence if "Atomic Elements" were the established top-level names, a
CA
could select one at random and assign it as the first identifying "element"
in my certificate (if the goal were simply to make directories
"navigable".)

Why, exactly, is there a need to have THESE names correspond to anything in
the "real world"?  As long as an entity can be uniquely defined, it would
be
the corresponding CA who should hold whatever information about the entity
that might reveal the qualified "real-world" attributes.

[Tom Gindin]   The problem I see is that a client performing a verification
needs to find the issuing CA (not just its own CA) itself.  The main reason
to have these names correspond to something sizable in the real world is to
keep the number of top-level names manageable, and to have a defensible
basis for allowing certain entities to be at the top level and others not.
Since the set of major industries is roughly as stable as that of
countries, if assignment authorities for them could be as clearly
determined, they would be reasonable candidates for top-level entries - if
somebody could impose a lower bound on what is a "major industry".


Indeed, why should I, and my next-door neighbor, reside "near each other"
in
some global directory?  The very thought is chilling, to say the least.

If I have this all wrong, please straighten me out.

Thanks.

___tony___


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15453 for ietf-pkix-bks; Mon, 1 Mar 1999 15:51:24 -0800 (PST)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15449 for <[e-mail]>; Mon, 1 Mar 1999 15:51:23 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id PAA09033; Mon, 1 Mar 1999 15:56:26 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 01 Mar 1999 15:55:38 -0800
To: [e-mail], Stefan Santesson <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Qualified Certificates draft - Country name
Cc: "Bob Jueneman" <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:30 PM 3/1/99 -0500, [e-mail] wrote:
>     I think that country name should be made mandatory.  If country name
>is made optional, how is the number of first-level entries in the global
>directory tree going to be held down to navigable levels?  I would have no
>objection to defining the mandatory attribute superior to organization as a
>choice between country name and international assignment authority, but to
>allow any organization that wishes to assign itself as a first-level entry
>in the tree to do so will produce a situation in which there is no entity
>with a complete list of first-level entries.  That would probably make it
>permanently impossible for client systems to navigate the tree.
>     One problem with country name, however, is that it implicitly assumes
>a "Westphalia model" of countries and makes no provision for such things as
>the EU.  Does anyone know of an alternative attribute that organizations
>could be made subordinate to?

Signs of the Zodiac?  Elements of the Periodic Table? ...

Pardon for being flip, and perhaps a bit mystified by the urge to subordinate
all things to "countries".  I think of the Balkans, or other areas of the world
where maps and countries seems to transform themselves on a regular basis.

Client systems required to navigate a global directory must be pre-armed with
information sufficient to locate a unique "leaf" in the tree.  Since the only
real "naming" authority becomes the CA (in negotiation with the certified party)
it would seem they can be free to select any top-level name from some set of
pre-established "top-level" names (pre-established for reasons of efficiency
only).  Hence if "Atomic Elements" were the established top-level names, a CA
could select one at random and assign it as the first identifying "element"
in my certificate (if the goal were simply to make directories "navigable".)

Why, exactly, is there a need to have THESE names correspond to anything in
the "real world"?  As long as an entity can be uniquely defined, it would be
the corresponding CA who should hold whatever information about the entity
that might reveal the qualified "real-world" attributes.

Indeed, why should I, and my next-door neighbor, reside "near each other" in
some global directory?  The very thought is chilling, to say the least.

If I have this all wrong, please straighten me out.

Thanks.

___tony___


Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14928 for ietf-pkix-bks; Mon, 1 Mar 1999 14:24:24 -0800 (PST)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14924 for <[e-mail]>; Mon, 1 Mar 1999 14:24:23 -0800 (PST)
From: [e-mail]
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id RAA86706; Mon, 1 Mar 1999 17:30:04 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay01.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id RAA112516; Mon, 1 Mar 1999 17:29:07 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 85256727.007B8309 ; Mon, 1 Mar 1999 17:29:04 -0500
X-Lotus-FromDomain: IBMUS
To: Stefan Santesson <[e-mail]>
cc: "Bob Jueneman" <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 1 Mar 1999 17:30:32 -0500
Subject: RE: Qualified Certificates draft - Country name
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=afBFaSOaahhCmNNpM0NOCSqhWNrum538vvpNKi33RFMOKyIYtGl9Z0q3"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=afBFaSOaahhCmNNpM0NOCSqhWNrum538vvpNKi33RFMOKyIYtGl9Z0q3
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I think that country name should be made mandatory.  If country name
is made optional, how is the number of first-level entries in the global
directory tree going to be held down to navigable levels?  I would have no
objection to defining the mandatory attribute superior to organization as a
choice between country name and international assignment authority, but to
allow any organization that wishes to assign itself as a first-level entry
in the tree to do so will produce a situation in which there is no entity
with a complete list of first-level entries.  That would probably make it
permanently impossible for client systems to navigate the tree.
     One problem with country name, however, is that it implicitly assumes
a "Westphalia model" of countries and makes no provision for such things as
the EU.  Does anyone know of an alternative attribute that organizations
could be made subordinate to?

          Tom Gindin     ([e-mail])

Note: These opinions are mine, and are not necessarily those of my
employer.





Stefan Santesson <[e-mail]> on 02/27/99 10:51:59 AM

To:   "Bob Jueneman" <[e-mail]>, Tom Gindin/Watson/IBM
cc:   [e-mail], ietf-pkix <[e-mail]>, Stephen Kent
      <[e-mail]>
Subject:  RE: Qualified Certificates draft - Country name




--0__=afBFaSOaahhCmNNpM0NOCSqhWNrum538vvpNKi33RFMOKyIYtGl9Z0q3
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



All,

I would like to clarify the scope of the draft.

It is NOT the intent of the draft to specify how a meaningful identity
should be composed.

Period.

It is though the intent of the draft to specify a well defined structur=
e
within which any useful identity information could be expressed accordi=
ng
to the issuers and the key holders preferences.

The qualified certificate has two different compartments for subject
identity information.
1) The subject field
2) The PersonalData field (stored in subjextAltName extension as a new
information construct stored under otherNames.)

The main purpose of the subject field is to hold a "technical name"
fulfilling all technical requirements that might be imposed on the
certificate with respect to presence of a unique X.500 type of name. Th=
is
name may or may not be suitable as the subjects preferred legal name
(unmistakable identity).

The optional PersonalData field has the main purpose of providing means=
 to
express a legal name in cases where the subject field is not sufficient=
 for
this purpose. The advantage of this approach is to free the subject fie=
ld
of strange attributes and semantics necessary for expressing the legal
name.

So, this debate is about whether the countryName attribute in the subje=
ct
field (the technical name)shall be mandatory or optional. Keep in mind =
that
any country information as part of the legal name can be handled in the=

PersonalData field regardless of what is done in the subject field.

This gives the conclusion that what we decide in the subject field (as
mandatory or not), should only be based on technical requirements from
X.500 directory systems and similar, not from requirements on legal nam=
e
forming.

Based on this presumption I would appreciate a consensus in this subjec=
t.

/Stefan




-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systems=E4kerhet AB
Lotsgatan 27 D                  Tel. [phone]
216 42  Malm=F6                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

=

--0__=afBFaSOaahhCmNNpM0NOCSqhWNrum538vvpNKi33RFMOKyIYtGl9Z0q3--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13115 for ietf-pkix-bks; Mon, 1 Mar 1999 11:14:40 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA13111 for <[e-mail]>; Mon, 1 Mar 1999 11:14:39 -0800 (PST)
Received: (qmail 9031 invoked from network); 1 Mar 1999 19:19:55 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 1 Mar 1999 19:19:55 -0000
Received: (qmail 9091 invoked from network); 1 Mar 1999 19:15:28 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 1 Mar 1999 19:15:28 -0000
Message-ID: <000701be6408$3e3fff10$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: <[e-mail]>
Subject: PKIX Path determination/construction/processing and AKI pointer hanging
Date: Mon, 1 Mar 1999 11:23:37 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Preamble

Consider the following quotation from our RFC, and envisage
the demo path situation in which one has an signed email quoting
a user certificate from a VeriSign Class 3 organizational CA.
Futhermore, envision that the various user and authority
certificates in the VeriSign hierarchy link backwards
to identify their parent certificates or self-signed public-
key registered by the VeriSign Root registration authority.

" (a) Certification paths may start with a public key of a CA in a
      user's own domain, or with the public key of the top of a
      hierarchy.  Starting with the public key of a CA in a user's own
      domain has certain advantages.  In some environments, the local
      domain is the most trusted. "[RFC2459]

Following the option of 2459, the certification path selected by a
validating
user may commence with the users own private CA; which, issues
a private-usage interdomain certificate for ANY of the various VeriSign
authority certificates. Let us say it issues the interdomain
certificate for the lowest VeriSign operated CA (the one
that manages the enterprise-operated CAs in the VeriSign domain).

Issue:

When our relying party performs conforming path processing,
authority identifiers,  which are marked critical for the user and say the
enterprise authority certs, the  authority key id pointer in the enterprise
cert will be left "hanging".

That is, the parties path validation software would presumably
not enforce presence or knowlege or well-identifiedness
of other VerISign authority certificates. Instead it would
apply processing based on its local trust delegation
mechanisms. Said software, will ensure that the interdomain certificate
issued by the relying parties CA to to thge enterpise CA's public
key validly introduces the user certificate to the local environment.

Apparent Rule:

PKIX-QC might restrict valid path processing to the chain implied
by authority pointers, so that fixed and CA-managed policy
controls are enforced.

In general PKIX, and with any non-legalistic policies, relying party
domain rules governing path processing/validation are free to leave chain
pointers hanging, providing that they have local-CA mechanisms
such as that suggested in 2459 to discover/determine/proces
the locally-required trust path.

Question:

Any major disagreement with what seems to be PKIX-conforming process,
and suggestions for the PKIX-QC document?

Peter.


NB: The same issues goes for CRL(DP) and OCSP certification paths.

.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12759 for ietf-pkix-bks; Mon, 1 Mar 1999 10:30:56 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA12755 for <[e-mail]>; Mon, 1 Mar 1999 10:30:55 -0800 (PST)
Received: (qmail 8865 invoked from network); 1 Mar 1999 18:36:10 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 1 Mar 1999 18:36:10 -0000
Received: (qmail 6987 invoked from network); 1 Mar 1999 18:31:43 -0000
Received: from unknown (HELO peternt) (10.0.0.230) by internal-mail.valicert.com with SMTP; 1 Mar 1999 18:31:43 -0000
Message-ID: <00f701be6402$21723e80$[e-mail]>
From: "Peter Williams" <[e-mail]>
To: "Rich Salz" <[e-mail]>, <[e-mail]>
Subject: Re: OCSP Service Locator and RFC2459's Authority Information Access
Date: Mon, 1 Mar 1999 10:39:52 -0600
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.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What *are* the critical "usage semantics" of an OCSP/CRLDP
service locator, in the various kinds of signalling fields,
AKI, CRLDP distributionPoint URI, etc.?

What are the non-critical usage semantics of the same?

For example, if the locator is an http URI or URL, may I
use my UA's or local proxies http cache, or must I positively
identify and use the values from the URI/URL in an
end-end online exchange, authenticated by http's basic auth,
MSIE's challenege/response auth,  or other mechanism such as
TLS or  IPSEC?

If a Internet OCSP/CRLDP UA is ever forced to use a online
exchange as a result of standard conformance
language, we will be undermining the assurance
of 2459, which states (informally, speaking) that PKIX does
not assume the average Internet UA worldwide
has other than minimal connectivity to the Net. Also,
confidentiality of acts of reliance would be potentially
compromised by traffic-pattern analysis threats.

One could imagine mandatory locator semantics
being usefully specified, but being either recommended
or required operationally only in policy documents such
as PKIX-QC, where the UA-desired legal respectability
of the online revocation/validation attestation might benefit
 from the CA/VA's online confirmation. Similarly, one could
imagine PKIX-QC profiling OCSP to use the available
nonces, to ensure replay threats are countered in such
enviornments and applications, whereas
normal-internet OCSP UA's may use/enforce nonces only
at the option of the UA , responder's private
commercial/liability policy permitting.

Peter.

Notes:

"In order to relieve some of the obstacles to using X.509
   certificates, this document defines a profile to promote the
   development of certificate management systems; development of
   application tools; and interoperability determined by policy." [RFC 2459]

"This profile supports users without
   high bandwidth, real-time IP connectivity, or high connection
   availability.  In addition, the profile allows for the presence of
   firewall or other filtered communication." [RFC 2459]


-----Original Message-----
From: Rich Salz <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Sunday, February 28, 1999 5:17 PM
Subject: OCSP Service Locator and RFC2459's Authority Information Access


>Is there any reason to use the OCSP "Service Locator", (Draft 7,
>Section 5.4.6) instead of defining an Authority Information Access
>AccessDescription for the OCSP service (RFC2459, Section 4.2.2.1)?
>Is it just a case of parallel efforts duplicating work, or is there
>a subtlety I'm missing?
>
>Replies to me will be summarized for the list.
> /r$



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11305 for ietf-pkix-bks; Mon, 1 Mar 1999 08:01:07 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11300 for <[e-mail]>; Mon, 1 Mar 1999 08:01:06 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA20016; Mon, 1 Mar 1999 08:02:17 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA10665; Mon, 1 Mar 1999 08:05:48 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Larry Layten" <[e-mail]>
Cc: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Subject: RE: A web of directories
Date: Mon, 1 Mar 1999 11:08:03 -0500
Message-ID: <000001be63fd$b0169be0$[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
Importance: Normal
In-Reply-To: <v0401170cb2f9e5f83cd5@[128.89.0.110]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

	That is exactly what the SRV record that I have been going 
on about for a year now does.

	It was deployed in the Vixie BIND code about 3 years back.

		Phill

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Stephen Kent
> Sent: Wednesday, February 24, 1999 12:24 PM
> To: Larry Layten
> Cc: Bob Jueneman; [e-mail]
> Subject: RE: A web of directories
> 
> 
> Larry,
> 
> >For e-mail certificates, can't you use the domain from
> >the internet e-mail address to point you to a DNS server
> >And can't that in turn point you to the correct LDAP directory.
> 
> One can certainly look up the user's DNS server based on e-mail address,
> but we don't have a record format in the DNS that points to an LDAP
> directory as a result.  One could define such a record type, though.
> 
> Steve
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10863 for ietf-pkix-bks; Mon, 1 Mar 1999 07:23:20 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10859 for <[e-mail]>; Mon, 1 Mar 1999 07:23:18 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA12646 for <[e-mail]>; Mon, 1 Mar 1999 10:28:34 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA12614 for <[e-mail]>; Mon, 1 Mar 1999 10:28:29 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA01979 for <[e-mail]>; Mon, 1 Mar 1999 10:27:06 -0500 (EST)
Received: from avenger.missi.ncsc.mil (avenger58.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 01 Mar 1999 10:28:20 -0500
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <F432RWV8>; Mon, 1 Mar 1999 10:28:20 -0500
Message-Id: <[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Cc: [e-mail], ietf-pkix <[e-mail]>, Stephen Kent <[e-mail]>
Subject: RE: Qualified Certificates draft - Country name
Date: Mon, 1 Mar 1999 10:28:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE63F8.22D34846"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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_01BE63F8.22D34846
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would like to request that the country field remain optional.
Sandi Miklos

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Saturday, February 27, 1999 10:52 AM
To: Bob Jueneman; [e-mail]
Cc: [e-mail]; ietf-pkix; Stephen Kent
Subject: RE: Qualified Certificates draft - Country name


All,

I would like to clarify the scope of the draft.

It is NOT the intent of the draft to specify how a meaningful identity
should be composed.

Period.

It is though the intent of the draft to specify a well defined =
structure
within which any useful identity information could be expressed =
according
to the issuers and the key holders preferences.

The qualified certificate has two different compartments for subject
identity information.
1) The subject field
2) The PersonalData field (stored in subjextAltName extension as a new
information construct stored under otherNames.)

The main purpose of the subject field is to hold a "technical name"
fulfilling all technical requirements that might be imposed on the
certificate with respect to presence of a unique X.500 type of name. =
This
name may or may not be suitable as the subjects preferred legal name
(unmistakable identity).

The optional PersonalData field has the main purpose of providing means =
to
express a legal name in cases where the subject field is not sufficient =
for
this purpose. The advantage of this approach is to free the subject =
field
of strange attributes and semantics necessary for expressing the legal =
name.

So, this debate is about whether the countryName attribute in the =
subject
field (the technical name)shall be mandatory or optional. Keep in mind =
that
any country information as part of the legal name can be handled in the
PersonalData field regardless of what is done in the subject field.

This gives the conclusion that what we decide in the subject field (as
mandatory or not), should only be based on technical requirements from
X.500 directory systems and similar, not from requirements on legal =
name
forming.

Based on this presumption I would appreciate a consensus in this =
subject.

/Stefan




-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systems=E4kerhet AB    =20
Lotsgatan 27 D                  Tel. [phone]             =20
216 42  Malm=F6                   Fax. [phone]             =20
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

------_=_NextPart_001_01BE63F8.22D34846
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: Qualified Certificates draft - Country name</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would like to request that the country field remain =
optional.</FONT>
<BR><FONT SIZE=3D2>Sandi Miklos</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stefan Santesson [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Saturday, February 27, 1999 10:52 AM</FONT>
<BR><FONT SIZE=3D2>To: Bob Jueneman; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; ietf-pkix; Stephen =
Kent</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Qualified Certificates draft - Country =
name</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>I would like to clarify the scope of the =
draft.</FONT>
</P>

<P><FONT SIZE=3D2>It is NOT the intent of the draft to specify how a =
meaningful identity</FONT>
<BR><FONT SIZE=3D2>should be composed.</FONT>
</P>

<P><FONT SIZE=3D2>Period.</FONT>
</P>

<P><FONT SIZE=3D2>It is though the intent of the draft to specify a =
well defined structure</FONT>
<BR><FONT SIZE=3D2>within which any useful identity information could =
be expressed according</FONT>
<BR><FONT SIZE=3D2>to the issuers and the key holders =
preferences.</FONT>
</P>

<P><FONT SIZE=3D2>The qualified certificate has two different =
compartments for subject</FONT>
<BR><FONT SIZE=3D2>identity information.</FONT>
<BR><FONT SIZE=3D2>1) The subject field</FONT>
<BR><FONT SIZE=3D2>2) The PersonalData field (stored in subjextAltName =
extension as a new</FONT>
<BR><FONT SIZE=3D2>information construct stored under =
otherNames.)</FONT>
</P>

<P><FONT SIZE=3D2>The main purpose of the subject field is to hold a =
&quot;technical name&quot;</FONT>
<BR><FONT SIZE=3D2>fulfilling all technical requirements that might be =
imposed on the</FONT>
<BR><FONT SIZE=3D2>certificate with respect to presence of a unique =
X.500 type of name. This</FONT>
<BR><FONT SIZE=3D2>name may or may not be suitable as the subjects =
preferred legal name</FONT>
<BR><FONT SIZE=3D2>(unmistakable identity).</FONT>
</P>

<P><FONT SIZE=3D2>The optional PersonalData field has the main purpose =
of providing means to</FONT>
<BR><FONT SIZE=3D2>express a legal name in cases where the subject =
field is not sufficient for</FONT>
<BR><FONT SIZE=3D2>this purpose. The advantage of this approach is to =
free the subject field</FONT>
<BR><FONT SIZE=3D2>of strange attributes and semantics necessary for =
expressing the legal name.</FONT>
</P>

<P><FONT SIZE=3D2>So, this debate is about whether the countryName =
attribute in the subject</FONT>
<BR><FONT SIZE=3D2>field (the technical name)shall be mandatory or =
optional. Keep in mind that</FONT>
<BR><FONT SIZE=3D2>any country information as part of the legal name =
can be handled in the</FONT>
<BR><FONT SIZE=3D2>PersonalData field regardless of what is done in the =
subject field.</FONT>
</P>

<P><FONT SIZE=3D2>This gives the conclusion that what we decide in the =
subject field (as</FONT>
<BR><FONT SIZE=3D2>mandatory or not), should only be based on technical =
requirements from</FONT>
<BR><FONT SIZE=3D2>X.500 directory systems and similar, not from =
requirements on legal name</FONT>
<BR><FONT SIZE=3D2>forming.</FONT>
</P>

<P><FONT SIZE=3D2>Based on this presumption I would appreciate a =
consensus in this subject.</FONT>
</P>

<P><FONT SIZE=3D2>/Stefan</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
<BR><FONT SIZE=3D2>Stefan =
Santesson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Accurata Systems=E4kerhet AB&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>Lotsgatan 27 =
D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. +46-40 =
152211&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>216 42&nbsp; =
Malm=F6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fax. +46-40 =
150790&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>Sweden&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Mobile [phone]</FONT>
</P>

<P><FONT SIZE=3D2>PGP fingerprint: 89BC 6C79 5B3D 591B 8547&nbsp; 1512 =
7D11 DBF4 528F 29A0</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BE63F8.22D34846--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA06675 for ietf-pkix-bks; Mon, 1 Mar 1999 02:26:43 -0800 (PST)
Received: from nexus.webmatic.de ([195.206.76.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA06671 for <[e-mail]>; Mon, 1 Mar 1999 02:26:41 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [195.206.79.60]) by nexus.webmatic.de (Postfix) with ESMTP id 5E3E82D; Mon, 01 Mar 1999 11:31:55 +0100 (CET)
Received: from deh.de (juergen.deh.de [195.206.79.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id LAA04203; Mon, 1 Mar 1999 11:32:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Mar 1999 11:35:32 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
Organization: DEH information systems GmbH
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Comments on Qualified Certificates draft (incl. countryName)
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments in line. (I have changed the subject name to cover the
content.)

Stefan Santesson wrote:
> 
> All,
> 
> I would like to clarify the scope of the draft.
> 
> It is NOT the intent of the draft to specify how a meaningful identity
> should be composed.

The current draft seems to provide QCs as the elektronic pendant of ID
cards. But we need an electronic pendant of handwritten signatures. This
scope contains legal issues. They must be outside the scope of any
standard. Therefore the draft should address the technical issues of the
electronic pendant of handwritten signatures, i. e. non-repudiation of
origin. Furthermore, the standard should address attribute definitions
suitable for electronic commerce and other applications (e. g.
administration).

> 
> Period.
> 
> It is though the intent of the draft to specify a well defined structure
> within which any useful identity information could be expressed according
> to the issuers and the key holders preferences.

This implies that country name should be OPTIONAL.

> 
> The qualified certificate has two different compartments for subject
> identity information.
> 1) The subject field
> 2) The PersonalData field (stored in subjextAltName extension as a new
> information construct stored under otherNames.)
> 
> The main purpose of the subject field is to hold a "technical name"
> fulfilling all technical requirements that might be imposed on the
> certificate with respect to presence of a unique X.500 type of name. This
> name may or may not be suitable as the subjects preferred legal name
> (unmistakable identity).

I am not a lawyer. But in most circumstances my legal name is Jürgen
Walter (sorry for the umlaut "ü" in advance :-). Whether I sign a
contract in England or in Germany, my handwritten signature is still the
same. No birthday, gender, countryName, residence, ... is included.
After I sign a contract I may be asked for my ID card depending on
relying party´s policy. The electronic pendant may be an attribute
certificate that provides the REQUIRED information. It should be noted
that data protection laws would restrict the usage of QCs in most
countries. Furthermore, some customers may have reservations to give
full identity information by signing data.

> 
> The optional PersonalData field has the main purpose of providing means to
> express a legal name in cases where the subject field is not sufficient for
> this purpose. The advantage of this approach is to free the subject field
> of strange attributes and semantics necessary for expressing the legal name.

The draft should be define attributes which are suitable in public key
certificates and in attribute certificates as well. All these attributes
should be OPTIONAL present in public key certificates. Whether a
particular attribute is present or not, should be a matter of PKI
design.

The PersonalData record includes attributes which are not names like ate
of birth. The encoding altSubjectName|otherNames|PersonalData may be
misleading. 

Is semantics really necessary? There should be an appropriate CPS and/or
certificate policy that may provide sufficiently information about
semantics. Is somebody on the mailing list who plans to implement
semantics?

> 
> So, this debate is about whether the countryName attribute in the subject
> field (the technical name)shall be mandatory or optional. 

I propose it should be OPTIONAL.

>Keep in mind that
> any country information as part of the legal name

I beg to differ. Legal identity rather than legal name. Definitely not
part of handwritten signature.

> can be handled in the
> PersonalData field regardless of what is done in the subject field.
> 
> This gives the conclusion that what we decide in the subject field (as
> mandatory or not), should only be based on technical requirements from
> X.500 directory systems and similar, not from requirements on legal name
> forming.
> 
> Based on this presumption I would appreciate a consensus in this subject.
> 
> /Stefan

Jürgen

> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. [phone]
> 216 42  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------

--