RE: Minor confusion in PKIX part 1, section 7.3.3

[Al Arsenault <[e-mail]>]

Santosh,

	You are correct - in my haste, I missed the statement two paragraphs above
the one being discussed, which is:

		The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred to as p, q, and g. 
		When omitted, the parameters component shall be omitted entirely. That
is, the AlgorithmIdentifier shall be a SEQUENCE 
		of one component - the OBJECT IDENTIFIER id-dsa.

	Thus, the NULL value is not permitted in this field of PKIX-compliant
certificates.  Given that, I agree that the sentence about "distributed by
other means" should be dropped.

			Al Arsenault




At 02:35 PM 11/30/98 -0500, Santosh Chokhani wrote:
>Al:
>
>I think whether the parameter value of NULL is valid is driven by the
>Algorithm OID registration.  For example, RSA algorithm OIDs registered
>would have NULL parameter value.
>
>Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
>parameters.  But, it is recommended only for the algorithm OID in the
>issuer signature and SIGNED MACRO fields.
>
>I think the point regarding the NULL is not germane to this discussion.
>
>> -----Original Message-----
>> From:	Al Arsenault [SMTP:[e-mail]]
>> Sent:	Tuesday, December 01, 1998 2:00 AM
>> To:	Grall, Cynthia; 'Santosh Chokhani'; 'Russ Housley'
>> Cc:	[e-mail]; [e-mail]
>> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> 
>> If I recall correctly, this paragraph is actually trying to address
>> the
>> fact that the parameters field is optional, and even if it's there, it
>> might be NULL.  The relevant wording is:
>> 
>> > If the DSA algorithm parameters are absent 
>> > from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
>> 
>> > the subject certificate using a signature algorithm other than DSA, 
>> > then  the subject's DSA parameters are distributed by other means.
>> If 
>> > the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
>> > parameters component and the CA signed the subject with a signature 
>> > algorithm other than DSA, then clients shall reject the certificate.
>> 
>> > 
>> 
>> 
>> This is poorly worded, I admit, but it tries to address two different
>> cases:
>> 
>> 	case 1:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
>> end-entity need not reject the certificate, but it has to get the
>> parameter
>> values from some place other than the certificate.
>> 
>> 	case 2:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no
>> field.
>>  In this case, the end-entity has to reject the certificate.
>> 
>> (There was actually a long discussion in the S/MIME WG in Chicago
>> about
>> whether this field should be there and be set to NULL, or left out
>> altogether. You can see the S/MIME meeting minutes/mailing list for
>> all the
>> gory details.)
>> 
>> Before figuring out the wording that would make this clearer, the
>> important
>> question is:  is this correct?  That is, should the actions be
>> different in
>> these 2 cases (including the field & setting it to NULL, and omitting
>> the
>> field altogether), or should they be the same?  If they're the same,
>> which
>> should they be - reject the cert, or go get the parameters from
>> somewhere else?
>> 
>> In my opinion, the proper action in both cases is to look for the
>> parameter
>> values first, before rejecting the certificate, but that's just a
>> personal
>> preference.  Other opinions are welcome (and I'm confident they'll
>> come :-)  
>> 
>> 			Al Arsenault
>> 
>> 
>> 
>> 
>> At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
>> >I agree.  If the intent is to disgard a subject certificate if the
>> DSA
>> >param's are not present AND the CA used a signature algorithm other
>> than
>> >DSA, then this sentence (especially the phrase "distributed by other
>> means")
>> >is confusing.  To me it directly contradicts the next sentence which
>> states
>> >"...then clients shall reject the certificate."
>> >
>> >Cindy
>> >-------------
>> >Cindy Grall
>> >Network Associates, Inc.                    [e-mail]
>> >3415 s. Sepulvida Blvd. suite 700       phone: [phone]
>> >Los Angeles, CA 90034                       fax: [phone]
>> >
>> >> -----Original Message-----
>> >> From:	Santosh Chokhani [SMTP:[e-mail]]
>> >> Sent:	Monday, November 30, 1998 7:15 AM
>> >> To:	'Russ Housley'; [e-mail]
>> >> Cc:	[e-mail]; [e-mail]
>> >> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> >> 
>> >> Russ and Tim Polk:
>> >> 
>> >> I think the following sentence is confusing and may mislead:
>> >> 
>> >> 	"If the DSA  algorithm parameters are absent from the
>> >> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>> subject
>> >> certificate using a signature algorithm other than DSA, then the
>> >> subject's DSA parameters are distributed by other means." 
>> >> 
>> >> It does not seem to lead to any processing requirements.  Thus, I
>> >> suggest we delete it from PKIX part 1.
>> >> 
>> >> 
>> >> 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18722 for ietf-pkix-bks; Mon, 30 Nov 1998 12:03:46 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18718 for <[e-mail]>; Mon, 30 Nov 1998 12:03:45 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id PAA07957; Mon, 30 Nov 1998 15:08:30 -0500
Message-Id: <4.1.19981201030259.00a5f700@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 03:06:49 -0500
To: Santosh Chokhani <[e-mail]>, "Grall, Cynthia" <[e-mail]>, "'Russ Housley'" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E23D875@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Santosh,

	You are correct - in my haste, I missed the statement two paragraphs above
the one being discussed, which is:

		The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred to as p, q, and g. 
		When omitted, the parameters component shall be omitted entirely. That
is, the AlgorithmIdentifier shall be a SEQUENCE 
		of one component - the OBJECT IDENTIFIER id-dsa.

	Thus, the NULL value is not permitted in this field of PKIX-compliant
certificates.  Given that, I agree that the sentence about "distributed by
other means" should be dropped.

			Al Arsenault




At 02:35 PM 11/30/98 -0500, Santosh Chokhani wrote:
>Al:
>
>I think whether the parameter value of NULL is valid is driven by the
>Algorithm OID registration.  For example, RSA algorithm OIDs registered
>would have NULL parameter value.
>
>Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
>parameters.  But, it is recommended only for the algorithm OID in the
>issuer signature and SIGNED MACRO fields.
>
>I think the point regarding the NULL is not germane to this discussion.
>
>> -----Original Message-----
>> From:	Al Arsenault [SMTP:[e-mail]]
>> Sent:	Tuesday, December 01, 1998 2:00 AM
>> To:	Grall, Cynthia; 'Santosh Chokhani'; 'Russ Housley'
>> Cc:	[e-mail]; [e-mail]
>> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> 
>> If I recall correctly, this paragraph is actually trying to address
>> the
>> fact that the parameters field is optional, and even if it's there, it
>> might be NULL.  The relevant wording is:
>> 
>> > If the DSA algorithm parameters are absent 
>> > from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
>> 
>> > the subject certificate using a signature algorithm other than DSA, 
>> > then  the subject's DSA parameters are distributed by other means.
>> If 
>> > the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
>> > parameters component and the CA signed the subject with a signature 
>> > algorithm other than DSA, then clients shall reject the certificate.
>> 
>> > 
>> 
>> 
>> This is poorly worded, I admit, but it tries to address two different
>> cases:
>> 
>> 	case 1:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
>> end-entity need not reject the certificate, but it has to get the
>> parameter
>> values from some place other than the certificate.
>> 
>> 	case 2:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no
>> field.
>>  In this case, the end-entity has to reject the certificate.
>> 
>> (There was actually a long discussion in the S/MIME WG in Chicago
>> about
>> whether this field should be there and be set to NULL, or left out
>> altogether. You can see the S/MIME meeting minutes/mailing list for
>> all the
>> gory details.)
>> 
>> Before figuring out the wording that would make this clearer, the
>> important
>> question is:  is this correct?  That is, should the actions be
>> different in
>> these 2 cases (including the field & setting it to NULL, and omitting
>> the
>> field altogether), or should they be the same?  If they're the same,
>> which
>> should they be - reject the cert, or go get the parameters from
>> somewhere else?
>> 
>> In my opinion, the proper action in both cases is to look for the
>> parameter
>> values first, before rejecting the certificate, but that's just a
>> personal
>> preference.  Other opinions are welcome (and I'm confident they'll
>> come :-)  
>> 
>> 			Al Arsenault
>> 
>> 
>> 
>> 
>> At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
>> >I agree.  If the intent is to disgard a subject certificate if the
>> DSA
>> >param's are not present AND the CA used a signature algorithm other
>> than
>> >DSA, then this sentence (especially the phrase "distributed by other
>> means")
>> >is confusing.  To me it directly contradicts the next sentence which
>> states
>> >"...then clients shall reject the certificate."
>> >
>> >Cindy
>> >-------------
>> >Cindy Grall
>> >Network Associates, Inc.                    [e-mail]
>> >3415 s. Sepulvida Blvd. suite 700       phone: [phone]
>> >Los Angeles, CA 90034                       fax: [phone]
>> >
>> >> -----Original Message-----
>> >> From:	Santosh Chokhani [SMTP:[e-mail]]
>> >> Sent:	Monday, November 30, 1998 7:15 AM
>> >> To:	'Russ Housley'; [e-mail]
>> >> Cc:	[e-mail]; [e-mail]
>> >> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> >> 
>> >> Russ and Tim Polk:
>> >> 
>> >> I think the following sentence is confusing and may mislead:
>> >> 
>> >> 	"If the DSA  algorithm parameters are absent from the
>> >> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>> subject
>> >> certificate using a signature algorithm other than DSA, then the
>> >> subject's DSA parameters are distributed by other means." 
>> >> 
>> >> It does not seem to lead to any processing requirements.  Thus, I
>> >> suggest we delete it from PKIX part 1.
>> >> 
>> >> 
>> >> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18514 for ietf-pkix-bks; Mon, 30 Nov 1998 11:33:17 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18510 for <[e-mail]>; Mon, 30 Nov 1998 11:33:14 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HPK>; Mon, 30 Nov 1998 14:35:20 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D875@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, "Grall, Cynthia" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 14:35:18 -0500
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

Al:

I think whether the parameter value of NULL is valid is driven by the
Algorithm OID registration.  For example, RSA algorithm OIDs registered
would have NULL parameter value.

Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
parameters.  But, it is recommended only for the algorithm OID in the
issuer signature and SIGNED MACRO fields.

I think the point regarding the NULL is not germane to this discussion.

> -----Original Message-----
> From:	Al Arsenault [SMTP:[e-mail]]
> Sent:	Tuesday, December 01, 1998 2:00 AM
> To:	Grall, Cynthia; 'Santosh Chokhani'; 'Russ Housley'
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> If I recall correctly, this paragraph is actually trying to address
> the
> fact that the parameters field is optional, and even if it's there, it
> might be NULL.  The relevant wording is:
> 
> > If the DSA algorithm parameters are absent 
> > from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> 
> > the subject certificate using a signature algorithm other than DSA, 
> > then  the subject's DSA parameters are distributed by other means.
> If 
> > the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> > parameters component and the CA signed the subject with a signature 
> > algorithm other than DSA, then clients shall reject the certificate.
> 
> > 
> 
> 
> This is poorly worded, I admit, but it tries to address two different
> cases:
> 
> 	case 1:  the CA used an algorithm other than DSA, the end-entity
> cert has
> a DSA key, and the parameters component of the subjectPublicKeyInfo
> AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
> end-entity need not reject the certificate, but it has to get the
> parameter
> values from some place other than the certificate.
> 
> 	case 2:  the CA used an algorithm other than DSA, the end-entity
> cert has
> a DSA key, and the parameters component of the subjectPublicKeyInfo
> AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no
> field.
>  In this case, the end-entity has to reject the certificate.
> 
> (There was actually a long discussion in the S/MIME WG in Chicago
> about
> whether this field should be there and be set to NULL, or left out
> altogether. You can see the S/MIME meeting minutes/mailing list for
> all the
> gory details.)
> 
> Before figuring out the wording that would make this clearer, the
> important
> question is:  is this correct?  That is, should the actions be
> different in
> these 2 cases (including the field & setting it to NULL, and omitting
> the
> field altogether), or should they be the same?  If they're the same,
> which
> should they be - reject the cert, or go get the parameters from
> somewhere else?
> 
> In my opinion, the proper action in both cases is to look for the
> parameter
> values first, before rejecting the certificate, but that's just a
> personal
> preference.  Other opinions are welcome (and I'm confident they'll
> come :-)  
> 
> 			Al Arsenault
> 
> 
> 
> 
> At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
> >I agree.  If the intent is to disgard a subject certificate if the
> DSA
> >param's are not present AND the CA used a signature algorithm other
> than
> >DSA, then this sentence (especially the phrase "distributed by other
> means")
> >is confusing.  To me it directly contradicts the next sentence which
> states
> >"...then clients shall reject the certificate."
> >
> >Cindy
> >-------------
> >Cindy Grall
> >Network Associates, Inc.                    [e-mail]
> >3415 s. Sepulvida Blvd. suite 700       phone: [phone]
> >Los Angeles, CA 90034                       fax: [phone]
> >
> >> -----Original Message-----
> >> From:	Santosh Chokhani [SMTP:[e-mail]]
> >> Sent:	Monday, November 30, 1998 7:15 AM
> >> To:	'Russ Housley'; [e-mail]
> >> Cc:	[e-mail]; [e-mail]
> >> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> >> 
> >> Russ and Tim Polk:
> >> 
> >> I think the following sentence is confusing and may mislead:
> >> 
> >> 	"If the DSA  algorithm parameters are absent from the
> >> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
> subject
> >> certificate using a signature algorithm other than DSA, then the
> >> subject's DSA parameters are distributed by other means." 
> >> 
> >> It does not seem to lead to any processing requirements.  Thus, I
> >> suggest we delete it from PKIX part 1.
> >> 
> >> 
> >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18185 for ietf-pkix-bks; Mon, 30 Nov 1998 10:57:08 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18181 for <[e-mail]>; Mon, 30 Nov 1998 10:57:06 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA05029; Mon, 30 Nov 1998 14:01:37 -0500
Message-Id: <4.1.19981201014809.00a67610@209.172.119.98>
X-Sender: aarsenault#207.212.34.30@209.172.119.98
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 02:00:21 -0500
To: "Grall, Cynthia" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

If I recall correctly, this paragraph is actually trying to address the
fact that the parameters field is optional, and even if it's there, it
might be NULL.  The relevant wording is:

> If the DSA algorithm parameters are absent 
> from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 
> the subject certificate using a signature algorithm other than DSA, 
> then  the subject's DSA parameters are distributed by other means. If 
> the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> parameters component and the CA signed the subject with a signature 
> algorithm other than DSA, then clients shall reject the certificate. 
> 


This is poorly worded, I admit, but it tries to address two different cases:

	case 1:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
end-entity need not reject the certificate, but it has to get the parameter
values from some place other than the certificate.

	case 2:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no field.
 In this case, the end-entity has to reject the certificate.

(There was actually a long discussion in the S/MIME WG in Chicago about
whether this field should be there and be set to NULL, or left out
altogether. You can see the S/MIME meeting minutes/mailing list for all the
gory details.)

Before figuring out the wording that would make this clearer, the important
question is:  is this correct?  That is, should the actions be different in
these 2 cases (including the field & setting it to NULL, and omitting the
field altogether), or should they be the same?  If they're the same, which
should they be - reject the cert, or go get the parameters from somewhere else?

In my opinion, the proper action in both cases is to look for the parameter
values first, before rejecting the certificate, but that's just a personal
preference.  Other opinions are welcome (and I'm confident they'll come :-)  

			Al Arsenault




At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
>I agree.  If the intent is to disgard a subject certificate if the DSA
>param's are not present AND the CA used a signature algorithm other than
>DSA, then this sentence (especially the phrase "distributed by other means")
>is confusing.  To me it directly contradicts the next sentence which states
>"...then clients shall reject the certificate."
>
>Cindy
>-------------
>Cindy Grall
>Network Associates, Inc.                    [e-mail]
>3415 s. Sepulvida Blvd. suite 700       phone: [phone]
>Los Angeles, CA 90034                       fax: [phone]
>
>> -----Original Message-----
>> From:	Santosh Chokhani [SMTP:[e-mail]]
>> Sent:	Monday, November 30, 1998 7:15 AM
>> To:	'Russ Housley'; [e-mail]
>> Cc:	[e-mail]; [e-mail]
>> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> 
>> Russ and Tim Polk:
>> 
>> I think the following sentence is confusing and may mislead:
>> 
>> 	"If the DSA  algorithm parameters are absent from the
>> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
>> certificate using a signature algorithm other than DSA, then the
>> subject's DSA parameters are distributed by other means." 
>> 
>> It does not seem to lead to any processing requirements.  Thus, I
>> suggest we delete it from PKIX part 1.
>> 
>> 
>> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16685 for ietf-pkix-bks; Mon, 30 Nov 1998 07:42:32 -0800 (PST)
Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16680 for <[e-mail]>; Mon, 30 Nov 1998 07:42:28 -0800 (PST)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id KAA23880; Mon, 30 Nov 1998 10:47:05 -0500 (EST)
Received: by world.std.com (TheWorld/Spike-2.0) id AA04125; Mon, 30 Nov 1998 10:47:04 -0500
Message-Id: <[e-mail]>
To: Carlisle Adams <[e-mail]>
Cc: [e-mail]
Subject: Re: generation of private keys 
In-Reply-To: Your message of "Fri, 27 Nov 1998 12:46:26 EST." <[e-mail]> 
Date: Mon, 30 Nov 1998 10:47:03 -0500
From: Dan Geer <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    > What could have happened in the past couple of years to cause you
    > to alter your view so radically?
    
"Do I contradict myself?
Very well then....I contradict myself;
I am large....I contain multitudes."
       --Walt Whitman

As to the point about marking who generated the keys,
either it has to be a falsifiable hypothesis or it has
to carry warranty of/by the CA.  Since there is no way
to make the hypothesis falsifiable and since the CA is
in the random warranty business anyway (or the RA is,
small difference), then this is the CA's opinion and
either it stands behind it (warranty) or it does not.
I certainly wouldn't treat it as a hint -- who the 
hell would take a hint on something as crucial as 
whether this set of keys was gen'd by XYZ?  Of course,
whether gen'd on the up-and-up or not, incompetently
escrowed trumps competently gen'd any day.

Bottom line:
one bit answer to _CA_takes_responsibility_for_key_gen?_

contradictorily speaking,

--dan



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16667 for ietf-pkix-bks; Mon, 30 Nov 1998 07:40:52 -0800 (PST)
Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16663 for <[e-mail]>; Mon, 30 Nov 1998 07:40:51 -0800 (PST)
Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2232.9) id <WY0KLH76>; Mon, 30 Nov 1998 07:40:38 -0800
Message-ID: <[e-mail]>
From: "Grall, Cynthia" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, "Grall, Cynthia" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 07:49:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.  If the intent is to disgard a subject certificate if the DSA
param's are not present AND the CA used a signature algorithm other than
DSA, then this sentence (especially the phrase "distributed by other means")
is confusing.  To me it directly contradicts the next sentence which states
"...then clients shall reject the certificate."

Cindy
-------------
Cindy Grall
Network Associates, Inc.                    [e-mail]
3415 s. Sepulvida Blvd. suite 700       phone: [phone]
Los Angeles, CA 90034                       fax: [phone]

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[e-mail]]
> Sent:	Monday, November 30, 1998 7:15 AM
> To:	'Russ Housley'; [e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> Russ and Tim Polk:
> 
> I think the following sentence is confusing and may mislead:
> 
> 	"If the DSA  algorithm parameters are absent from the
> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
> certificate using a signature algorithm other than DSA, then the
> subject's DSA parameters are distributed by other means." 
> 
> It does not seem to lead to any processing requirements.  Thus, I
> suggest we delete it from PKIX part 1.
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16457 for ietf-pkix-bks; Mon, 30 Nov 1998 07:12:53 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16453 for <[e-mail]>; Mon, 30 Nov 1998 07:12:51 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HJC>; Mon, 30 Nov 1998 10:15:00 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D86C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 10:14:57 -0500
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

Russ and Tim Polk:

I think the following sentence is confusing and may mislead:

	"If the DSA  algorithm parameters are absent from the
subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
certificate using a signature algorithm other than DSA, then the
subject's DSA parameters are distributed by other means." 

It does not seem to lead to any processing requirements.  Thus, I
suggest we delete it from PKIX part 1.


> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Monday, November 30, 1998 9:45 AM
> To:	[e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> Cindy:
> 
> This is trying to explain parameter inheritance.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using
> DSA,
> the CA's parameters are inherited by the issued certificate.  This is
> done
> to reduce the size of the certificate.  The parameters are more than
> twice
> the size of the public key, so to reduce the number of certificates
> that
> include them.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using an
> algorithm other than DSA, the CA's parameters cannot be inherited.  To
> avoid this situaltion, the parameters should be put in the
> certificate.  If
> they are not in the certificate, it should be rejected.
> 
> Russ
> 
> 
> > The following paragraph seems to have two conflicting sentences:
> > 
> > 7.3.3  DSA Signature Keys
> > 
> > ...
> > 
> >    If the DSA algorithm parameters are absent from the
> subjectPublicKey-
> >    Info AlgorithmIdentifier and the CA signed the subject
> certificate
> >    using DSA, then the certificate issuer's DSA parameters apply to
> the
> >    subject's DSA key.  If the DSA algorithm parameters are absent
> from
> >    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> the
> >    subject certificate using a signature algorithm other than DSA,
> then
> >    the subject's DSA parameters are distributed by other means.  If
> the
> >    subjectPublicKeyInfo AlgorithmIdentifier field omits the
> parameters
> >    component and the CA signed the subject with a signature
> algorithm
> >    other than DSA, then clients shall reject the certificate.
> > 
> > I understand the second sentence to mean if the CA cert. has a (for
> > example) RSA key, and the EE cert. has a DSA key with no parameters,
> > then the EE cert. is okay and I have to find the parameters
> somewhere
> > else.  
> > 
> > The third sentence says if the CA cert. has (for example) a RSA key,
> > and the EE cert. has a DSA key with no parameters, then I should
> reject
> > the EE cert.
> > 
> > Is there something I'm missing here?  If these do conflict, which is
> the
> > correct statement?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16249 for ietf-pkix-bks; Mon, 30 Nov 1998 06:39:49 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16245 for <[e-mail]>; Mon, 30 Nov 1998 06:39:48 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA25910; Mon, 30 Nov 1998 09:44:36 -0500
Message-Id: <4.1.19981130092904.0098f320@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 30 Nov 1998 09:45:29 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E23D867@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Cindy:

This is trying to explain parameter inheritance.

When the DSA algorithm parameters are absent from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using DSA,
the CA's parameters are inherited by the issued certificate.  This is done
to reduce the size of the certificate.  The parameters are more than twice
the size of the public key, so to reduce the number of certificates that
include them.

When the DSA algorithm parameters are absent from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using an
algorithm other than DSA, the CA's parameters cannot be inherited.  To
avoid this situaltion, the parameters should be put in the certificate.  If
they are not in the certificate, it should be rejected.

Russ


> The following paragraph seems to have two conflicting sentences:
> 
> 7.3.3  DSA Signature Keys
> 
> ...
> 
>    If the DSA algorithm parameters are absent from the subjectPublicKey-
>    Info AlgorithmIdentifier and the CA signed the subject certificate
>    using DSA, then the certificate issuer's DSA parameters apply to the
>    subject's DSA key.  If the DSA algorithm parameters are absent from
>    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>    subject certificate using a signature algorithm other than DSA, then
>    the subject's DSA parameters are distributed by other means.  If the
>    subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters
>    component and the CA signed the subject with a signature algorithm
>    other than DSA, then clients shall reject the certificate.
> 
> I understand the second sentence to mean if the CA cert. has a (for
> example) RSA key, and the EE cert. has a DSA key with no parameters,
> then the EE cert. is okay and I have to find the parameters somewhere
> else.  
> 
> The third sentence says if the CA cert. has (for example) a RSA key,
> and the EE cert. has a DSA key with no parameters, then I should reject
> the EE cert.
> 
> Is there something I'm missing here?  If these do conflict, which is the
> correct statement?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA02028 for ietf-pkix-bks; Sun, 29 Nov 1998 00:42:36 -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 AAA02010 for <[e-mail]>; Sun, 29 Nov 1998 00:39:39 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id AAA24812; Sun, 29 Nov 1998 00:41:18 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id AAA29918; Sun, 29 Nov 1998 00:42:56 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLAXVF>; Sun, 29 Nov 1998 00:42:57 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Sun, 29 Nov 1998 00:42:49 -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

Carlisle:

Thanks for pointing this out. When the book is revised, I'll ensure that
that passage is reworded to address the other options that are now apparent.

Warwick

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:46 AM
To: 'Warwick Ford'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi Warwick,

A couple of quotes (from W. Ford, "Computer Communications Security:
Principles, Standard Protocols and Techniques", pp.97-98):

"To minimize vulnerabilities, the key generation process is best carried out
either within the owner system or within the certification authority system,
thereby necessitating only one protected key transfer."

"If keys are generated with the certification authority system, transfer of
the private key to the owner system will require both integrity and
confidentiality protection.  In either case, if key archiving is required,
reliable copies of both keys will need to be sent to an archiving system
(which may be co-located with the certification authority system)..."

Not a word about "highly undesirable", "questionable security practice", or
"might be O.K., subject to complete risk analysis".  What could have
happened in the past couple of years to cause you to alter your view so
radically?


In any case, we are in full agreement that all options should be left open
(in order to suit the needs of all environments).  I'm not sure what
"technical protocol" you're referring to below, since Stefan's suggestion
was simply to add an extension to a Certificate, but an enumeration rather
than a Boolean is perfectly fine with me.

Carlisle.


-----Original Message-----
From: Warwick Ford [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:29 AM
To: 'Carlisle Adams'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11118 for ietf-pkix-bks; Fri, 27 Nov 1998 13:38:10 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11114 for <[e-mail]>; Fri, 27 Nov 1998 13:38:06 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HAR>; Fri, 27 Nov 1998 16:40:43 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D867@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Grall, Cynthia'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Fri, 27 Nov 1998 16:40:43 -0500
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

Cindy:

You are correct that the two sentences are contradictory.  The safer
thing to do is to reject the certificate since with the X.509
authentication framework and certificate path there is no guarantee as
to what the parameters are.  Thus, the first sentence should be deleted
from PKIX Part 1.

May be the editors of PKIX Part 1 can shed some light on it also.

> -----Original Message-----
> From:	Grall, Cynthia [SMTP:[e-mail]]
> Sent:	Tuesday, November 24, 1998 11:43 AM
> To:	'[e-mail]'
> Subject:	FW: Minor confusion in PKIX part 1, section 7.3.3
> 
> 
> > The following paragraph seems to have two conflicting sentences:
> > 
> > 7.3.3  DSA Signature Keys
> > 
> > ...
> > 
> >    If the DSA algorithm parameters are absent from the
> subjectPublicKey-
> >    Info AlgorithmIdentifier and the CA signed the subject
> certificate
> >    using DSA, then the certificate issuer's DSA parameters apply to
> the
> >    subject's DSA key.  If the DSA algorithm parameters are absent
> from
> >    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> the
> >    subject certificate using a signature algorithm other than DSA,
> then
> >    the subject's DSA parameters are distributed by other means.  If
> the
> >    subjectPublicKeyInfo AlgorithmIdentifier field omits the
> parameters
> >    component and the CA signed the subject with a signature
> algorithm
> >    other than DSA, then clients shall reject the certificate.
> > 
> > I understand the second sentence to mean if the CA cert. has a (for
> > example) RSA key, and the EE cert. has a DSA key with no parameters,
> > then the EE cert. is okay and I have to find the parameters
> somewhere
> > else.  
> > 
> > The third sentence says if the CA cert. has (for example) a RSA key,
> > and the EE cert. has a DSA key with no parameters, then I should
> reject
> > the EE cert.
> > 
> > Is there something I'm missing here?  If these do conflict, which is
> the
> > correct statement?
> > 
> > Cindy
> > ----------
> > Cindy Grall                       [e-mail]
> > Network Associates, Inc.          phone: [phone]
> > 3415 S. Sepulvida Blvd.           fax:   [phone]
> > Los Angeles, California 90034


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA10070 for ietf-pkix-bks; Fri, 27 Nov 1998 09:49:40 -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 JAA10066 for <[e-mail]>; Fri, 27 Nov 1998 09:49:38 -0800 (PST)
Received: 	id MAA29461; Fri, 27 Nov 1998 12:51:16 -0500
Received: by gateway id <XNGHBSNR>; Fri, 27 Nov 1998 12:46:28 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Warwick Ford'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Fri, 27 Nov 1998 12:46:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Warwick,

A couple of quotes (from W. Ford, "Computer Communications Security:
Principles, Standard Protocols and Techniques", pp.97-98):

"To minimize vulnerabilities, the key generation process is best carried out
either within the owner system or within the certification authority system,
thereby necessitating only one protected key transfer."

"If keys are generated with the certification authority system, transfer of
the private key to the owner system will require both integrity and
confidentiality protection.  In either case, if key archiving is required,
reliable copies of both keys will need to be sent to an archiving system
(which may be co-located with the certification authority system)..."

Not a word about "highly undesirable", "questionable security practice", or
"might be O.K., subject to complete risk analysis".  What could have
happened in the past couple of years to cause you to alter your view so
radically?


In any case, we are in full agreement that all options should be left open
(in order to suit the needs of all environments).  I'm not sure what
"technical protocol" you're referring to below, since Stefan's suggestion
was simply to add an extension to a Certificate, but an enumeration rather
than a Boolean is perfectly fine with me.

Carlisle.


-----Original Message-----
From: Warwick Ford [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:29 AM
To: 'Carlisle Adams'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA08453 for ietf-pkix-bks; Fri, 27 Nov 1998 06:25:14 -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 GAA08449 for <[e-mail]>; Fri, 27 Nov 1998 06:25:13 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA07797; Fri, 27 Nov 1998 06:26:49 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id GAA04101; Fri, 27 Nov 1998 06:29:19 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLAWQ6>; Fri, 27 Nov 1998 06:29:21 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Fri, 27 Nov 1998 06:29: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

Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.

Warwick


-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 3:11 PM
To: 'Warwick Ford'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi Warwick,

:-----Original Message-----
:From: Warwick Ford [mailto:[e-mail]]
:Sent: Wednesday, November 25, 1998 9:36 AM
:To: '[e-mail]'; [e-mail]; [e-mail]
:Subject: RE: generation of private keys
:
:I think the case of a CA generating key pairs is the least 
:interesting of
:all.  Generally, for security separation purposes, it is 
:considered highly
:undesirable for a CA to generate user key pairs.  


The above sentence should probably be clarified because it is misleading as
it stands (which I'm sure was not your intention).  I prefer "Generally, for
security separation purposes, it is considered highly undesirable for a CA
to generate user key pairs when the CA is at 'arm's length' from the user.",
or something similar.  In particular, a CA that is external to an
organization (e.g., a CA service provider) may have nothing in its CPS
discussing such functionality and may take no legal responsibility for user
key pair generation.  This is a case where separation of duties makes sense.

However, for other environments the CA, the RA, and the key generation
facility may effectively be the same entity within an organization.
Separation of duties need not be required in such cases and there is no
reason for it to be "undesirable" for this entity to perform both key
generation and CA functions.


:Having the key pair
:generated by an RA or another "authority" devoted to key 
:management, maybe
:within the same enterprise, are better.  


Absolutely.  "Better" if the CA is outside the enterprise.  Not necessarily
"better" for any inherent reason if the CA is within the enterprise.


:In the case of an RA or other
:authority, there is generally an established trust 
:relationship between the
:CA and that entity, supported, for example, by their inherent 
:organizational
:relationship or by a contractual relationship, plus trusted 
:communications
:paths.  Hence, it is likely quite reasonable for a CA to have 
:confidence
:that, when an RA or key management authority says it generated 
:a particular
:key pair, it did, in fact, generate that key pair.
:
:Warwick


Does this, then, argue for Stefan's original suggestion of an extension
specifying the location of key generation?  Do you think that because of
such relationships, trusted communications paths, etc., the CA can have
sufficient confidence in the location to encode it into a certificate and
stand by it in a legal sense?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02403 for ietf-pkix-bks; Thu, 26 Nov 1998 21:43:51 -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 VAA02399 for <[e-mail]>; Thu, 26 Nov 1998 21:43:47 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2QJBW>; Fri, 27 Nov 1998 16:47:03 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A67@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: [e-mail]
Subject: RE: some comments on OCSP vs 7
Date: Fri, 27 Nov 1998 16:47:00 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

If the purpose of this RFP is to quickly find / identify a specific
certificate and its status, rather than trawl through CRLs, then it
seems to me that that rather than adding additional protocol and trust
management to validate certificates, that some of this could be moved
back into the CA and directories, as follows: -

*  When a certificate is revoked, put a CRL style wrapper around the
individual certificate (rather than just its Issuer & Serial), with
Revocation DateTime, Reason Codes etc and the CA signs it, to create a
RevokedCertificateObject
 
*  This RevokedCertificateObject can be stored into a nominated arc of a
DIT along with all other revokedcertificatesobjects

*  I would tend to add additional attributes into the directory's
representation of this object, to improve searchability i.e. SubjectDn,
Validity Date / Time,    MD5 Hash Fingerprint), KeyUsage periods etc as
this is a simpler alternative than implementing certificate matching
rules on the server and helps with reporting / summarisation.

The benefits of the approach are as follows: -

* Existing LDAP / DAP protocols can be used for queries

* Existing directory functions are used to quickly retrieve an object.
If its not found, its not revoked, if its   found the reason codes and
CA signature are readily accessible as part of the object.  Matching on
the client side is easy because you retrieve a copy of the certficate
and can do a compare, as well as all validations.

* Backend DISP / DSP are available for shadowing and distributed queries
is possible, respectively, although I would probably use something with
more guaranteed service than DISP.

* The CA's private key does not need to be available to a Responder
task.  Signing of revoked certificates is a behind the scenes / trusted
function.

* The complexity of Designated Responder key management is avoided

* Online real-time certificate validity checking is available through
online real-time directory support, without needing to invent a new
protocol.

* The user receives an object of real value, because they could archive
/ keep it for proof of revocation, without requiring the whole list.

CRLs have their place as a list of revoked certs and are good for the
process of batch distrubution, but I have always felt that they do not
make for
good online / realtime retrieval purposes.

Directories are pretty fast and reliable now, so we should leverage
their capabilities by adding to information models over existing
protocols.

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15756 for ietf-pkix-bks; Wed, 25 Nov 1998 15:28:09 -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 PAA15752 for <[e-mail]>; Wed, 25 Nov 1998 15:28:08 -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 PAA13698 for <[e-mail]>; Wed, 25 Nov 1998 15:32:32 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 25 Nov 1998 15:31:21 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: generation of private keys
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:57 AM 11/25/98 +0100, you wrote:
>Tony,
>
>> >Interesting question.  My initial reaction is to wonder if a new certificate
>> >extension is really the right solution for this.  If the CA generates the
>> >key pair, it can certainly populate such an extension with confidence.
>> >However, if the CA did not generate the key pair, how will it distinguish
>> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
>> >the actual key pair generation so that it can populate the extension)?
>> >
>> >Carlisle.
>>
>> It seems the most a CA could do is indicate either that it did, or did not
>> generate the keypair, correct?
>
>You're probably right. So it comes down to a boolean indicator. Do you agree
>that such an indicator would be a useful enhancement?
>
>If we don't use an extension, what other means would we have to indicate
>the key generation location?
>
>Cheers,
>
>        Stefan.

Stefan,

Beign unfamiliar with the German Dig-Sig Law, it is hard to say.
I can see no harm from such an extension.  In the case where "law"
requires that "key-gen-authorhood" be positively identified, this
would tend to make CA-key-generation somewhat mandatory, but then
law is law.

I was trying to think of some way that keys, (or simply random
numbers) could be generated in a way that each generator "inserts"
its ID into each number, while not affecting the randomness (i.e.,
predictability) in any significant way.

I'm still thinking...;)

___tony___


Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15629 for ietf-pkix-bks; Wed, 25 Nov 1998 15:14:30 -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 PAA15624 for <[e-mail]>; Wed, 25 Nov 1998 15:14:24 -0800 (PST)
Received: 	id SAA03629; Wed, 25 Nov 1998 18:15:29 -0500
Received: by gateway id <XNGHB3RD>; Wed, 25 Nov 1998 18:10:44 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Warwick Ford'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 18:10:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Warwick,

:-----Original Message-----
:From: Warwick Ford [mailto:[e-mail]]
:Sent: Wednesday, November 25, 1998 9:36 AM
:To: '[e-mail]'; [e-mail]; [e-mail]
:Subject: RE: generation of private keys
:
:I think the case of a CA generating key pairs is the least 
:interesting of
:all.  Generally, for security separation purposes, it is 
:considered highly
:undesirable for a CA to generate user key pairs.  


The above sentence should probably be clarified because it is misleading as
it stands (which I'm sure was not your intention).  I prefer "Generally, for
security separation purposes, it is considered highly undesirable for a CA
to generate user key pairs when the CA is at 'arm's length' from the user.",
or something similar.  In particular, a CA that is external to an
organization (e.g., a CA service provider) may have nothing in its CPS
discussing such functionality and may take no legal responsibility for user
key pair generation.  This is a case where separation of duties makes sense.

However, for other environments the CA, the RA, and the key generation
facility may effectively be the same entity within an organization.
Separation of duties need not be required in such cases and there is no
reason for it to be "undesirable" for this entity to perform both key
generation and CA functions.


:Having the key pair
:generated by an RA or another "authority" devoted to key 
:management, maybe
:within the same enterprise, are better.  


Absolutely.  "Better" if the CA is outside the enterprise.  Not necessarily
"better" for any inherent reason if the CA is within the enterprise.


:In the case of an RA or other
:authority, there is generally an established trust 
:relationship between the
:CA and that entity, supported, for example, by their inherent 
:organizational
:relationship or by a contractual relationship, plus trusted 
:communications
:paths.  Hence, it is likely quite reasonable for a CA to have 
:confidence
:that, when an RA or key management authority says it generated 
:a particular
:key pair, it did, in fact, generate that key pair.
:
:Warwick


Does this, then, argue for Stefan's original suggestion of an extension
specifying the location of key generation?  Do you think that because of
such relationships, trusted communications paths, etc., the CA can have
sufficient confidence in the location to encode it into a certificate and
stand by it in a legal sense?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15426 for ietf-pkix-bks; Wed, 25 Nov 1998 14:43:25 -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 OAA15422 for <[e-mail]>; Wed, 25 Nov 1998 14:43:22 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2Q2YH>; Thu, 26 Nov 1998 09:46:23 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A5F@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, Andrew Probert <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Time stamp request
Date: Thu, 26 Nov 1998 09:46:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I was thing thinking Notary when I wrote my comment, and a combined
standard for both purposed, thanks for clarifying the context.


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA09247 for ietf-pkix-bks; Wed, 25 Nov 1998 08:21:09 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA09243 for <[e-mail]>; Wed, 25 Nov 1998 08:21:08 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1G49>; Wed, 25 Nov 1998 11:23:16 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9114@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time stamp request
Date: Wed, 25 Nov 1998 11:23:15 -0500
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

We have built a TimeStamping Authority for a client of ours. This TSA
has been undergoing field trials and tests since June, 1998 and is now
relatively stable. I would like to share our experiences on the topic of
hash versus entire message.

We built the first version of our TSA by having the entire message sent
to the TSA. The TSA computed the hash of the message and created the
token and signed it. In looking at the problem more carefully, we
realized that sending the entire message has several drawbacks, e.g. the
bandwidth availability problem, and the liability problem for the TSA
since it now has a copy of the actual message, etc. In later versions of
our product, we are sending just the hash of the message to the TSA,
since it has all of the advantages, without many of the disadvantages,
of sending the entire message. 

In general, I would agree with Denis, Paul and Robert that there appears
to be no benefit to sending the entire message instead of an imprint of
the message. 

On the other hand, currently (in draft-ietf-pkix-time-stamp-00.txt), the
MessageImprint data structure seems to imply that only a cryptographic
hash of the message is permitted. However, it would be relatively easy
to accommodate other types of message imprints, including the actual
message (there is no better imprint of a message than the message
itself!!) and arithmetic checksums, etc. 

- Sarbari Gupta
=================================
Sarbari Gupta, PhD
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================
-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 9:33 AM
To: 'Denis Pinkas'; Carmen Garcia; 'Andrew Probert'
Cc: [e-mail]; [e-mail]
Subject: RE: Time stamp request


Andrew;

In your response to Denis you said:

> ----------
> From: 	Andrew Probert[SMTP:[e-mail]]
> Sent: 	Tuesday, November 24, 1998 5:53 PM
> To: 	'Denis Pinkas'; Carmen Garcia
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: 
> 
> This standard seems to be restricting capability based upon a
bandwidth
> assumption.  With the right business case, the bandwith may well be
> available?
> 
Actually, I don't think we are restricting capability based upon a
bandwidth
assumption.  I would like to draw your attention to something Denis
said.

> > Another advantage is that the TSA does not see the
> > content of the message and it cannot disclose the content to
anybody:
> > it places less trust in the TSA. For, at least,
> > theses reasons, the message itself is never sent to the TSA.
> 
And also to one of our assumptions in the TSA draft:

The TSA is required:
     3. not to examine the imprint being time stamped in any way. 

In order to distinguish between a Time Stamp Authority and a "notary"
(or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed
that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document
within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have
to
hash any message that is contained in the request, regardless of its
content
(because it cannot examine the message in any way) and place the
resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the
document.
This is not a problem, except for the fact that given just the document
and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used
to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was
unacceptable.
Therefore, we decided that the TSA would not create the message imprint,
the
requester would.  This allows the TSA to be totally unaware of what is
being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08089 for ietf-pkix-bks; Wed, 25 Nov 1998 07:04:38 -0800 (PST)
Received: from hq.ljl.COM (hq.ljl.com [206.151.234.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA08085 for <[e-mail]>; Wed, 25 Nov 1998 07:04:37 -0800 (PST)
Received: from larry.ljl.com by hq.ljl.COM. with smtp id aa09768; Wed, 25 Nov 1998 09:09:14 -0600
Received: by localhost with Microsoft MAPI; Wed, 25 Nov 1998 09:09:19 -0600
Message-ID: <[e-mail]>
From: Larry Layten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Kelm'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 09:09:18 -0600
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

It would seem to me that if an RA is certifying information to
be contained in a certificate, to be signed by a CA, that policy
could be implemented that would also allow it to certify that
it did in fact create the key-pairs -- or to take it further, to 
certify the strength of the token that the subject is using,
which also should be of interest.

Larry

-----Original Message-----
From:	Stefan Kelm [SMTP:[e-mail]]
Sent:	Wednesday, November 25, 1998 3:57 AM
To:	[e-mail]; [e-mail]
Cc:	[e-mail]
Subject:	RE: generation of private keys

Tony,

> >Interesting question.  My initial reaction is to wonder if a new certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07753 for ietf-pkix-bks; Wed, 25 Nov 1998 06:38:35 -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 GAA07748 for <[e-mail]>; Wed, 25 Nov 1998 06:38:32 -0800 (PST)
Received: 	id JAA20928; Wed, 25 Nov 1998 09:38:00 -0500
Received: by gateway id <XNGHBLPK>; Wed, 25 Nov 1998 09:33:15 -0500
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, "'Andrew Probert'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Time stamp request
Date: Wed, 25 Nov 1998 09:33:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Andrew;

In your response to Denis you said:

> ----------
> From: 	Andrew Probert[SMTP:[e-mail]]
> Sent: 	Tuesday, November 24, 1998 5:53 PM
> To: 	'Denis Pinkas'; Carmen Garcia
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: 
> 
> This standard seems to be restricting capability based upon a bandwidth
> assumption.  With the right business case, the bandwith may well be
> available?
> 
Actually, I don't think we are restricting capability based upon a bandwidth
assumption.  I would like to draw your attention to something Denis said.

> > Another advantage is that the TSA does not see the
> > content of the message and it cannot disclose the content to anybody:
> > it places less trust in the TSA. For, at least,
> > theses reasons, the message itself is never sent to the TSA.
> 
And also to one of our assumptions in the TSA draft:

The TSA is required:
     3. not to examine the imprint being time stamped in any way. 

In order to distinguish between a Time Stamp Authority and a "notary" (or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have to
hash any message that is contained in the request, regardless of its content
(because it cannot examine the message in any way) and place the resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the document.
This is not a problem, except for the fact that given just the document and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was unacceptable.
Therefore, we decided that the TSA would not create the message imprint, the
requester would.  This allows the TSA to be totally unaware of what is being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07691 for ietf-pkix-bks; Wed, 25 Nov 1998 06:32:54 -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 GAA07687 for <[e-mail]>; Wed, 25 Nov 1998 06:32:53 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA07147; Wed, 25 Nov 1998 06:33:39 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id GAA15214; Wed, 25 Nov 1998 06:36:08 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLATJR>; Wed, 25 Nov 1998 06:36:11 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 06:36:07 -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

I think the case of a CA generating key pairs is the least interesting of
all.  Generally, for security separation purposes, it is considered highly
undesirable for a CA to generate user key pairs.  Having the key pair
generated by an RA or another "authority" devoted to key management, maybe
within the same enterprise, are better.  In the case of an RA or other
authority, there is generally an established trust relationship between the
CA and that entity, supported, for example, by their inherent organizational
relationship or by a contractual relationship, plus trusted communications
paths.  Hence, it is likely quite reasonable for a CA to have confidence
that, when an RA or key management authority says it generated a particular
key pair, it did, in fact, generate that key pair.

Warwick

-----Original Message-----
From: Stefan Kelm [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 1:57 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: generation of private keys


Tony,

> >Interesting question.  My initial reaction is to wonder if a new
certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who
did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

____________________________________________________________________________
__
Stefan Kelm            PGP key: "finger [e-mail]" or via key
server
DFN-PCA, University of Hamburg
<[e-mail]>
Vogt-Koelln-Str. 30
http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]
2241


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07589 for ietf-pkix-bks; Wed, 25 Nov 1998 06:22:17 -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 GAA07585 for <[e-mail]>; Wed, 25 Nov 1998 06:22:16 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfran28365; Wed, 25 Nov 1998 09:25:29 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26455; Wed, 25 Nov 98 09:23:15 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA12732; Wed, 25 Nov 1998 09:25:27 -0500
Date: Wed, 25 Nov 1998 09:25:27 -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], [e-mail]
Subject: RE: 
References: <C13ABC20EDDAD111B29E0000B456EABC053A57@SPRINGFIELD>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Andrew" == Andrew Probert <[e-mail]> writes:

 Andrew> This standard seems to be restricting capability based upon a
 Andrew> bandwidth assumption.  With the right business case, the
 Andrew> bandwith may well be available?

 >> -----Original Message----- From: Denis Pinkas
 >> 
 >> > Hi all, > > We are involved in a time stamp project.  > > We
 >> need to send a request for a timestamp to the Time Stamping
 >> Authority including in the request itself alternatively the hash
 >> value of the data or the entire document. 

I don't see the bandwidth argument as the primary argument.  Instead,
it seems that the main arguments are (a) there is no benefit to
sending the whole message, (b) it introduces extra risks, and yes also 
(c) it consumes extra bandwidth.

Having an option to use the extra bandwidth would be fine if there
were some benefit, but I can see no benefit at all, only extra danger, 
so why do it?

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA28984 for ietf-pkix-bks; Wed, 25 Nov 1998 01:53:59 -0800 (PST)
Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA28980 for <[e-mail]>; Wed, 25 Nov 1998 01:53:57 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id KAA19473; Wed, 25 Nov 1998 10:57:20 +0100 (MET)
Date: Wed, 25 Nov 1998 10:57:20 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: generation of private keys
Cc: [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk

Tony,

> >Interesting question.  My initial reaction is to wonder if a new certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA23869 for ietf-pkix-bks; Tue, 24 Nov 1998 23:48:42 -0800 (PST)
Received: from mail.latinmail.com (smtp.latinmail.com [209.2.135.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA23863 for <[e-mail]>; Tue, 24 Nov 1998 23:48:41 -0800 (PST)
Message-Id: <[e-mail]>
Received: from latinmail.com [209.2.135.54] by mail.latinmail.com (SMTPD32-4.07) id A8152330150; Wed, 25 Nov 1998 02:56:05 EST
To: [e-mail]
From: Carmen Garcia <[e-mail]>
Date: Wed, 25 Nov 98 02:54:00 -0500
Subject: TimeStamp request
X-Mailer: LatinMail v3.0 -- http://www.latinmail.com
Sender: [e-mail]
Precedence: bulk

Hi all,

We are involved in a time stamp project. 
We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.

At this point we have two questions to propose you for discussion.

1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint OPTIONAL 
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message. If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way? 

Obviously the second point influences the format of the response described in the draft if we want
to receive in a unique response all the required timestamps.

Regards,

Carmen Garcia.

__________________________________________________
Carmen Garcia
Software Engineer
__________________________________________________






________________________________________________________
http://www.latinmail.com. Tu correo gratuito en español.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08946 for ietf-pkix-bks; Tue, 24 Nov 1998 14:50: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 OAA08941 for <[e-mail]>; Tue, 24 Nov 1998 14:50:43 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2Q24C>; Wed, 25 Nov 1998 09:53:16 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A57@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: 
Date: Wed, 25 Nov 1998 09:53:08 +1100
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 OAA08943
Sender: [e-mail]
Precedence: bulk

This standard seems to be restricting capability based upon a bandwidth
assumption.  With the right business case, the bandwith may well be
available?

Why not have the MessageImprint as a PKCS#7 construct, in that way you
could service many options.

1)   SignedData with empty content (detached signature) would meet
current requirement
2)   SignedData with content would meet your request
3)   EnvelopedData sent in for timestamping would allow encrypted
content i.e. solving trust issue in TSA
3)a Specific encoding of PKCS#7 => SMIME payloads

Regards

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[e-mail]]
> Sent:	Wednesday, November 25, 1998 1:11 PM
> To:	Carmen Garcia
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: 
> 
> > Hi all,
> >
> > We are involved in a time stamp project.
> >
> > We need to send a request for a timestamp to the Time Stamping
> Authority including in the request itself alternatively the hash value
> of the data or the entire document.
> > Further we could ask for more than one timestamp, thus we need to
> put, in the same request, the number of required timestamps that the
> TSA should give back.
> >
> > At this point we have two questions to propose you for discussion.
> >
> > 1. In the time stamping request described into the draft "Internet
> X.509 Public Key Infrastructure Time Stamp Protocols" (at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt
> )....
> >
> > TimeStampReq ::= SEQUENCE  {
> >      version                      Integer  { v1(0) },
> >      reqPolicy                    PolicyInformation OPTIONAL,
> >      tdas                         SEQUENCE OF GeneralName OPTIONAL,
> >      nonce                        Integer,
> >      messageImprint               MessageImprint OPTIONAL
> >        --a hash algorithm OID and the hash value of the data to be
> >        --time stamped
> > }
> >
> > ....there is no reference to the possibility to send the ENTIRE
> DOCUMENT to be timestamped, instead of  the hash of the message.
> 
> This choice was deliberate. It saves bandwith, e.g. if the message is
> 2 Mbytes long, you do not send the whole message to the TSA, but only
> the imprint (160 or 128 bits). It also allows better performance for
> the Time Stamping server (responding to short messages improves
> performance). Another advantage is that the TSA does not see the
> content of the message and it cannot disclose the content to anybody:
> it places less trust in the TSA. For, at least,
> theses reasons, the message itself is never sent to the TSA.
> 
> > If we want to have the possibility to send the whole document into
> the request, how can be done? Can we include into the request another
> optional field in order to send the whole document? What kind of
> interoperability implications with others implementations could occur?
> Is this one the right way or are there other solutions?
> 
> See above.
> 
> > 2. As above, there is no a specific field to hold the NUMBER OF
> REQUESTED TIMESTAMPS. Can we work in the same way?
> >
> 
> You can send multiple such elementary requests in a single message:
> the transport layer is not mandated.
> 
> Regards,
> 
> Denis
> 
> 
> > Obviously the second point influences the format of the response
> described in the draft if we want
> > to receive in a unique response all the required timestamps.
> >
> > Regards,
> >
> > Carmen Garcia.
> >
> > _____________________________________________
> > Carmen Garcia
> > Software Engineer
> > _____________________________________________
> >
> > ________________________________________________________
> > http://www.latinmail.com. Tu correo gratuito en español.
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08541 for ietf-pkix-bks; Tue, 24 Nov 1998 13:53:16 -0800 (PST)
Received: from yafa.alquds.org (alquds.org [208.162.200.234] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08537 for <[e-mail]>; Tue, 24 Nov 1998 13:53:13 -0800 (PST)
Received: from localhost (adel@localhost) by yafa.alquds.org (8.8.5/8.8.5) with SMTP id PAA14398; Tue, 24 Nov 1998 15:42:01 -0600 (CST)
Date: Tue, 24 Nov 1998 15:42:00 -0600 (CST)
From: Adel Jaber <[e-mail]>
To: Adel Jaber <[e-mail]>
cc: [e-mail]
Subject: DSA Source Code
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Trying to obtain the source code for the DSA algorithm.

Will appreciate any pointers.

Regards

Adel Jaber



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08325 for ietf-pkix-bks; Tue, 24 Nov 1998 13:22:16 -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 NAA08320 for <[e-mail]>; Tue, 24 Nov 1998 13:22:15 -0800 (PST)
Received: 	id QAA27147; Tue, 24 Nov 1998 16:20:03 -0500
Received: by gateway id <XNGHB28Q>; Tue, 24 Nov 1998 16:15:19 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Adel Jaber'" <[e-mail]>
Subject: RE: x.509v3
Date: Tue, 24 Nov 1998 16:15:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The final text of the 1997 edition of X.509 can be found at:

ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

That is the latest approved standard.

There is an ongoing project that is defining a set of future enhancements
which you can find a pointer to in a message posted to this list by Hoyt
Kesterson yesterday.



> ----------
> From: 	Adel Jaber[SMTP:[e-mail]]
> Sent: 	November 24, 1998 2:49 PM
> To: 	[e-mail]
> Subject: 	x.509v3
> 
> 
> I need to download the latest ITU Recommendation X.509.
> I think it is on a Bull site but I am failing to locate
> it.
> 
> Can any body help?
> 
> Thanks
> 
> Adel Jaber
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07738 for ietf-pkix-bks; Tue, 24 Nov 1998 12:00:11 -0800 (PST)
Received: from yafa.alquds.org (alquds.org [208.162.200.234] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07734 for <[e-mail]>; Tue, 24 Nov 1998 12:00:10 -0800 (PST)
Received: from localhost (adel@localhost) by yafa.alquds.org (8.8.5/8.8.5) with SMTP id NAA14186 for <[e-mail]>; Tue, 24 Nov 1998 13:49:11 -0600 (CST)
Date: Tue, 24 Nov 1998 13:49:11 -0600 (CST)
From: Adel Jaber <[e-mail]>
To: [e-mail]
Subject: x.509v3
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I need to download the latest ITU Recommendation X.509.
I think it is on a Bull site but I am failing to locate
it.

Can any body help?

Thanks

Adel Jaber



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07152 for ietf-pkix-bks; Tue, 24 Nov 1998 10:41:12 -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 KAA07148 for <[e-mail]>; Tue, 24 Nov 1998 10:41:11 -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 KAA05903; Tue, 24 Nov 1998 10:45:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 24 Nov 1998 10:44:13 -0800
To: Carlisle Adams <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: generation of private keys
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:54 AM 11/24/98 -0500, Carlisle Adams wrote:
>Hi Stefan,
>> In a legal context (esp. the German Signature law) a relying 
>> party might want
>> to know who generated the key pair of another end entity 
>> before deciding to
>> enter a contractual relationship with this entity. One might 
>> place trust
>> in another subject's certificate based on that question so 
>> wouldn't it make
>> sense to specify an optional certificate extension that indicates who
>> performed the process of key generation (eg. EE, CA, RA, other)?

>Interesting question.  My initial reaction is to wonder if a new certificate
>extension is really the right solution for this.  If the CA generates the
>key pair, it can certainly populate such an extension with confidence.
>However, if the CA did not generate the key pair, how will it distinguish
>between EE, RA, and "other" (i.e., how will it know (with certainty) who did
>the actual key pair generation so that it can populate the extension)?
>
>Carlisle.

It seems the most a CA could do is indicate either that it did, or did not
generate the keypair, correct?

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06452 for ietf-pkix-bks; Tue, 24 Nov 1998 09:08:09 -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 JAA06441 for <[e-mail]>; Tue, 24 Nov 1998 09:08:05 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id SAA31715; Tue, 24 Nov 1998 18:10:29 +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 SAA27658; Tue, 24 Nov 1998 18:13:05 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 24 Nov 1998 18:11:20 -0800
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Carmen Garcia <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: 
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

> Hi all,
>
> We are involved in a time stamp project.
>
> We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
> Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.
>
> At this point we have two questions to propose you for discussion.
>
> 1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….
>
> TimeStampReq ::= SEQUENCE  {
>      version                      Integer  { v1(0) },
>      reqPolicy                    PolicyInformation OPTIONAL,
>      tdas                         SEQUENCE OF GeneralName OPTIONAL,
>      nonce                        Integer,
>      messageImprint               MessageImprint OPTIONAL
>        --a hash algorithm OID and the hash value of the data to be
>        --time stamped
> }
>
> ….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message.

This choice was deliberate. It saves bandwith, e.g. if the message is 2 Mbytes long, you do not send the whole message to the TSA, but only the imprint (160 or 128 bits). It also allows better performance for the Time Stamping server (responding to short messages improves performance). Another advantage is that the TSA does not see the content of the message and it cannot disclose the content to anybody: it places less trust in the TSA. For, at least,
theses reasons, the message itself is never sent to the TSA.

> If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

See above.

> 2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way?
>

You can send multiple such elementary requests in a single message: the transport layer is not mandated.

Regards,

Denis


> Obviously the second point influences the format of the response described in the draft if we want
> to receive in a unique response all the required timestamps.
>
> Regards,
>
> Carmen Garcia.
>
> _____________________________________________
> Carmen Garcia
> Software Engineer
> _____________________________________________
>
> ________________________________________________________
> http://www.latinmail.com. Tu correo gratuito en español.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06043 for ietf-pkix-bks; Tue, 24 Nov 1998 08:34:07 -0800 (PST)
Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06039 for <[e-mail]>; Tue, 24 Nov 1998 08:34:06 -0800 (PST)
Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2232.9) id <WY0KH7T2>; Tue, 24 Nov 1998 08:33:39 -0800
Message-ID: <[e-mail]>
From: "Grall, Cynthia" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: Minor confusion in PKIX part 1, section 7.3.3
Date: Tue, 24 Nov 1998 08:42:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> The following paragraph seems to have two conflicting sentences:
> 
> 7.3.3  DSA Signature Keys
> 
> ...
> 
>    If the DSA algorithm parameters are absent from the subjectPublicKey-
>    Info AlgorithmIdentifier and the CA signed the subject certificate
>    using DSA, then the certificate issuer's DSA parameters apply to the
>    subject's DSA key.  If the DSA algorithm parameters are absent from
>    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>    subject certificate using a signature algorithm other than DSA, then
>    the subject's DSA parameters are distributed by other means.  If the
>    subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters
>    component and the CA signed the subject with a signature algorithm
>    other than DSA, then clients shall reject the certificate.
> 
> I understand the second sentence to mean if the CA cert. has a (for
> example) RSA key, and the EE cert. has a DSA key with no parameters,
> then the EE cert. is okay and I have to find the parameters somewhere
> else.  
> 
> The third sentence says if the CA cert. has (for example) a RSA key,
> and the EE cert. has a DSA key with no parameters, then I should reject
> the EE cert.
> 
> Is there something I'm missing here?  If these do conflict, which is the
> correct statement?
> 
> Cindy
> ----------
> Cindy Grall                       [e-mail]
> Network Associates, Inc.          phone: [phone]
> 3415 S. Sepulvida Blvd.           fax:   [phone]
> Los Angeles, California 90034


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05761 for ietf-pkix-bks; Tue, 24 Nov 1998 08:01:29 -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 IAA05757 for <[e-mail]>; Tue, 24 Nov 1998 08:01:25 -0800 (PST)
Received: 	id KAA04009; Tue, 24 Nov 1998 10:59:14 -0500
Received: by gateway id <XNGHBG0S>; Tue, 24 Nov 1998 10:54:28 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Tue, 24 Nov 1998 10:54:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:[e-mail]]
> Sent: Tuesday, November 24, 1998 8:28 AM
> To: [e-mail]
> Subject: CMP: generation of private keys
> 
> 
> I do not want to start the discussions about key generation 
> again but the
> following paragraph from draft-ietf-pkix-ipki3cmp-08.txt 
> raises a question
> to me:
> 
> : 2.2.1.3 Location of key generation
> :
> : In this specification, "key generation" is regarded as occurring
> : wherever either the public or private component of a key pair first
> : occurs in a PKIMessage. Note that this does not preclude a 
> centralized
> : key generation service - the actual key pair MAY have been generated
> : elsewhere and transported to the end entity, RA, or CA using a
> : (proprietary or standardized) key generation 
> request/response protocol
> : (outside the scope of this specification).
> :
> : There are thus three possibilities for the location of "key
> : generation":  the end entity, an RA, or a CA.
> 
> In a legal context (esp. the German Signature law) a relying 
> party might want
> to know who generated the key pair of another end entity 
> before deciding to
> enter a contractual relationship with this entity. One might 
> place trust
> in another subject's certificate based on that question so 
> wouldn't it make
> sense to specify an optional certificate extension that indicates who
> performed the process of key generation (eg. EE, CA, RA, other)?
> 
> I don't think this is merely a policy/CPS issue since the CA might not
> address this issue in its policy. The German Signature law 
> profile, for
> example, in principle allows for the key material to be 
> generated by either
> the CA or the end entity (although the latter is very 
> unlikely to happen
> due to the technical requirements). So the relying party 
> wouldn't get an
> answer from reading the policy/CPS.
> 
> Comments?


Interesting question.  My initial reaction is to wonder if a new certificate
extension is really the right solution for this.  If the CA generates the
key pair, it can certainly populate such an extension with confidence.
However, if the CA did not generate the key pair, how will it distinguish
between EE, RA, and "other" (i.e., how will it know (with certainty) who did
the actual key pair generation so that it can populate the extension)?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05469 for ietf-pkix-bks; Tue, 24 Nov 1998 07:18:54 -0800 (PST)
Received: from mail.latinmail.com (smtp.latinmail.com [209.2.135.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05464 for <[e-mail]>; Tue, 24 Nov 1998 07:18:53 -0800 (PST)
Message-Id: <[e-mail]>
Received: from latinmail.com [209.2.135.54] by mail.latinmail.com (SMTPD32-4.07) id A005DA0146; Tue, 24 Nov 1998 10:25:57 EST
To: [e-mail]
CC: [e-mail]
From: Carmen Garcia <[e-mail]>
Date: Tue, 24 Nov 98 10:23:55 -0500
X-Mailer: LatinMail v3.0 -- http://www.latinmail.com
Sender: [e-mail]
Precedence: bulk

Hi all,

We are involved in a time stamp project. 

We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.

At this point we have two questions to propose you for discussion.

1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint OPTIONAL 
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message. If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way? 

Obviously the second point influences the format of the response described in the draft if we want
to receive in a unique response all the required timestamps.

Regards,

Carmen Garcia.

_____________________________________________
Carmen Garcia
Software Engineer
_____________________________________________




________________________________________________________
http://www.latinmail.com. Tu correo gratuito en español.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04610 for ietf-pkix-bks; Tue, 24 Nov 1998 05:24:28 -0800 (PST)
Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04603 for <[e-mail]>; Tue, 24 Nov 1998 05:23:43 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id OAA03230 for [e-mail]; Tue, 24 Nov 1998 14:27:37 +0100 (MET)
Date: Tue, 24 Nov 1998 14:27:37 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CMP: generation of private keys
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk

I do not want to start the discussions about key generation again but the
following paragraph from draft-ietf-pkix-ipki3cmp-08.txt raises a question
to me:

: 2.2.1.3 Location of key generation
:
: In this specification, "key generation" is regarded as occurring
: wherever either the public or private component of a key pair first
: occurs in a PKIMessage. Note that this does not preclude a centralized
: key generation service - the actual key pair MAY have been generated
: elsewhere and transported to the end entity, RA, or CA using a
: (proprietary or standardized) key generation request/response protocol
: (outside the scope of this specification).
:
: There are thus three possibilities for the location of "key
: generation":  the end entity, an RA, or a CA.

In a legal context (esp. the German Signature law) a relying party might want
to know who generated the key pair of another end entity before deciding to
enter a contractual relationship with this entity. One might place trust
in another subject's certificate based on that question so wouldn't it make
sense to specify an optional certificate extension that indicates who
performed the process of key generation (eg. EE, CA, RA, other)?

I don't think this is merely a policy/CPS issue since the CA might not
address this issue in its policy. The German Signature law profile, for
example, in principle allows for the key material to be generated by either
the CA or the end entity (although the latter is very unlikely to happen
due to the technical requirements). So the relying party wouldn't get an
answer from reading the policy/CPS.

Comments?

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06560 for ietf-pkix-bks; Mon, 23 Nov 1998 12:01:05 -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 MAA06556 for <[e-mail]>; Mon, 23 Nov 1998 12:01:03 -0800 (PST)
From: [e-mail]
Received: by us-mta1.ma02.bull.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 852566C5.006E1BEE ; Mon, 23 Nov 1998 15:02:41 -0500
X-Lotus-FromDomain: BULL
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1998 12:59:48 -0700
Subject: pdam registration of the certificate extensions document
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

hello

sharon boeyen, the editor of the certificate extensions document, has made
the revisions asked of her during the document review

i have seen no objection to registering the pdam for certificate
extensions. therefore i have sent it to the sc6 secretariat requesting she
begin the ballot as soon as possible. prior to doing so i have assigned
some object identifier values for new attributes, object classes, and
matching rules.

the revised text, CertificateExtensionsPDAM, is in .doc and .pdf format at
ftp://ftp.bull.com/pub/OSIdirectory/BeijingVancouver98Output

note that the ballot period will be 3 months and that we will resolve
comments at an editing meeting in orlando soon after the ballot close date.

i expect that this document will have comments from international liaison
organizations such as the ietf and tc68. i am the iso/iec directory liaison
to those organizations. ballot comments from international liaison
organizations should be sent to the sc6 secretariat, jean shildneck (
[e-mail]). to allow sufficient time for review before the editing
meeting, those comments should also be sent to [e-mail].
comments from organization with a country should be consolidated  by the
responsible organization for that country.

i want to thank sharon for quickly handling the comments brought up in the
review period.

     hoyt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13491 for ietf-pkix-bks; Fri, 20 Nov 1998 14:46:31 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13487 for <[e-mail]>; Fri, 20 Nov 1998 14:46:30 -0800 (PST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <XJR0VD36>; Fri, 20 Nov 1998 14:44:13 -0800
Message-ID: <39ADCF833E74D111A2D700805F1951EF056BA008@RED-MSG-06>
From: Brian LaMacchia <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Fri, 20 Nov 1998 14:44:10 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk

Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list, 
>taken from the thread on NT SP4 fixes:
> 
>>Does your end-entity cert have a basicConstraints extension in it?  When
we
>>have to pick a default certificate store for a particular cert we first
try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
 
I'm the author of the CryptoAPI-L message Peter's quoting here, so let me
give you my perspective on the basicConstraints question.  I agree with
Peter that the PKIX-1 position that BC SHOULD NOT be included in EE certs is
wrong.  If anything, I would expect PKIX to say BC SHOULD be included
(cA=FALSE, no pathLen of course) but not mandate it.  

For our products, the issue is primarily one of backward compatibility with
the universe of CA certificates in existence that do not contain a BC
extension (and there are plenty out there that do not.)  Since PKIX-1
mandates the presence of a critical BC extension in all CA certs, it's
certainly the case that in a world consisting of only PKIX-compliant CAs and
EEs I can distinguish between the two types of certs and not consider EE
certs during the path discovery process.  But that's not a reasonable
position for a product to take because there *are* certs in use that don't
meet this spec.  Lack of a BC extension in a cert cannot preclude that cert
from potentially being a CA cert.  It's the same situation as that we faced
with the introduction of extended key usage (EKU); lack of an EKU extension
implies "all" not "none".

My comment to the CryptoAPI list mixed together two specific instances when
determining whether a cert is an EE or a CA cert is important, which I
should explicitly separate.  First, of course, is path development and chain
validation policy, where I care about the universe of possible parent
certificates as I walk through the cert graph and overall pathLen
constraints in found paths.  Second, from a product perspective I may want
to be able to distinguish between EE and CA certs in the user interface when
presenting collections of certs to users.  Products may make distinctions in
how they store and present EE certs vs. CA certs.  Since I have to assume
that a cert w/o BC is a potential CA cert, I have to treat it that way in
the UI as well or I'll have inconsistent behavior.

I'm afraid I don't understand Tim's arguments (dealing with out-of-band
designation of an EE cert as acceptable as a cert issuer) as justification
for the current text.  Certainly any user can build his own trust policies
and designate any cert (self-signed root, intermediate CA or EE) as a
trusted root of cert paths.   But since that's a client-based policy
decision, I can do that anyway, even if the cert contains a basicConstraints
extension.  (I probably won't have any recourse against the issuer should
something go wrong, but that's my choice.)

As for our current/upcoming crop of products, we always include a BC
extension in certs we issue, EE or CA.  If a BC extension is present in a
cert we use and respect that information, whether or not it's marked
critical.  Lack of a BC extension implies the possibility that the cert
could be an old CA cert, and we therefore must consider that possibility.

Bottom line: we seem to be going out of our way here to break old CA certs.
That doesn't seem reasonable, especially when we jump through hoops in other
areas of the draft to explicitly grandfather old certs forward.

					--Brian LaMacchia
					  [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13269 for ietf-pkix-bks; Fri, 20 Nov 1998 14:02:09 -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 OAA13265 for <[e-mail]>; Fri, 20 Nov 1998 14:02:08 -0800 (PST)
Received: 	id RAA28476; Fri, 20 Nov 1998 17:02:50 -0500
Received: by gateway id <XFCQWMMB>; Fri, 20 Nov 1998 16:58:09 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: [e-mail], "'Tammy Carter'" <[e-mail]>
Subject: RE: Entrust certificate storage
Date: Fri, 20 Nov 1998 16:58:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi,

Entrust transfers the certificate and other signed objects within the LDAP
protocol using the binary DER encoding. It is also possible to configure the
Entrust software to use an ASCII representation of the DER encoding instead.
In this case, the ASCII encoding is applied after the DER encoding has been
rendered so that the DER encoding is preserved. The ASCII representation is
supported for interoperability with directory systems which do not support
binary attribute syntaxes. If you would like to follow-up further, let's
take the discussion off the list, since it is not a PKIX issue. Please feel
free to contact me directly.

-----------------------------------------
Chris Oliva
Entrust Technologies

[phone]
[e-mail]
http://www.entrust.com
-----------------------------------------

> ----------
> From: 	Tammy Carter[SMTP:[e-mail]]
> Sent: 	Friday, November 20, 1998 2:12 PM
> To: 	[e-mail]
> Subject: 	Entrust certificate storage
> 
> My understanding of X.509 is that certificates should be stored in an
> X.500 directory in their binary DER encoded format.  However, after
> talking with a person who has been using Entrust to store user
> certificates in the directory (in the userCertificate attribute), it
> appears that Entrust stores a user's certificates in some kind of ASCII
> translation of the DER encoding?  My source reports that a dump of what is
> actually being stored via LDAP is "{ASN1}..." followed by a translation of
> the hex into ASCII.  Apparently, Entrust also reads out any certificates
> stored in a binary DER encoding in the attribute, translates them to
> ASCII, and then writes them back to the directory.
> 
> Is my understanding of X.509 correct?  Is Entrust following some kind of
> standard?  Has anyone else noticed this behavior?
> 
> Tammy Green Carter
> [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12247 for ietf-pkix-bks; Fri, 20 Nov 1998 11:10:37 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA12243 for <[e-mail]>; Fri, 20 Nov 1998 11:10:36 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Nov 1998 12:14:11 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 20 Nov 1998 12:12:25 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Subject: Entrust certificate storage
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 LAA12244
Sender: [e-mail]
Precedence: bulk

My understanding of X.509 is that certificates should be stored in an X.500 directory in their binary DER encoded format.  However, after talking with a person who has been using Entrust to store user certificates in the directory (in the userCertificate attribute), it appears that Entrust stores a user's certificates in some kind of ASCII translation of the DER encoding?  My source reports that a dump of what is actually being stored via LDAP is "{ASN1}..." followed by a translation of the hex into ASCII.  Apparently, Entrust also reads out any certificates stored in a binary DER encoding in the attribute, translates them to ASCII, and then writes them back to the directory.

Is my understanding of X.509 correct?  Is Entrust following some kind of standard?  Has anyone else noticed this behavior?

Tammy Green Carter
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09342 for ietf-pkix-bks; Fri, 20 Nov 1998 05:48:26 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09338 for <[e-mail]>; Fri, 20 Nov 1998 05:48:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA09487; Fri, 20 Nov 1998 08:52:25 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 19 Nov 1998 17:27:00 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

You are being inconsistent.  You said: " ... PKIX requires that CA certs
have a critical  basicConstraints extension present if the cert is a CA
cert ...". I agree.  So, where is PKIX's "take a guess at the CA status"?
If there is not a basicConstraints extension with the cA bit set to TRUE,
then the certificate belongs to a CA, otherwise it belongs to an EE.  No
guessing.

Russ


At 02:54 PM 11/19/98 +0000, Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list, 
>taken from the thread on NT SP4 fixes:
> 
>>Does your end-entity cert have a basicConstraints extension in it?  When we
>>have to pick a default certificate store for a particular cert we first try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
> 
>I'll repeat again my assertion that omitting basicConstraints from a cert
is a 
>very dangerous practice because it leaves the interpretation of the certs CA 
>status entirely to chance.  Users will use whatever the default for the 
>software is, and the default for a lot of software is exactly the opposite of 
>what is intended by PKIX.
> 
>[BTW the claim that leaving it out lets you use the cert as a CA cert if you 
> like is incorrect, since PKIX requires that CA certs have a critical 
> basicConstraints extension present if the cert is a CA cert, which should 
> exclude a cert without basicConstraints from acting as a CA if you follow
the 
> PKIX interpretation.  I guess the user could always override this (meaning 
> that interpretation of the cert is at the whim of the user), and who knows 
> how the various pieces of software out there at the moment will handle it].
> 
>To comment on the claim that users must have out-of-band verification of
CA's, 
>a few months ago a group of people ran a test using an ISP's web pages to see 
>how many people, when given an unknown CA cert, would accept it without 
>question.  As far as they could tell, *everyone* accepted it (some may have 
>accepted rejected it but connected to the following SSL'd page anyway despite 
>the warning about a bad signature on the server cert).  This means that using 
>the PKIX interpretation, any end entity can pass themselves off as a CA, and 
>it'll work close to 100% of the time.
> 
>When it comes to cert fingerprints, there are German banks who have gone so 
>far as to refuse to publish fingerprints because "it'll confuse the users" 
>(which for about 99.99% of users is probably correct).  This upset some 
>computer security types because it wouldn't allow out-of-band verification so 
>they took it up with the banks, who after escalating it up several levels
said 
>they wouldn't publish the fingerprints, end of story.  Again, this doesn't 
>bode well for PKIX's "take a guess at the CA status" interpretation.
>
>I guess I've now said my bit on this topic... I still think doing this is a 
>serious mistake, and reserve the right to dance around singing "I told you
so" 
>six months down the track :-).
> 
>Peter.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08535 for ietf-pkix-bks; Thu, 19 Nov 1998 15:53:51 -0800 (PST)
Received: from shell.tsoft.com ([e-mail] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08531 for <[e-mail]>; Thu, 19 Nov 1998 15:53:51 -0800 (PST)
Received: from [209.133.59.210] (briank.ppp.tsoft.com.59.133.209.in-addr.arpa [209.133.59.210] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id PAA21285; Thu, 19 Nov 1998 15:56:12 -0800 (PST)
X-Sender: briank@pop
Message-Id: <l03110721b27a6012fdff@[209.133.59.210]>
In-Reply-To:  <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Nov 1998 16:01:50 -0800
To: "Flanigan, Bill" <[e-mail]>
From: Brian Korver <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

At 3:57 PM -0500 11/19/98, Flanigan, Bill wrote:
>Not really.  Although it, of course, depends on the application (not the PKI
>per se), Basic Constraints, well, constrain EEs from acting as CAs; Key
>Usage bit set(s) indicate(s), well, key usage.  What would happen if an
>app's certs have BC = not used (or c=no), and KU = keyCertSign, cRLSign?
>Since every EE can now be its own CA, I'll let you guess!

Bill,

In theory, not what you think -- such a cert is malformed.

According to my copy of the amendments DAM (section 12.2.2.3 "Key usage
field"):

   The bits keyCertSign and cRLSign are for use in CA-certificates only,
   and if the basic constraints extension (see 12.4.2.1) is present in
   the same certificate the values in the subjectType field of that
   extension and in the key usage restriction shall not conflict.

So, according to X.509 law, "BC=not used" cannot legally appear with
"K=keyCertSign,cRLSign".


-brian
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06284 for ietf-pkix-bks; Thu, 19 Nov 1998 12:53:09 -0800 (PST)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06280 for <[e-mail]>; Thu, 19 Nov 1998 12:53:08 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <W0QG69VX>; Thu, 19 Nov 1998 15:57:50 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Brian Korver'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Thu, 19 Nov 1998 15:57:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Not really.  Although it, of course, depends on the application (not the PKI
per se), Basic Constraints, well, constrain EEs from acting as CAs; Key
Usage bit set(s) indicate(s), well, key usage.  What would happen if an
app's certs have BC = not used (or c=no), and KU = keyCertSign, cRLSign?
Since every EE can now be its own CA, I'll let you guess!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  

> -----Original Message-----
> From:	Brian Korver [SMTP:[e-mail]]
> Sent:	Thursday, November 19, 1998 1:58 AM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Re: Problem with PKIX part 1 basicConstraints
> 
	[snip]

> Don't forget about the KeyUsage extention.  When this extention is
> present,
> the BasicConstraints extension is redundant in EE certifications.
> 
	[snip]

> -brian
> [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05712 for ietf-pkix-bks; Thu, 19 Nov 1998 11:52: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 LAA05708 for <[e-mail]>; Thu, 19 Nov 1998 11:52:12 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA12700; Thu, 19 Nov 1998 11:53:14 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA25275; Thu, 19 Nov 1998 11:55:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 19 Nov 1998 11:55:40 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Aram,

The Authenticode CA's slipped my mind.  I'll let the list know when this
page has been updated.

Thanks!
Alex

Aram Perez wrote:
> 
> Hi Alex,
> 
> [snip]
> >
> >> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> >> certificates and Navigotor lists 6 Verisign certificates. Where are the
> >> fingerprints for those "extra" certificates?
> >
> >The rest of the CA certs you see are subordinate CA's signed by the one
> >of the VeriSign roots.  Applications should determine the
> >trustworthyness of these subordinate CA certs by "walking the chain" and
> >validating signatures up to one of these trusted root certs.
> 
> IE lists the following certs:
> 1) VeriSign Class 1 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
> (This one does not match any information from the URL).
> 2) VeriSign Class 2 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
> 3) VeriSign Commercial Software Publishers CA, Expires: Wed, Jan 7, 2004
> 4) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
> 5) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
> (This is is a duplicate, don't know why Microsoft would do that :(
> 6) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
> 7) VeriSign Individual Software Publishers CA, Expires: Wed, Jan 7, 2004
> 8) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
> (Another duplicate)
> 
> Navigator lists the following certs:
> 1) Verisign Class 1 Primary CA, Expires: Fri Dec 31, 1999 (This one matches
> except it states the cert is valid starting Mon Jan 29, 1996)
> 2) Verisign Class 1 Primary CA, Expires: Tue Jan 7, 2020 (This one matches
> except for 'Tue' not 'Mon' and it has a serial number which you do not list)
> 3) Verisign Class 2 Primary CA (similar to 1 above, also it appears that
> Navigator main list of certificates only shows the "main" name, but when you
> try to "Edit" the certificate, Navigator lets you chose one of two
> certificates with the same name).
> 4) Verisign Class 3 Primary CA
> 5) Verisign Class 4 Primary CA (Not listed on the URL)
> 6) Verisign/RSA Commercial CA (Not listed on the URL)
> 7) Verisign/RSA Secure Server CA
> 
> Regards,
> Aram


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA25035 for ietf-pkix-bks; Wed, 18 Nov 1998 22:50:39 -0800 (PST)
Received: from shell.tsoft.com ([e-mail] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA25030 for <[e-mail]>; Wed, 18 Nov 1998 22:50:37 -0800 (PST)
Received: from [209.133.59.210] (briank.ppp.tsoft.com.59.133.209.in-addr.arpa [209.133.59.210] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id WAA17033; Wed, 18 Nov 1998 22:53:06 -0800 (PST)
X-Sender: briank@pop
Message-Id: <l03110704b279715f72d9@[209.133.59.210]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Nov 1998 22:57:44 -0800
To: [e-mail]
From: Brian Korver <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 2:54 PM +0000 11/19/98, Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list,
>taken from the thread on NT SP4 fixes:
>
>>Does your end-entity cert have a basicConstraints extension in it?  When we
>>have to pick a default certificate store for a particular cert we first try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
>
>I'll repeat again my assertion that omitting basicConstraints from a cert
>is a
>very dangerous practice because it leaves the interpretation of the certs CA
>status entirely to chance.  Users will use whatever the default for the
>software is, and the default for a lot of software is exactly the opposite of
>what is intended by PKIX.
>
>[BTW the claim that leaving it out lets you use the cert as a CA cert if you
> like is incorrect, since PKIX requires that CA certs have a critical
> basicConstraints extension present if the cert is a CA cert, which should
> exclude a cert without basicConstraints from acting as a CA if you follow
>the
> PKIX interpretation.  I guess the user could always override this (meaning
> that interpretation of the cert is at the whim of the user), and who knows
> how the various pieces of software out there at the moment will handle it].
>
>To comment on the claim that users must have out-of-band verification of
>CA's,
>a few months ago a group of people ran a test using an ISP's web pages to see
>how many people, when given an unknown CA cert, would accept it without
>question.  As far as they could tell, *everyone* accepted it (some may have
>accepted rejected it but connected to the following SSL'd page anyway despite
>the warning about a bad signature on the server cert).  This means that using
>the PKIX interpretation, any end entity can pass themselves off as a CA, and
>it'll work close to 100% of the time.

Don't forget about the KeyUsage extention.  When this extention is present,
the BasicConstraints extension is redundant in EE certifications.


>
>When it comes to cert fingerprints, there are German banks who have gone so
>far as to refuse to publish fingerprints because "it'll confuse the users"
>(which for about 99.99% of users is probably correct).  This upset some
>computer security types because it wouldn't allow out-of-band verification so
>they took it up with the banks, who after escalating it up several levels
>said
>they wouldn't publish the fingerprints, end of story.  Again, this doesn't
>bode well for PKIX's "take a guess at the CA status" interpretation.
>
>I guess I've now said my bit on this topic... I still think doing this is a
>serious mistake, and reserve the right to dance around singing "I told you
>so"
>six months down the track :-).
>
>Peter.


-brian
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04913 for ietf-pkix-bks; Wed, 18 Nov 1998 17:50: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 RAA04909 for <[e-mail]>; Wed, 18 Nov 1998 17:50: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 OAA23083 for <[e-mail]>; Thu, 19 Nov 1998 14:54:11 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91144045125598>; Thu, 19 Nov 1998 14:54:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 19 Nov 1998 14:54:11 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've just been forwarded the following message from the MS CryptoAPI list, 
taken from the thread on NT SP4 fixes:
 
>Does your end-entity cert have a basicConstraints extension in it?  When we
>have to pick a default certificate store for a particular cert we first try
>to figure out whether we're looking at an EE or a CA cert.  If there's no
>basicConstraints extension present then the cert could be either and we
>default to treating the cert as a CA cert in this case.
 
I'll repeat again my assertion that omitting basicConstraints from a cert is a 
very dangerous practice because it leaves the interpretation of the certs CA 
status entirely to chance.  Users will use whatever the default for the 
software is, and the default for a lot of software is exactly the opposite of 
what is intended by PKIX.
 
[BTW the claim that leaving it out lets you use the cert as a CA cert if you 
 like is incorrect, since PKIX requires that CA certs have a critical 
 basicConstraints extension present if the cert is a CA cert, which should 
 exclude a cert without basicConstraints from acting as a CA if you follow the 
 PKIX interpretation.  I guess the user could always override this (meaning 
 that interpretation of the cert is at the whim of the user), and who knows 
 how the various pieces of software out there at the moment will handle it].
 
To comment on the claim that users must have out-of-band verification of CA's, 
a few months ago a group of people ran a test using an ISP's web pages to see 
how many people, when given an unknown CA cert, would accept it without 
question.  As far as they could tell, *everyone* accepted it (some may have 
accepted rejected it but connected to the following SSL'd page anyway despite 
the warning about a bad signature on the server cert).  This means that using 
the PKIX interpretation, any end entity can pass themselves off as a CA, and 
it'll work close to 100% of the time.
 
When it comes to cert fingerprints, there are German banks who have gone so 
far as to refuse to publish fingerprints because "it'll confuse the users" 
(which for about 99.99% of users is probably correct).  This upset some 
computer security types because it wouldn't allow out-of-band verification so 
they took it up with the banks, who after escalating it up several levels said 
they wouldn't publish the fingerprints, end of story.  Again, this doesn't 
bode well for PKIX's "take a guess at the CA status" interpretation.

I guess I've now said my bit on this topic... I still think doing this is a 
serious mistake, and reserve the right to dance around singing "I told you so" 
six months down the track :-).
 
Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03323 for ietf-pkix-bks; Wed, 18 Nov 1998 14:36:21 -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 OAA03319 for <[e-mail]>; Wed, 18 Nov 1998 14:36:14 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XDTQ826Y>; Thu, 19 Nov 1998 09:37:38 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A3F@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Aram Perez'" <[e-mail]>, Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Thu, 19 Nov 1998 09:37:36 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

As I recall, Verisign rolled out a new set of certs about 6 months ago
to superseed older certs from the IE3 era.

Rotek's TrustedNet Smart Card Enabled S/MIME Secure Email

WINS

"INTERACT 98  BEST INTERNET, INTRANET & EXTRANET SOLUTION"

See our Web Site for details

Rotek Consulting 
Melbourne, Australia 
[phone] 
[phone] (Fax) 
www.rotek.com.au 


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Aram Perez [SMTP:[e-mail]]
> Sent:	Thursday, November 19, 1998 3:58 AM
> To:	Alex Deacon
> Cc:	Tim Polk; [e-mail]; [e-mail]
> Subject:	Re: Problem with PKIX part 1 basicConstraints
> 
> Hi Alex,
> 
> Thanks for the URL. I had previously found it, but like I said it was
> "very
> hard". My questions to Verisign are:
> 
> 1) Why isn't there a link to the URL on your home page?
> 2) There are only 4 certificates listed on the page but IE lists 8
> Verisign
> certificates and Navigotor lists 6 Verisign certificates. Where are
> the
> fingerprints for those "extra" certificates?
> 
> Regards,
> Aram
> 
> P.S. Please say hello to Hoa Ly (I believe she still works for
> Verisign).
> 
> 
> >> I also find it ironic that it is
> >> very hard to find out Verisign's fingerprints from their Web site. 
> >
> >See https://www.verisign.com/repository/root.html fingerprints of
> >VeriSign's root certificates.
> >
> >Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03198 for ietf-pkix-bks; Wed, 18 Nov 1998 14:30:49 -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 OAA03194 for <[e-mail]>; Wed, 18 Nov 1998 14:30:45 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XDTQ826S>; Thu, 19 Nov 1998 09:32:19 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A3E@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'David Sweigert'" <[e-mail]>, Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Thu, 19 Nov 1998 09:32:17 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In a former life (about a year ago), I went down this path and had
hardware crypto integrated to an NT / IIS3 server, to implement 128 bit
crypto.

The primary reason for this was for improving trust / key management.  

As it turned out, software based crypto in SSL is awfully fast (but a
bit variable depending on which vendor you get it from), so unless you
are careful you may end up implementing hardware decelleration.  The
approach we took was to have Server Private Key and Certs in hardware
board and the rest was done in software i.e. SHA1, RC4, MD5 et al.

I think your best bet for performance numbers will be with the vendors
of said crypto accelerator boards.    

Also, you could exchange emails with the guys of SSLEAY fame (Eric Young
and Tim Hudson) as they have trod these paths.


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	David Sweigert [SMTP:[e-mail]]
> Sent:	Wednesday, November 18, 1998 10:10 AM
> To:	Trevor Freeman; 'John Hughes'; [e-mail]
> Subject:	RE: LDAP Schema
> 
> 
> Has anyone in the group run across sources of information
> RE: use of digital certificates with Web SSL and the accompanying
> server performance problems and need for hardware accelerators ?
> 
> Dave Sweigert
>  
> 
> At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
> >Hi John,
> >The Exchange schema is not extensible so you cannot add these
> classes.
> >however, the mailbox objects do already have a UserCertificate
> attribute
> >and there is also a CertificateAuthority object in these schema which
> has
> >most of the required attributes such as CACertificate and
> >certificateRevocationList etc. If you open the directory in Raw mode
> you can
> >see these objects and all of their attributes. 
> >
> >Trevor
> >
> >
> >-----Original Message-----
> >From: John Hughes [mailto:[e-mail]]
> >Sent: Tuesday, November 17, 1998 6:38 AM
> >To: [e-mail]
> >Subject: LDAP Schema
> >
> >
> >Has any one tried to configure Exchange Directory Server 5.5 to
> support the
> >pkiUser and pkiCA object classes.  Is it possible?
> >
> >
> >John
> >
> >
> >
> > -------------------------------------------------------------------
> >| John Hughes             [e-mail]                 |
> >| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
> >|                         Home Fax No:           [phone]  |
> >|                         Main Office Tel:       [phone] |
> >| www.entegrity.com       Mobile:                [phone]   |
> > ------------------------------------------------------------------- 
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01941 for ietf-pkix-bks; Wed, 18 Nov 1998 12:20:21 -0800 (PST)
Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.127.33]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01937 for <[e-mail]>; Wed, 18 Nov 1998 12:20:19 -0800 (PST)
Received: from wu-wien.ac.at (snoopy.wu-wien.ac.at [137.208.224.121]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id VAA02798emf [e-mail]; Wed, 18 Nov 1998 21:23:37 +0100 (MEZ)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 21:23:46 +0100
From: Michael Fritscher <[e-mail]>
Reply-To: [e-mail]
Organization: WU-Wien
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Deacon <[e-mail]>
CC: Aram Perez <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Alex Deacon wrote:
> 
> Aram Perez wrote:
> >
...
> 
> > 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> > certificates and Navigotor lists 6 Verisign certificates. Where are the
> > fingerprints for those "extra" certificates?
> 
> The rest of the CA certs you see are subordinate CA's signed by the one
> of the VeriSign roots.  Applications should determine the
> trustworthyness of these subordinate CA certs by "walking the chain" and
> validating signatures up to one of these trusted root certs.
> 

When I look at Netscape, this point is true for only one CA certificate of
Verisign. The others whoose Fingerprints are not on Verisign Website are also
self-signed certificates (as the "Class 4 Public Primary Certification
Authority" or the "Commercial Certification Authority").

Michael

--
-----------------------------------------------------------
| Michael Fritscher
| Department of Management Information Systems
| Vienna University of Economics And Business Administration
| mailto:[e-mail]
| http://wwwi.wu-wien.ac.at/finanz/
| "An APPLE a day keeps WINDOWS.95 away..."
------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01439 for ietf-pkix-bks; Wed, 18 Nov 1998 11:29:13 -0800 (PST)
Received: from atlas.arc.nasa.gov (atlas-ops.arc.nasa.gov [198.123.8.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01435 for <[e-mail]>; Wed, 18 Nov 1998 11:29:12 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-49-113.s113.tnt14.ann.erols.com [207.172.49.113]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with SMTP id LAA14332; Wed, 18 Nov 1998 11:33:00 -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: Wed, 18 Nov 1998 11:28:00 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I believe the PKIX text is correct.  Many implementations need to make
modification to align with PKIX Part 1.

Russ


> ----------
> From: 	Tim Polk[SMTP:[e-mail]]
> Sent: 	November 17, 1998 9:49 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: Problem with PKIX part 1 basicConstraints
> 
> Peter,
> 
> Both MSIE and Netscape are relying on the user's judgement: the user
> *must*
> have out-of-band information that the subject is a trustworthy CA, or
> they
> wouldn't install it as a site certificate, would they??? (If I could
> remember how to make a smiley face, I'd insert it here!)
> 
> The basicConstraints extension does not fix this problem, though.  If
> NIST
> used that extension (and marked it critical) in end entity
> certificates,
> that prevents me from using my NIST certificate to claim CA status.  I
> don't really need that for the browser scenario.  If I can generate
> new
> certs, I can generate my own.  When I generate my self-signed
> certificate I
> might as well include the basicConstraints extension. If I could get
> folks
> to accept it without that extension, they'll certainly accept with
> that
> extension.
> 
> Clearly, the safest choice would be to select a single trusted CA (or
> a
> very small number) as the beginning (end?) of all valid paths and only
> accept a subject as a CA if the basicConstraints extension is present.
> (That is, never accept a subject as CA based on out-of-band
> information.)
> User selected trust points are always fraught with danger.  The
> solutions
> are to improve the client software and educate the users, in my
> opinion.
> 
> How?  Now that's a tough question!
> 
> Tim
> 
> 
> At 01:08 PM 11/17/98, Peter Gutmann wrote:
> >Tim Polk <[e-mail]> wrote:
> >
> >>If the basic constraints extension is not present, certificate
> processing
> >>is consistent with v1 or v2 certificates.  If out-of-band
> information
> >>specifies the subject is a CA, it's a CA.  If out of band
> information is
> >>not available, the user of the certificate assumes the subject is
> NOT a
> >>CA.
> >
> >Assertion: If basicConstraints is not present, current software
> typically
> >           assumes the subject is a CA.
> >Proof: Create a self-signed certificate without basicConstraints,
> load it
> >       into MSIE or Netscape, and see what happens.
> >
> >>3) If an end entity wishes to accept a certificate without a
> >>basicConstraints extension as a CA certificate, it must rely on
> >>out-of-band information.  In this case, the responsibility lies on
> the
> >>certificate user and the source of the out-of-band information, not
> on
> >>the certificate issuer.  The certificate issuer attests to the
> binding of
> >>subject and key, not the subject's status as a CA.
> >
> >Both MSIE and Netscape treat self-signed certs without
> basicConstraits as 
> >CA's by default (in fact I don't know of any way to get them to *not*
> 
> >treat the cert owners as CA's).
> >
> >MSIE: "You have been offered a new site certificate to place in your
> list
> >       of trusted issuers..."
> >Netscape: "You are about to go through the process of accepting a
> >           certificate authority..."
> >
> >Leaving out the basicConstraints makes the assumption that relying
> parties
> >are using PKIX-compliant software, and that the software will DTRT
> when it
> >finds one of these certs.  I think this is leaving what could be a
> critical
> >security issue more or less to chance - all I need to do is find some
> >software which happens to not follow PKIX's implied behaviour and I
> can go
> >ahead and issue my own certs and let the entire world in the door.
> >
> >Peter.
> >
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00733 for ietf-pkix-bks; Wed, 18 Nov 1998 10:12:49 -0800 (PST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00729 for <[e-mail]>; Wed, 18 Nov 1998 10:12:48 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA36110 for <[e-mail]>; Wed, 18 Nov 1998 10:02:12 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 18 Nov 1998 10:01:58 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id KAA62850; Wed, 18 Nov 1998 10:01:53 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Wed, 18 Nov 1998 10:01:56 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Alex,

[snip]
>
>> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
>> certificates and Navigotor lists 6 Verisign certificates. Where are the
>> fingerprints for those "extra" certificates?
>
>The rest of the CA certs you see are subordinate CA's signed by the one
>of the VeriSign roots.  Applications should determine the
>trustworthyness of these subordinate CA certs by "walking the chain" and
>validating signatures up to one of these trusted root certs.   

IE lists the following certs:
1) VeriSign Class 1 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
(This one does not match any information from the URL).
2) VeriSign Class 2 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
3) VeriSign Commercial Software Publishers CA, Expires: Wed, Jan 7, 2004
4) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
5) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
(This is is a duplicate, don't know why Microsoft would do that :(
6) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
7) VeriSign Individual Software Publishers CA, Expires: Wed, Jan 7, 2004
8) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
(Another duplicate)

Navigator lists the following certs:
1) Verisign Class 1 Primary CA, Expires: Fri Dec 31, 1999 (This one matches
except it states the cert is valid starting Mon Jan 29, 1996)
2) Verisign Class 1 Primary CA, Expires: Tue Jan 7, 2020 (This one matches
except for 'Tue' not 'Mon' and it has a serial number which you do not list)
3) Verisign Class 2 Primary CA (similar to 1 above, also it appears that
Navigator main list of certificates only shows the "main" name, but when you
try to "Edit" the certificate, Navigator lets you chose one of two
certificates with the same name).
4) Verisign Class 3 Primary CA
5) Verisign Class 4 Primary CA (Not listed on the URL)
6) Verisign/RSA Commercial CA (Not listed on the URL)
7) Verisign/RSA Secure Server CA

Regards,
Aram



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00243 for ietf-pkix-bks; Wed, 18 Nov 1998 09:15:48 -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 JAA00239 for <[e-mail]>; Wed, 18 Nov 1998 09:15:47 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA10560; Wed, 18 Nov 1998 09:16:44 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA22212; Wed, 18 Nov 1998 09:19:11 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 09:19:12 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Aram Perez wrote:
> 
> Hi Alex,
> 
> Thanks for the URL. I had previously found it, but like I said it was "very
> hard". My questions to Verisign are:
> 
> 1) Why isn't there a link to the URL on your home page?

I agree that it is not easy to find.  I'll forward this issue to our web
people.

> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> certificates and Navigotor lists 6 Verisign certificates. Where are the
> fingerprints for those "extra" certificates?

The rest of the CA certs you see are subordinate CA's signed by the one
of the VeriSign roots.  Applications should determine the
trustworthyness of these subordinate CA certs by "walking the chain" and
validating signatures up to one of these trusted root certs.   

Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29981 for ietf-pkix-bks; Wed, 18 Nov 1998 08:58:14 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29977 for <[e-mail]>; Wed, 18 Nov 1998 08:58:13 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id IAA35264 for <[e-mail]>; Wed, 18 Nov 1998 08:58:17 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 18 Nov 1998 08:58:06 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id IAA62940; Wed, 18 Nov 1998 08:58:00 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Wed, 18 Nov 1998 08:58:04 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Alex,

Thanks for the URL. I had previously found it, but like I said it was "very
hard". My questions to Verisign are:

1) Why isn't there a link to the URL on your home page?
2) There are only 4 certificates listed on the page but IE lists 8 Verisign
certificates and Navigotor lists 6 Verisign certificates. Where are the
fingerprints for those "extra" certificates?

Regards,
Aram

P.S. Please say hello to Hoa Ly (I believe she still works for Verisign).


>> I also find it ironic that it is
>> very hard to find out Verisign's fingerprints from their Web site. 
>
>See https://www.verisign.com/repository/root.html fingerprints of
>VeriSign's root certificates.
>
>Alex



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29545 for ietf-pkix-bks; Wed, 18 Nov 1998 08:26:57 -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 IAA29541 for <[e-mail]>; Wed, 18 Nov 1998 08:26:56 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA09116; Wed, 18 Nov 1998 08:27:53 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA19162; Wed, 18 Nov 1998 08:30:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 08:30:20 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> I also find it ironic that it is
> very hard to find out Verisign's fingerprints from their Web site. 

See https://www.verisign.com/repository/root.html fingerprints of
VeriSign's root certificates.

Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28618 for ietf-pkix-bks; Wed, 18 Nov 1998 07:18:50 -0800 (PST)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28614 for <[e-mail]>; Wed, 18 Nov 1998 07:18:45 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <W0QG6BRX>; Wed, 18 Nov 1998 10:23:13 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David Sweigert'" <[e-mail]>, Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Wed, 18 Nov 1998 10:23:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yes we have.  But the list is long and constantly changing (mostly due to
newly discovered problems--found another one just this morning!).  Sorry,
but I don't have the time right now to go into all this on the list.  Maybe
we can sit down and chat a bit in Orlando.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	David Sweigert [SMTP:[e-mail]]
> Sent:	Tuesday, November 17, 1998 6:10 PM
> To:	Trevor Freeman; 'John Hughes'; [e-mail]
> Subject:	RE: LDAP Schema
> 
> 
> Has anyone in the group run across sources of information
> RE: use of digital certificates with Web SSL and the accompanying
> server performance problems and need for hardware accelerators ?
> 
> Dave Sweigert
>  
> 
> At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
> >Hi John,
> >The Exchange schema is not extensible so you cannot add these classes.
> >however, the mailbox objects do already have a UserCertificate attribute
> >and there is also a CertificateAuthority object in these schema which has
> >most of the required attributes such as CACertificate and
> >certificateRevocationList etc. If you open the directory in Raw mode you
> can
> >see these objects and all of their attributes. 
> >
> >Trevor
> >
> >
> >-----Original Message-----
> >From: John Hughes [mailto:[e-mail]]
> >Sent: Tuesday, November 17, 1998 6:38 AM
> >To: [e-mail]
> >Subject: LDAP Schema
> >
> >
> >Has any one tried to configure Exchange Directory Server 5.5 to support
> the
> >pkiUser and pkiCA object classes.  Is it possible?
> >
> >
> >John
> >
> >
> >
> > -------------------------------------------------------------------
> >| John Hughes             [e-mail]                 |
> >| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
> >|                         Home Fax No:           [phone]  |
> >|                         Main Office Tel:       [phone] |
> >| www.entegrity.com       Mobile:                [phone]   |
> > ------------------------------------------------------------------- 
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA25632 for ietf-pkix-bks; Wed, 18 Nov 1998 04:49:35 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA25628 for <[e-mail]>; Wed, 18 Nov 1998 04:49:34 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id HAA31427 for <[e-mail]>; Wed, 18 Nov 1998 07:53:23 -0500
Message-Id: <4.1.19981118073654.00a50ea0@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 18 Nov 1998 07:46:55 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Can we now kill CMMF?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In describing the new version of the CMC document, Michael Myers wrote that
version 2

>2. Reduces the need for readers to refer to multiple documents by replacing
>references to CMMF with direct specification of functional equivalents.
>

So - I suggest that we now kill the CMMF document, as it serves no useful
purpose.

Approximately one year ago, at the Washington IETF, it was announced that
the CRMF and CMMF documents would be developed to contain the message
formats  to be used by cert management protocols.  This was one of the
resolutions to the CMP vs. then-CRS (now CMC) issue.  It was stated that
the best way to proceed was to specify the common message formats first,
and then let any protocol you wanted to use reference those formats.

Now, however, we find that all of the formats defined in CMMF are
explicitly contained in both CMP and CMC.  Thus, the message format
definitions in CMMF are redundant, and that document serves no apparent
purpose.  (Unless, of course, you want to allow for the possibility that
somebody will develop a third protocol for certificate management, and use
those formats, but I really hope that nobody gets that bright idea.)

So, given this, can we now just let the current CMMF draft expire, and not
do any further work on it?  

(Warning:  hidden agenda alert:  I'm also going to propose down the road
that we take the CRMF definition, put it in CMP and CMC, and let the CRMF
I-D die.  I've never understood why, other than timing concerns, that
occupied a whole different document.)

Comments, dissenting opinions, etc., are welcome.

				Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03629 for ietf-pkix-bks; Tue, 17 Nov 1998 13:14:20 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03625 for <[e-mail]>; Tue, 17 Nov 1998 13:14:19 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id NAA28918 for <[e-mail]>; Tue, 17 Nov 1998 13:06:27 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 17 Nov 1998 13:06:14 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id NAA34174; Tue, 17 Nov 1998 13:06:09 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Tue, 17 Nov 1998 13:06:11 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Another soapbox sermon ;-)

[Stand on soapbox]
PKI is a "key management solution" that greatly eases the key management
problems associated with cryptography but it does not eliminate all of them.
Symmetric cryptography, when using good key management principles (i.e. only
two parties share the same symmetric key), has the inherent problem that the
number of keys needed for a given set of parties grows geometrically. For
example, two parties need 1 key, three parties need 3 keys, four parties
need 6 keys, five parties need 10 keys, etc. Another problem is that a key
has to be manually exchanged, usually by some sort of face-to-face contact
or via a trusted third party (or parties).

When Diffie-Hellman first proposed public key encryption, the idea was that
an individual could "publish" his/her public key (after all, it is "public")
so that it would solve the manual key distribution problem. First, a party
only needs a public key pair (for key exchange) no matter how many parties
are involved. And it would no longer be necessary to have a face-to-face key
exchange since two parties could use each other's public keys to exchange a
symmetric key. Well in theory this works fine but not in practice. Why,
because if both parties are communicating purely electronically, how do they
know that they received the correct public key for the other party and not
the public key from a "man-in-the-middle"?

Well, we being engineers, came up with an easy solution, we created
"certificate authorities" (CAs) which sign public keys so that the keys can
be "trusted". So now a party receiving a public key (in a certificate) can
verify the key by following the chain (or web) of signers to the the CA.
This still leaves the problem of how do you know that the CAs public key
(i.e. the root certificate) is valid and therefore "trusted". I maintain
that the only way of trusting a root certificate is via some sort of manual
(i.e. out-of-band) method. There is no purely electronic way of verifying
root certificates. But I would rather manually verify a "handful" of root
certificates than a large number of public and/or symmetric keys.

Most people who download a browser that comes with root certificates
(whether IE, Navigator or whichever) do not know that they should "manually"
verify the root certificates by checking "fingerprints". If I download IE
from a non-Microsoft site, how do I know that the root certificates have not
been modified (or a bogus one inserted)? I also find it ironic that it is
very hard to find out Verisign's fingerprints from their Web site. Ditto for
GTE CyberTrust.

In conclusion (before the tomatoes start flying ;-), whether you have an
extension or not, you need to manually verify root certificates with some
out-of-band information. And like Tim wrote: "The solutions are to improve
the client software and educate the users". (But the how is not easy.)

[Get down from soapbox]

Regards,
Aram Perez


>Peter,
>
>Both MSIE and Netscape are relying on the user's judgement: the user *must*
>have out-of-band information that the subject is a trustworthy CA, or they
>wouldn't install it as a site certificate, would they??? (If I could
>remember how to make a smiley face, I'd insert it here!)
>
>The basicConstraints extension does not fix this problem, though.  If NIST
>used that extension (and marked it critical) in end entity certificates,
>that prevents me from using my NIST certificate to claim CA status.  I
>don't really need that for the browser scenario.  If I can generate new
>certs, I can generate my own.  When I generate my self-signed certificate I
>might as well include the basicConstraints extension. If I could get folks
>to accept it without that extension, they'll certainly accept with that
>extension.
>
>Clearly, the safest choice would be to select a single trusted CA (or a
>very small number) as the beginning (end?) of all valid paths and only
>accept a subject as a CA if the basicConstraints extension is present.
>(That is, never accept a subject as CA based on out-of-band information.)
>User selected trust points are always fraught with danger.  The solutions
>are to improve the client software and educate the users, in my opinion.
>
>How?  Now that's a tough question!
>
>Tim
>
>
>At 01:08 PM 11/17/98, Peter Gutmann wrote:
>>Tim Polk <[e-mail]> wrote:
>>
>>>If the basic constraints extension is not present, certificate processing
>>>is consistent with v1 or v2 certificates.  If out-of-band information
>>>specifies the subject is a CA, it's a CA.  If out of band information is
>>>not available, the user of the certificate assumes the subject is NOT a
>>>CA.
>>
>>Assertion: If basicConstraints is not present, current software typically
>>           assumes the subject is a CA.
>>Proof: Create a self-signed certificate without basicConstraints, load it
>>       into MSIE or Netscape, and see what happens.
>>
>>>3) If an end entity wishes to accept a certificate without a
>>>basicConstraints extension as a CA certificate, it must rely on
>>>out-of-band information.  In this case, the responsibility lies on the
>>>certificate user and the source of the out-of-band information, not on
>>>the certificate issuer.  The certificate issuer attests to the binding of
>>>subject and key, not the subject's status as a CA.
>>
>>Both MSIE and Netscape treat self-signed certs without basicConstraits as 
>>CA's by default (in fact I don't know of any way to get them to *not* 
>>treat the cert owners as CA's).
>>
>>MSIE: "You have been offered a new site certificate to place in your list
>>       of trusted issuers..."
>>Netscape: "You are about to go through the process of accepting a
>>           certificate authority..."
>>
>>Leaving out the basicConstraints makes the assumption that relying parties
>>are using PKIX-compliant software, and that the software will DTRT when it
>>finds one of these certs.  I think this is leaving what could be a critical
>>security issue more or less to chance - all I need to do is find some
>>software which happens to not follow PKIX's implied behaviour and I can go
>>ahead and issue my own certs and let the entire world in the door.
>>
>>Peter.
>>
>>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00618 for ietf-pkix-bks; Tue, 17 Nov 1998 15:10:53 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA00614 for <[e-mail]>; Tue, 17 Nov 1998 15:10:52 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa19579; 17 Nov 98 18:12 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Nov 1998 18:10:27 -0500
To: Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
From: David Sweigert <[e-mail]>
Subject: RE: LDAP Schema
In-Reply-To: <2F2DC5CE035DD1118C8E00805FFE354C0509BB1E@RED-MSG-56>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Has anyone in the group run across sources of information
RE: use of digital certificates with Web SSL and the accompanying
server performance problems and need for hardware accelerators ?

Dave Sweigert
 

At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
>Hi John,
>The Exchange schema is not extensible so you cannot add these classes.
>however, the mailbox objects do already have a UserCertificate attribute
>and there is also a CertificateAuthority object in these schema which has
>most of the required attributes such as CACertificate and
>certificateRevocationList etc. If you open the directory in Raw mode you can
>see these objects and all of their attributes. 
>
>Trevor
>
>
>-----Original Message-----
>From: John Hughes [mailto:[e-mail]]
>Sent: Tuesday, November 17, 1998 6:38 AM
>To: [e-mail]
>Subject: LDAP Schema
>
>
>Has any one tried to configure Exchange Directory Server 5.5 to support the
>pkiUser and pkiCA object classes.  Is it possible?
>
>
>John
>
>
>
> -------------------------------------------------------------------
>| John Hughes             [e-mail]                 |
>| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
>|                         Home Fax No:           [phone]  |
>|                         Main Office Tel:       [phone] |
>| www.entegrity.com       Mobile:                [phone]   |
> ------------------------------------------------------------------- 
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02532 for ietf-pkix-bks; Tue, 17 Nov 1998 11:03:23 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02528 for <[e-mail]>; Tue, 17 Nov 1998 11:03:22 -0800 (PST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <XC3N7WGP>; Tue, 17 Nov 1998 10:21:13 -0800
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0509BB1E@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Tue, 17 Nov 1998 10:21:05 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk

Hi John,
The Exchange schema is not extensible so you cannot add these classes.
however, the mailbox objects do already have a UserCertificate attribute
and there is also a CertificateAuthority object in these schema which has
most of the required attributes such as CACertificate and
certificateRevocationList etc. If you open the directory in Raw mode you can
see these objects and all of their attributes. 

Trevor


-----Original Message-----
From: John Hughes [mailto:[e-mail]]
Sent: Tuesday, November 17, 1998 6:38 AM
To: [e-mail]
Subject: LDAP Schema


Has any one tried to configure Exchange Directory Server 5.5 to support the
pkiUser and pkiCA object classes.  Is it possible?


John



 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01443 for ietf-pkix-bks; Tue, 17 Nov 1998 08:57:55 -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 IAA01439 for <[e-mail]>; Tue, 17 Nov 1998 08:57:54 -0800 (PST)
Received: 	id LAA06061; Tue, 17 Nov 1998 11:52:24 -0500
Received: by gateway id <W59RVZJ5>; Tue, 17 Nov 1998 11:49:20 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'Tim Polk'" <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Tue, 17 Nov 1998 11:47:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I believe the PKIX text is correct the way it is. It is consistent with
X.509 and takes it one step further. I don't think any change is
warranted here.

> ----------
> From: 	Tim Polk[SMTP:[e-mail]]
> Sent: 	November 17, 1998 9:49 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: Problem with PKIX part 1 basicConstraints
> 
> Peter,
> 
> Both MSIE and Netscape are relying on the user's judgement: the user
> *must*
> have out-of-band information that the subject is a trustworthy CA, or
> they
> wouldn't install it as a site certificate, would they??? (If I could
> remember how to make a smiley face, I'd insert it here!)
> 
> The basicConstraints extension does not fix this problem, though.  If
> NIST
> used that extension (and marked it critical) in end entity
> certificates,
> that prevents me from using my NIST certificate to claim CA status.  I
> don't really need that for the browser scenario.  If I can generate
> new
> certs, I can generate my own.  When I generate my self-signed
> certificate I
> might as well include the basicConstraints extension. If I could get
> folks
> to accept it without that extension, they'll certainly accept with
> that
> extension.
> 
> Clearly, the safest choice would be to select a single trusted CA (or
> a
> very small number) as the beginning (end?) of all valid paths and only
> accept a subject as a CA if the basicConstraints extension is present.
> (That is, never accept a subject as CA based on out-of-band
> information.)
> User selected trust points are always fraught with danger.  The
> solutions
> are to improve the client software and educate the users, in my
> opinion.
> 
> How?  Now that's a tough question!
> 
> Tim
> 
> 
> At 01:08 PM 11/17/98, Peter Gutmann wrote:
> >Tim Polk <[e-mail]> wrote:
> >
> >>If the basic constraints extension is not present, certificate
> processing
> >>is consistent with v1 or v2 certificates.  If out-of-band
> information
> >>specifies the subject is a CA, it's a CA.  If out of band
> information is
> >>not available, the user of the certificate assumes the subject is
> NOT a
> >>CA.
> >
> >Assertion: If basicConstraints is not present, current software
> typically
> >           assumes the subject is a CA.
> >Proof: Create a self-signed certificate without basicConstraints,
> load it
> >       into MSIE or Netscape, and see what happens.
> >
> >>3) If an end entity wishes to accept a certificate without a
> >>basicConstraints extension as a CA certificate, it must rely on
> >>out-of-band information.  In this case, the responsibility lies on
> the
> >>certificate user and the source of the out-of-band information, not
> on
> >>the certificate issuer.  The certificate issuer attests to the
> binding of
> >>subject and key, not the subject's status as a CA.
> >
> >Both MSIE and Netscape treat self-signed certs without
> basicConstraits as 
> >CA's by default (in fact I don't know of any way to get them to *not*
> 
> >treat the cert owners as CA's).
> >
> >MSIE: "You have been offered a new site certificate to place in your
> list
> >       of trusted issuers..."
> >Netscape: "You are about to go through the process of accepting a
> >           certificate authority..."
> >
> >Leaving out the basicConstraints makes the assumption that relying
> parties
> >are using PKIX-compliant software, and that the software will DTRT
> when it
> >finds one of these certs.  I think this is leaving what could be a
> critical
> >security issue more or less to chance - all I need to do is find some
> >software which happens to not follow PKIX's implied behaviour and I
> can go
> >ahead and issue my own certs and let the entire world in the door.
> >
> >Peter.
> >
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00602 for ietf-pkix-bks; Tue, 17 Nov 1998 06:50:18 -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 GAA00598 for <[e-mail]>; Tue, 17 Nov 1998 06:50:16 -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 JAA16729; Tue, 17 Nov 1998 09:47:03 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 17 Nov 1998 09:49:13 -0500
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter,

Both MSIE and Netscape are relying on the user's judgement: the user *must*
have out-of-band information that the subject is a trustworthy CA, or they
wouldn't install it as a site certificate, would they??? (If I could
remember how to make a smiley face, I'd insert it here!)

The basicConstraints extension does not fix this problem, though.  If NIST
used that extension (and marked it critical) in end entity certificates,
that prevents me from using my NIST certificate to claim CA status.  I
don't really need that for the browser scenario.  If I can generate new
certs, I can generate my own.  When I generate my self-signed certificate I
might as well include the basicConstraints extension. If I could get folks
to accept it without that extension, they'll certainly accept with that
extension.

Clearly, the safest choice would be to select a single trusted CA (or a
very small number) as the beginning (end?) of all valid paths and only
accept a subject as a CA if the basicConstraints extension is present.
(That is, never accept a subject as CA based on out-of-band information.)
User selected trust points are always fraught with danger.  The solutions
are to improve the client software and educate the users, in my opinion.

How?  Now that's a tough question!

Tim


At 01:08 PM 11/17/98, Peter Gutmann wrote:
>Tim Polk <[e-mail]> wrote:
>
>>If the basic constraints extension is not present, certificate processing
>>is consistent with v1 or v2 certificates.  If out-of-band information
>>specifies the subject is a CA, it's a CA.  If out of band information is
>>not available, the user of the certificate assumes the subject is NOT a
>>CA.
>
>Assertion: If basicConstraints is not present, current software typically
>           assumes the subject is a CA.
>Proof: Create a self-signed certificate without basicConstraints, load it
>       into MSIE or Netscape, and see what happens.
>
>>3) If an end entity wishes to accept a certificate without a
>>basicConstraints extension as a CA certificate, it must rely on
>>out-of-band information.  In this case, the responsibility lies on the
>>certificate user and the source of the out-of-band information, not on
>>the certificate issuer.  The certificate issuer attests to the binding of
>>subject and key, not the subject's status as a CA.
>
>Both MSIE and Netscape treat self-signed certs without basicConstraits as 
>CA's by default (in fact I don't know of any way to get them to *not* 
>treat the cert owners as CA's).
>
>MSIE: "You have been offered a new site certificate to place in your list
>       of trusted issuers..."
>Netscape: "You are about to go through the process of accepting a
>           certificate authority..."
>
>Leaving out the basicConstraints makes the assumption that relying parties
>are using PKIX-compliant software, and that the software will DTRT when it
>finds one of these certs.  I think this is leaving what could be a critical
>security issue more or less to chance - all I need to do is find some
>software which happens to not follow PKIX's implied behaviour and I can go
>ahead and issue my own certs and let the entire world in the door.
>
>Peter.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00449 for ietf-pkix-bks; Tue, 17 Nov 1998 06:32:11 -0800 (PST)
Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA00445 for <[e-mail]>; Tue, 17 Nov 1998 06:32:10 -0800 (PST)
Received: from m5pqp [195.99.52.123]  by neodymium.btinternet.com with smtp (Exim 1.70 #1) id 0zfmCo-0003ir-00; Tue, 17 Nov 1998 14:34:11 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 17 Nov 1998 14:38:13 +0000
To: "[e-mail]" <[e-mail]>
From: John Hughes <[e-mail]>
Subject: LDAP Schema
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Has any one tried to configure Exchange Directory Server 5.5 to support the
pkiUser and pkiCA object classes.  Is it possible?


John



 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA25539 for ietf-pkix-bks; Mon, 16 Nov 1998 21:31:21 -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 VAA25535 for <[e-mail]>; Mon, 16 Nov 1998 21:31:13 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LNT>; Tue, 17 Nov 1998 16:28:40 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D50A@DSG1>
From: Alan Lloyd <[e-mail]>
To: [e-mail]
Subject: some comments on OCSP vs 7
Date: Tue, 17 Nov 1998 16:28:37 +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

A quick review - and some operational issues.

Also agree with discussion re Explicit tags. I am not concerned re bytes
on the wire - but they are not consistenly used and make the ASN.1
"clunky".


General comments - from a system perspective is the usual Hows and When
issues.

3.2 
1) an OCSP responder can have the same (private) key as the CA who
issues the certs being validated.
There may be more than one OCSP responder and there may be many CAs who
want to use them so that a client can be simplified in a multi cert
domain environment. This just requiresprivate key distribution and
management. Not good IMHO.

2) CA designated responder - this means that the clients requesting
validation by an OCSP responder must also validate the responder - in
the same way they would have validated the CA if the OCSP responder was
not there.


3) The "good" state para is a worry re "a good state does not
necessarily indicate that the certficate was ever issued" ???! All this
engineering and no trust.

4) The "Unknown" state - I suppose that means that the client goes back
to directory based validation or gives up.


3.3
1) Internal Error - OCSP responder in an inconsistent state - try
another server.
If the extensions in the certs contain AuthorityInfoAccess - with a
sequence of entries, then by defintion the client could go through a
sequence of responders - This does mean however, that a system's fault
tolerant strategy and its system configuration is cryptographically tied
to a cert. This is not good as it means a very inflexible system and a
lot of pre knowledge.
If on the other hand this extension is not used - then the fault
management strategy is a client configuration issue. My concern is that
this scenario is a bit like a telephone being configured with all the
PABXs it can talk to. ie. lots of hand configs and not generally
applied.

2) Try Later - Hmmm
left for a long time will cause a failure in the transaction being
verified.
tried rapidly and frequently will cause protocols and servers to burn
out.

How is "try later" applied to make it operationally useful. I get
concerned that timers and counters (as used in lower layer protocols) to
stop looping for ever, are not included in the spec. ie. these things
also need common configuration definition.

3.4
Updates - 
What does the client do if next update is set to an hour or so infront
of the current time.
Should all client software have a "window" in which requests can be
fired off to the OCSP server and valid responses seen - AND that if the
next update is greater than nnnn it does something about it? What is the
process here under these conditions?

3.6. 
1) The client must check that if the OCSP server signature is not that
of the cert issuer, then it must check the OCSP server cert to see if
the extended key usage is set and the the fact that the OCSP server
cert's Issuer CA is a valid signature for the OCSP server's cert. HMMM


3.7
1) This must be corrected as its very bad to have a trusted function?
that "knows" a CA key has been compromised and the MAY mention the fact
to the supported clients.
a) Does the spec need to say how this key knowledge is provided and it
MUST invalidate all.
Otherwise the text has no substance.

4.1
Issue re crypto binding of system config knowledge is IMHO not a good
idea - or otherwise configure the client software - for any server that
will be used by many CAs/originiators of signed transactions. This does
represent a scaling issue in the making.

Thoughts are welcome. But the concerns are of scaling and the multitude
of conditions that need to be dealt with and  at the end of the day, the
client will probably still have to validate the OCSP's sig  cert path
and other certs via the normal method... via directories.

regards alan









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23253 for ietf-pkix-bks; Mon, 16 Nov 1998 17:47:36 -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 RAA23248 for <[e-mail]>; Mon, 16 Nov 1998 17:47:33 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LM7>; Tue, 17 Nov 1998 12:45:03 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D504@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Elliott Ginsburg <[e-mail]>
Cc: [e-mail]
Subject: RE: Fwd: Re: A different architecture
Date: Tue, 17 Nov 1998 12:45:02 +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

Stephen - I think you are to late - Big organisations and the hundreds
if not thousands of people I work with are actually deploying large
scale - application level, business and CA oriented X.500 directory
systems.

If you want the same functionality from DNS as X.500 - one will have to
upgrade it to X.500.
Or one can just put DNS interfaces/servers onto an X.500 system and
migrate DNS to X.500 - see DEN - re DHCP/DNS/RADIUS coupled to X.500.
regards alan

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 10:20
> To:	Elliott Ginsburg
> Cc:	[e-mail]
> Subject:	Re: Fwd: Re: A different architecture
> 
> Elliott,
> 
> >I'm adding to my own message. Someone also stated on the list that we
> do
> >not want to have a directory between our apps and our PKI services.
> But,
> >again, how often today do we have DNS between our apps and our
> network
> >communication services?
> 
> We already need the DNS to make the existing Internet protocols work.
> In
> many apps, we don't need a directory to support certs/CRLs, so the
> introduction of an additional directory system for that purpose
> introduces
> new failure modes.
> 
> steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22513 for ietf-pkix-bks; Mon, 16 Nov 1998 16:22:01 -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 QAA22504 for <[e-mail]>; Mon, 16 Nov 1998 16:21:58 -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 NAA17859 for <[e-mail]>; Tue, 17 Nov 1998 13:08:11 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91126129111896>; Tue, 17 Nov 1998 13:08:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 17 Nov 1998 13:08:11 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tim Polk <[e-mail]> wrote:

>If the basic constraints extension is not present, certificate processing
>is consistent with v1 or v2 certificates.  If out-of-band information
>specifies the subject is a CA, it's a CA.  If out of band information is
>not available, the user of the certificate assumes the subject is NOT a
>CA.

Assertion: If basicConstraints is not present, current software typically
           assumes the subject is a CA.
Proof: Create a self-signed certificate without basicConstraints, load it
       into MSIE or Netscape, and see what happens.

>3) If an end entity wishes to accept a certificate without a
>basicConstraints extension as a CA certificate, it must rely on
>out-of-band information.  In this case, the responsibility lies on the
>certificate user and the source of the out-of-band information, not on
>the certificate issuer.  The certificate issuer attests to the binding of
>subject and key, not the subject's status as a CA.

Both MSIE and Netscape treat self-signed certs without basicConstraits as 
CA's by default (in fact I don't know of any way to get them to *not* 
treat the cert owners as CA's).

MSIE: "You have been offered a new site certificate to place in your list
       of trusted issuers..."
Netscape: "You are about to go through the process of accepting a
           certificate authority..."

Leaving out the basicConstraints makes the assumption that relying parties
are using PKIX-compliant software, and that the software will DTRT when it
finds one of these certs.  I think this is leaving what could be a critical
security issue more or less to chance - all I need to do is find some
software which happens to not follow PKIX's implied behaviour and I can go
ahead and issue my own certs and let the entire world in the door.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22336 for ietf-pkix-bks; Mon, 16 Nov 1998 16:01:16 -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 QAA22331 for <[e-mail]>; Mon, 16 Nov 1998 16:01:10 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LL8>; Tue, 17 Nov 1998 10:58:40 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F6@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: More problems with OCSP
Date: Tue, 17 Nov 1998 10:58:39 +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

> -----Original Message-----
> From:	Peter Gutmann [SMTP:[e-mail]]
> Sent:	Saturday, 7 November 1998 22:19
> To:	[e-mail]; [e-mail]
> Subject:	Re: More problems with OCSP
> 
	[Alan Lloyd]  snip
>   Given a query with an arbitrary
> CertID, it's not possible for an OCSP responder to provide a useful
> response.
	[Alan Lloyd]  Yes - thats precisely why I said OCSP is a
mechanism - not a system design. No information or system model or HOW
it relats to the real world of scaleable systems and their knowledge
properties - makes OCSP a "mechanism".
	regards alan 
> Peter.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22163 for ietf-pkix-bks; Mon, 16 Nov 1998 15:34:01 -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 PAA22159 for <[e-mail]>; Mon, 16 Nov 1998 15:33:58 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LLT>; Tue, 17 Nov 1998 10:31:26 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F2@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Tue, 17 Nov 1998 10:31:24 +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

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Friday, 6 November 1998 14:16
> To:	[e-mail]; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
	[Alan Lloyd]  snip

> [Purely in order to forestall the inevitable comments about "it won't
> scale 
>  and there's no replication and it's not distributed and you can't get
> it with 
>  fuzzy dice and ...", I'll reiterate what I said above: The users
> don't care.  
	[Alan Lloyd]  Its always this line that gets me when its used to
negate the engineering issues of dealing with information (or any)
infrastructure for large scale systems.

	Users of the telephone service dont care about undersea cables,
sats, switches, plesiochronous digital hierarchies, etc But the
engineering and the people that biuld the system do.

	Yes Use what you want.

	I work with many large customers that do care about their
infrastructures and how they deal with services, information and
certificates - and naturally because I am involved with them its
distributed X.500 (with LDAP access).

>   Given the choice, they've gone for the easy-to-use, widely-available
> solution 
>  which does the job. 
	[Alan Lloyd]  These arenot engineering terms - the phone system
or building a large corporate information system is NOT and never will
be a product that is easy to apply - if you want it easy to use) eg
phone systems and what is the job here?

>  I'll continue to support whatever's around and let the
>  users make their own choice, but when it comes to key storage
> mechanisms they 
>  sure aren't choosing X.500 or anything derived from it]
	[Alan Lloyd]  Thats a view - but it depend what you are building
- islands of information for islands of users with simple products or
scaleable, distributed, coherent, secure, large scale, service based
information infrastructures.

	regards alan 
> Peter.
>  
> [0] So-called because it both sucks and blows.
>  


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21419 for ietf-pkix-bks; Mon, 16 Nov 1998 13:50:52 -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 NAA21415 for <[e-mail]>; Mon, 16 Nov 1998 13:50:51 -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 QAA09955; Mon, 16 Nov 1998 16:54:20 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 16 Nov 1998 16:56:28 -0500
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter,


I believe that the PKIX part 1 basicConstraints text is okay.


X.509 v3 does not require that the basicConstraints extension appear in
each certificate.  It simply specifies the processing rules if it is, or
is not, present.  The "NOTES" at the end of the section state:

 

>>>>

<excerpt>1	If this extension is not present or is flagged non-critical
and is not recognized by a certificate-using system, then that system
should use other means to determine if the certified public key may be
used to verify certificate signatures.


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.

</excerpt><<<<<<<<


I believe the current PKIX text is not only consistent with X.509, but
specifies the appropriate practices.  Here's my "logic":


If the basic constraints extension is not present, certificate processing
is consistent with v1 or v2 certificates.  If out-of-band information
specifies the subject is a CA, it's a CA.  If out of band information is
not available, the user of the certificate assumes the subject is NOT a
CA.


If the basic constraints extension appears and is critical, certificate
processing may *only* consider the subject as specified in the
extension.


If the basic constraints extension is present, but is not critical,
certificate processors may honor the specified value, but are not
required to.


So, a certificate's subject is an end entity by default.  Using basic
constraints to specify that the subject is not a CA is a preventive
measure.  Out-of-band information specifying the entity is not a CA is
redundant.


The basic constraints extension OR out-of-band information can specify a
subject is a CA.


Section 4.2.10 requires the extension appear in all CA certificates, and
be marked critical.  The text recommends against placing this extension
in end entity certificates.


This has a few nice properties:

<paraindent><param>left</param>1) CA certificates are explicitly
specified by PKIX compliant CAs.  As a result, out-of-band information is
restricted to the idnetity of the "trusted CA(s)".

2) End entity certificates simply default to end entities.  This means
the majority of certificates will be a little simpler.

3) If an end entity wishes to accept a certificate without a
basicConstraints extension as a CA certificate, it must rely on
out-of-band information.  In this case, the responsibility lies on the
certificate user and the source of the out-of-band information, not on
the certificate issuer.  The certificate issuer attests to the binding of
subject and key, not the subject's status as a CA.

4) If CA wishes to ensure that the certificate user doesn't use the
certificate with out-of-band information to build a longer certificate
path, it may include a critical basicContraints extension stating this.

</paraindent>

Property 3) is actually very useful.  Here's a scenario:  NIST issues
certificates to NIST employees, but not contractors.  NIST issues
certificates to NIST employees, including me, omitting the
basicConstraints extension.  I issue certificates to contractors working
in the PKI lab.  Other folks on the NIST PKI project use out-of-band
information to determine that I'm a CA, and trust those certificates. 
It's not the NIST CA's concern, since the remainder of NIST is not fooled
into trusting those certificates.


By omitting the extension, we leave lots of flexibility.  The NIST PKI
maintains revocation information for me; if my key is compromised, the
NIST CA revokes my certificate and even the NIST PKI project team rejects
the contractors' certificates.


I don't know if anyone will use this feature, but it is conceptually
quite attractive.


Property 4) is also useful.  As a commercial vendor, I might charge more
to issue certificates to CAs than end entities.  By inserting a critical
basicConstraints extension, I keep my customers from ripping me off.


All in all, I think the PKIX profile for basicConstraints works correctly
and is consistent with X.509v3.



The FPKI profile predated the PKIX profile, and is out of synch in
several areas.  Now that PKIX is stable, the editor plans to modify the
FPKI profile to be more consistent.  The group that "owns" that document
met last week, and approved the changes.  I believe this is one of the
changes he plans, but I can't find my notes.  I will try to find them and
confirm that.


Thanks,


Tim



At 02:58 PM 11/16/98, Peter Gutmann wrote:

>Section 4.2.1.10 says

> 

>>This extension MUST appear as a critical extension in all CA
certificates.

>>This extension SHOULD NOT appear in end entity certificates.

> 

>This is wrong, because without the basicConstraint to say the subject
isn't a

>CA, a relying party doesn't know how to treat the cert - you need to
have an

>empty sequence there for end entities.  Looking at some other profiles,
both

>X.509v3 (section 14.4.2.1) and the FPKI profile (to take the top two
lying on

>the stack) require an empty sequence for end entities.

> 

>Peter.

> 

>

>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16524 for ietf-pkix-bks; Mon, 16 Nov 1998 05:40:54 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16520 for <[e-mail]>; Mon, 16 Nov 1998 05:40:53 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA00813; Mon, 16 Nov 1998 05:44:06 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 16 Nov 1998 08:37:21 -0500
To: "Tammy Carter" <[e-mail]>, <[e-mail]>, "Dwight Arthur" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Tammy,

	It's the CA's responsibility to track keys.  Comments in line:


At 01:01 PM 11/11/98 -0700, Tammy Carter wrote:
>Al,
>
>How can a piece of software tell if the key's useful lifetime has expired?  
>The onus 
>for such a check must logically be upon (1) the CA, or (2) the client 
>software.  
>[Here I'm assuming that it is unreasonable to expect users to remember when 
>the key in each of their certificates was first created.]
>
>It doesn't seem obvious to me that a CA should make the determination.
>If a CA kept a database containing tuples of 
><public key, subject name, date of issue>, the CA could find that it had 
>issued a certificate with the same public key and the same subject name X
>days/months/years ago given only a CSR (or similar request).  This doesn't
>seem like a good idea for two reasons: 
>(1)  Not all CAs will be able to keep information about every certificate it 
>has
>       ever issued and be able to search it in a reasonable amount of time 
>before
>       issuing a new certificate.

AWA:  Tammy, it's the CA's job to track certificates and do renewals, if
appropriate.  In our system, the CA keeps a database of all certificates it
issued.  Included in each certificate record are things like a copy of the
actual certificate, the date it was originally issued, the key validity
period, how to contact the subject of the certificate,  whether this
certificate has already been renewed, whether this certificate has been
revoked, and some other stuff.  The CA software automatically does the
record creation/update every time the CA takes some action, so the
information is there.  In general, the CA is not allowed to delete records
from the database until they have been "archived" - preserved for long-term
storage via an explicit action. You should only archive records that you
don't actively care about - the certificates have been revoked, or have
expired, or...  So, unless a CA (human being) is being deliberately
malicious or truly imcompetent, there's not a problem searching for and
finding a certficate when a renewal request takes place. 

Renewal can be either pro-active or re-active.  The CA has the capability
to scan the database and find all of the certificates that are about to
expire, say within 30 days or some other window.  The CA can look at these
certs and contact the subjects to see if anything has changed.  If the CA
is satisfied that renewal is appropriate, she can renew the certificate and
send the new one to the user via some appropriate channel - e.g., e-mailing
it, or posting it to a directory.

Alternately, the user can notice that her cert is about to expire, and send
in a renewal request.  The CA will decide whether or not to approve the
request; if it's approved, the CA will do the renewal and send back the new
cert.

>(2)  In order for a user to determine that the key has passed its useful 
>lifetime,
>       they user must try to renew the certificate _with_the_same_CA_ which 
>is not
>       always possible.
>

AWA:  Only the CA that issued a certificate can renew it.  You as a user
can ask a different CA for a *new* certificate with a public key that's
already in another certificate you have.  That new CA (which may not even
know that the public key is one that's already in a different certificate
you have) will make a decision about whether to issue that new certificate.
 But that's not a renewal, because it changes a field other than validity
period, serial number, or signature value.


>That means that the client software should do it.  But, I just don't see how 
>the 
>client software can keep track either.  Well, unless some state is kept with 
>each
>certificate saying when the key was created.  But, then, where is this state 
>stored?
>Surely it should be protected at least by a signature....  But, does it belong
>in a certificate?
>

AWA:  Again, this is all done at the CA.  We tried not to put any
certificate management tasks on the clients unless we absolutely had to.
With a reasonable database at the CA workstation, it's not a major problem.
 It's not as automated as some customers would like - they'd like the
renewal to be completely transparent - but it works well enough.

>Lack of a good way discover how old the key in a particular certificate is 
>seems an
>excellent reason for client software to enforce a new key for each 
>certificate.  If only
>to protect naive users from keeping the same key for years because they
know no
>better or because they can't remember when they last did a rekey.
>

AWA:  If the users/clients want a new key with each certificate, that's
certainly their option.  We support both.  

				Al Arsenault


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA06686 for ietf-pkix-bks; Mon, 16 Nov 1998 00:50:00 -0800 (PST)
Received: from services.editel.cz (services.editel.cz [194.196.54.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA06682 for <[e-mail]>; Mon, 16 Nov 1998 00:49:54 -0800 (PST)
From: [e-mail]
Received: from editelnt.editel.cz ([172.16.2.120]) by services.editel.cz (8.8.8/0.1) with SMTP id JAA09424 for <[e-mail]>; Mon, 16 Nov 1998 09:51:37 +0100
Date: Mon, 16 Nov 1998 9:51:32 +0100
Message-ID: <[e-mail]>
X-Mailer: Mail602 v.3.32
To: [e-mail]
Reply-To: [e-mail]
Subject: draft-ietf-pkix-ipki-part1-11
Sender: [e-mail]
Precedence: bulk

Hi,

I've just noticed some inconsistence in doc draft-ietf-pkix-ipki-part1-11.txt in appendix D - certs and CRLs samples -

D.4 RSA certificate -

field signatureAlgorithm in Certifikate is here:

0579 30 80           : . SEQUENCE (indefinite length)
0581 06 07          7: . . OID
0583 05 00          0: . . NULL
0585 00 00          0: . . end of contents marker

This look strange - the OID value is missing



Regards

IvanZ 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04024 for ietf-pkix-bks; Mon, 16 Nov 1998 00:15:47 -0800 (PST)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA03996 for <[e-mail]>; Mon, 16 Nov 1998 00:15:38 -0800 (PST)
Received: from kiku.itsise ([e-mail] [192.168.2.2]) by atsgw.cyber.ee (8.8.3/8.7.3) with ESMTP id KAA13627; Mon, 16 Nov 1998 10:19:11 +0200
Received: from pahuvere (pahuvere.itsise [192.168.2.140]) by kiku.itsise (8.9.1a/8.9.1) with SMTP id KAA31084; Mon, 16 Nov 1998 10:15:38 +0200
Received: by localhost with Microsoft MAPI; Mon, 16 Nov 1998 10:18:13 +0200
Message-ID: <[e-mail]>
From: Tarvi Martens <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: SEIS:  EID business model? Was CA certificates on smart cards)
Date: Mon, 16 Nov 1998 10:18:12 +0200
Organization: Cybernetica
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

Just couple of thoughts:

First, about directories and LDAP/DAP/X.500 in particular.
We should assume that delivery of certificates and CRL-s does not
require any special technologies. The public certificate should not
contain any confidential information, not talking about CRL-s. In
this case, just any (secured) WWW service should do. If one could
agree on certain rules on this kind of directory service (eg. WebCAP)
the life could be easier for all of us.

The most problematic thing as of today about X.509v3 certificates
(for me) is DN usage/subordination and usage of v3 extensions.
There are evidently different requirements on DN form and usage
of extensions for different
	- communities
	- usages
	- protcols/applications

By communities I mean CA -> certificate holder relationships eg:
	government -> citizen (EID case)
	government -> company
	government -> government (cross-country certification)
	company -> client
	company -> employee
	company -> company
	person -> person

It is evident that these relationships require different DN form (eg government
cannot tell your O= whether company doest not care much about your nationality 
;)

Some certificates are issued today for very specific usages, eg. "tax 
declaration only"
or "database access only".

Some protocols/applications like SSL, SET and S/MIME define usage of v3 
extensions
pretty clearly. However, they are not the only ones in the world.

Our common goal should be to facilitate growth of digital signature 
technologies
in general. We cannot do this top-down. Instead, we should allow for "everyone"
to start running CA services.

If we just could define a profile, regulating usage of DN attributes and v3 
extensions
depenging on community, usage and protocol... then this protocol would be
profitable to follow in order to get hooked with the overall (national, world, 
...) PKI.

Any thoughts or real activities towards this?

Best regards,

Tarvi Martens
Cybernetica



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20139 for ietf-pkix-bks; Sun, 15 Nov 1998 17:54:50 -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 RAA20135 for <[e-mail]>; Sun, 15 Nov 1998 17:54:46 -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 OAA01742 for <[e-mail]>; Mon, 16 Nov 1998 14:58:25 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91118150506680>; Mon, 16 Nov 1998 14:58:25 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 16 Nov 1998 14:58:25 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Section 4.2.1.10 says
 
>This extension MUST appear as a critical extension in all CA certificates.
>This extension SHOULD NOT appear in end entity certificates.
 
This is wrong, because without the basicConstraint to say the subject isn't a
CA, a relying party doesn't know how to treat the cert - you need to have an
empty sequence there for end entities.  Looking at some other profiles, both
X.509v3 (section 14.4.2.1) and the FPKI profile (to take the top two lying on
the stack) require an empty sequence for end entities.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10704 for ietf-pkix-bks; Sat, 14 Nov 1998 16:31:51 -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 QAA10700 for <[e-mail]>; Sat, 14 Nov 1998 16:31:50 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7R9X>; Sat, 14 Nov 1998 16:34:31 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A9F@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'EKR'" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: I-D ACTION:draft-schaad-dhsign-00.txt
Date: Sat, 14 Nov 1998 16:34:29 -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

Eric,

It appears that I need to get a new set of reviews as they all missed this.
I think you are correct and there is a problem in the draft.  I currently
plan to remove the ephermal scheme from the draft on the next revision.

jim


-----Original Message-----
From: EKR [mailto:[e-mail]]
Sent: Friday, November 13, 1998 3:47 PM
To: Jim Schaad (Exchange)
Cc: IETF-PKIX (E-mail)
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt


"Jim Schaad (Exchange)" <[e-mail]> writes:
> This draft is referenced from the new CMC draft so it should be of
interest
> to the readers of that draft.
Jim, 
First, a meta-comment:
Why do we need this at all? DH keys are suitable for computing
DSA signatures. Wouldn't it be simpler just to compute a DSA
signature over the data? This would eliminate the need for a common
group between the sender and recipient.

Secondly, I don't believe that the ephemeral scheme is strong.
Provided that the attacker has access to the triplet
g,p,Ys (sender's public key), it's trivial for him to compute
a private key Xe such that he knows:
  
Ye^Xe = g^(XsXe) 

This allows him to forge any number of signed messages
Remember, computing the DH shared secret requires access
to only one of the DH private keys.

I hesitate to bring this up because I'm sure I'm missing something
really obvious, but I sure can't see what it is.

Confused,
-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02023 for ietf-pkix-bks; Fri, 13 Nov 1998 17:54: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 RAA02019 for <[e-mail]>; Fri, 13 Nov 1998 17:54: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 RAA14490; Fri, 13 Nov 1998 17:58:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 13 Nov 1998 17:57:05 -0800
To: EKR <[e-mail]>, "Jim Schaad (Exchange)" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <"Jim Schaad's message of "Fri, 13 Nov 1998 12:04:29 -0800"> <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:46 PM 11/13/98 -0800, EKR wrote:

>Secondly, I don't believe that the ephemeral scheme is strong.
>Provided that the attacker has access to the triplet
>g,p,Ys (sender's public key), it's trivial for him to compute
>a private key Xe such that he knows:
>  
>Ye^Xe = g^(XsXe)

Since g^(Xs) = Ys, don't you mean Ys^Xe = g(XsXe) ?

So you use the shared secret Ys^Xe = g(XsXe).  The recipient
must calculate the same shared secret, using the "Xr" of their
own keypair (Xr,Yr), and the (supposed) sender's Ys.  I believe
DH key agreement needs both sides public keys to be "certified"
or otherwise already trusted by both parties.
 
The DSA and DH methods rest upon the "hardness" of inverting
the exponential.  Given you know g, p, and Y (Y = (g^X)mod p)
you should not be able to recover X (in human time, anyway).
But I gather you didn't intend to say you could recover X.
 
>
>This allows him to forge any number of signed messages
>Remember, computing the DH shared secret requires access
>to only one of the DH private keys.

Perhaps I don't understand ALL the issues;)  My understanding:

  Let (Xs,Ys) = sender's keypair
  Let (Xr,Yr) = recipient's keypair
 
  SENDER calculates:     Yr^Xs = g^(XrXs) = SharedSecret1
  RECIPIENT calculates:  Ys^Xr = g^(XsXr) = SharedSecret1

Now, for an impostor to pose as SENDER to the RECIPIENT, they
would need either the sender's Xs or the recipient's Xr.  But
each of these are supposedly secret.

Is the "ephemeral" scheme different than this?
 
>Confused,

Me too.
___tony___

>-Ekr
>
>-- 
>[Eric Rescorla                                   [e-mail]]
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01121 for ietf-pkix-bks; Fri, 13 Nov 1998 15:41:58 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01117 for <[e-mail]>; Fri, 13 Nov 1998 15:41:52 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id PAA19896; Fri, 13 Nov 1998 15:46:40 -0800 (PST)
To: "Jim Schaad (Exchange)" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt
References: <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
From: EKR <[e-mail]>
Date: 13 Nov 1998 15:46:39 -0800
In-Reply-To: "Jim Schaad's message of "Fri, 13 Nov 1998 12:04:29 -0800"
Message-ID: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Jim Schaad (Exchange)" <[e-mail]> writes:
> This draft is referenced from the new CMC draft so it should be of interest
> to the readers of that draft.
Jim, 
First, a meta-comment:
Why do we need this at all? DH keys are suitable for computing
DSA signatures. Wouldn't it be simpler just to compute a DSA
signature over the data? This would eliminate the need for a common
group between the sender and recipient.

Secondly, I don't believe that the ephemeral scheme is strong.
Provided that the attacker has access to the triplet
g,p,Ys (sender's public key), it's trivial for him to compute
a private key Xe such that he knows:
  
Ye^Xe = g^(XsXe) 

This allows him to forge any number of signed messages
Remember, computing the DH shared secret requires access
to only one of the DH private keys.

I hesitate to bring this up because I'm sure I'm missing something
really obvious, but I sure can't see what it is.

Confused,
-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29507 for ietf-pkix-bks; Fri, 13 Nov 1998 12:01:58 -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 MAA29503 for <[e-mail]>; Fri, 13 Nov 1998 12:01:57 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7L3G>; Fri, 13 Nov 1998 12:04:31 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: I-D ACTION:draft-schaad-dhsign-00.txt
Date: Fri, 13 Nov 1998 12:04:29 -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

This draft is referenced from the new CMC draft so it should be of interest
to the readers of that draft.

>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-schaad-dhsign-00.txt
>Date: Fri, 13 Nov 1998 10:46:45 -0500
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: Diffie-Hellman Signing Algorithm
>	Author(s)	: H. Prafullchandra, J. Schaad
>	Filename	: draft-schaad-dhsign-00.txt
>	Pages		: 8
>	Date		: 12-Nov-98
>	
>This document describes a method 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.  This document
>describes two different flavors of the signature algorithm, one using a
>D-H key from a CA and the other using a temporary key created by the
>signer.
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>	"get draft-schaad-dhsign-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-schaad-dhsign-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nic.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[e-mail].  In the body type:
>	"FILE /internet-drafts/draft-schaad-dhsign-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.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-schaad-dhsign-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-schaad-dhsign-00.txt>


--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28185 for ietf-pkix-bks; Fri, 13 Nov 1998 09:41:05 -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 JAA28181 for <[e-mail]>; Fri, 13 Nov 1998 09:41:04 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfpis21778; Fri, 13 Nov 1998 12:43:27 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA29586; Fri, 13 Nov 98 12:41:26 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA16934; Fri, 13 Nov 1998 12:43:25 -0500
Date: Fri, 13 Nov 1998 12:43:25 -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: Proposal for a new CRL extension
References: <[e-mail]> <002201be0f1c$71bc0140$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Phillip" == Phillip M Hallam-Baker <[e-mail]> writes:

 Phillip> I think the idea is a good one, but only up to a point. I
 Phillip> considered an ordered CRL extension at length earlier in the
 Phillip> year when I for some reason I was spending a lot of time
 Phillip> thinking about CRLs.

 Phillip> The problem that was put to me was one of backwards
 Phillip> compatibility. If the extension is to be any use in a legal
 Phillip> sense it has to be marked critical which breaks backwards
 Phillip> compatibility.

I don't understand that.

If you sort the CRL and indicate this, and I don't recognize the
extension, that has to mean that I don't have code that optimizes the
handling of sorted CRLs.  Instead, I treat all CRLs as unsorted.

Nothing bad happens.  Since nothing bad happens, the extension must
not be marked critical.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27208 for ietf-pkix-bks; Fri, 13 Nov 1998 07:41:59 -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 HAA27204 for <[e-mail]>; Fri, 13 Nov 1998 07:41:58 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11910; Fri, 13 Nov 1998 10:44:55 -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-02.txt
Date: Fri, 13 Nov 1998 10:44:55 -0500
Sender: [e-mail]
Precedence: bulk

--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, B. Fox, J. Weinstein
	Filename	: draft-ietf-pkix-cmc-02.txt
	Pages		: 37
	Date		: 12-Nov-98
	
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].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmc-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-02.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-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-02.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 HAA27186 for ietf-pkix-bks; Fri, 13 Nov 1998 07:39:14 -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 HAA27181; Fri, 13 Nov 1998 07:39:14 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA29270; Fri, 13 Nov 1998 07:39:48 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA06226; Fri, 13 Nov 1998 07:42:09 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Date: Fri, 13 Nov 1998 10:44:05 -0500
Message-ID: <002201be0f1c$71bc0140$[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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

I think the idea is a good one, but only up to a point. I considered an
ordered CRL extension at length earlier in the year when I for some
reason I was spending a lot of time thinking about CRLs.

The problem that was put to me was one of backwards compatibility. If
the extension is to be any use in a legal sense it has to be marked 
critical which breaks backwards compatibility.

Also I started to go off the idea when I rediscovered scopes for OCDP
since the length of the CRL can then be absolutely bounded to an arbitrary
limit.

The CRL processing problem is much less of a problem IMNSHO as the 'we
can't stuff a darn CRL into our IPSEC handshake' problem.


Its a valid point though and the cost of adding it to the profile would
not be very high. If the list thinks there is value we could add the 
proposal to the OCDP draft, rename it extended certificate processing and
use it as a vehicle for similar CRL optimizations that may turn out to be
usefull.

The application I would envisage is for managing very large archival CRLs
where the cost of a possibly unnecssary extension is not very significant.


		Phill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Thursday, November 12, 1998 3:16 PM
> To: [e-mail]
> Subject: Proposal for a new CRL extension
> 
> 
> The entries in CRLs are not ordered. This means that a CRL-reading client
> must read the entire CRL to know if a particular certificate is revoked.
> That's pretty wasteful, it seems to me.
> 
> I would like to propose a new non-critical CRL extension that would say
> that the revokedCertificates sequence is in the ascending order either by
> userCertificate or by revocationDate. I don't see any problem with this,
> but wanted input before I wrote up the draft.
> 
> Comments?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17045 for ietf-pkix-bks; Thu, 12 Nov 1998 15:14:49 -0800 (PST)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17041 for <[e-mail]>; Thu, 12 Nov 1998 15:14:49 -0800 (PST)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA26365 for <[e-mail]>; Thu, 12 Nov 1998 15:18:15 -0800 (PST)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <WX1ZQ73A>; Thu, 12 Nov 1998 15:17:19 -0800
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 15:17:17 -0800
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

Paul

Going back to the "you have to read it all anyways argument", it seems to me
that there are several ways to improve the CRL checking speed already
without inventing any new modifiers.  Consider the following:


a)  The size of any given CRL message can be controlled at the CA by simply
assigning the distribution points judiciously.  For example, one could
switch to a new CRL after every 500 certificates, thus putting an absolute
upper bound on the size of any given CRL.

b)  The clever programmer, after retrieving and checking the signature of a
CRL record, can easily construct searchable lists internally using his own
favorite algorithm (B-tree, hash-table, linked lists ... the list is
endless).

I'd say that all of this is an implementation issue, and should not be
present in a standard.

David



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16698 for ietf-pkix-bks; Thu, 12 Nov 1998 14:59:01 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16692; Thu, 12 Nov 1998 14:58:59 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id PAA07307; Thu, 12 Nov 1998 15:03:48 -0800 (PST)
To: Paul Hoffman / IMC <[e-mail]>
Cc: "Kurn, David" <[e-mail]>, [e-mail]
Subject: Re: Proposal for a new CRL extension
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 12 Nov 1998 15:03:46 -0800
In-Reply-To: Paul Hoffman / IMC's message of "Thu, 12 Nov 1998 13:36:55 -0800"
Message-ID: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Paul Hoffman / IMC <[e-mail]> writes:

> >If I am not mistaken, CRL's are signed.  How can you verify the signature
> >unless you read the entire CRL?
> 
> Your read the entire CRL once to verify the signature. You store the CRL
> with some marking that it is valid. You later read it looking for certificates.
> 
> Yes, you could extract and sort the certificates when you validated the
> CRL, but that means many more steps than just keeping the CRL in some place
> that you trust.
Paul,
This really isn't that useful an optimization. Firstly, pretty 
much every ASN.1 codec I know of decodes the entire message
in one shot, so you've got to run over the entire message
anyway. The extra comparisons aren't that expensive.

But, for the sake of argument, let's assume that you have
an ASN.1 codec that is incremental. You still can't use
binary search, because you have to at least partially decode
entry n in order to know where entry n+1 starts. Consequently,
you now have to use linear search, so on average you have to
read half the CRL. This seems like a lot of standardization
work for a factor of two speedup.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15508 for ietf-pkix-bks; Thu, 12 Nov 1998 13:46:58 -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 NAA15503; Thu, 12 Nov 1998 13:46:57 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7CC6>; Thu, 12 Nov 1998 13:49:16 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A8A@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "Kurn, David" <[e-mail]>, [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 13:49: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

Additionally there is a big difference between just running the set of items
on the CRL through a hash function to verify the signature (which can be
done as a binary stream), and parsing the contents of the list and doing
comparisions of the serial numbers on each item in the list.   Having the
list sorted allows one to optimize the search and reduce the number of
comparisons done.

jim schaad

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Thursday, November 12, 1998 1:37 PM
To: Kurn, David; [e-mail]
Subject: RE: Proposal for a new CRL extension


>If I am not mistaken, CRL's are signed.  How can you verify the signature
>unless you read the entire CRL?

Your read the entire CRL once to verify the signature. You store the CRL
with some marking that it is valid. You later read it looking for
certificates.

Yes, you could extract and sort the certificates when you validated the
CRL, but that means many more steps than just keeping the CRL in some place
that you trust.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15271 for ietf-pkix-bks; Thu, 12 Nov 1998 13:35:34 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15236; Thu, 12 Nov 1998 13:33:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 13:34:11 -0800
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Cc: "'Hoyt Kesterson'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:48 PM 11/12/98 -0500, Sharon Boeyen wrote:
>fyi - in the X.509 meeting in Sept, a new extension that does some of
>what you want, was added to to the text that will be issued for PDAM
>ballot shortly.

I'll take this as meaning that I don't need to do the extension draft. I
think someone (probably an implementor) should be keeping track of
extensions to PKIX part 1 that are being added by the PDAM folk so that we
can pull them together in a draft, maybe in six months or so.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15240 for ietf-pkix-bks; Thu, 12 Nov 1998 13:33:59 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15234; Thu, 12 Nov 1998 13:33:57 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 13:36:55 -0800
To: "Kurn, David" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Proposal for a new CRL extension
In-Reply-To: <[e-mail]. tandem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>If I am not mistaken, CRL's are signed.  How can you verify the signature
>unless you read the entire CRL?

Your read the entire CRL once to verify the signature. You store the CRL
with some marking that it is valid. You later read it looking for certificates.

Yes, you could extract and sort the certificates when you validated the
CRL, but that means many more steps than just keeping the CRL in some place
that you trust.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14623 for ietf-pkix-bks; Thu, 12 Nov 1998 13:02:03 -0800 (PST)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14618; Thu, 12 Nov 1998 13:02:02 -0800 (PST)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA09812; Thu, 12 Nov 1998 13:05:27 -0800 (PST)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <WX1ZQZ6X>; Thu, 12 Nov 1998 13:04:32 -0800
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 13:04:30 -0800
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

Paul

If I am not mistaken, CRL's are signed.  How can you verify the signature
unless you read the entire CRL?

David Kurn
Compaq Computer Corp.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Thursday, November 12, 1998 12:16 PM
To: [e-mail]
Subject: Proposal for a new CRL extension


The entries in CRLs are not ordered. This means that a CRL-reading client
must read the entire CRL to know if a particular certificate is revoked.
That's pretty wasteful, it seems to me.

I would like to propose a new non-critical CRL extension that would say
that the revokedCertificates sequence is in the ascending order either by
userCertificate or by revocationDate. I don't see any problem with this,
but wanted input before I wrote up the draft.

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14480 for ietf-pkix-bks; Thu, 12 Nov 1998 12:54:04 -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 MAA14475; Thu, 12 Nov 1998 12:54:01 -0800 (PST)
Received: 	id PAA00436; Thu, 12 Nov 1998 15:53:37 -0500
Received: by gateway id <W1GJNVPF>; Thu, 12 Nov 1998 15:50:40 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Paul Hoffman / IMC'" <[e-mail]>
Cc: "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 15:48:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Paul,

fyi - in the X.509 meeting in Sept, a new extension that does some of
what you want, was added to to the text that will be issued for PDAM
ballot shortly.

The extension is:

The ordered list extension identifies that a list of revoked
certificates in the revokedCertificates field of a CRL is ordered by
certificate serial number, in increasing order. This field is defined as
follows:
orderedList EXTENSION	::= {
	SYNTAX	BOOLEAN DEFAULT FALSE
	IDENTIFIED BY	id-ce-orderedList }
This extension is always non-critical. 
If orderedList is present and set to TRUE, the list of certificates is
ordered by serial number in increasing order. If orderedList is present
and set to FALSE, the list of certificates is either unordered or in
some order other than increasing by serial number. If orderedList is not
present, no information is provided as to the ordering, if any, of the
list of revoked certificates in the CRL.

I'm still working on the editing from the meeting but the document
should be posted on the Bull ftp site maintained by Hoyt Kesterson
sometime next week.

Although for this particular extension, this is the extent of what was
agreed at that meeting, changes and further enhancements can be made
during the PDAM ballot phase. 

As with the current edition of X.509, input from IETF groups on relevant
parts of that spec will obviously be welcome inputs to the 509 process.
The revocation enhancements will be of particular relevance to the PKIX
WG. 

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	November 12, 1998 3:16 PM
> To: 	[e-mail]
> Subject: 	Proposal for a new CRL extension
> 
> The entries in CRLs are not ordered. This means that a CRL-reading
> client
> must read the entire CRL to know if a particular certificate is
> revoked.
> That's pretty wasteful, it seems to me.
> 
> I would like to propose a new non-critical CRL extension that would
> say
> that the revokedCertificates sequence is in the ascending order either
> by
> userCertificate or by revocationDate. I don't see any problem with
> this,
> but wanted input before I wrote up the draft.
> 
> Comments?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13929 for ietf-pkix-bks; Thu, 12 Nov 1998 12:13:09 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA13925 for <[e-mail]>; Thu, 12 Nov 1998 12:13:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 12:16:06 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Proposal for a new CRL extension
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

The entries in CRLs are not ordered. This means that a CRL-reading client
must read the entire CRL to know if a particular certificate is revoked.
That's pretty wasteful, it seems to me.

I would like to propose a new non-critical CRL extension that would say
that the revokedCertificates sequence is in the ascending order either by
userCertificate or by revocationDate. I don't see any problem with this,
but wanted input before I wrote up the draft.

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10046 for ietf-pkix-bks; Thu, 12 Nov 1998 08:22:00 -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 IAA10039 for <[e-mail]>; Thu, 12 Nov 1998 08:21:59 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA01098; Thu, 12 Nov 1998 08:22:30 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA27264; Thu, 12 Nov 1998 08:24:51 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 12 Nov 1998 08:24:53 -0800
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: CMC Update
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

All,

At the Chicago meeting, some issues were raised from the floor regarding
CMC (in WG Last Call).  Follow-up uncovered additional problems, leading
the CMC authors to initiate a comprehensive joint review of the protocol's
requirements and mechanisms.  The draft "draft-ietf-pkix-cmc-02.txt" is the
outcome of our working sessions.  In summary, this draft:

1. Has been reorganized to better reflect its role in meeting user needs,
especially those of the S/MIME, IPSEC and TLS communities. Refinements in
support of dual key operations and automated administration were considered
essential.

2. Reduces the need for readers to refer to multiple documents by replacing
references to CMMF with direct specification of functional equivalents.

3. Maintains interoperability with CRMF via a requirement that CRMF MUST be
implemented at the server while it MAY be implemented in the client.

4. Reinstates the requirement to implement support for standalone PKCS#10,
which had been agreed to long ago by the working group, and was
inadvertently dropped.

5. Clarifies use of the protocol in conjunction with the role of
Registration Authorities.

6. Refines proof of possession requirements and mechanisms to improve
implementability.

7. Proposes an industry-standard method of proving identity based on a
shared secret between the certificate requestor and the verifying authority.

8. Facilitates (optional) end-user emergency key recovery mechanisms
against several constraints and key generation options.

We believe that this draft is a much-improved work product and invite your
comments. A temporary copy is available at
<http://www.imc.org/ietf-pkix/temp-cmc-02.txt>. After the Internet Drafts
editor has posted it to the official drafts directory, it will be available
from the URL that the most up-to-date version is always available, which is
<http://www.imc.org/draft-ietf-pkix-cmc>.



Michael Myers   (VeriSign)			
Xiaoyi Liu      (Cisco)
Barbara Fox     (Microsoft)				
Jeff Weinstein  (Netscape)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA09323 for ietf-pkix-bks; Thu, 12 Nov 1998 07:17:39 -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 HAA09318 for <[e-mail]>; Thu, 12 Nov 1998 07:17:38 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA14619 for <[e-mail]>; Thu, 12 Nov 1998 10:21:02 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA14599 for <[e-mail]>; Thu, 12 Nov 1998 10:20:58 -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 KAA07840 for <[e-mail]>; Thu, 12 Nov 1998 10:20:00 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 12 Nov 1998 10:20:55 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 12 Nov 1998 10:20:54 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: email oid
Date: Thu, 12 Nov 1998 10:20:53 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Thanks for the information.  

Now, please enlighten me on another (possible mis-) conception that I
have.  Given that there may be a need to validate a certificate path by
relying on information in a repository, what are the implications of
having an object (pkcs#9 email address) as an element of the issuer
and/or subject name, and having the 'corresponding' data object in a
repository identified by the oid for rfc822mailbox?  Does the repository
have to 'map' the two?

My concern is a disconnect between the naming in a certificate and the
storage of potential path information in a repository that requires
additional/complex code. 

Sandi

>----------
>From: 	Russ Housley[SMTP:[e-mail]]
>Sent: 	Tuesday, November 10, 1998 4:09 PM
>To: 	[e-mail]; [e-mail]
>Cc: 	[e-mail]; [e-mail]
>Subject: 	Re: email oid
>
>I just took a look atRFC 1274.  I do not see anything in that document that
>leads me to believe that rfc822mailbox was intended to be used as a
>component of a Distrinuished Name.  It is clearly defining an attribute for
>sotorage in an X.500 directory.
>
>On the other hand, I know that the PKCS#9 emailAddress attribute is used as
>a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone using
>PKCS#9 emailAddress as an attribute in a X.500 directory.
>
>Maybe there is not an issue...
>
>Russ
>
>
>At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
>>Sue,
>>
>>Adding the additional OID would not be the optimum solution.  Since if I
>>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>>problem.  pkix should NOT perpetuate the problem by again calling the same
>>thing two different names.
>>
>>Robert
>>
>>-----Original Message-----
>>From: Miklos, Sue A. <[e-mail]>
>>To: 'Russ Housley' <[e-mail]>
>>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>>'[e-mail]' <[e-mail]>
>>Date: Friday, October 30, 1998 2:34 PM
>>Subject: RE: email oid
>>
>>
>>>Russ, and others, may I then request that it be included or is that not
>>>possible?
>>>
>>>Sandi
>>>
>>>>----------
>>>>From: Russ Housley[SMTP:[e-mail]]
>>>>Sent: Friday, October 30, 1998 1:35 PM
>>>>To: Miklos, Sue A.
>>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>>Subject: Re: email oid
>>>>
>>>>Sandi:
>>>>
>>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>>
>>>>Russ
>>>>
>>>>
>>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>>All,
>>>>>In the specifications for the schema for an international defense
>>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>>registered
>>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>>I would like to request that this remain in whatever documentation you
>>>>>develop.
>>>>>
>>>>>Thanks,
>>>>>Sandi Miklos
>>>>>>
>>>>>>
>>>>>>----------
>>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>>Subject: RE: email oid
>>>>>>
>>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>>if there is a demand for it.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>>To: [e-mail]
>>>>>>Subject: email oid
>>>>>>
>>>>>>
>>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>>problem
>>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>>specifies
>>>>>>that the oid used for an email address in the distinguished name is
>>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>>mail
>>>>>>as specified in RFC1274.
>>>>>>
>>>>>>Since I believe that the intention is for both of these oids are meant
>>to
>>>>>>represent attributes that hold the same information, this discrepancy
>>may
>>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>>change part1 to refer to the more commonly used OID.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01889 for ietf-pkix-bks; Wed, 11 Nov 1998 17:24:03 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01838; Wed, 11 Nov 1998 17:21:23 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA12824; Wed, 11 Nov 1998 17:23:38 -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: Tue, 10 Nov 1998 17:24:42 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Diffie-Hellman Public Key Validation
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 09 Nov 1998 15:45:02 EST."             <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

>> I guess that we will have to determine whether or not the CA performed
>> public key validation prior to certification from the certificate policy
>> OID.  This is not a very nice answer, but I cannot come up with another 
>> answer.
>
>Can you produce some proposed text for this? Is there a fixed set of
>OIDs that are appropriate or do you need an ever-growing lookup table?

For now, I think that we should simply say that the public key validation
does not need to be performed by the end entity if the CA did the
validation at the time the public key was certified.  I think that the PKIX
group should propose a mechanism for indicaing that validation was done in
a certificate.  Once that is specified, we can duplicate the information in
the S/MIME documents before DRAFT standard.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29253 for ietf-pkix-bks; Wed, 11 Nov 1998 14:20:49 -0800 (PST)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29249 for <[e-mail]>; Wed, 11 Nov 1998 14:20:47 -0800 (PST)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id IAA07424; Thu, 12 Nov 1998 08:22:14 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Santosh Chokhani <[e-mail]>
cc: "'Simonetti David'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Path Validation Variables 
In-reply-to: Your message of "Tue, 10 Nov 1998 16:22:54 EST." <51BF55C30B4FD1118B4900207812701E20B1AE@WUHER> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 12 Nov 1998 08:22:11 +1000
From: Dean Povey <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA29250
Sender: [e-mail]
Precedence: bulk

>I agree with Dave that the current draft does not permit an application
>force policy checking.
>

Ditto.  I think this is a valid point.  Is it possible for someone to update 
the Certificate profile if there are no other objections?


-- 
Dean Povey,         | e-m: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27851 for ietf-pkix-bks; Wed, 11 Nov 1998 11:58:39 -0800 (PST)
Received: from cpl-mh.cpl.novell.com (cpl-gw-hub.cpl.novell.com [147.2.71.30]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA27847 for <[e-mail]>; Wed, 11 Nov 1998 11:58:37 -0800 (PST)
Received: from HUB-EMEA2-Message_Server by cpl-mh.cpl.novell.com with Novell_GroupWise; Wed, 11 Nov 1998 21:01:22 +0100
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 11 Nov 1998 21:01:12 +0100
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 LAA27848
Sender: [e-mail]
Precedence: bulk

Al,

How can a piece of software tell if the key's useful lifetime has expired?  The onus 
for such a check must logically be upon (1) the CA, or (2) the client software.  
[Here I'm assuming that it is unreasonable to expect users to remember when 
the key in each of their certificates was first created.]

It doesn't seem obvious to me that a CA should make the determination.
If a CA kept a database containing tuples of 
<public key, subject name, date of issue>, the CA could find that it had 
issued a certificate with the same public key and the same subject name X
days/months/years ago given only a CSR (or similar request).  This doesn't
seem like a good idea for two reasons: 
(1)  Not all CAs will be able to keep information about every certificate it has
       ever issued and be able to search it in a reasonable amount of time before
       issuing a new certificate.
(2)  In order for a user to determine that the key has passed its useful lifetime,
       they user must try to renew the certificate _with_the_same_CA_ which is not
       always possible.

That means that the client software should do it.  But, I just don't see how the 
client software can keep track either.  Well, unless some state is kept with each
certificate saying when the key was created.  But, then, where is this state stored?
Surely it should be protected at least by a signature....  But, does it belong
in a certificate?

Lack of a good way discover how old the key in a particular certificate is seems an
excellent reason for client software to enforce a new key for each certificate.  If only
to protect naive users from keeping the same key for years because they know no
better or because they can't remember when they last did a rekey.

Tammy Green Carter
[e-mail]

>>> Al Arsenault <[e-mail]> 11-5-98 1:26:12 PM >>>
<snip>

> Why use the same key?  Why not - assuming that the useful lifetime hasn't
> expired, it's not a security problem. If the useful lifetime hasn't
> expired, we don't let the cert be renewed.

<snip>

				Al Arsenault




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26008 for ietf-pkix-bks; Wed, 11 Nov 1998 08:31:06 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26004 for <[e-mail]>; Wed, 11 Nov 1998 08:31:05 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id LAA10302 for <[e-mail]>; Wed, 11 Nov 1998 11:39:14 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA01469 for <[e-mail]>; Wed, 11 Nov 1998 11:32:09 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B9.005B9215 ; Wed, 11 Nov 1998 11:40:11 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 17:14:43 +0100
Subject: ASN.1 Toolkit
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Hello Everybody,

does anyone know a free ASN.1 Toolkit for developing ASN.1 specifications and
encoding them. Are there any free resources on the internet?

Thanks for your response
Stefan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20975 for ietf-pkix-bks; Wed, 11 Nov 1998 02:01:11 -0800 (PST)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20959 for <[e-mail]>; Wed, 11 Nov 1998 02:01:05 -0800 (PST)
Received: by relay2.elvis.ru (8.8.5/1.30) id NAA23557; Wed, 11 Nov 1998 13:04:11 +0300 (MSK)
Received: from fangorn(194.190.192.48) by ss10 via smap (V2.0) id xma023533; Wed, 11 Nov 98 13:03:31 +0300
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Wed, 11 Nov 1998 07:03:02 -0300 (GMT)
From: Pavel Krylov <[e-mail]>
To: [e-mail]
Subject: Subject & Issuer ( LDAP V2 )
Sender: [e-mail]
Precedence: bulk

Hi All!
I'd like to ask You:
        If You remember in LDAPv2 there may be such ( for example ) subject :
        ...,1.3.6.1.4.1.1466.0=#04024869,... It means that certificate->LDAP
        converter didn't understand some ObjectId, therefore it put 
        AttributeValue ( to LDAP ) in form #04[len][octet_string]...
        So, the question is : When another side received this LDAP message,
        what kind of asn1 encoding does the side must do for attributeValue to
        make a certificate ? ( I mean that encode to OCTET tag or another 
        one? ).





___________________________________________________
Pavel V.Krylov          [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00613 for ietf-pkix-bks; Tue, 10 Nov 1998 16:22:20 -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 QAA00609 for <[e-mail]>; Tue, 10 Nov 1998 16:22:17 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <VLZFY4S7>; Wed, 11 Nov 1998 11:23:19 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A29@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: email oid
Date: Wed, 11 Nov 1998 11:23:18 +1100
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

I think this convention came about when people wanted to represent an
internet mailbox in a 
version 1 certificate i.e. exensions were not available to carry it and
CA's could more easily modify
DN than extensions in the early days.

Netscape were probably the first to do this.

Rotek's TrustedNet Smart Card Enabled S/MIME Secure Email

WINS

"INTERACT 98  BEST INTERNET, INTRANET & EXTRANET SOLUTION"

See our Web Site for details

Rotek Consulting 
Melbourne, Australia 
[phone] 
[phone] (Fax) 
www.rotek.com.au 


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Wednesday, November 11, 1998 8:09 AM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: email oid
> 
> I just took a look atRFC 1274.  I do not see anything in that document
> that
> leads me to believe that rfc822mailbox was intended to be used as a
> component of a Distrinuished Name.  It is clearly defining an
> attribute for
> sotorage in an X.500 directory.
> 
> On the other hand, I know that the PKCS#9 emailAddress attribute is
> used as
> a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone
> using
> PKCS#9 emailAddress as an attribute in a X.500 directory.
> 
> Maybe there is not an issue...
> 
> Russ
> 
> 
> At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
> >Sue,
> >
> >Adding the additional OID would not be the optimum solution.  Since
> if I
> >have an RDN of EA=[e-mail], am I referring to the
> RFC822mailbox or
> >the pkcs-9 address?  Whichever choice will be wrong sometimes --
> hence the
> >problem.  pkix should NOT perpetuate the problem by again calling the
> same
> >thing two different names.
> >
> >Robert
> >
> >-----Original Message-----
> >From: Miklos, Sue A. <[e-mail]>
> >To: 'Russ Housley' <[e-mail]>
> >Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
> <[e-mail]>;
> >'[e-mail]' <[e-mail]>
> >Date: Friday, October 30, 1998 2:34 PM
> >Subject: RE: email oid
> >
> >
> >>Russ, and others, may I then request that it be included or is that
> not
> >>possible?
> >>
> >>Sandi
> >>
> >>>----------
> >>>From: Russ Housley[SMTP:[e-mail]]
> >>>Sent: Friday, October 30, 1998 1:35 PM
> >>>To: Miklos, Sue A.
> >>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
> >>>Subject: Re: email oid
> >>>
> >>>Sandi:
> >>>
> >>>"Remain" is the issue.  It is not in PKIX part 1!
> >>>
> >>>Russ
> >>>
> >>>
> >>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
> >>>>All,
> >>>>In the specifications for the schema for an international defense
> >>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
> >>>>registered
> >>>>in RFC 1274. This attribute was also called mail in one Internet
> Draft.
> >>>>I would like to request that this remain in whatever documentation
> you
> >>>>develop.
> >>>>
> >>>>Thanks,
> >>>>Sandi Miklos
> >>>>>
> >>>>>
> >>>>>----------
> >>>>>From: Wang, John[SMTP:[e-mail]]
> >>>>>Sent: Thursday, October 29, 1998 9:17 AM
> >>>>>To: 'Robert Klerer'; [e-mail]
> >>>>>Subject: RE: email oid
> >>>>>
> >>>>>It was my understanding that the RSA-pkcs-9 email address OID
> >>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
> >>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
> >>>>>if there is a demand for it.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Robert Klerer [mailto:[e-mail]]
> >>>>>Sent: Thursday, October 29, 1998 8:19 AM
> >>>>>To: [e-mail]
> >>>>>Subject: email oid
> >>>>>
> >>>>>
> >>>>>The other day in trying to accommodate a legacy pki, I ran into a
> >problem
> >>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The
> ASN.1
> >>>>>specifies
> >>>>>that the oid used for an email address in the distinguished name
> is
> >>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.
> I and
> >>>>>others have been using 0.9.2342.19200300.100.1.3 which is for
> internet
> >mail
> >>>>>as specified in RFC1274.
> >>>>>
> >>>>>Since I believe that the intention is for both of these oids are
> meant
> >to
> >>>>>represent attributes that hold the same information, this
> discrepancy
> >may
> >>>>>cause confusion and failures in the future.  My suggestion would
> be to
> >>>>>change part1 to refer to the more commonly used OID.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29434 for ietf-pkix-bks; Tue, 10 Nov 1998 13:21:46 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29430 for <[e-mail]>; Tue, 10 Nov 1998 13:21:45 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1B73>; Tue, 10 Nov 1998 16:22:56 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E20B1AE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Simonetti David'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: RE: Path Validation Variables
Date: Tue, 10 Nov 1998 16:22:54 -0500
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 NAA29431
Sender: [e-mail]
Precedence: bulk

I agree with Dave that the current draft does not permit an application
force policy checking.

> -----Original Message-----
> From:	Simonetti David [SMTP:[e-mail]]
> Sent:	Tuesday, November 10, 1998 3:02 PM
> To:	IETF-PKIX
> Subject:	Path Validation Variables
> 
> The PKIX Profile provides three elements by which to control
> certificate
> policy processing:  the Certificate Policies and Policy Constraint
> extensions, and a set of initial policy identifiers (X.509 calls this
> initial-policy-set).  
> 
> Based on the Basic Path Validation procedues in Section 6.1, these
> three
> elements may interact in a way that allows the application to
> determine:
>  - whether at least one policy present in the initial-policy-set is
> consistently present in all the certs in the certification path (via a
> critical Certificate Policies extension in EACH cert); or
>  - whether at least one policy present in the initial-policy-set is
> present in each cert in the certification path beginning at some point
> (via a critical (or non-critical?) Policy Constraints extension).
> 
> Notice that policy processing in both of these situations is dependent
> on the CA including the associated extension.  Therefore, if these
> extensions are not included in a certificate, then the relying party
> has
> no contribution to this policy processing (initial-policy-set will be
> ignored).
> 
> This seems counterintuitive.  As the relying party I should be allowed
> to have some input on the policies that I accept.  For example, if I
> want my high assurance financial application to only accept other high
> assurance financial certificates, then my application should be able
> to
> implement this constraint.  
> 
> This could be accomplished by setting the initial value of the
> "explicit
> policy state variable" to zero, and including only the "high assurance
> financial certificates" policy into my initial-policy-set.  However,
> PKIX states that the "explicit policy state variable" is set to n+1,
> where n=cert-path-length.  As a result, the initial-policy-set will
> only
> be checked throughout the cert path if the first cert in the path
> includes a policyConstraints extension with requireExplicitPolicy set
> to
> zero.  As a user I have no control over this.
> 
> Has anyone else analyzed this?  X.509 gets around this issue by not
> indicating any initial value for these variables (at least that leaves
> it ambiguous).  I'd like to know if my analysis is valid, and if so
> propose that either there be no recommended initial value for
> "explicit
> policy state variable", or that an initial value of zero be explicitly
> allowed.
> -- 
> David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29311 for ietf-pkix-bks; Tue, 10 Nov 1998 13:06:52 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29307 for <[e-mail]>; Tue, 10 Nov 1998 13:06:51 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.106]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA23175; Tue, 10 Nov 1998 13:08:11 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 16:09:22 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: email oid
Cc: [e-mail], [e-mail]
In-Reply-To: <006f01be044e$f2061e40$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I just took a look atRFC 1274.  I do not see anything in that document that
leads me to believe that rfc822mailbox was intended to be used as a
component of a Distrinuished Name.  It is clearly defining an attribute for
sotorage in an X.500 directory.

On the other hand, I know that the PKCS#9 emailAddress attribute is used as
a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone using
PKCS#9 emailAddress as an attribute in a X.500 directory.

Maybe there is not an issue...

Russ


At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
>Sue,
>
>Adding the additional OID would not be the optimum solution.  Since if I
>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>problem.  pkix should NOT perpetuate the problem by again calling the same
>thing two different names.
>
>Robert
>
>-----Original Message-----
>From: Miklos, Sue A. <[e-mail]>
>To: 'Russ Housley' <[e-mail]>
>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>'[e-mail]' <[e-mail]>
>Date: Friday, October 30, 1998 2:34 PM
>Subject: RE: email oid
>
>
>>Russ, and others, may I then request that it be included or is that not
>>possible?
>>
>>Sandi
>>
>>>----------
>>>From: Russ Housley[SMTP:[e-mail]]
>>>Sent: Friday, October 30, 1998 1:35 PM
>>>To: Miklos, Sue A.
>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>Subject: Re: email oid
>>>
>>>Sandi:
>>>
>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>
>>>Russ
>>>
>>>
>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>All,
>>>>In the specifications for the schema for an international defense
>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>registered
>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>I would like to request that this remain in whatever documentation you
>>>>develop.
>>>>
>>>>Thanks,
>>>>Sandi Miklos
>>>>>
>>>>>
>>>>>----------
>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>Subject: RE: email oid
>>>>>
>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>if there is a demand for it.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>To: [e-mail]
>>>>>Subject: email oid
>>>>>
>>>>>
>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>problem
>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>specifies
>>>>>that the oid used for an email address in the distinguished name is
>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>mail
>>>>>as specified in RFC1274.
>>>>>
>>>>>Since I believe that the intention is for both of these oids are meant
>to
>>>>>represent attributes that hold the same information, this discrepancy
>may
>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>change part1 to refer to the more commonly used OID.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28615 for ietf-pkix-bks; Tue, 10 Nov 1998 11:58:35 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28611 for <[e-mail]>; Tue, 10 Nov 1998 11:58:34 -0800 (PST)
Received: from bah.com ([156.80.128.156]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA2C3D for <[e-mail]>; Tue, 10 Nov 1998 15:02:00 -0500
Message-ID: <[e-mail]>
Date: Tue, 10 Nov 1998 15:02:21 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
Subject: Path Validation Variables
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 LAA28612
Sender: [e-mail]
Precedence: bulk

The PKIX Profile provides three elements by which to control certificate
policy processing:  the Certificate Policies and Policy Constraint
extensions, and a set of initial policy identifiers (X.509 calls this
initial-policy-set).  

Based on the Basic Path Validation procedues in Section 6.1, these three
elements may interact in a way that allows the application to determine:
 - whether at least one policy present in the initial-policy-set is
consistently present in all the certs in the certification path (via a
critical Certificate Policies extension in EACH cert); or
 - whether at least one policy present in the initial-policy-set is
present in each cert in the certification path beginning at some point
(via a critical (or non-critical?) Policy Constraints extension).

Notice that policy processing in both of these situations is dependent
on the CA including the associated extension.  Therefore, if these
extensions are not included in a certificate, then the relying party has
no contribution to this policy processing (initial-policy-set will be
ignored).

This seems counterintuitive.  As the relying party I should be allowed
to have some input on the policies that I accept.  For example, if I
want my high assurance financial application to only accept other high
assurance financial certificates, then my application should be able to
implement this constraint.  

This could be accomplished by setting the initial value of the "explicit
policy state variable" to zero, and including only the "high assurance
financial certificates" policy into my initial-policy-set.  However,
PKIX states that the "explicit policy state variable" is set to n+1,
where n=cert-path-length.  As a result, the initial-policy-set will only
be checked throughout the cert path if the first cert in the path
includes a policyConstraints extension with requireExplicitPolicy set to
zero.  As a user I have no control over this.

Has anyone else analyzed this?  X.509 gets around this issue by not
indicating any initial value for these variables (at least that leaves
it ambiguous).  I'd like to know if my analysis is valid, and if so
propose that either there be no recommended initial value for "explicit
policy state variable", or that an initial value of zero be explicitly
allowed.
-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA24936 for ietf-pkix-bks; Tue, 10 Nov 1998 05:04:30 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA24932 for <[e-mail]>; Tue, 10 Nov 1998 05:04:29 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA16451; Tue, 10 Nov 1998 05:07:04 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 08:00:56 -0500
To: Robert Moskowitz <[e-mail]>, "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail]>
References: <000001be0b17$7a9e4a60$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In reply to Dwight Arthur's first comment:


>1. You state "If the useful lifetime hasn't expired, we don't let the cert 
>be renewed .." I assume that if the useful key life _has_ expired you do not 
>let it renew. But what do you do then? Are you implying that the entire 
>account history associated with this person should be abandoned and the 
>person treated as a brand new contact? This seems to present a security 
>hole.

AWA:  yes, I apologize for the typo. If the key's useful lifetime has
expired, a certificate CANNOT be renewed.  At that point, the certificate
must at be "updated." (Remember that updating means that the key is
replaced, and if no other attributes are changed, we just call this a
"rekey" operation.)  No, we don't get rid of the account history.  We just
add a new record to our CA's database with the new certificate and relevant
information, and tie it to the old record, which we keep.  (You can't get
rid of the old record until you've taken the explicit step of 'archiving' it.)


Then, Bob Moskowitz replied to Dwight's second question:
>>
>>2. If you allow renewals with the same key for the duration of the key's
>>useful life, why not just set the certificate validity to the key's useful
>>life? What's the benefit of expiring and renewing if not to force a new key?
>>If you are pushing full CRL's I understand that expiration gives an
>>opportuinity to purge the CRL. But there are other ways to manage this,
>>perhaps less costly and certainly less of a burden on the subject.
>>(Examples, OCSP, delta CRL)
>
>But delta CRLs do not address the size of the CRL which impacts processing
>time and total size.  These are issues for silicon implementations.
>
>Reasonable expire dates also address the nature of people NOT to notifiy
>that they have moved to other jobs or died....
>

AWA:  That's a good summary.  Basically, setting the certificate validity
period shorter than the useful key lifetime allows us to manage a couple of
logistics issues.  First, for many of my customers, the longest we can
count on anybody being in one job under normal circumstances is three
years.  It's usually less than that; often, incumbency is on the order of a
few months.  And, no matter how many processes you want to institute about
check-out sheets and notifying all of the cognizant authorities when
somebody quits/transfers/gets fired, a few are going to slip through the
cracks because humans make mistakes.  The CA is just not going to be
notified a certain percentage of the time when people leave the
organization, and the farther away the CA/RA are from the users, the higher
that percentage is.  Setting a shorter certificate validity period makes
the default behavior "better" in that it requires the user to take a
positive action to retain access, rather than having access continue for a
couple more years unless something is explicitly revoked.  (One of the
sections I always try to read in any vendor's CP/CPS is the section on
revocation, loss of access, etc.  Most CA vendors are smart enough to cover
their tails; they say something like "if the user should no longer have
this certificate and you don't explicitly notify us to revoke the cert,
nothing that happens afterward is our fault."  That limits their liability,
but it doesn't help enforce security.)

As Bob points out, the second advantage is that you can control CRL size.
Since we don't use delta-CRLs in our system, the overall length of the CRL
that gets shipped around the system is a concern. Since a revoked
certificate is on the CRL until after it expires, having all certificates
good for three years can lead to a large CRL if you have to revoke a big
group of certificates.  Having shorter certificate lifetimes constrains the
size of the CRL to some degree.  Even if the CRL does get huge at one time
because of the revocation of a large group of certificates for some reason,
we can limit the amount of time the CRL is huge.

As Bob also points out, even if we did use delta-CRLs, size would still be
a problem.  We wouldn't necessarily be worried about sending multi-megabit
CRL files, because they'd be broken into pieces.  But, the end-entities
still have to reconstitute the entire CRL from the base and delta lists,
and the entire thing has to be stored and checked.  For some of the devices
we're required to support, that can potentially be a problem.


							Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00510 for ietf-pkix-bks; Mon, 9 Nov 1998 19:07:07 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00505 for <[e-mail]>; Mon, 9 Nov 1998 19:07:06 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12586; Mon, 9 Nov 1998 19:09:44 -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: Mon, 09 Nov 1998 12:41:02 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: [e-mail]
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

PKIX Part 1 is quite clear on this topic.  It recommends that e-mail
addresses belong in subjectAltName.  However, it warns implementors that
PKCS#9 emailAddress attributes are used by S/MIME v2 as part of the subject
Distringuished Name.

Russ

At 09:43 AM 11/5/98 -0500, [e-mail] wrote:
>E-mail addresses in Certificates sounds good, but please do not put them
>into the Certificate's subject.
>
>A Certificate's subject is a singular Name. A Name is a CHOICE of one type:
>RDNSequence.
>
>S/MIME embeds two names into subject: a distinguished name and an e-mail
>address. Embedding multiple names into subject works OK for S/MIME, but does
>not scale. Just imagine 20 or 30 names.
>
>Should a Certificate contain multiple names? Why not!
>
>One solution is to add a CHOICE to Name each time a new application naming
>system is defined. This system is pretty efficient and works in a closed
>system. In an open system, this solution does not scale very well and
>requires everyone to update their systems.
>
>Another solution is to leave Name alone (RDNSequence remains the common
>"handle") and let application's define Extension(s) for their naming
>systems. For example, Alice might choose to integrate all her names (and
>identifiers) into one monolithic Certificate (e.g., social security number,
>credit card account number, checking account number, email address, etc.),
>while Bob might choose to use separate certificates.
>
>Frank Balluffi
>CertCo
>
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, November 04, 1998 5:18 PM
>To: Phillip M Hallam-Baker
>Cc: [e-mail]
>Subject: Re: Scale (and the SRV record)
>
>
>Phill,
>
>Although I'm very late getting into this particular debate due to being
>away on travel (mostly not Internet connected) for almost 2 weeks, I concur
>with several of the themes of your observations, although I might prefer
>storing certs and CRLs in the DNS per se, rather than using DNS records as
>pointers to othyer repositories.
>
>The DNS is the only robust, distributed directory system the Internet has.
>That makes it attractive for two things: storing data, such as certs and
>CRLs, and for its naming tree.  Note that anytime we use a name in a cert
>that is not exactly the same as the name we use in an application, we are
>required to perform a mapping between two name spaces, and that introduces
>another database which imposes significant additional management overhead
>and another place to make errors with adverse security implications.  So,
>for example, for IPsec, i really want certs with DNS names and IP
>addresses, since these are the native name forms that the applications
>employ and upon which access control decisions are made.  For SSL, browsers
>check a DNS name in a certificate against the corresponding portion of the
>URL, and ignore the rest of the DN in the subject field.  For e-mail the
>case may not be so strong, since people may mentally map identifies
>irrespective of e-mail addresses, but even there I worry that cognitive
>overload can eaisly set in and cause people to make perception mistakes.
>(If one has an S/MIME system that automatically checks for the
>correspondence between the "from" address and the sender's DN from his
>cert, instead of presenting the subject DN from the certificate, then the
>above arguments apply.) So, here too, I really prefer certs with e-mail
>addresses, which is a change from a stance I adopted years ago when I wrote
>RFC 1422.
>
>Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21584 for ietf-pkix-bks; Mon, 9 Nov 1998 08:57:51 -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 IAA21579 for <[e-mail]>; Mon, 9 Nov 1998 08:57:50 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA19525; Mon, 9 Nov 1998 08:58:09 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA07889; Mon, 9 Nov 1998 09:00:26 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "David Sweigert" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Larowe, Rick" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "'Paul Koning'" <[e-mail]>, <[e-mail]>
Subject: RE: Scale (and the SRV record) 
Date: Mon, 9 Nov 1998 12:00:57 -0500
Message-ID: <000001be0c02$858f9500$[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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

> This brings up the question of tactical PKI; or digital certs 
> that are "lightweight" -- 1/10th the size of a X.509v3 cert.

Please no! We have explored that particular rathole more than once.

Four years back before there was a large deployed base of X.509v3 on
the Internet the question of encoding format was an open one. Today
there are many toolkits available which perform parsing. The path of
least resistance for an implementer is now to use CAPI or one of the 
numerous third party toolkits.

I don't think the 'handheld' argument is compelling. Having written
a number of X.509 encoders and decoders I don't see writing a 
compact decoder as being much of a problem. If you are willing to
accept a very narrow profile of the PKIX profile a table driven 
decoder can be written in about a Kb of code.

If you profile PKIX very narrowly you can have a certificate with
just the issuer and subject names, a policy attribute and the subject 
key. The overhead over the public key bits being perhaps 100 bytes.

I don't see how a certificate 'a tenth the size' of such a 'liposuctioned'
PKIX cert is going to be possible. The problem with ASN.1 BER and DER
is not the compactness of the representation.


		Phill
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22960 for ietf-pkix-bks; Sun, 8 Nov 1998 06:22:36 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22956 for <[e-mail]>; Sun, 8 Nov 1998 06:22:35 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA95; Sun, 8 Nov 1998 09:25:36 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 08 Nov 1998 09:25:55 -0500
To: "Dwight Arthur" <[e-mail]>, "Al Arsenault" <[e-mail]>, <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <000001be0b17$7a9e4a60$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 07:58 AM 11/8/98 -0500, Dwight Arthur wrote:
>
>2. If you allow renewals with the same key for the duration of the key's
>useful life, why not just set the certificate validity to the key's useful
>life? What's the benefit of expiring and renewing if not to force a new key?
>If you are pushing full CRL's I understand that expiration gives an
>opportuinity to purge the CRL. But there are other ways to manage this,
>perhaps less costly and certainly less of a burden on the subject.
>(Examples, OCSP, delta CRL)

But delta CRLs do not address the size of the CRL which impacts processing
time and total size.  These are issues for silicon implementations.

Reasonable expire dates also address the nature of people NOT to notifiy
that they have moved to other jobs or died....


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22757 for ietf-pkix-bks; Sun, 8 Nov 1998 04:55:40 -0800 (PST)
Received: from dewdrop2.mindspring.com (dewdrop2.mindspring.com [207.69.200.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22753 for <[e-mail]>; Sun, 8 Nov 1998 04:55:39 -0800 (PST)
Received: from NS95LAP005.nscc.com (pool-209-138-0-245.nwrk.grid.net [209.138.0.245]) by dewdrop2.mindspring.com (8.8.5/8.8.5) with SMTP id HAA24836; Sun, 8 Nov 1998 07:58:36 -0500 (EST)
From: "Dwight Arthur" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
Date: Sun, 8 Nov 1998 07:58:26 -0500
Message-ID: <000001be0b17$7a9e4a60$[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.2232.26
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

I have a couple of questions:

1. You state "If the useful lifetime hasn't expired, we don't let the cert
be renewed .." I assume that if the useful key life _has_ expired you do not
letit renew. But what do you do then? Are you implying that the entire
account history associated with this person should be abandoned and the
person treated as a brand new contact? This seems to present a security
hole.

2. If you allow renewals with the same key for the duration of the key's
useful life, why not just set the certificate validity to the key's useful
life? What's the benefit of expiring and renewing if not to force a new key?
If you are pushing full CRL's I understand that expiration gives an
opportuinity to purge the CRL. But there are other ways to manage this,
perhaps less costly and certainly less of a burden on the subject.
(Examples, OCSP, delta CRL)
--------------------------------------------------
p:[phone]                     Dwight Arthur
f:[phone]        Managing Director: Systems
b:[phone]      National Securities Clearing
[e-mail]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
From:	[e-mail] [mailto:[e-mail]] On Behalf Of
Al Arsenault
Sent:	Thursday, November 05, 1998 3:26 PM
To:	Dwight Arthur; [e-mail]
Subject:	RE: Is certificate renewal a good idea?

In the PKI with which I am familiar (which has been operational for more
than 3 and 1/2 years now), we use a couple of different terms:

	renewal:  issue a new certificate with the same DN, the same attributes,
the same key, a different certificate serial number, and a different
validity period

	update:  issue a new certificate with the same DN, but with one or more
new attributes, a new key, a different certificate serial number, and a
different validity period (where here, "attribute" means any field in the
certificate other than the subject DN, issuer DN, certificate serial
number, or validity period).

"Renewal" is used when a user is continuing on in the same job.  E.g.,
certificates are issued for a period of 6 months.  At the end of that time,
the user is in the same job, at the same place, with the same privileges,
etc.  We just give the user a renewed certificate, good for another six
months, because nothing else is changed.  We change the serial number to
distinguish between the old and new certs - it's the issuer/serial number
combination that uniquely identifies the certificate.  And, obviously, the
signature value changes.

Why use the same key?  Why not - assuming that the useful lifetime hasn't
expired, it's not a security problem. If the useful lifetime hasn't
expired, we don't let the cert be renewed.

"Update" is when something else (other than the user's name) has changed -
the user's access authorizations, privileges, etc. In that case, we revoke
the old certificate, because the change may have resulted in the loss of
access, and we want to make sure that the old cert won't work.  We demand a
new key for the same reason.  (Strictly speaking, you wouldn't have to
revoke the old certificate if the change resulted in an increase of access
privileges, but it's administratively easier to just always revoke the old
cert.)

If the only attribute that changes in an "update" is the user's public key,
it's called a "rekey", but the same rules apply.

Note that in a renewal, you can have multiple certificates valid for the
same user at the same time (if you issue the renewal before the old
certificate expires, which is generally considered to be the smart thing to
do).  Since the public key's the same (and thus the associated private
key's the same) it's not a major problem, assuming that the end-entity is
capable of dealing with the fact that there are two certs for the same user
in the repository.

				Al Arsenault


-- these are my opinions only.  They do not necessarily reflect the
opinions of my employer, or of any other organization with which I have a
relationship.




At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>At the National Securities Clearing Corporation we are beginning to face
>renewal requirements. In every case we are talking about same CN, same CA,
>same DN, and different validity period. I would like to say that in all
>cases we will be seeing a new public key, and we would certainly discourage
>the idea or re-certifying the same key, but I cannot guarantee that we will
>never see renewal with the same public key.
>
>Two requirements that we consider critical, but not easily fulfilled given
>the current state of the are, are:
>- DN in renewed certificate is exactly identical to DN in original
>certificate.
>- Start of renewed certificate's validity period is exactly equal to
>expiration of the original certificate's validity period no overlap no gap.
>The renewed certificate would be issued as much as six weeks before the
>start of its validity period.
>--------------------------------------------------
>p:[phone]                     Dwight Arthur
>f:[phone]        Managing Director: Systems
>b:[phone]      National Securities Clearing
>[e-mail]        55 Water Street
>http://www.nscc.com        New York, NY 10041-0082
>
>-----Original Message-----
>>	Actually, the most prevalent case is likely to be:
>>	3) Same CA, different public key, same CN
>>
>Really?  I always thought it would be validity date.  Of course this would
>be about 18 months after PKI rollout.
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA11935 for ietf-pkix-bks; Sat, 7 Nov 1998 15:04:29 -0800 (PST)
Received: from dns05fdr.Firstdatacorp.COM ([170.186.38.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11931 for <[e-mail]>; Sat, 7 Nov 1998 15:04:27 -0800 (PST)
From: [e-mail]
Received: (from smtp@localhost) by dns05fdr.Firstdatacorp.COM (8.9.1a/8.9.1) id QAA19645; Sat, 7 Nov 1998 16:55:03 -0600 (CST)
X-Authentication-Warning: dns05fdr.firstdatacorp.com: smtp set sender to <[e-mail]> using -f
Received: from () by dns05fdr via smap (V2.1) id xma019640; Sat, 7 Nov 98 16:54:58 -0600
Received: by firstdatacorp.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 862566B5.007D9F08 ; Sat, 7 Nov 1998 16:52:07 -0600
X-Lotus-FromDomain: FDC@FDCNOTESPO
To: David Sweigert <[e-mail]>
cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 7 Nov 1998 15:05:15 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

,,,, relying party certificates was something that a european financial
institution brought up at NISSC during e-commerce session (issues addressed
were business issues associated  privacy and liability .... wasn't
technical issue regarding size or bandwidth, etc). In discussions
afterwards .... the processing flow is almost identical to X9.59 and AADS
.... the difference is that one of these certificates flows along with the
transaction and gets to the relying party .... where (if they hadn't
noticed) they had the original (i.e. client was appending a copy of the
certificate to the end of of every transaction sent to the relying pary
.... which had the original ... easy to show it was superfulous).

nissc web site is
                   http://csrc.nist.gov/nissc/1998/

but there is nothing there on that particular discussion.

They also mentioned an evidence server to validate parts of the
infrastructure. That part is also nearly identical to part of an overall
infrastructure that i've been presenting for last 8-9 months (which have
had included europeans in the audience).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11331 for ietf-pkix-bks; Sat, 7 Nov 1998 13:23:23 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA11327 for <[e-mail]>; Sat, 7 Nov 1998 13:23:21 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa11520; 7 Nov 98 16:25 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 07 Nov 1998 16:23:49 -0500
To: [e-mail]
From: David Sweigert <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Lynn:

Sounds very similiar to what you are speaking of.  Is there a formal
articulation of the proposed relying party certificates; and is so
do you have a URL you can point me to ?

Thanks in advance.

dave

At 03:37 PM 11/6/98 -0800, [e-mail] wrote:

>re: tatical certificates; is this similar to or different than the relying
>party certificates that are being proposed (at least in part) because of
>privacy issues (i.e. divulge nothing but an identification number and the
>public key)???
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17288 for ietf-pkix-bks; Fri, 6 Nov 1998 17:47:32 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA17284 for <[e-mail]>; Fri, 6 Nov 1998 17:47:31 -0800 (PST)
Received: (qmail 5102 invoked from network); 7 Nov 1998 01:50:29 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 7 Nov 1998 01:50:29 -0000
Received: (qmail 1448 invoked from network); 7 Nov 1998 01:50:28 -0000
Received: from unknown (HELO rhone) (10.0.0.101) by 10.0.0.4 with SMTP; 7 Nov 1998 01:50:28 -0000
From: "Ambarish Malpani (test)" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: More problems with OCSP
Date: Fri, 6 Nov 1998 17:50:45 -0800
Message-ID: <000c01be09f1$0996aaf0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01BE09AD.FB736AF0"
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

This is a multi-part message in MIME format.

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


Hi Peter,
    Actually, even if you wanted to act as a general OCSP responder,
you would still need to have a set of CAs that you trust - since
you would need to be able to verify their revocation data (or CRL),
to create the OCSP response (except if you assume you have a
trusted directory, whose entries you trust blindly).

Once you have the list of CAs you trust, you should have both their
names and their private keys. So you should be able to act
as a general responder as long as the CAs you trust are a
(improper) superset of the CAs your clients trust.

Ambarish

------=_NextPart_000_000D_01BE09AD.FB736AF0
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Reply-To: <[e-mail]>
From: "Peter Gutmann" <[e-mail]>
Sender: <[e-mail]>
To: <[e-mail]>,
	<[e-mail]>
Subject: Re: More problems with OCSP
Date: Sat, 7 Nov 1998 03:19:25 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz

[I've copied this part of the message back to PKIX because I think it's more
a
 general discussion of OCSP philosophy]

>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.

This only works if you know in advance which CA's you plan to serve.  The
model I had for an OCSP responder is that they work like an SNMP element
manager where your toaster contacts the element manager to ask "is this
thing
valid?".  The element manager then goes out and wanders all over the X.500
directory space pulling out certs and CRL's and whatnot, checks their
validity, and tells the toaster "yes" or "no".  This means that the
responder
will have to be able to process arbitrary certs from arbitrary CA's.  At the
moment the CertID only works if either the OCSP responder is run by the CA
(it
knows which CertID's it has to work with) or is tied to a very small number
of
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary
CertID, it's not possible for an OCSP responder to provide a useful
response.

Peter.


------=_NextPart_000_000D_01BE09AD.FB736AF0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17143 for ietf-pkix-bks; Fri, 6 Nov 1998 17:15:59 -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 RAA17138 for <[e-mail]>; Fri, 6 Nov 1998 17:15:58 -0800 (PST)
Received: (from uucp@localhost) by btec-fw.certco.com (8.8.8/8.8.8) id UAA11630; Fri, 6 Nov 1998 20:18:39 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com(192.168.69.12) by btec-fw.certco.com via smap (V2.1) id xma011628; Fri, 6 Nov 98 20:18:12 -0500
Received: from kar.ma.certco.com ([10.200.200.55]) by nycertco-srv1.ny.certco.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id W1RH1TCR; Fri, 6 Nov 1998 20:18:11 -0500
Received: (from salzr@localhost) by kar.ma.certco.com (8.9.0/8.9.0) id UAA18538; Fri, 6 Nov 1998 20:18:11 -0500 (EST)
Date: Fri, 6 Nov 1998 20:18:11 -0500 (EST)
From: Rich Salz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: More problems with OCSP
Sender: [e-mail]
Precedence: bulk

>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
 This is why I thought it a mistake why removing the ability to send the
 whole cert was a mistake at the end of the OCSP development.  For the
 sake of some network traffic, a severe implmentation constraint was
 imposed.  Unfortunately my view wasn't in the consensus.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16465 for ietf-pkix-bks; Fri, 6 Nov 1998 15:36:53 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16460 for <[e-mail]>; Fri, 6 Nov 1998 15:36:47 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA29918; Fri, 6 Nov 1998 18:39:44 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id SAA05807; Fri, 6 Nov 1998 18:39:42 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.0081A311 ; Fri, 6 Nov 1998 18:35:58 -0500
X-Lotus-FromDomain: FDC
To: David Sweigert <[e-mail]>
cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 15:37:47 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

re: tatical certificates; is this similar to or different than the relying
party certificates that are being proposed (at least in part) because of
privacy issues (i.e. divulge nothing but an identification number and the
public key)???




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16200 for ietf-pkix-bks; Fri, 6 Nov 1998 15:00:50 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16196 for <[e-mail]>; Fri, 6 Nov 1998 15:00:45 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id XAA05643; Fri, 6 Nov 1998 23:06:14 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 23:03:42 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
CC: EKR <[e-mail]>
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> "Frank O'Dwyer" <[e-mail]> writes:
> > For most applications the vulnerability is significantly
> > reduced by ensuring that the certificate corresponds to the user
> > interface, and removing any name mappings that are subvertible and
> > hidden from the user.
> The number of applications for which that can be done is shrinking
> rapidly, as users get increasingly divorced from network naming.

All the more reason to stop checking just those names and check the name
forms that are actually visible. (I just mean removing dependency on
those name mappings for security btw., obviously they will still be
present.)

> > > > user clicks on a pepsi logo with a https link, the server certificate
> > > > could contain that logo in an appropriate extension and it could be
> > > > mechanically checked for.
> > > This really can't work, in the face of the n different sizes and color
> > > variants of the logos.
> >
> > That's not true. Images can be scaled in HTML (so you just need the logo
> > in its largest size).
> 1. Images are almost never done in HTML. They're GIFs.

Right, but they are presented by dereferencing and rendering HTML IMG
tags, which may contain scaling attributes. This means that the same
source image can be presented at different scales just by rewriting the
HTML.

> 2. Images aren't CANONICALLY scaled, so this makes the rescaled
> logo unverifiable.

No, that's not correct. If the IMG tag is used to do the scaling, then
the source image is the same string of bits no matter how it is scaled
for presentation. Only the enclosing HTML differs. (Some other image
formats are even designed to render the same image at any scale, but
unfortunately those aren't used by the browsers. I don't know whether
PNG is like that or not.)

> > As far as color and other variants go there will
> > be a small number of those, and in any case only one is necessary to
> > identify a secure service.
> Right, but this requires the web page developer to choose only
> one logo and stick with it. I don't believe it.

The only difficulty I see is where a corporation alters its logo, which
does happen. But that is no different than a corporate or DNS name
change, which also happen -- you just get a new certificate. As for web
developers, they can be made use what ever logos they are given. Given
the current risk of (say) spoofing an online banking service, which is
considerable, there is plenty of incentive for an organisation to make
this happen. Nor would there be any added security risk if the developer
used the wrong logo, either, it would just mean the page would load with
severe security warnings (assuming browsers actually made this check).

> > However the tls-https spec currently has a MUST for using
> > the dns altname if it is present--it's not clear if that simply means it
> > is to be used instead of the common name, or if you are barred from
> > performing other checks instead or additionally.
> It seems clear enough to me. You MUST do the subjectAltName check. It
> certainly doesn't preclude other checks as well.
> Moreover, -02 says
>    If the client has external information as to the expected identity of
>    the server, the hostname check MAY be omitted.
> 
> Your check would fall into this category.

OK, then that is just a misreading on my part. The version I have says
"if a subjectAltName of type dNSName is present, that MUST be used as
the identity". I took that to override the previous paragraph, which
contains your text above.

> > > Except that this is easily spoofed by having the certificate say
> > > "Bank of Mafia" and getting the user to click on "bank" when you
> > > change the page.
> >
> > No, I didn't mean to imply a substring check--I meant actually checking
> > that the phrases exactly matched.
> Yeah, I still don't buy it.
> I don't believe users will carefully check for the difference
> between
> "Bank of Foo"
> and
> "Bank of a Foo"
> for instance.

OK, on one level it's a mechanical check, and the browser would do it.
On another level, yes, the user could confuse the text of the link with
some other name and still be spoofed. The nastiest case of that would be
where two separate organisations actually possess the same name in
different jurisdictions. That is a problem of reliance on global names,
which is a general PKIX problem. Other cases include things like
"Micros0ft", however I can't think of any plausible variant of (say)
"Bank of Ireland" that misdirects to an attacker AND that someone could
get a trustworthy certificate for. ("Bank of 1reland" is the best I can
come up with--and I can't see any trustworthy CA issuing that, unless in
error to the bank itself.) Regardless, this is still a stronger defense
than the hostname check alone. Without this check the user doesn't need
to misread the link at all (it need only be unaware of network names)
and the attacker has to do less work. 

> There are simply too many lookalike variants. Now, if there was only
> one CA, you could expect them to enforce uniqueness across variants,
> as the PTO does (poorly). However, in the face of multiple CAs ,
> I don't believe this will work.

Even if so, a lot of organisations propose to be their own CA. If it
worked for them, that's better than not addressing the problem at all.

> To be blunt, I believe this is a lost cause. I've heard
> a nearly infinite number of such proposals over the years,
> and IMHO none of them stand up to close scrutiny.

Well, the difficulty with that view is that the proposal to only check
the DNS hostname doesn't stand up to close scrutiny either. Why dismiss
the others and accept that? Regardless, if you agree it's a serious
concern and you think it's not fixable, then I think the spec should at
least bring it to people's attention. 

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15837 for ietf-pkix-bks; Fri, 6 Nov 1998 14:16:40 -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 OAA15833 for <[e-mail]>; Fri, 6 Nov 1998 14:16:38 -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 LAA11075; Sat, 7 Nov 1998 11:19:25 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91039076508924>; Sat, 7 Nov 1998 11:19:25 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: More problems with OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 7 Nov 1998 11:19:25 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[I've copied this part of the message back to PKIX because I think it's more a 
 general discussion of OCSP philosophy]
 
>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
This only works if you know in advance which CA's you plan to serve.  The 
model I had for an OCSP responder is that they work like an SNMP element 
manager where your toaster contacts the element manager to ask "is this thing 
valid?".  The element manager then goes out and wanders all over the X.500 
directory space pulling out certs and CRL's and whatnot, checks their 
validity, and tells the toaster "yes" or "no".  This means that the responder 
will have to be able to process arbitrary certs from arbitrary CA's.  At the 
moment the CertID only works if either the OCSP responder is run by the CA (it 
knows which CertID's it has to work with) or is tied to a very small number of 
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary 
CertID, it's not possible for an OCSP responder to provide a useful response.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15668 for ietf-pkix-bks; Fri, 6 Nov 1998 13:59:55 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15664 for <[e-mail]>; Fri, 6 Nov 1998 13:59:49 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa00784; 6 Nov 98 16:57 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 06 Nov 1998 16:55:35 -0500
To: [e-mail], Stephen Kent <[e-mail]>
From: David Sweigert <[e-mail]>
Subject: Re: Scale (and the SRV record) 
Cc: "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Thu, 05 Nov 1998 18:43:15 EST."             <v0401170bb267e710f05f@[128.33.238.37]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

This brings up the question of tactical PKI; or digital certs 
that are "lightweight" -- 1/10th the size of a X.509v3 cert.

Dave

At 01:57 PM 11/6/98 -0500, Perry E. Metzger wrote:
>
>Stephen Kent writes:
>> Good point, but I'm loathe to skew the current model for the benefit of
>> some of these devices.  The PDAs are getting pretty powerful; phones and
>> pagers do pose more of a problem.  I'm not worried about my watch needing
>> to validate the cert for WWV.
>
>On the other hand, you should be worried about your pacemaker getting
>commands from anyone other than an authorized source.
>
>Within less than ten years, desktop machines are going to start
>dissolving with mobile platforms becoming universal. Those that skoff
>at this are suffering from "Vannevar's Syndrome" -- the inability to
>notice already extant technology (named for Vannevar Bush's famous
>gaffe where he predicted water cooled vacuum tube computers the size
>of skyscrapers substantially after the transistor was already
>invented.) The proofs of concept are already out there.
>
>Right now, you can pack virtually the entire functionality of a
>substantial desktop computer into a pack of cigarettes. People don't
>do that largely because keyboards, CD-ROM drives and displays get in
>the way, so they just build "laptops". Given chord keyboards and
>eyeglass displays, or voice i/o, or one of a dozen other things, the
>issue of keyboards and displays goes away. Given a multi-megabit
>constant mobile internet connection (see the current W-CDMA proposals
>which are already being pushed by serious companies) you no longer
>will really need the CD-ROM (and probably don't need it now.)
>
>In a decade or maybe fifteen years, we're still going to have an
>internet and still going to need digital signature technology, but the
>end points are generally going to be things attached to people which
>are almost unnoticeable in size. I do not believe we actually need to
>alter the models we are working with, but if it turned out that we
>*did* need to alter those models to fit mobile applications, it would
>be foolish to think that we were "skewing the model to deal with rare
>devices" given that these devices will not be rare for long.
>
>Perry
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14018 for ietf-pkix-bks; Fri, 6 Nov 1998 10:55:23 -0800 (PST)
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14014 for <[e-mail]>; Fri, 6 Nov 1998 10:55:21 -0800 (PST)
Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA06413; Fri, 6 Nov 1998 13:57:34 -0500 (EST)
Message-Id: <[e-mail]>
To: Stephen Kent <[e-mail]>
cc: "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record) 
In-reply-to: Your message of "Thu, 05 Nov 1998 18:43:15 EST." <v0401170bb267e710f05f@[128.33.238.37]> 
Reply-To: [e-mail]
X-Reposting-Policy: redistribute only with permission
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 06 Nov 1998 13:57:33 -0500
From: "Perry E. Metzger" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stephen Kent writes:
> Good point, but I'm loathe to skew the current model for the benefit of
> some of these devices.  The PDAs are getting pretty powerful; phones and
> pagers do pose more of a problem.  I'm not worried about my watch needing
> to validate the cert for WWV.

On the other hand, you should be worried about your pacemaker getting
commands from anyone other than an authorized source.

Within less than ten years, desktop machines are going to start
dissolving with mobile platforms becoming universal. Those that skoff
at this are suffering from "Vannevar's Syndrome" -- the inability to
notice already extant technology (named for Vannevar Bush's famous
gaffe where he predicted water cooled vacuum tube computers the size
of skyscrapers substantially after the transistor was already
invented.) The proofs of concept are already out there.

Right now, you can pack virtually the entire functionality of a
substantial desktop computer into a pack of cigarettes. People don't
do that largely because keyboards, CD-ROM drives and displays get in
the way, so they just build "laptops". Given chord keyboards and
eyeglass displays, or voice i/o, or one of a dozen other things, the
issue of keyboards and displays goes away. Given a multi-megabit
constant mobile internet connection (see the current W-CDMA proposals
which are already being pushed by serious companies) you no longer
will really need the CD-ROM (and probably don't need it now.)

In a decade or maybe fifteen years, we're still going to have an
internet and still going to need digital signature technology, but the
end points are generally going to be things attached to people which
are almost unnoticeable in size. I do not believe we actually need to
alter the models we are working with, but if it turned out that we
*did* need to alter those models to fit mobile applications, it would
be foolish to think that we were "skewing the model to deal with rare
devices" given that these devices will not be rare for long.

Perry


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13949 for ietf-pkix-bks; Fri, 6 Nov 1998 10:45:58 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13945 for <[e-mail]>; Fri, 6 Nov 1998 10:45:56 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id KAA01074; Fri, 6 Nov 1998 10:47:33 -0800 (PST)
To: "Frank O'Dwyer" <[e-mail]>
Cc: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 06 Nov 1998 10:47:32 -0800
In-Reply-To: "Frank O'Dwyer"'s message of "Fri, 06 Nov 1998 18:13:59 +0000"
Message-ID: <[e-mail]>
Lines: 102
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Frank O'Dwyer" <[e-mail]> writes:
> EKR wrote:
> > "Frank O'Dwyer" <[e-mail]> writes:
> > > The minor flaw may apply to TLS in general, in that UDP/TCP transport
> > > connections are identified by a 4-tuple {source host, source port,
> > > destination host, destination port} but tls-https only authenticates the
> > > destination host, not the port. This leaves scope for one TLS service to
> > > impersonate another, provided they have the same DNS hostname. The same
> > > problem exists for different and seperately-administered HTTPS services
> > > at the same DNS hostname but at different well-known ports. This might
> > > be fixable via appropriate trust criteria on the certificates, but I
> > > think a more straightforward fix is to either include the port number in
> > > the server identity and mechanically check for it, and/or (for backward
> > > compatibility) to forbid reuse of a DNS hostname for TLS services
> > > running on different well-known ports.
> > Yes, this is an issue, but I consider it a much less important one.
> > Primarily, end-node machines should arrange that this can't
> > happen.
> 
> OK, but this should be stated somewhere (perhaps the base TLS spec).
Feel free to tell the TLS editors.

> > > The major problem is hyperlink/web spoofing (see
> > > http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> > > http://www.cs.princeton.edu/sip/).
> > Sure. This has been a problem since day one. But it's basically
> > unfixable. This isn't just a problem with TLS. It's a problem with
> > any system anywhere that's ever purported to verify certificates
> > mechanically. To whit: You need to verify that the user's expectations
> > for who they are talking to match who they are in fact talking to.
> > Except that we don't have direct access to the user's expectations.
> 
> Yes, it's a general problem, and there is no 100% fix, but still some
> certificate checks are better than others (otherwise why specify any
> check at all?). For most applications the vulnerability is significantly
> reduced by ensuring that the certificate corresponds to the user
> interface, and removing any name mappings that are subvertible and
> hidden from the user.
The number of applications for which that can be done is shrinking
rapidly, as users get increasingly divorced from network naming.

> > > This issue should at least be pointed
> > > out in a "security considerations" section or similar. It's difficult to
> > > fix, but in some cases mechanical checks can be made. For example, if a
> > > user clicks on a pepsi logo with a https link, the server certificate
> > > could contain that logo in an appropriate extension and it could be
> > > mechanically checked for.
> > This really can't work, in the face of the n different sizes and color
> > variants of the logos. 
> 
> That's not true. Images can be scaled in HTML (so you just need the logo
> in its largest size).
1. Images are almost never done in HTML. They're GIFs.
2. Images aren't CANONICALLY scaled, so this makes the rescaled
logo unverifiable. 

> As far as color and other variants go there will
> be a small number of those, and in any case only one is necessary to
> identify a secure service.
Right, but this requires the web page developer to choose only
one logo and stick with it. I don't believe it.

> However the tls-https spec currently has a MUST for using
> the dns altname if it is present--it's not clear if that simply means it
> is to be used instead of the common name, or if you are barred from
> performing other checks instead or additionally.
It seems clear enough to me. You MUST do the subjectAltName check. It
certainly doesn't preclude other checks as well.
Moreover, -02 says
   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.

Your check would fall into this category.

> > Except that this is easily spoofed by having the certificate say
> > "Bank of Mafia" and getting the user to click on "bank" when you
> > change the page.
> 
> No, I didn't mean to imply a substring check--I meant actually checking
> that the phrases exactly matched.
Yeah, I still don't buy it. 
I don't believe users will carefully check for the difference
between 
"Bank of Foo"
and 
"Bank of a Foo"

for instance.

There are simply too many lookalike variants. Now, if there was only
one CA, you could expect them to enforce uniqueness across variants,
as the PTO does (poorly). However, in the face of multiple CAs ,
I don't believe this will work.

To be blunt, I believe this is a lost cause. I've heard
a nearly infinite number of such proposals over the years,
and IMHO none of them stand up to close scrutiny.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13643 for ietf-pkix-bks; Fri, 6 Nov 1998 10:11:55 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13639 for <[e-mail]>; Fri, 6 Nov 1998 10:11:49 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id SAA05436; Fri, 6 Nov 1998 18:16:32 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 18:13:59 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> "Frank O'Dwyer" <[e-mail]> writes:
> > The minor flaw may apply to TLS in general, in that UDP/TCP transport
> > connections are identified by a 4-tuple {source host, source port,
> > destination host, destination port} but tls-https only authenticates the
> > destination host, not the port. This leaves scope for one TLS service to
> > impersonate another, provided they have the same DNS hostname. The same
> > problem exists for different and seperately-administered HTTPS services
> > at the same DNS hostname but at different well-known ports. This might
> > be fixable via appropriate trust criteria on the certificates, but I
> > think a more straightforward fix is to either include the port number in
> > the server identity and mechanically check for it, and/or (for backward
> > compatibility) to forbid reuse of a DNS hostname for TLS services
> > running on different well-known ports.
> Yes, this is an issue, but I consider it a much less important one.
> Primarily, end-node machines should arrange that this can't
> happen.

OK, but this should be stated somewhere (perhaps the base TLS spec).

> > The major problem is hyperlink/web spoofing (see
> > http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> > http://www.cs.princeton.edu/sip/).
> Sure. This has been a problem since day one. But it's basically
> unfixable. This isn't just a problem with TLS. It's a problem with
> any system anywhere that's ever purported to verify certificates
> mechanically. To whit: You need to verify that the user's expectations
> for who they are talking to match who they are in fact talking to.
> Except that we don't have direct access to the user's expectations.

Yes, it's a general problem, and there is no 100% fix, but still some
certificate checks are better than others (otherwise why specify any
check at all?). For most applications the vulnerability is significantly
reduced by ensuring that the certificate corresponds to the user
interface, and removing any name mappings that are subvertible and
hidden from the user. For example TLS used with a normal telnet client
would be less vulnerable since a DNS name is what you type in there. 

> > This issue should at least be pointed
> > out in a "security considerations" section or similar. It's difficult to
> > fix, but in some cases mechanical checks can be made. For example, if a
> > user clicks on a pepsi logo with a https link, the server certificate
> > could contain that logo in an appropriate extension and it could be
> > mechanically checked for.
> This really can't work, in the face of the n different sizes and color
> variants of the logos. 

That's not true. Images can be scaled in HTML (so you just need the logo
in its largest size). As far as color and other variants go there will
be a small number of those, and in any case only one is necessary to
identify a secure service. To reduce the size of the extension, a hash
of the image bits could be used instead of the bits themselves.

> Worse yet, the certificate ISN'T in the
> certificate.

That is easily fixed (I assume you mean the logo isn't there today). I'm
not sure if a suitable extension already exists for it (probably not)
but it should be just another alt name form. (It would certainly be more
useful than some of the cruft that is currently allowed in
certificates.) However the tls-https spec currently has a MUST for using
the dns altname if it is present--it's not clear if that simply means it
is to be used instead of the common name, or if you are barred from
performing other checks instead or additionally. The latter
interpretation precludes the use of a superior check if you have one.

> > Similarly, if the user clicks on the phrase
> > "Bank of Foo online banking", the server certificate could contain that
> > phrase and it could be checked for.
> Except that this is easily spoofed by having the certificate say
> "Bank of Mafia" and getting the user to click on "bank" when you
> change the page.

No, I didn't mean to imply a substring check--I meant actually checking
that the phrases exactly matched. You could put a regular expression or
wildcards in the cert but then you'd need to be careful of attacks like
the one you describe. To avoid having to include every hyperlink phrase
used on a https site, or unduly constraining the content of those sites,
this really only needs to be checked when you move from one site to
another. 

Cheers,
Frank O'Dwyer


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13386 for ietf-pkix-bks; Fri, 6 Nov 1998 09:26:30 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13377 for <[e-mail]>; Fri, 6 Nov 1998 09:26:28 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id MAA09792; Fri, 6 Nov 1998 12:28:00 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA21410; Fri, 6 Nov 1998 12:26:36 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.005F76A7 ; Fri, 6 Nov 1998 12:22:42 -0500
X-Lotus-FromDomain: FDC
To: Jun Yoshitake <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 09:18:54 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

there are financial infrastructures that have much higher integrity than
any of the CAs or public key infrastructures (i.e. spending past six years
getting to the point where there is no down time).
When my wife & I were running skunk works in the 80s doing high speed data
transport & high availability product  ... i coined the term disaster
servivability (to distinquish from disaster recovery ... requiring hot
operation with geographic seperation).

Part of insuring the integrity of a financial transaction is having access
to being able to complete every transaction. Places have gone to the point
of guarentee that all information is available in a single place for the
completion of the transaction .... bunkering that single place with
no-single-point-of-failure iredundancy and UPS with diesel back-up; and
then replicating the facility at two additional bunkered sites (any single
system at any single site is sufficient to complete the transaction).

Having transaction completion dependency on any offiste data/function
lowers the integrity ....
availability is the product of all the availability numbers for all things
that must be available for the completion .... redundant availability is
one minus the product of the non-availability numbers.
The financial redundent single site availability number might be five nines
(.99999). Triple redendant geographic survivability then would be
1-(.00001*.00001*.00001). Not having all information stored at each site
necessary to complete the transaction .... implies that at least two sites
have to be operational ... as well as the communication path between them.
The financial infrastructure has availability number of
1-(.00001*.00001*.00001). The communication path ... even with diverse
routing might be three nines (.999) and the 2nd site mght be four nines
(.9999).

The resulting availability for non-single-site-stored-data then is
something like:
                 (1-(.00001*.00001*.00001))*.999*.9999

that can be easily shown to be less than .9999 (since it is the product of
numbers that are all less than one ... and at least one of the numbers is
.9999 or less) ... which was the original unacceptable number for (at least
some) financial infrastructure which prompted the original triple bunkered
site with geographic dispersement in the first place.

The alternative model to reach this level of availability w/o requiring
geographic redundancy with the single-site data model .... is the
simulation of some ECC/FEC possibly R/S 64/80 where all eighty sites have
independent failure modes (some mainframe memory subsystems do 64/80 ECC).
Small problem is resync'ing sites when some have been offline and their
information becomes stale (this is problem in the three site replication
also .... but is somewhat easier with three ... than it would be with
eighty).

In any case, just saying a CA &/or independent certificate directory has
high availability support with no-single-point-of-failure  .... doesn't
necessarily show the whole scope of the issue. Taking an existing operation
that has effectively single-site completion dependency (or even redundnat
single-site completion architecture) ... and move to non-single-site
completion paradigm ... involves (at least) the local site, the
communication modes between the sites, and the 2nd site.

There are also issues of partitioning and locality specific failure modes.
An ISP might cover a geographic locality and provides redundancy to handle
availability levels up to major geogrpahic specific outages .... but
doesn't want to be subject to outages outside local geographic area (i.e.
ISP in california would survive everything up to major earthquake in
california ... but doesn't have to survive a local major earthquake since
all of the
customers would be down also). ISPs with geographic locality coverage only
has to
survive failure  modes that the majority of their customers would also
survive. National or
international ISPs can create gegraphic centered service centers to take
advantage of geographic nature of some failure modes. This gets into an
area of failure mode management
slightly different from the raw statisticaly distribution probability mode
of handling failures.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13385 for ietf-pkix-bks; Fri, 6 Nov 1998 09:26:29 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13376 for <[e-mail]>; Fri, 6 Nov 1998 09:26:28 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id MAA09783; Fri, 6 Nov 1998 12:27:57 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA21420; Fri, 6 Nov 1998 12:26:38 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.005F7664 ; Fri, 6 Nov 1998 12:22:42 -0500
X-Lotus-FromDomain: FDC
To: "Frank O'Dwyer" <[e-mail]>
cc: EKR <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 08:24:51 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

.... and that a spoofer can't obtain the same thumbnail/phrase  in their
certificate extension ...  requiring all CAs (typically valid for the
browser community) to reference a central registry of thumbnail/phrases
(ala copyright or service mark office).

X9.59 standard proposed exactly that for merchant web servers certificates
selling on the internet. There was split between the banks that were
interested in being the CA for such certificates on the part of their
merchants and banks that proposing bank AADS server (did client browser
cross-check service mark with what was in the merchant's certificate
extension ... or did client browser do a online reference to well-know bank
web server checking the service mark, merchant's URL ... and was the bank
still financial responsible party for the merchant). A side issue of
specifying such a thumbnail service mark in a certificate was that X9.59 is
suppose to be for all account-based payments in all electronic environments
(and at least one such electronic environment is point-of-sale where
neither browswer nor certificates are available).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12967 for ietf-pkix-bks; Fri, 6 Nov 1998 08:17:14 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12963 for <[e-mail]>; Fri, 6 Nov 1998 08:17:13 -0800 (PST)
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA24031 for <[e-mail]>; Fri, 6 Nov 1998 10:20:08 -0600 (CST)
Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender [e-mail] )
Received: from csn1.geg.mot.com (csn1.geg.mot.com [137.162.96.72]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA17315 for <[e-mail]>; Fri, 6 Nov 1998 10:20:08 -0600 (CST)
Received: from gegpo1.geg.mot.com (dubtest.geg.mot.com [137.162.17.1]) by csn1.geg.mot.com (8.8.8/8.8.8) with SMTP id JAA14054 for <[e-mail]>; Fri, 6 Nov 1998 09:30:08 -0700 (MST)
Received: by gegpo1.geg.mot.com with Microsoft Mail id <[e-mail]>; Fri, 06 Nov 98 09:20:05 MST
From: Covey Carlin <[e-mail]>
To: ietf-pkix <[e-mail]>
Subject: FW: Is certificate renewal a good idea?
Date: Fri, 06 Nov 98 09:08:00 MST
Message-ID: <[e-mail]>
X-Mailer: Microsoft Mail V3.0
Sender: [e-mail]
Precedence: bulk

It seems to me that cases #2 and #3 are issues that concern the client, but 
case#1
seems to be strictly a registration issue.

case#1:
Since clients will find certificates based upon the DN, it should be 
transparent to the
client whether the same public key appears in another certificate with a 
different DN .
It may matter to the CA, however.  Presumably the CA insists upon proof of 
possession
of the private key when responding to a certification request, to prevent 
someone
hijacking someone else's public key.  The CA may or may not have rules 
concerning
the same user using two different DNs with the same public key.

cases#2 and #3:
The client may need to concern itself with these cases if two certificates 
having the same
CA and same DN are still valid, regardless of whether they have the same 
public key.
If they are encryption certificates and the only difference is the not-after 
date, and both are
still valid, then the client can choose either.  If they are signature 
certificates and both
are still valid and they have the same public key (case#2), then the client 
can pick either.
If the signature certificates have different public keys, then obviously 
only the one that
matches the signature to be verified will be useful.  The client will have 
to concern itself
with the possibility that the first certificate it tries may not work, but 
the second might.

cases#2 and #3 (reprise):
If two valid certificates have the same DN but differ in some other regard 
that is of
concern to the client (e.g. policy OID), the client will have to pay 
attention regardless of
whether the two certificates have the same public key.  The first 
certificate tried may not
have the right attributes, but the second might.
 ----------
From: owner-ietf-pkix
To: ietf-pkix; flanigab
Subject: RE: Is certificate renewal a good idea?
Date: Wednesday, November 04, 1998 12:28PM

Bill,

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and 
#2.
And, should client software be built to support case #2?


>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
See comments below.

> -----Original Message-----
> From: Tammy Carter [SMTP:[e-mail]]
> Sent: Tuesday, November 03, 1998 6:24 PM
> To:   [e-mail]
> Subject:      Is certificate renewal a good idea?
>
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten
> me?
>
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name,
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
>
        Actually, the most prevalent case is likely to be:
        3) Same CA, different public key, same CN

        [snip]

> Comments?
>
        Above.

> Tammy Green Carter
> [e-mail]
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone]
Information Assurance Office (JED)      DSN:                      761
5600 Columbia Pike, Room 632     Voice Mail:           [phone]
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12736 for ietf-pkix-bks; Fri, 6 Nov 1998 07:46:33 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12732 for <[e-mail]>; Fri, 6 Nov 1998 07:46:32 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id HAA06282; Fri, 6 Nov 1998 07:48:12 -0800 (PST)
To: "Frank O'Dwyer" <[e-mail]>
Cc: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 06 Nov 1998 07:48:11 -0800
In-Reply-To: "Frank O'Dwyer"'s message of "Fri, 06 Nov 1998 11:19:53 +0000"
Message-ID: <[e-mail]>
Lines: 62
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Frank O'Dwyer" <[e-mail]> writes:
> EKR wrote:
> > Folks, there is a draft on this topic:
> > draft-ietf-tls-https-02.txt
> > 
> > I believe I've done a reasonable job of covering the appropriate
> > issues, and the TLS-WG has pretty much come to a consensus that
> > the name matching stuff is done correctly. If PKIX people
> > have problems with how it's done, I'd like to hear them.
> 
> I think that there are two flaws in how that's done, one minor and
> reasonably easily fixed, and one major and difficult to fix. I'm working
> off draft-ietf-tls-https-01.txt, though, so maybe something's changed
> meanwhile.
> 
> The minor flaw may apply to TLS in general, in that UDP/TCP transport
> connections are identified by a 4-tuple {source host, source port,
> destination host, destination port} but tls-https only authenticates the
> destination host, not the port. This leaves scope for one TLS service to
> impersonate another, provided they have the same DNS hostname. The same
> problem exists for different and seperately-administered HTTPS services
> at the same DNS hostname but at different well-known ports. This might
> be fixable via appropriate trust criteria on the certificates, but I
> think a more straightforward fix is to either include the port number in
> the server identity and mechanically check for it, and/or (for backward
> compatibility) to forbid reuse of a DNS hostname for TLS services
> running on different well-known ports.
Yes, this is an issue, but I consider it a much less important one.
Primarily, end-node machines should arrange that this can't
happen.

> The major problem is hyperlink/web spoofing (see
> http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> http://www.cs.princeton.edu/sip/).
Sure. This has been a problem since day one. But it's basically 
unfixable. This isn't just a problem with TLS. It's a problem with
any system anywhere that's ever purported to verify certificates
mechanically. To whit: You need to verify that the user's expectations
for who they are talking to match who they are in fact talking to.
Except that we don't have direct access to the user's expectations.

> This issue should at least be pointed
> out in a "security considerations" section or similar. It's difficult to
> fix, but in some cases mechanical checks can be made. For example, if a
> user clicks on a pepsi logo with a https link, the server certificate
> could contain that logo in an appropriate extension and it could be
> mechanically checked for.
This really can't work, in the face of the n different sizes and color
variants of the logos. Worse yet, the certificate ISN'T in the
certificate.

> Similarly, if the user clicks on the phrase
> "Bank of Foo online banking", the server certificate could contain that
> phrase and it could be checked for.
Except that this is easily spoofed by having the certificate say
"Bank of Mafia" and getting the user to click on "bank" when you
change the page.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12005 for ietf-pkix-bks; Fri, 6 Nov 1998 06:08:13 -0800 (PST)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12000 for <[e-mail]>; Fri, 6 Nov 1998 06:08:11 -0800 (PST)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id WAA01065; Fri, 6 Nov 1998 22:59:10 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA00483; Fri, 6 Nov 98 23:04:20 JST
Received: from elgw.isl.melco.co.jp ([133.141.13.130]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with ESMTP id XAA14193; Fri, 6 Nov 1998 23:18:35 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id XAA20332; Fri, 6 Nov 1998 23:11:06 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id XAA07955; Fri, 6 Nov 1998 23:17:21 +0900 (JST)
Received: from zaku by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA27123; Fri, 6 Nov 1998 23:10:50 +0900
Message-Id: <[e-mail]>
Date: Fri, 06 Nov 1998 23:09:25 +0900
From: Jun Yoshitake <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I am beginning to be afraid we have been thinking
of a differnet situation or application ...
But, anyway, my comments are in line.

[e-mail] wrote:

> 1) registering a public key in a RADIUS account record in lieu of a
> password, modifying the RADIUS serrver to do digital signature
> authentication with the registered public key, and modifying the RADIUS
> client to accept a digital signature (in lieu of a password).

I think you don't necessarily have to register the public key
in your record.
A client can send all the certificates that are needed to
validate the client's certificte.
(I don't know RADIUS, so I am explaining in a general
 PKI case.)

> First off, the transaction in neither mode will complete if the RADIUS
> server and RADIUS account record is unavailable. However, in addition, the
> second mode won't complete if none of the remaining PKI infrastructure is
> unavailable (and/or if it chooses to continue in spite of it being
> unavailble opens up fraud and risk potential completing the operation w/o
> completing the authentication process).

If you are saying, for example, what if no directory servers can be
available to get necessary CRLs, I admit this is a big point.
And this issue - how revocation information is surely provided -
has been one of big points in this mailing list, I think.
I think in a real system a high availability server (for example,
a dual server system) is used for a directory server (if you use
a directory server as a revocation information provider).

> At NISS conference last month a financial institution talked about
> migration to relying party certificates because of privacy and liability
> issues .... i.e. a certificate containing only the account number and
> public key. In this scenerio, the certificate is stored in the account
> record when the public key is registered and a copy returned to the owner.
> This about reduces privacy, liability, complexity, risk, availability and
> fraud exposures to a minimum (associated with using both a certificate and
> an account record). At this point, the question becomes why does the owner
> have to send a digital signature and the certificate to the institution on
> every operation .... if the institution already has the original of the
> certificate.

Again, you don't necessarily have to store a client's certificate.
And I think it depends on an application or a protocol whether
a client has to send its digital signature and its certificate
every time it sends a message to the server.
(SET Protocol might be of some help in this point.)

> The downside risk is that the certificate signing key at least
> becomes a point of attack ...

If you mean "the certificate signing key" is the CA key
which signs a client's certificate, I think the real world CAs
(especially for financial applications) protect thier facilities
including their private keys and  in highly secure and strict
manners.


Regards,

Jun Yoshitake

Mitsubishi Electric Corp.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA11284 for ietf-pkix-bks; Fri, 6 Nov 1998 05:08:38 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA11280 for <[e-mail]>; Fri, 6 Nov 1998 05:08:37 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA05958; Fri, 6 Nov 1998 05:10:56 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 08:05:15 -0500
To: Stephen Kent <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: [e-mail]
In-Reply-To: <v0401170eb2668eb0e84e@[128.89.31.126]>
References: <[e-mail]> <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Steve,

We agree completely on this.  I think that's what Section 5.1.2 of the PKIX
Roadmap document says; it's what we were trying to capture. If we didn't do
a good enough job of it, we can correct it.

I recognize that many non-SPKI-folk share this view.  Hey, I was just
trying to be polite to the folk doing the SPKI work. :-)

			Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


At 06:14 PM 11/4/98 -0500, Stephen Kent wrote:
>Al,
>
>>This is one of the areas where the SPKI folk make sense.  There is not, and
>>will not ever be, a single, unified, global directory where everything has
>>a name that fits into the schema.  There are instead "directories" of
>>information that apply to a specific "domain".  In PKIX's case, it's the
>>information that applies to the Internet.  The namespace covers those
>>things that are important in the Internet context, and nothing else.  To
>>me, that's (right now), IP addresses, domain names, port numbers, service
>>names, user names/mailbox names, and maybe one or two other things. If the
>>Internet expands to cover toll plazas, then a naming space will have to be
>>developed for them, and after it's defined and standardized we can figure
>>out how to put the proper names in certificates.
>
>The notion of no single, unique, name that is appropriate for every context
>is not unqiue to SPKI;  I've been preaching this notion for at least 3
>years and gave talks on this at a DIMACS workshop in 1996 and at the RSA
>conference in 1997, before publishing a paper on the topic in MILCOM 97.
>The SDSI model says that the names in certs are not useful except very
>locally, and hence emphasizes the idea of the key as an ID.  What we are
>talkin g about does not share that notion.  DNS names, 822 addresses, IP
>addresses, URLs, etc. have widespread semantics, even though they are not
>universal.
>
>Steve

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA11178 for ietf-pkix-bks; Fri, 6 Nov 1998 05:00:20 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA11174 for <[e-mail]>; Fri, 6 Nov 1998 05:00:17 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA05900; Fri, 6 Nov 1998 05:02:35 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 07:56:41 -0500
To: Elliott Ginsburg <[e-mail]>, [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Re: A different architecture
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Well, as the "loudmouth" who started this, let me quickly clarify.  What I
actually wrote was:

"There is not, and will not ever be, a single, unified, global directory where
everything has 
a name that fits into the schema. There are instead "directories" of 
information that apply to a specific "domain"." 

I was responding to previous comments about the X.500 notion of everything
(specific examples cited were toll plazas, toll booth operators, etc.) having a
name that fits into a single global structure - much different from the
(relatively simple) idea of assigning domain names to things that connect to
the Internet.

The DNS is an example of a directory of information that applies to a specific
"domain".  (Yes, I realize that my use of the term 'domain' in the original
post was unfortunate - I'm now overloading the word.  Hopefully, the meaning is
clear from context.)  This is what we meant in Section 5.1.2 of the Roadmap
document, which says:
5.1.2 Scope of Names

The original X.500 work presumed that every subject in the world wouldhave a
globally-unique distinguished name. Thus, every subject could be easily
located, and there would never be a conflict. All that would be needed is a
sufficiently-large name space, and rules for constructing names based on
subordination and location.

Obviously, that is not practical in the real world, for a variety of reasons.
There is no single entity in the world trusted by everybody to reside at the
top of the name space, and there is no way to enforce uniqueness on names for
all entities. (These were among the reasons for the failure of PEM to be widely
implemented.)

This does not mean, however, that a name-based PKI cannot work. It is important
to recognize that the scope of names in PKIX is local; they need to be defined
and unique only within their own domain. 

Suppose for example that a rootCA is established with DN "O=IETF, OU=PKIX,
CN=PKIX_CA". That CA will then issue certificates for names subordinate to it.
The only requirement - and this can be enforced procedurally - is that no two
distinct entities beneath this rootCA have the same name. We can't prevent
somebody else in the world from creating her own CA, called "O=IETF, OU=PKIX,
CN=PKIX_CA", and it is not necessary to do so. Within the domain of the
original rootCA, there will be no conflict, and the fact that there is another
CA of the same name in some other domain is irrelevant.

This is analogous to the current DNS or IP address situations. On the Internet,
there is only one node called www.ietf.org. The fact that there might be 10
different intranets, each with a host given the DNS name www.ieft.org, is
irrelevant and causes no interoperability problems- those are different
domains. However, if there were to be another node on the Internet with domain
name www.ietf.org, then there would be a problem due to name duplication.

The same applies for IP addresses. As long as only one node on the Internet
responds to the IP address 130.85.1.3, there is no problem, despite the fact
that there are 100 different corporate Intranets, each using that same IP
address. However, if two different nodes on the Internet each responded to the
IP address 130.85.1.3, there would be a problem.



Since Bill Burr did an excellent job of answering the original post, I'll add
that I agree with Bill, and let it go at that.

(Request:  any other comments on the Roadmap - on the above section or any
other part of the document - would be appreciated.)

                        Al Arsenault

--  these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



At 08:00 AM 11/3/98 -0500, Elliott Ginsburg wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09766 for ietf-pkix-bks; Fri, 6 Nov 1998 03:17:33 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.166]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA09761 for <[e-mail]>; Fri, 6 Nov 1998 03:17:29 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id LAA05113; Fri, 6 Nov 1998 11:22:27 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 11:19:53 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> Folks, there is a draft on this topic:
> draft-ietf-tls-https-02.txt
> 
> I believe I've done a reasonable job of covering the appropriate
> issues, and the TLS-WG has pretty much come to a consensus that
> the name matching stuff is done correctly. If PKIX people
> have problems with how it's done, I'd like to hear them.

I think that there are two flaws in how that's done, one minor and
reasonably easily fixed, and one major and difficult to fix. I'm working
off draft-ietf-tls-https-01.txt, though, so maybe something's changed
meanwhile.

The minor flaw may apply to TLS in general, in that UDP/TCP transport
connections are identified by a 4-tuple {source host, source port,
destination host, destination port} but tls-https only authenticates the
destination host, not the port. This leaves scope for one TLS service to
impersonate another, provided they have the same DNS hostname. The same
problem exists for different and seperately-administered HTTPS services
at the same DNS hostname but at different well-known ports. This might
be fixable via appropriate trust criteria on the certificates, but I
think a more straightforward fix is to either include the port number in
the server identity and mechanically check for it, and/or (for backward
compatibility) to forbid reuse of a DNS hostname for TLS services
running on different well-known ports.

The major problem is hyperlink/web spoofing (see
http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
http://www.cs.princeton.edu/sip/). This issue should at least be pointed
out in a "security considerations" section or similar. It's difficult to
fix, but in some cases mechanical checks can be made. For example, if a
user clicks on a pepsi logo with a https link, the server certificate
could contain that logo in an appropriate extension and it could be
mechanically checked for. Similarly, if the user clicks on the phrase
"Bank of Foo online banking", the server certificate could contain that
phrase and it could be checked for.

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09322 for ietf-pkix-bks; Fri, 6 Nov 1998 03:10:31 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA09317 for <[e-mail]>; Fri, 6 Nov 1998 03:10:23 -0800 (PST)
Received: (qmail 362 invoked from network); 6 Nov 1998 10:56:21 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 6 Nov 1998 10:56:21 -0000
Received: (qmail 13043 invoked from network); 6 Nov 1998 10:11:07 -0000
Received: from unknown (HELO valicert.com) (10.0.0.101) by internal-mail.valicert.com with SMTP; 6 Nov 1998 10:11:07 -0000
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 02:11:31 -0800
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Peter,
    Thanks for the comments - actually, this is a great review. Let
me try and justify the various points:

Peter Gutmann wrote:
> 
> I've just spent the afternoon (trying to) implement this weeks version of
> OCSP.  There are some problems with this, here they are in rough order of
> severity:
> 
> - In the ResponseData there's a clash of tags between responseExtensions and
>   responderID.byName

This clash shouldn't cause any problems in either encoding or decoding,
since the responderID and Extensions are separated by more than one
required fields.

Is this still an issue? Dan W. had actually pointed out the clash
between Version and ResponderID, which both had a tag of 0 and were
adjacent to each other. That was the reason for changing the tags.
However, I am not sure why the clash of non-adjacent tags is bad.

> 
> - The certStatus is communicated by the tag on the encoded data rather than an
>   actual value, which means that unless you've got some hand-hacked ASN.1
>   decoder you can't tell what the status is because it's stripped out by the
>   decoding layer - you end up having to poke around to see what parts of the
>   XXXInfo you've wound up with and then try to guess the cert status from that.
>   This should be:
> 
>    ...
>    certStatus           ENUMERATED,
>    certStatusInfo       CertStatusInfo OPTIONAL
>    ...
> 
>    CertStatusInfo ::= SEQUENCE {
>       [revocationTime etc]
>       }

Actually, I thought this was a pretty neat idea (all the credit goes to
Slava for this one). I would think most people would encode a CHOICE as
a union and have something to distinguish which field of the union is
in use. Given that, it is unclear why we need to have a separate
certStatus field. Actually, I would think it make software more error
prone - what if the enumerated and the tag that tells you what the
field of the union is don't match?

It is possible, I suppose that one uses a void * instead of a union.
In that case, you would need to keep something telling you what the
type of the data is.


> 
> - The responseBytes are encoded using the dreaded OCTET STRING black hole, for
>   no good reason.  Instead of the current:
> 
>    ResponseBytes ::=       SEQUENCE {
>        responseType   OBJECT IDENTIFIER,
>        response       OCTET STRING }
> 
>   it should be:
> 
>    ResponseBytes ::=       SEQUENCE {
>        responseType   OBJECT IDENTIFIER,
>        response       ANY DEFINED BY responseType }
> 
>   (using the 1988 syntax, replace with the '93 version as required).

Got my syntax from the definition of Extensions - "Monkey see, monkey
do", I suppose :-)

> 
> Finally, the entire set of PDU's are defined using an incredible amount of
> gratuitous and unnecessary tagging - were the authors being paid by the tag
> for this or something? :-).  You can strip out almost every tag in the spec
> without any adverse effects.  For example the OCSPRequest can be rewritten
> from:
> 
>    OCSPRequest     ::=     SEQUENCE {
>        tbsRequest                  TBSRequest,
>        optionalSignature   [0]     EXPLICIT Signature OPTIONAL }
> 
>    TBSRequest      ::=     SEQUENCE {
>        version             [0]     EXPLICIT Version DEFAULT v1,
>        requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
>        requestList                 SEQUENCE OF Request,
>        requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
> 
>    Signature       ::=     SEQUENCE {
>        signatureAlgorithm      AlgorithmIdentifier,
>        signature               BIT STRING,
>        certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
> 
>    Request         ::=     SEQUENCE {
>        reqCert                     CertID,
>        singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
> 
> to
> 
>    OCSPRequest     ::=     SEQUENCE {
>        tbsRequest                  TBSRequest,
>        optionalSignature           Signature OPTIONAL }
> 
>    TBSRequest      ::=     SEQUENCE {
>        version                     Version DEFAULT v1,
>        requestorName       [0]     GeneralName OPTIONAL,
>        requestList                 SEQUENCE OF Request,
>        requestExtensions           Extensions OPTIONAL }
> 
>    Signature       ::=     SEQUENCE {
>        signatureAlgorithm      AlgorithmIdentifier,
>        signature               BIT STRING,
>        certs                   SEQUENCE OF Certificate OPTIONAL }
> 
>    Request         ::=     SEQUENCE {
>        reqCert                     CertID,
>        singleRequestExtensions     Extensions OPTIONAL }
> 
> This is functionally completely identical to the previous version, but:
> 
>  - It's easier to read
>  - It's easier to encode
>  - It's easier to decode
>  - It's smaller when encoded
> 
> The same goes for the response format (with the exception of the responderID I
> can't find a single context-specific tag which is actually necessary).  Is
> there any reason why all the unnecessary tagging has to be there?

I think you are making 2 points here:
1. Why am I tagging things I didn't need to.
2. Why am I using explicit tagging.

Here are the reasons:
I actually like following simple rules that don't make me think too
much :-). Here are the two choices:
a. Tag only if you have two optional fields (actually only if they are
	adjacent (and of the same type))
b. Tag any time a field is optional.

Choice a. is more difficult to follow and more error prone as the spec
changes and people add/remove fields.

If you buy the previous argument, then, EXPLICIT tagging actually
helps me debug, because with IMPLICIT tagging, I lose the
actual type of the field and run something like your asn1dump,
or SSLeay's asn1parse doesn't actually give me a very useful
output.

I did assume that given that you already have the overhead of a
128 byte signature with the response, the few extra bytes
added by EXPLICIT encoding wouldn't be too bad.

Is that a reasonable argument, or could I have had my cake and
eaten it too and save some bytes all at the same time?

> 
> Peter.
> 

Regards,
Ambarish

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA03178 for ietf-pkix-bks; Fri, 6 Nov 1998 01:00:17 -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 BAA03173 for <[e-mail]>; Fri, 6 Nov 1998 01:00:15 -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 WAA02055 for <[e-mail]>; Fri, 6 Nov 1998 22:03:08 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91034298701348>; Fri, 6 Nov 1998 22:03:07 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: More problems with OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 22:03:07 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I knew there was something I forgot in the previous message...
 
The use of CertID isn't at all clear.  Firstly, I assume that "hash of the 
subject key field" means a hash of the subjectPublicKey rather than the 
subjectPublicKeyInfo (is this correct)?  However once you've done that, there 
isn't really much you can do with the result.  How are you supposed to look up 
a certificate with the resulting OCTET STRINGs and whatnot without enumerating 
each one and hashing whatever you need until you find a match?  The only way I 
can see for doing this is by adding a whole series of extra attributes to your 
key database/directory containing every possible combination of hash algorithm 
and hash type for the different fields - each cert would need to be stored 
with the hash of issuer DN and key for every conceivable hash algorithm type 
which someone might use in a request.
 
I'm assuing here that the OCSP server acts as a go-between between some CA/CRL 
repository and the user (ie that it consults some sort of directory for 
certificate information and uses that to build a local cache of info which it 
doles out to requestors).  However since you can't consult a directory based 
on a CertID you don't really get very far unless the OCSP server is run by the 
issuer, who has an unambiguous means of mapping a serialNumber to a 
certificate which it issued.  For anyone else, a random octet string and 
integer as a cert ID aren't useful for anything because finding the issuer 
involves reversing the hash function.
 
Has anyone actually tried to implement OCSP before?
 
[If you need a way to uniquely identify a cert, might I suggest the 160-bit 
 SHA-1 hash of:
 
  SEQUENCE {
    issuerKey           SubjectPublicKeyInfo,
    serialNumber        CertificateSerialNumber
    }
 
 Then define a new attribute certificateID and get everyone to store this 
 alongside the cert.  Given the unhealthy practice of renewing keys, it may be 
 necessary to include some sort of generational qualifier as well]
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA28620 for ietf-pkix-bks; Thu, 5 Nov 1998 23:31:50 -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 XAA28611 for <[e-mail]>; Thu, 5 Nov 1998 23:31:48 -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 UAA00783 for <[e-mail]>; Fri, 6 Nov 1998 20:34:40 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91033768003596>; Fri, 6 Nov 1998 20:34:40 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Comments on OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 20:34:40 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've just spent the afternoon (trying to) implement this weeks version of 
OCSP.  There are some problems with this, here they are in rough order of 
severity:
 
- In the ResponseData there's a clash of tags between responseExtensions and 
  responderID.byName
 
- The certStatus is communicated by the tag on the encoded data rather than an 
  actual value, which means that unless you've got some hand-hacked ASN.1 
  decoder you can't tell what the status is because it's stripped out by the 
  decoding layer - you end up having to poke around to see what parts of the 
  XXXInfo you've wound up with and then try to guess the cert status from that.
  This should be:
 
   ...
   certStatus           ENUMERATED,
   certStatusInfo       CertStatusInfo OPTIONAL
   ...
 
   CertStatusInfo ::= SEQUENCE {
      [revocationTime etc]
      }
 
- The responseBytes are encoded using the dreaded OCTET STRING black hole, for 
  no good reason.  Instead of the current:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }
 
  it should be:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       ANY DEFINED BY responseType }
 
  (using the 1988 syntax, replace with the '93 version as required).
 
Finally, the entire set of PDU's are defined using an incredible amount of 
gratuitous and unnecessary tagging - were the authors being paid by the tag 
for this or something? :-).  You can strip out almost every tag in the spec 
without any adverse effects.  For example the OCSPRequest can be rewritten 
from:
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
 
to
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature           Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version                     Version DEFAULT v1,
       requestorName       [0]     GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions           Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs                   SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     Extensions OPTIONAL }
 
This is functionally completely identical to the previous version, but:
                        
 - It's easier to read
 - It's easier to encode
 - It's easier to decode
 - It's smaller when encoded
 
The same goes for the response format (with the exception of the responderID I 
can't find a single context-specific tag which is actually necessary).  Is 
there any reason why all the unnecessary tagging has to be there?
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA19189 for ietf-pkix-bks; Thu, 5 Nov 1998 21:06:13 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA19178 for <[e-mail]>; Thu, 5 Nov 1998 21:06:11 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id VAA02188; Thu, 5 Nov 1998 21:10:17 -0800 (PST)
To: "Phillip M Hallam-Baker" <[e-mail]>
Cc: "Frank O'Dwyer" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 21:10:16 -0800
In-Reply-To: "Phillip M Hallam-Baker"'s message of "Thu, 5 Nov 1998 18:08:27 -0500"
Message-ID: <[e-mail]>
Lines: 28
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Phillip M Hallam-Baker" <[e-mail]> writes:

> > I think this is an extremely important point--any mapping between name
> > spaces must be done securely and where such mapping can be avoided then
> > all the better.
> 
> Frank makes some excellent points. What he is addressing is the 
> interface between PKIX and SSL (TLS). Is this a PKIX-WG issue or a
> TLS-WG issue?
> 
> I think it is something which TLS should address since it naming
> is an issue which must be handled separately by each 'PKIX aware'
> protocol. The naming issues of S/MIME are very different for example.
> Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
> different.
Folks, there is a draft on this topic:
draft-ietf-tls-https-02.txt

I believe I've done a reasonable job of covering the appropriate
issues, and the TLS-WG has pretty much come to a consensus that
the name matching stuff is done correctly. If PKIX people
have problems with how it's done, I'd like to hear them.

-Ekr


-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA15773 for ietf-pkix-bks; Thu, 5 Nov 1998 17:58:45 -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 RAA15769 for <[e-mail]>; Thu, 5 Nov 1998 17:58:44 -0800 (PST)
Received: from [128.33.238.127] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id VAA22039; Thu, 5 Nov 1998 21:01:10 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170bb267e710f05f@[128.33.238.37]>
In-Reply-To:  <[e-mail]>
Date: Thu, 5 Nov 1998 18:43:15 -0500
To: "Larowe, Rick" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

At 7:07 AM -0500 11/5/98, Larowe, Rick wrote:
>> -----Original Message-----
>> From: Stephen Kent [mailto:[e-mail]]
>> Anyway, didn't thin clients become less of a goal with the
>> demise of netPCs
>> :-)?  All of the software on my desktop and laptop machines is getting
>> bigger each year, not smaller.
>
>But let's not forget about PDAs, smart phones, pagers, and even
>watches.  They'll be the next targets.

Good point, but I'm loathe to skew the current model for the benefit of
some of these devices.  The PDAs are getting pretty powerful; phones and
pagers do pose more of a problem.  I'm not worried about my watch needing
to validate the cert for WWV.  If we go down this path too far, we might
next decide to create "lite" certs because regular X.509 certs are too big,
have uncessarily complex name forms, etc.  People sometimes tell me that
every lightbulb in my house needs to have an IP address and that's why IPv6
needs to be deployed. Maybe not.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13426 for ietf-pkix-bks; Thu, 5 Nov 1998 15:22:01 -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 PAA13422 for <[e-mail]>; Thu, 5 Nov 1998 15:22:00 -0800 (PST)
Received: from stefans (t1o68p64.telia.com [62.20.138.64]) by maila.telia.com (8.8.8/8.8.8) with SMTP id AAA16070; Fri, 6 Nov 1998 00:24:41 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 06 Nov 1998 00:20:45 +0100
To: Al Arsenault <[e-mail]>, "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 PAA13423
Sender: [e-mail]
Precedence: bulk

Al,

I agree with your definitions.

What you provide is som useful labels which I find sound and useful. I
would encourage labels like these to be defined for different types of
practices. Maybe something for the roadmap ?

One case that seems to be missing is the case where one certificate of one
type is used to apply for another certificate of another type. They may use
same key, different naming attributes, identify different privilages, maybe
issued by different CA:s, but they are both individual statements valid at
the same time. 
In physical life we do this all the time. We may use our ID-card to apply
for a petrol card or a credit card. We use the same key (our signature in
hand writing). Still the context will make clear which certificate to use
in any given occasion. I would not use my ID-card to by petrol and not the
petrol card in the Bank. They are not even cross certified, they are just
individual statements by the issuer according to their policies.

The "Qualified Certificate" may be used in this context to carry the
function of an electronic ID-card, thus may considerably enhance initial
registration to other CA:s such as SET CA:s, elelctronic trade CA:s, helth
care CA:s, other private domain CA:s etc.

But in all this I hope that we don't confuse this with the problem of
defining what is good or bad practice for a particular CA. As long as a
certificate is suitable for its intended usage, it's good parctice. And
what is suitable or not is a pure policy issue which requires a clear
context to be evaluated.

/Stefan

At 03:26 PM 11/5/98 -0500, Al Arsenault wrote:
>In the PKI with which I am familiar (which has been operational for more
>than 3 and 1/2 years now), we use a couple of different terms:
>
>	renewal:  issue a new certificate with the same DN, the same attributes,
>the same key, a different certificate serial number, and a different
>validity period
>
>	update:  issue a new certificate with the same DN, but with one or more
>new attributes, a new key, a different certificate serial number, and a
>different validity period (where here, "attribute" means any field in the
>certificate other than the subject DN, issuer DN, certificate serial
>number, or validity period).
>
>"Renewal" is used when a user is continuing on in the same job.  E.g.,
>certificates are issued for a period of 6 months.  At the end of that time,
>the user is in the same job, at the same place, with the same privileges,
>etc.  We just give the user a renewed certificate, good for another six
>months, because nothing else is changed.  We change the serial number to
>distinguish between the old and new certs - it's the issuer/serial number
>combination that uniquely identifies the certificate.  And, obviously, the
>signature value changes. 
>
>Why use the same key?  Why not - assuming that the useful lifetime hasn't
>expired, it's not a security problem. If the useful lifetime hasn't
>expired, we don't let the cert be renewed.
>
>"Update" is when something else (other than the user's name) has changed -
>the user's access authorizations, privileges, etc. In that case, we revoke
>the old certificate, because the change may have resulted in the loss of
>access, and we want to make sure that the old cert won't work.  We demand a
>new key for the same reason.  (Strictly speaking, you wouldn't have to
>revoke the old certificate if the change resulted in an increase of access
>privileges, but it's administratively easier to just always revoke the old
>cert.)
>
>If the only attribute that changes in an "update" is the user's public key,
>it's called a "rekey", but the same rules apply.
>
>Note that in a renewal, you can have multiple certificates valid for the
>same user at the same time (if you issue the renewal before the old
>certificate expires, which is generally considered to be the smart thing to
>do).  Since the public key's the same (and thus the associated private
>key's the same) it's not a major problem, assuming that the end-entity is
>capable of dealing with the fact that there are two certs for the same user
>in the repository.
>
>				Al Arsenault
>
>
>-- these are my opinions only.  They do not necessarily reflect the
>opinions of my employer, or of any other organization with which I have a
>relationship.
>
>
>
>
>At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>>At the National Securities Clearing Corporation we are beginning to face
>>renewal requirements. In every case we are talking about same CN, same CA,
>>same DN, and different validity period. I would like to say that in all
>>cases we will be seeing a new public key, and we would certainly discourage
>>the idea or re-certifying the same key, but I cannot guarantee that we will
>>never see renewal with the same public key.
>>
>>Two requirements that we consider critical, but not easily fulfilled given
>>the current state of the are, are:
>>- DN in renewed certificate is exactly identical to DN in original
>>certificate.
>>- Start of renewed certificate's validity period is exactly equal to
>>expiration of the original certificate's validity period no overlap no gap.
>>The renewed certificate would be issued as much as six weeks before the
>>start of its validity period.
>>--------------------------------------------------
>>p:[phone]                     Dwight Arthur
>>f:[phone]        Managing Director: Systems
>>b:[phone]      National Securities Clearing
>>[e-mail]        55 Water Street
>>http://www.nscc.com        New York, NY 10041-0082
>>
>>-----Original Message-----
>>>	Actually, the most prevalent case is likely to be:
>>>	3) Same CA, different public key, same CN
>>>
>>Really?  I always thought it would be validity date.  Of course this would
>>be about 18 months after PKI rollout.
>>
>
>
>
>
-------------------------------------------------------------------
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 PAA13181 for ietf-pkix-bks; Thu, 5 Nov 1998 15:05:38 -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 PAA13177 for <[e-mail]>; Thu, 5 Nov 1998 15:05:37 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA25460; Thu, 5 Nov 1998 15:05:38 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA07024; Thu, 5 Nov 1998 15:07:55 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Frank O'Dwyer" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 18:08:27 -0500
Message-ID: <006601be0911$320d9ec0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I think this is an extremely important point--any mapping between name
> spaces must be done securely and where such mapping can be avoided then
> all the better.

Frank makes some excellent points. What he is addressing is the 
interface between PKIX and SSL (TLS). Is this a PKIX-WG issue or a
TLS-WG issue?

I think it is something which TLS should address since it naming
is an issue which must be handled separately by each 'PKIX aware'
protocol. The naming issues of S/MIME are very different for example.
Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
different.


	Phill


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12994 for ietf-pkix-bks; Thu, 5 Nov 1998 14:50:16 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.56]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12989 for <[e-mail]>; Thu, 5 Nov 1998 14:50:12 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id WAA04680; Thu, 5 Nov 1998 22:55:08 GMT
Message-ID: <[e-mail]>
Date: Thu, 05 Nov 1998 22:52:32 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1> <v04011709b2667633b778@[128.89.31.126]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Stephen Kent wrote:
> The DNS is the only robust, distributed directory system the Internet has.
> That makes it attractive for two things: storing data, such as certs and
> CRLs, and for its naming tree.  Note that anytime we use a name in a cert
> that is not exactly the same as the name we use in an application, we are
> required to perform a mapping between two name spaces, and that introduces
> another database which imposes significant additional management overhead
> and another place to make errors with adverse security implications.  So,
> for example, for IPsec, i really want certs with DNS names and IP
> addresses, since these are the native name forms that the applications
> employ and upon which access control decisions are made. For SSL, browsers
> check a DNS name in a certificate against the corresponding portion of the
> URL, and ignore the rest of the DN in the subject field.   

I think this is an extremely important point--any mapping between name
spaces must be done securely and where such mapping can be avoided then
all the better. However I think it's important to understand that the
important native name forms are those that appear on the user interfaces
of applications, which are not necessarily those used deep in the
technical undergrowth. In fact, SSL as used for web browsing got that
wrong and is vulnerable as a result; it authenticated DNS names whereas
most users click on icons and natural language hyperlinks. The linkage
between those hyperlinks and DNS names is not supplied securely and thus
web spoofing is possible. (The situation is even worse today, since now
the browsers automatically map keywords when you type them into the
location bar.)  

The whole issue of naming is critical for PKI security, however I think
it's fair to say that even among experts there is no common
understanding of how PKI naming works in detail, and that does not augur
well for the security of PKI applications. The "end-to-end" naming
solution you describe above (native names in certificates) removes many
vulnerabilities, but I think you need to be sure that the names really
go end-to-end, in the sense of going all the way up onto the user's
screen, and from the user's keyboard. The issue of local vs. global
names raised by the SPKI group is also highly relevant, and really needs
to be taken on board here--for example the existence of NAT and network
10 addresses makes it staringly obvious that many distinct machines will
have the same IP address in their certificates, therefore they cannot
share the same namespace. Or will public CAs issue certs for 10.0.0.0?

For e-mail the
> case may not be so strong, since people may mentally map identifies
> irrespective of e-mail addresses, but even there I worry that cognitive
> overload can eaisly set in and cause people to make perception mistakes.
> (If one has an S/MIME system that automatically checks for the
> correspondence between the "from" address and the sender's DN from his
> cert, instead of presenting the subject DN from the certificate, then the
> above arguments apply.) So, here too, I really prefer certs with e-mail
> addresses, which is a change from a stance I adopted years ago when I wrote
> RFC 1422.

Unfortunately that still suffers from a name mapping problem. I
occasionally receive emails from people who have confused me with some
other Frank O'Dwyer on the Internet. I also have a friend who has the
same name as another person in the company where he works; he regularly
receives email about the golf society his namesake belongs to--I had to
phone him to verify his email address. The risks for encrypted email
should be obvious. The difficulty is that authenticating the email
address is insufficient if the email address itself is not obtained
securely (i.e. if it does not correspond to the user's understanding of
the name presented on the mailer's user interface). Another way of
looking at it is that securely mapping an email address to a key is only
one half of the problem; the other half is securely mapping a warm body
(or a machine recipient) to an email address.

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12955 for ietf-pkix-bks; Thu, 5 Nov 1998 14:44:52 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12951 for <[e-mail]>; Thu, 5 Nov 1998 14:44:50 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1AN3>; Thu, 5 Nov 1998 17:45:20 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E20B189@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Simonetti David <[e-mail]>
Cc: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers
Date: Thu, 5 Nov 1998 17:45:18 -0500
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

I agree with Steve for the most part.

Please note that with all due respect to X.509, even if the key
identifiers were not unique to a single subject or authority, it does
not cause any security or interoperability problem.

Please further note that use of the DN, serial number tuple for
authority key identifier is a bad idea.  It does not help with path
discovery for two reasons: 1 The syntax of subject key identifier does
not accommodate it; this becomes an issue since authority of a given
certificate is the subject of the previous certificate in a trust chain.
2.  If an authority is certified by multiple authorities, which tuple
should it put in the authKeyID field of the certificates it signs.
Putting one does not help discovering (actual it inhibits) paths going
through other authorities.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Wednesday, November 04, 1998 8:41 PM
> To:	Simonetti David
> Cc:	Kevin Kingdon; '[e-mail]'
> Subject:	Re: keyIdentifiers
> 
> Folks,
> 
> Sorry I didn't jump in earlier, but I've been out of town and out of
> touch
> for a while.
> 
> Key identifiers were motivated as a hueristic to solve the problem of
> which
> of several certs (presumably with different keys) belonging to a CA
> should
> be used to validate a cert that was signed by that CA.  This means
> that the
> IDs need only be unique relative to the CA in question, since the
> scope of
> the "search" was just the set of certs associated with that CA. Note
> that
> CA name and serial number also are an acceptable alternative for this
> purpose.
> 
> Some have suggested using these IDs are a "key" for database searches
> for
> cert chain construction, etc., but this is not within the scope of the
> extension, and thus I would advise against design decisions based on
> presumed global uniqueness, even though the odds are in your favor for
> many
> values of "global" ;-).  S/MIME does rely on the likely global
> uniqueness
> of this value, if I recall correctly, using it as a tag for
> per-recipient
> tokens.  This is a carryover from the MSP design, where we had a key
> material ID that was guaranteed to be unique and which could be used
> for
> this purpose.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA11155 for ietf-pkix-bks; Thu, 5 Nov 1998 12:29:34 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11151 for <[e-mail]>; Thu, 5 Nov 1998 12:29:33 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA26281; Thu, 5 Nov 1998 12:31:46 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 05 Nov 1998 15:26:12 -0500
To: "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <000801be08ed$9d1f5420$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In the PKI with which I am familiar (which has been operational for more
than 3 and 1/2 years now), we use a couple of different terms:

	renewal:  issue a new certificate with the same DN, the same attributes,
the same key, a different certificate serial number, and a different
validity period

	update:  issue a new certificate with the same DN, but with one or more
new attributes, a new key, a different certificate serial number, and a
different validity period (where here, "attribute" means any field in the
certificate other than the subject DN, issuer DN, certificate serial
number, or validity period).

"Renewal" is used when a user is continuing on in the same job.  E.g.,
certificates are issued for a period of 6 months.  At the end of that time,
the user is in the same job, at the same place, with the same privileges,
etc.  We just give the user a renewed certificate, good for another six
months, because nothing else is changed.  We change the serial number to
distinguish between the old and new certs - it's the issuer/serial number
combination that uniquely identifies the certificate.  And, obviously, the
signature value changes. 

Why use the same key?  Why not - assuming that the useful lifetime hasn't
expired, it's not a security problem. If the useful lifetime hasn't
expired, we don't let the cert be renewed.

"Update" is when something else (other than the user's name) has changed -
the user's access authorizations, privileges, etc. In that case, we revoke
the old certificate, because the change may have resulted in the loss of
access, and we want to make sure that the old cert won't work.  We demand a
new key for the same reason.  (Strictly speaking, you wouldn't have to
revoke the old certificate if the change resulted in an increase of access
privileges, but it's administratively easier to just always revoke the old
cert.)

If the only attribute that changes in an "update" is the user's public key,
it's called a "rekey", but the same rules apply.

Note that in a renewal, you can have multiple certificates valid for the
same user at the same time (if you issue the renewal before the old
certificate expires, which is generally considered to be the smart thing to
do).  Since the public key's the same (and thus the associated private
key's the same) it's not a major problem, assuming that the end-entity is
capable of dealing with the fact that there are two certs for the same user
in the repository.

				Al Arsenault


-- these are my opinions only.  They do not necessarily reflect the
opinions of my employer, or of any other organization with which I have a
relationship.




At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>At the National Securities Clearing Corporation we are beginning to face
>renewal requirements. In every case we are talking about same CN, same CA,
>same DN, and different validity period. I would like to say that in all
>cases we will be seeing a new public key, and we would certainly discourage
>the idea or re-certifying the same key, but I cannot guarantee that we will
>never see renewal with the same public key.
>
>Two requirements that we consider critical, but not easily fulfilled given
>the current state of the are, are:
>- DN in renewed certificate is exactly identical to DN in original
>certificate.
>- Start of renewed certificate's validity period is exactly equal to
>expiration of the original certificate's validity period no overlap no gap.
>The renewed certificate would be issued as much as six weeks before the
>start of its validity period.
>--------------------------------------------------
>p:[phone]                     Dwight Arthur
>f:[phone]        Managing Director: Systems
>b:[phone]      National Securities Clearing
>[e-mail]        55 Water Street
>http://www.nscc.com        New York, NY 10041-0082
>
>-----Original Message-----
>>	Actually, the most prevalent case is likely to be:
>>	3) Same CA, different public key, same CN
>>
>Really?  I always thought it would be validity date.  Of course this would
>be about 18 months after PKI rollout.
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA11109 for ietf-pkix-bks; Thu, 5 Nov 1998 12:23:50 -0800 (PST)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11105 for <[e-mail]>; Thu, 5 Nov 1998 12:23:48 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id MAA25218; Thu, 5 Nov 1998 12:26:42 -0800
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Is certificate renewal a good idea?
To: [e-mail] (Dwight Arthur)
Date: Thu, 5 Nov 1998 12:26:42 -0800 (PST)
Cc: [e-mail]
In-Reply-To: <000801be08ed$9d1f5420$[e-mail]> from "Dwight Arthur" at Nov 5, 98 01:53:44 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Dwight Arthur writes:
> 
> At the National Securities Clearing Corporation we are beginning to face
> renewal requirements. In every case we are talking about same CN, same CA,
> same DN, and different validity period. I would like to say that in all
> cases we will be seeing a new public key, and we would certainly discourage
> the idea or re-certifying the same key, but I cannot guarantee that we will
> never see renewal with the same public key.
> 
> Two requirements that we consider critical, but not easily fulfilled given
> the current state of the are, are:
> - DN in renewed certificate is exactly identical to DN in original
> certificate.
> - Start of renewed certificate's validity period is exactly equal to
> expiration of the original certificate's validity period no overlap no gap.
> The renewed certificate would be issued as much as six weeks before the
> start of its validity period.


Perhaps I'm missing something, but this doesn't seem that hard to me.
Just send a copy of the old certificate along with the renewal
request  (and something signed with the corresponding private key)
for the CA to use to fill in the Subject and calculate
the new Validity from.


However, what happens if a user signs a message with the old cert/key
right before it expires, and the new cert has a new key?  Then the
recipient of the signed message can't verify it because the certificate
has expired.  Unless your protocol has a way to deal with this, I'd
suggest overlapping Validity periods and/or using KeyUsagePeriod to
restrict the use of the private key to a shorter period than the cert is
valid for.


-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10875 for ietf-pkix-bks; Thu, 5 Nov 1998 11:49:59 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10871 for <[e-mail]>; Thu, 5 Nov 1998 11:49:58 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA26222; Thu, 5 Nov 1998 14:52:49 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA20434; Thu, 5 Nov 1998 14:52:47 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.006CD6DA ; Thu, 5 Nov 1998 14:48:48 -0500
X-Lotus-FromDomain: FDC
To: Francois Rousseau <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 11:50:39 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

one account attribute is the account balance in your bank account. would a
attribute certificate be re-issued and the previous one(s) invalidated
everytime the account balance changed. would you present an account balance
attribute certificate everytime you executed a financial transactions.
would a new CRL have to be sent out to all parties that you might possibly
ever do a financial transaction with everytime the value in your bank
account changed (either increased or decreased). Could you imagine an
optimization where you only sent out a CRL for decreases ... and not
necessarily for increases. What would be the protocol between you, your
bank, and the CA for issuing new validated attribute certificates everytime
your bank account changed. Because of privacy concerns are you really
interested in broadcasting your current account balance in an attribute
certificate on every financial transaction?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10765 for ietf-pkix-bks; Thu, 5 Nov 1998 11:39:52 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10761 for <[e-mail]>; Thu, 5 Nov 1998 11:39:51 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA21921; Thu, 5 Nov 1998 14:42:41 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA19983; Thu, 5 Nov 1998 14:41:15 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.006BC84E ; Thu, 5 Nov 1998 14:37:16 -0500
X-Lotus-FromDomain: FDC
To: EKR <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 11:40:05 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

x9.59 attacked different parts of the problem .... in the case of the
common useage of SSL for the buy button .... X9.59 was designed to insure
the integrity of the financial infrastructure using only digital signature
for authentication and not requiring any encryption.

... i.e. while the SSL URL (& certificate) check is interesting ... the
common useage for SSL is encryption connection between the client and
browser to protect something.

x9.59 insures the integrity of the financial infrastructure w/o requiring
SSL/encryption for protection.
it has the advantage of doing end-to-end integrity eliminating a lot of the
opportunity for fraud (security 101 teaches that any time you seperate
authentication and authorization .... holes/opportunities for fraud open
up). x9.59 also has the advantage that it works for all electronic
environments (not simply limited to internet).

one approach to the area that SSL URL checking addresses would be having
ISP boundary routers doing address filtering on origin address of incoming
packets. this can reduce many of the spoofing related attacks (not just the
one caught by the SSL URL checking) and provide some evidence trail back to
attack origins.  other is general upgrade of authentication procedures to
public key ... both at boundary points and infrastructure operations (like
DNS).

i believe that public key infrastructure for authentication is good thing.
I believe that basic justification for certificates is to provide
authentication attribute binding for offline operations; raising offline
integrity closer to what online account-based operations have. introducing
certificates into an online account-based operations can result in lowering
the integrity ....

i.e. online account-based operations with public key authentication (and no
certificates) can have extremely high integrity. The incremental increase
in integrity offered by certificates would be nominal and typically more
than offset by the decrease in integrity created by increased complexity
(i.e. complexity all by itself creates an integrity issue).  The addition
of certificate to an AADS PKI .... would represent an integrity issue ....
even if the certificate was totally ignored ... since, at the very least,
the level of complexity is raised. To the extent that the certificate is
not ignored and represents something in the process .... it further
increases complexity (having to check the CA-signing key on the certificate
or checking a CRL represents complexity & integrity issues)..... and to
actually represent a net increase in integrity there would have to some
significant reduction in the account-based operations (like eliminating the
account-related operations totally). A troublesome area for the elimination
of the account-based operations are real-time attributes and/or sensitive
attributes that raise privacy issues.

A pervasive example in the internet world are ISP account based operations
for internet service. There are real-time issues like has the account been
canceled and/or suspended (for say not paying the bill). One might consider
pre-paid accounts (like pre-paid phone cards) ... with a certificate that
was good for the pre-paid period. However, accounts still might be
cancelled ... which would need reference to the account record. As soon as
I have to touch an account record .... then having the public key bound in
the account record is simpler and higher integrity than processing
information both in the account record and in a certificate (along with all
the baggage of validating the certificate & certificate infrastructure).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10557 for ietf-pkix-bks; Thu, 5 Nov 1998 11:18:09 -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 LAA10553 for <[e-mail]>; Thu, 5 Nov 1998 11:18:06 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV17P6B>; Thu, 5 Nov 1998 14:21:28 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 14:21:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Interesting.  Does this mean that the same CN would have two certs to choose
from during this six-week period?

> -----Original Message-----
> From:	Dwight Arthur [SMTP:[e-mail]]
> Sent:	Thursday, November 05, 1998 1:54 PM
> To:	[e-mail]
> Subject:	RE: Is certificate renewal a good idea?
> 
> At the National Securities Clearing Corporation we are beginning to face
> renewal requirements. 
> 
	[snip]

> The renewed certificate would be issued as much as six weeks before the
> start of its validity period.
> --------------------------------------------------
> p:[phone]                     Dwight Arthur
> f:[phone]        Managing Director: Systems
> b:[phone]      National Securities Clearing
> [e-mail]        55 Water Street
> http://www.nscc.com        New York, NY 10041-0082
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10159 for ietf-pkix-bks; Thu, 5 Nov 1998 10:51:43 -0800 (PST)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA10155 for <[e-mail]>; Thu, 5 Nov 1998 10:51:43 -0800 (PST)
Received: from NS95LAP005.nscc.com (user-38ld19t.dialup.mindspring.com [209.86.133.61]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id NAA31809 for <[e-mail]>; Thu, 5 Nov 1998 13:54:32 -0500 (EST)
From: "Dwight Arthur" <[e-mail]>
To: <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 13:53:44 -0500
Message-ID: <000801be08ed$9d1f5420$[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.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At the National Securities Clearing Corporation we are beginning to face
renewal requirements. In every case we are talking about same CN, same CA,
same DN, and different validity period. I would like to say that in all
cases we will be seeing a new public key, and we would certainly discourage
the idea or re-certifying the same key, but I cannot guarantee that we will
never see renewal with the same public key.

Two requirements that we consider critical, but not easily fulfilled given
the current state of the are, are:
- DN in renewed certificate is exactly identical to DN in original
certificate.
- Start of renewed certificate's validity period is exactly equal to
expiration of the original certificate's validity period no overlap no gap.
The renewed certificate would be issued as much as six weeks before the
start of its validity period.
--------------------------------------------------
p:[phone]                     Dwight Arthur
f:[phone]        Managing Director: Systems
b:[phone]      National Securities Clearing
[e-mail]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
Really?  I always thought it would be validity date.  Of course this would
be about 18 months after PKI rollout.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10129 for ietf-pkix-bks; Thu, 5 Nov 1998 10:49:47 -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 KAA10124 for <[e-mail]>; Thu, 5 Nov 1998 10:49:45 -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 NAA26277; Thu, 5 Nov 1998 13:50:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 05 Nov 1998 13:47:45 -0500
To: [e-mail], [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jun and Lynn,

As indicated by Jun, a public-key certificate is meant to cryptographically
bound a public key to a user for authentication and identification
purposes, and should last as long as the strength of the cryptographic
algorithm used to sign this public-key certificate will permit unless it
needs to be revoked for various reasons.

For these volatile attributes, this is why Attribute Certificates have been
defined under X.509 (1997) and ANSI X9.57 (1997). An Attribute Certificate
is meant to cryptographically bound attributes (i.e. privileges) to the
public-key certificate of this user for access control and authorization
purposes, and should last as long as required by these privileges, which
can be extremely short or longer as required.

Francois Rousseau
AEPOS Technologies

Jun Yoshitake wrote:
>
>Lynn,
>
>I may misunderstand you, but
>I am wondering why a real-time attribute
>(which causes the privacy issues, etc.)
>has to be included in a certificate.
>
>I think the following method would be better:
>
>  A certificate shows the static binding
>  between the subject and the public key.
>
>  A real-time attribute is accessed inside the
>  application server after the successful
>  validation of the certificate. ("OK, this
>  transaction has surely come from this
>  entity, then we access the real-time
>  attribute of the entity.")
>
>Jun Yoshitake
>
>Mitsubishi Electric Corp.
>
>
>[e-mail] wrote:
>
>> an issue was binding of real-time attributes ... needing real-time access
>> to the account record .... or in a CA model the real-time invalidation &
>> real-time re-issue of a certificate anytime any of the real-time attributes
>> changed (i.e. like everytime you bank account balance changed ... which
>> possibly opens up the privacy issue of all this attribute information
>> flying around the world).
>>
>> if the attributes have to be accessed to complete the transaction ... then
>> the account record can be used in lieu of certificate to create a binding
>> between a public key and the attributes in question. If the transaction has
>> to touch the account record where the binding between the real-time
>> attributes and public key is located .... then a certificate with (possibly
>> stale) duplicate binding is superfulous to include in such a transaction.
>>
>> fundamentailly there are business requirements for authentication bindings
>> .... (passwords, shared secrets, public key, etc). this has been implemeted
>> and deployed for a very long time in the account-based world. one could
>> characterize certificates as having been created to extend a similar
>> capability into an offline environment. trying to propogate the offline
>> (relatively static/stale) certificate solution back into an online
>> environment where there exists a much richer capability for real-time
>> attribute authentication bindings would be at least superfulous .... and at
>> worst creating unecessary risks & liability.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09983 for ietf-pkix-bks; Thu, 5 Nov 1998 10:41:24 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09978 for <[e-mail]>; Thu, 5 Nov 1998 10:41:23 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id KAA14865 for <[e-mail]>; Thu, 5 Nov 1998 10:44:05 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: [e-mail]
Subject: Questions about the samples in Part1-11
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Nov 1998 10:44:05 -0800
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Hi all...

Not to detract from the terrific debate over fundamental PKI architectures,
but I have a couple of questions/comments about the annotated sample certs
in the Part1 draft.  These concern the AuthorityKeyIdentifier extension.

In the cert in D.2, the OID for the authKeyId (2.5.29.35) is mislabeled as
subjectAltName.

In the cert in D.3, the OID is properly labeled, but the key identifier 
itself is 16 bytes long.  16 bytes doesn't correspond to either of the key 
identifier possibilities (the 160-bit SHA1 hash or the 64-bit partial-
hash-and-prefix).

I'm guessing that the mislabeled authKeyId in the D.2 cert is correct, and
that the properly labeled one in D.3 has got a bad value.

(The subjectKeyId in D.1 looks OK to me.)

Am I misinterpreting this stuff?

		Marc



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNkHx9FrdFXNdDxPlAQE2kgL/Y8/Hi+nx1l7FwqykHpSS4ThRAys4vwo3
ZzBrxfaxOXixQLftLjpay2In1IC8KYWyCz68PNTXrNZyi3bb3PehA8DsOGMUdTWU
OaxESm6n8jcVK9CO5xuCwbH1V58f1CjE
=A/6n
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09890 for ietf-pkix-bks; Thu, 5 Nov 1998 10:37:32 -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 KAA09883 for <[e-mail]>; Thu, 5 Nov 1998 10:37:31 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV17PJM>; Thu, 5 Nov 1998 13:40:41 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 13:40:14 -0500 
Importance: low
X-Priority: 5
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

Let's, for a moment, go back to case # 2, viz.:  " 2)  Same CA, same public
key, same subject name, different information in the certificate (e.g.,
alternative names, validity period, CP/CPS)".  I can see how "alternative
names" will work (there are several ways to achieve it), but not how the
relying EE could deal with different validity periods or different CPs or
different CPS.  Each cert has one validity period (if it didn't, how could
the relying EE tell if it was still in play?--use the most distant Not
Before date?  I don't think so!).  Each cert also has it's own CP derived
from the three policy extensions.  And each CA has it's own CPS.  It's hard
enough to write just one CPS (it's a growth legal niche supreme).  Anyway,
all of these last three differences are academic, since they lie way outside
of PKIX compliance.  But you can always try SPKI!!

Bill
  


> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Wednesday, November 04, 1998 5:19 PM
> To:	Tammy Carter; [e-mail]; [e-mail]
> Subject:	RE: Is certificate renewal a good idea?
> 
> I would suggest that all cases #1, #2 and #3 could be valid and should be
> considered good practice as long as the certified information is correct.
> 
> All certificates are individual statements with individual liabilities. 
> 
> We have also identified several scenarios where the same public key can be
> associated with different subject names as long as they are associated
> with
> the same subject. The only "wrong" case I can see is if the same public
> key
> is certified to separate individuals in different certificates.
> 
> It will be the relying party who in the end will decide if a particular
> certificate is suitable for the present case, taking all factors in
> consideration. In this decision the relying party shall not have to be
> aware of any other related certificate for the same subject or key.
> 
> In cases of name change it would also be OK to re-issue the same
> certificate with the new name as long as the old certificate is revoked
> (if
> the old name is invalid).
> 
> For those interested in liabilities and the legal jungle associated with
> digital signatures, I would highly recommend to take a look at INCITRALs;
> "Planning of future work on electronic commerce: digital signatures,
> certification authorities and related legal issues", found at:
> http://www.un.or.at/uncitral/en-index.htm
> 
> /Stefan
> 
> At 12:28 PM 11/4/98 -0700, Tammy Carter wrote:
> >Bill, 
> >
> >I hope that you are right that your case #3 is the prevalent case.
> However,
> >my question is more along the lines of what a CA should do in cases #1
> and
> #2.
> >And, should client software be built to support case #2?
> >
> >
> >>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
> >See comments below.
> >
> >> -----Original Message-----
> >> From:	Tammy Carter [SMTP:[e-mail]] 
> >> Sent:	Tuesday, November 03, 1998 6:24 PM
> >> To:	[e-mail] 
> >> Subject:	Is certificate renewal a good idea?
> >> 
> >> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> >> others have mentioned 
> >> certificate renewal.  I had found this topic conspicuously absent from
> any
> >> of the PKIX drafts and 
> >> had assumed that renewing certificates was considered bad practice.
> Can
> >> someone enlighten 
> >> me?
> >> 
> >> It seems as though there are two cases to consider:
> >> 1)  Same CA, same public key, different subject name
> >> 2)  Same CA, same public key, same subject name, 
> >>       different information in the certificate (e.g., alternative
> names,
> >> validity period, CP/CPS)
> >> 
> >	Actually, the most prevalent case is likely to be:
> >	3) Same CA, different public key, same CN
> >
> >	[snip]
> >
> >> Comments?
> >> 
> >	Above.
> >
> >> Tammy Green Carter
> >> [e-mail] 
> >> 
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
> >Defense Information Systems Agency      Fax:           [phone] 
> >Information Assurance Office (JED)      DSN:                      761
> 
> >5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
> >Falls Church, VA 22041-2717        Internet:  <[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 KAA09823 for ietf-pkix-bks; Thu, 5 Nov 1998 10:34:10 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09819 for <[e-mail]>; Thu, 5 Nov 1998 10:34:09 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id KAA06727; Thu, 5 Nov 1998 10:38:16 -0800 (PST)
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 10:38:15 -0800
In-Reply-To: [e-mail]'s message of "Thu, 5 Nov 1998 10:11:36 -0800"
Message-ID: <[e-mail]>
Lines: 34
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:

> i stated that  i've never seen a SSL session fail the first time a client
> sees a server certificate that was manufactored by a CA on the browswer's
> CA list ... and you are claiming that is incorrect?
No, I'm claiming that the following statement is incorrect:
"(the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list)."

> I also believe that as a factor in exploit it is somewhat nullified in
> common practice because majority of SSL sessions are entered with things
> like clicking on a buy button. the URL check catches somebody claiming to
> being a URL that they aren't (and somehow misrouting traffic).
> If it is possible to mis-represent a URL ... prevented by the SSL check ...
> then it is also possible to mis-represent the page that (in common
> practice) gets you to the SSL session ...
> in which case the exploit just has a server certificate that corresponds to
> the URL that you are sent to.
Naturally. However, it's hard to see how to fix this problem
automatically without employing security all the time (which would
protect the references as well), since the issue is typically the
correspondence between the user's expectation of whom he is buying
from (which the program really doesn't have any way of knowing) and
the actual identity of that entity. I'd be interested in hearing
what mechanical check you think would protect against this attack.

Naturally, the user can check the certificate against his expectations,
but that's not automatic.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09657 for ietf-pkix-bks; Thu, 5 Nov 1998 10:24:52 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09652 for <[e-mail]>; Thu, 5 Nov 1998 10:24:51 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22639; Thu, 5 Nov 1998 13:27:41 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA16994; Thu, 5 Nov 1998 13:26:28 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F242 ; Thu, 5 Nov 1998 13:22:36 -0500
X-Lotus-FromDomain: FDC
To: EKR <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:11:36 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i stated that  i've never seen a SSL session fail the first time a client
sees a server certificate that was manufactored by a CA on the browswer's
CA list ... and you are claiming that is incorrect?

I didn't claim that the URL check didn't exist ... i claimed that I've
never seen it occur.

I also believe that as a factor in exploit it is somewhat nullified in
common practice because majority of SSL sessions are entered with things
like clicking on a buy button. the URL check catches somebody claiming to
being a URL that they aren't (and somehow misrouting traffic).
If it is possible to mis-represent a URL ... prevented by the SSL check ...
then it is also possible to mis-represent the page that (in common
practice) gets you to the SSL session ...
in which case the exploit just has a server certificate that corresponds to
the URL that you are sent to.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09615 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:47 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09611 for <[e-mail]>; Thu, 5 Nov 1998 10:23:46 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22331; Thu, 5 Nov 1998 13:26:36 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA17006; Thu, 5 Nov 1998 13:26:35 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F47E ; Thu, 5 Nov 1998 13:22:41 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:13:09 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i agree that the SSL specification works as you described ... including the
URL check.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09609 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:45 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09605 for <[e-mail]>; Thu, 5 Nov 1998 10:23:44 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22324; Thu, 5 Nov 1998 13:26:35 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA17001; Thu, 5 Nov 1998 13:26:33 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F4B5 ; Thu, 5 Nov 1998 13:22:42 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Alan Lloyd <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:22:06 -0800
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i've stated that if an account record has to be accessed in order to
complete the operation/transaction ..... then the certificate portion is
superfulous.

As mentioned elsewhere, certificates have been characterized as originating
to provide similar attribute/authentication binding in the offline world as
has been available in the online, account-based world (the certificates
don't do the authentication ... the certificates provide the binding
between attributes and public-key so that the authentication can be done
... i.e. enabling authentication capability similar to what is provided by
accounts in the online world).

Trying to then retrofit such an offline binding capability to the online
world ... where the binding capability has already existing ... is
superfolous, tends to unncessarily increase risk and complexity while
reducing availability.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09603 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:42 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09598 for <[e-mail]>; Thu, 5 Nov 1998 10:23:41 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22320; Thu, 5 Nov 1998 13:26:31 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA16997; Thu, 5 Nov 1998 13:26:29 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F1DD ; Thu, 5 Nov 1998 13:22:35 -0500
X-Lotus-FromDomain: FDC
To: Jun Yoshitake <[e-mail]>
cc: Stephen Kent <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Alan Lloyd <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 09:55:00 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

in order to  complete a transaction/operation ... if a account record has
to be accessed at all (because of real-time, privacy or other reasons),
then seperating attributes into those in a certificate and those in the
account record can, at best, represent superfulous effort and significant
increase in complexity .... and at worst increase various kinds of risk and
significantly lower availability of the infrastructure.

there is nothing implicit about partitioning the attributes needed to
complete a transaction/operation into several places ... however, each such
partitioning typically significantly increases complexity and risk while
lowering availability. Reasons for partitioning can include requirements
for account-based operations because of things like real-time attributes
and/or sensitivity/privacy issues associated with attributes.

the simplest example is an existing online, account-based, electronic
authorization environment (say like an ISP RADIUS environment that uses
passwords for authentication).  Contrast in terms of risk, failure modes,
complexity two implementation modes:

1) registering a public key in a RADIUS account record in lieu of a
password, modifying the RADIUS serrver to do digital signature
authentication with the registered public key, and modifying the RADIUS
client to accept a digital signature (in lieu of a password).

2) create a CA, create a CA database, create a CA customer call center
and/or tieing an existing customer call center into the CA database,
getting a signed CA certificate, registering public keys at the CA, issuing
certificates, modifying RADIUS client to accept certificate and digital
signature, modifying RADIUS server to verify certificate and authenticate
CA digital signature on the certificate, checking for a CRL entry for the
certificate, retrieving the CA's digital certificate, verifying the CA's
digital certificate and the digital signature on the CA's digital
signature, checking for a CRL entry for the CA's digital signature (etc ...
possibly on up to the root-CA tree) and finally accessing the RADIUS
account record.

First off, the transaction in neither mode will complete if the RADIUS
server and RADIUS account record is unavailable. However, in addition, the
second mode won't complete if none of the remaining PKI infrastructure is
unavailable (and/or if it chooses to continue in spite of it being
unavailble opens up fraud and risk potential completing the operation w/o
completing the authentication process).

At NISS conference last month a financial institution talked about
migration to relying party certificates because of privacy and liability
issues .... i.e. a certificate containing only the account number and
public key. In this scenerio, the certificate is stored in the account
record when the public key is registered and a copy returned to the owner.
This about reduces privacy, liability, complexity, risk, availability and
fraud exposures to a minimum (associated with using both a certificate and
an account record). At this point, the question becomes why does the owner
have to send a digital signature and the certificate to the institution on
every operation .... if the institution already has the original of the
certificate. The downside risk is that the certificate signing key at least
becomes a point of attack ... unless the institution totally ignores the
sent certificate and alwas relies on the original in the account  for
verifying the account owners digital signature ... in which case sending
the certificate even becomes more superfulous.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07624 for ietf-pkix-bks; Thu, 5 Nov 1998 06:40:58 -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 GAA07619 for <[e-mail]>; Thu, 5 Nov 1998 06:40:56 -0800 (PST)
From: [e-mail]
Received: (from uucp@localhost) by btec-fw.certco.com (8.8.8/8.8.8) id JAA23644; Thu, 5 Nov 1998 09:43:29 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com(192.168.69.12) by btec-fw.certco.com via smap (V2.1) id xma023627; Thu, 5 Nov 98 09:43:16 -0500
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <W1RH1PDB>; Thu, 5 Nov 1998 09:43:16 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:43:10 -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

E-mail addresses in Certificates sounds good, but please do not put them
into the Certificate's subject.

A Certificate's subject is a singular Name. A Name is a CHOICE of one type:
RDNSequence.

S/MIME embeds two names into subject: a distinguished name and an e-mail
address. Embedding multiple names into subject works OK for S/MIME, but does
not scale. Just imagine 20 or 30 names.

Should a Certificate contain multiple names? Why not!

One solution is to add a CHOICE to Name each time a new application naming
system is defined. This system is pretty efficient and works in a closed
system. In an open system, this solution does not scale very well and
requires everyone to update their systems.

Another solution is to leave Name alone (RDNSequence remains the common
"handle") and let application's define Extension(s) for their naming
systems. For example, Alice might choose to integrate all her names (and
identifiers) into one monolithic Certificate (e.g., social security number,
credit card account number, checking account number, email address, etc.),
while Bob might choose to use separate certificates.

Frank Balluffi
CertCo


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, November 04, 1998 5:18 PM
To: Phillip M Hallam-Baker
Cc: [e-mail]
Subject: Re: Scale (and the SRV record)


Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07464 for ietf-pkix-bks; Thu, 5 Nov 1998 06:15:51 -0800 (PST)
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07457 for <[e-mail]>; Thu, 5 Nov 1998 06:15:47 -0800 (PST)
Received: from boa.tycho.ncsc.mil (boa.tycho.ncsc.mil [144.51.3.28]) by tarius.tycho.ncsc.mil (8.9.1/8.9.1) with SMTP id JAA03127; Thu, 5 Nov 1998 09:14:20 -0500 (EST)
Received: by boa.tycho.ncsc.mil with Microsoft Mail id <[e-mail]>; Thu, 5 Nov 1998 09:03:33 -0500
Message-ID: <[e-mail]>
From: James M Hayes <[e-mail]>
To: "'EKR'" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:03:31 -0500
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 GAA07459
Sender: [e-mail]
Precedence: bulk

> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847

-----Original Message-----
From:	EKR [SMTP:[e-mail]]
Sent:	Thursday, November 05, 1998 7:58 AM
To:	[e-mail]
Cc:	Stephen Kent; [e-mail]
Subject:	Re: Scale (and the SRV record)

[e-mail] writes:
> you must live on another part of the internet than i do.
> 
> I've seen clients fail SSL connection because the supplied server
> certificate wasn't manufactored by a CA in the included browswer list.
Of course. 

> I've yet to see a client fail an SSL connection because it was the first
> time it had ever encountered a particular server certificate ... had
> absolutely no record of the particular server certificate or prior
> knowledge of the particular server (the only characteristic for succesful
> SSL seems to be that the server's certificate was manufactored by CA known
> in the browser list).
Lynn, this simply isn't correct.

There are two major checks for a server certificate:
1. That it's descended from a trust point.
2. That it contain a name that corresponds to the URL that the
client thinks it's dereferencing. 

In terms of browsers, I would add the following to keep things in perspective:

1. Trust - Trust management is still an issue within the browser environment.  The user doesn't really know which authority is actually authorized to certify a certificate for a given server (certificate masquerade). For example, if Bob connected to a web site outside of his company and ended up with a server certificate signed by his company CA (in his browser), he may actually think that this is okay.   His company is suppose to provide the security to entities outside of his company.  Chances are that Bob will just look for the "secure" icon and not ever see that his CA signed the certificate.
2. Education - Users do not actually know how to go about verifying the authenticity of the CAs in their browsers or where to go to get the actual information.   
3. PKIX Nemesis - Real-time revocation status is still an issue.  

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07436 for ietf-pkix-bks; Thu, 5 Nov 1998 06:13:43 -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 GAA07432 for <[e-mail]>; Thu, 5 Nov 1998 06:13:40 -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 DAA07696; Fri, 6 Nov 1998 03:16:15 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91027537526614>; Fri, 6 Nov 1998 03:16:15 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Scale (and the SRV record)
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 03:16:15 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alan Lloyd <[e-mail]> writes:
 
>Perhaps the answer to most of this is to ask how PKI suppliers are 
>integrating their non directory solutions into organisations - without 
>causing yet more islands of services, information and higher operational costs.
>
>Or why they built X.509 without X.500. Thats a bit like using a data 
>structure from a database - without using the features of a database.
 
It's interesting that you mention the word "database" here in relation to 
X.509.  About six months ago I did an informal poll of users of my crypto 
toolkit to see what they were doing for certificate storage.  The toolkit
supports everything from primitive flat files and smart cards through all 
manner of RDBMS's and LDAP.  The almost universal solution to certificate 
storage needs was MS Access.  Everything else may as well not have existed.
 
Some comments on this:
 
This is for the unwashed masses who have to work with crypto (developers and 
implementors), not cryptographers.  All they wanted was a way to map an email 
address/server name to a key.  Heirarchical storage and free-form attributes 
and fuzzy dice and chrome tailfins were nothing but a nuisance to work around 
(so far I've identified one single user of an LDAP directory, and AFAIK he was 
only playing with it on a Unix box).  Dunno how many users there are in total, 
but at one point it was averaging 200 downloads a week.  Most of the users in 
the informal poll used Win32 and VB (spit), followed by Delphi/C/C++.
 
Although I don't know whether I want to laugh or cry at the use of Access, it 
does make sense: It's either pre-installed on the most widely-used platform on 
the planet or can be trivially added via the MS Jet engine[0], and there are a 
huge number of third-party tools available to use with it.
                                                          
[Purely in order to forestall the inevitable comments about "it won't scale 
 and there's no replication and it's not distributed and you can't get it with 
 fuzzy dice and ...", I'll reiterate what I said above: The users don't care.  
 Given the choice, they've gone for the easy-to-use, widely-available solution 
 which does the job.  I'll continue to support whatever's around and let the
 users make their own choice, but when it comes to key storage mechanisms they 
 sure aren't choosing X.500 or anything derived from it]
 
Peter.
 
[0] So-called because it both sucks and blows.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA07201 for ietf-pkix-bks; Thu, 5 Nov 1998 05:39:12 -0800 (PST)
Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA07197 for <[e-mail]>; Thu, 5 Nov 1998 05:39:11 -0800 (PST)
Received: from doogie by smtp0-alterdial.uu.net with SMTP  (peer crosschecked as: 1Cust119.tnt3.tco2.da.uu.net [153.34.247.119]) id QQfoeo04801; Thu, 5 Nov 1998 13:41:37 GMT
Reply-To: <[e-mail]>
From: "Steve Russell" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Alan Lloyd" <[e-mail]>
Cc: "'Al Arsenault '" <[e-mail]>, <[e-mail]>
Subject: RE: A different architecture?  (was Re: certificate path services
Date: Thu, 5 Nov 1998 08:33:02 -0500
Message-ID: <004701be08c0$d004c870$[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
In-Reply-To: <v04011719b266a5d4610c@[128.89.31.126]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

General comments on this particular thread:

Can a PKI operate and survive without a directory?  Yes.

Could PKI, as envisioned by most companies, be deployed without a directory?
No.

One of the most fundamental issues that we are dealing with is certificate
and CRL retrieval because it deals with the deployability of PKI rather than
its mathematical validity.  To mandate the implementation of a certain style
or type of directory would be wrong.  However, to not formalize the
standards so that the process of retrieving CRLs and certs from a directory
would be interoperable would be just as wrong.

There are some major headaches that we inherit when we start looking at
directories such as does the directory need to be trusted, what is the
access protocol, how is the personal data in the directory protected, how
are multiple non-related directories referenced by a PKI client.  I won't
attempt to address all of these in this mail, but...

Having worked a lot with X.500 directories, I would rather have a limb
removed than mandate X.500 as a foundation for PKI, but some customers will
choose to do that.  Looking at a set of the sample PKI applications I do
think that accessibility via LDAP is necessary.  Having said that, DNS is a
much better model for the quick retrieval of specific data because of it
simplicity and very loose referral relationships.  The structure of a DNS
address is also much easier to process within an application than the
umpteen levels that are commonly implemented in X.500 and LDAP DITs.  The
question is do we place the certificate in DNS and maybe slap (pun intended)
a LDAP server on the database or do we design a separate structure which has
a similar format and build up the relations over time...

May I suggest a compromise?  Make one change to DNS to add a new record type
which is a directory server, however, the certificate repository would
remain separate from the DNS database.  When a user references 'foo.com' to
attempt to find a certificate or a CRL the appropriate DNS would refer them
to appropriate directory server much like MX records work today.  This also
allows users the flexibility to transparently maintain internal directories
separately from publicly available directories based on which DNS their
users reference.  It has the advantage of potentially providing a much
richer set of data storage and access controls (through LDAP or X.500) than
would ever be feasible to build into DNS.  Lastly, it resolves a potential
paging problem that would exist with DNS when requesting a large number of
certificates or CRLs.

Comments?

Steve
_______________________________________________________
Steve Russell
Chief Technologist
Public Key Strategies, Inc.
_______________________________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06943 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59: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 EAA06939 for <[e-mail]>; Thu, 5 Nov 1998 04:59:45 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03858; Thu, 5 Nov 1998 08:02:19 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011704b2674fc12933@[128.33.238.37]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Nov 1998 07:53:45 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>you must live on another part of the internet than i do.

Well, working for the company that pioneered Internet technology, I may
live in a better neighborhood :-).

>I've seen clients fail SSL connection because the supplied server
>certificate wasn't manufactored by a CA in the included browswer list.

Of course that's true, but that does not disagree with my observation;
first one authenticates the server cert, then one matches it against the
server URL.  You're just seeing a failure of the first part of a two stage
mechanism.

>I've yet to see a client fail an SSL connection because it was the first
>time it had ever encountered a particular server certificate ... had
>absolutely no record of the particular server certificate or prior
>knowledge of the particular server (the only characteristic for succesful
>SSL seems to be that the server's certificate was manufactored by CA known
>in the browser list).

First time has nothing to do with this, Lynn.  Review the description for
how SSL processing of server certs works.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06936 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06923 for <[e-mail]>; Thu, 5 Nov 1998 04:59:42 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03837; Thu, 5 Nov 1998 08:02:13 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011702b2674ddab6a1@[128.33.238.37]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4EE@DSG1>
Date: Thu, 5 Nov 1998 07:47:42 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Cc: [e-mail], Phillip M Hallam-Baker <[e-mail]>, Al Arsenault 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>Steve I think the response missed the issue. The issue Lynn describes is
>one of optimising information management and keeping all things
>pertinent to a User in one place (inc its certs) and that over a
>distributed business, different users will be stored in different
>places. Its not a question of "real time" because directories can be
>real time, thats sizing. Its not a question of caching, because the data
>has to come from somewhere in the first place.
> The common approach to User and user authentication is a single record
>- in a distributed "data store" - a directory system  and that a CA
>directory is part of the directory cloud and that User entries have User
>certs in for authentication.
> IMHO Its the information management and administration optimisation
>that drive the directory requirements for the larger organisations.
>

Not surprizingly, we again disagree.  The issue of realtime IS relevant
here because in such applications (vs. e-mail, for example) the
communicating peers can exchange cert and CRL data directly.  In contrast,
applications such as e-mail require one party to retrieve cert and CRL data
prior to communication.  That's the point I was making.  Also, it IS a
matter of caching because caching provides performamce improvements, an
issue in realtime apps, not so much so in stanged deliver apps.

The common approach you cite for user auth is valid, but the CA is NOT
intrinsically part of the directory.  It is just a subscriber to the
directory, just like the users.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06937 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06926 for <[e-mail]>; Thu, 5 Nov 1998 04:59:43 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03871; Thu, 5 Nov 1998 08:02:22 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011705b267506e51ae@[128.33.238.37]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Nov 1998 07:56:49 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

 <duplicate text deleted> ...
>
>URL is better than nothing ... but it just says that the URL and the
>certificate is the same. Most instances of https invokation is a button on
>a web-page. It is possible to make sure that the button does in fact invoke
>a URL that matches the certificate ... and it still be an exploit.

The URL against which the match is made is the one associated with the
current SSL session. Since the match is on the DNS name portion, page
differences within the same server are not an issue.  In fact, some
browsers adopt a star-name matching rule and thus allow a match for any of
a series of servers with the same name suffix, e.g., *server.foo.bar.com.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06938 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06925 for <[e-mail]>; Thu, 5 Nov 1998 04:59:42 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03845; Thu, 5 Nov 1998 08:02:16 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011703b2674efdfb23@[128.33.238.37]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4EF@DSG1>
Date: Thu, 5 Nov 1998 07:50:26 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: Alan Lloyd 	 <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>But where to these local caches and hard copy books come from. How do
>they get into order. What is the registration or allocation process.

The issue is not the ultimate source of the data, but how people access it
in real time.

>AND
>
>If there was an online directory service would they use that instead.

If it were free, yes. Here in the US the online form is called directory
assistance and it costs money, especially when the data is not local (a
caching issue).

>If directory technology has been designed to be distributed and scale
>and solves lots of people keeping lots of outdated copies - why not use
>it?

If all of this were true of the directory systems, I would agree.  But what
we have now is not characterized by these adjectives ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06843 for ietf-pkix-bks; Thu, 5 Nov 1998 04:54:20 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06838 for <[e-mail]>; Thu, 5 Nov 1998 04:54:19 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id EAA03445; Thu, 5 Nov 1998 04:58:25 -0800 (PST)
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 04:58:24 -0800
In-Reply-To: [e-mail]'s message of "Wed, 4 Nov 1998 21:42:55 -0800"
Message-ID: <[e-mail]>
Lines: 24
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:
> you must live on another part of the internet than i do.
> 
> I've seen clients fail SSL connection because the supplied server
> certificate wasn't manufactored by a CA in the included browswer list.
Of course. 

> I've yet to see a client fail an SSL connection because it was the first
> time it had ever encountered a particular server certificate ... had
> absolutely no record of the particular server certificate or prior
> knowledge of the particular server (the only characteristic for succesful
> SSL seems to be that the server's certificate was manufactored by CA known
> in the browser list).
Lynn, this simply isn't correct.

There are two major checks for a server certificate:
1. That it's descended from a trust point.
2. That it contain a name that corresponds to the URL that the
client thinks it's dereferencing. 

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06706 for ietf-pkix-bks; Thu, 5 Nov 1998 04:23:42 -0800 (PST)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06702 for <[e-mail]>; Thu, 5 Nov 1998 04:23:40 -0800 (PST)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id VAA29918; Thu, 5 Nov 1998 21:13:39 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA24175; Thu, 5 Nov 98 21:18:48 JST
Received: from elgw.isl.melco.co.jp ([133.141.13.130]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with ESMTP id VAA02559; Thu, 5 Nov 1998 21:32:59 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id VAA26523; Thu, 5 Nov 1998 21:25:27 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id VAA28623; Thu, 5 Nov 1998 21:31:37 +0900 (JST)
Received: from zaku by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA02354; Thu, 5 Nov 1998 21:24:55 +0900
Message-Id: <[e-mail]>
Date: Thu, 05 Nov 1998 21:23:48 +0900
From: Jun Yoshitake <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Alan Lloyd <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Lynn,

I may misunderstand you, but
I am wondering why a real-time attribute
(which causes the privacy issues, etc.)
has to be included in a certificate.

I think the following method would be better:

  A certificate shows the static binding
  between the subject and the public key.

  A real-time attribute is accessed inside the
  application server after the successful
  validation of the certificate. ("OK, this
  transaction has surely come from this
  entity, then we access the real-time
  attribute of the entity.")

Jun Yoshitake

Mitsubishi Electric Corp.


[e-mail] wrote:

> an issue was binding of real-time attributes ... needing real-time access
> to the account record .... or in a CA model the real-time invalidation &
> real-time re-issue of a certificate anytime any of the real-time attributes
> changed (i.e. like everytime you bank account balance changed ... which
> possibly opens up the privacy issue of all this attribute information
> flying around the world).
>
> if the attributes have to be accessed to complete the transaction ... then
> the account record can be used in lieu of certificate to create a binding
> between a public key and the attributes in question. If the transaction has
> to touch the account record where the binding between the real-time
> attributes and public key is located .... then a certificate with (possibly
> stale) duplicate binding is superfulous to include in such a transaction.
>
> fundamentailly there are business requirements for authentication bindings
> .... (passwords, shared secrets, public key, etc). this has been implemeted
> and deployed for a very long time in the account-based world. one could
> characterize certificates as having been created to extend a similar
> capability into an offline environment. trying to propogate the offline
> (relatively static/stale) certificate solution back into an online
> environment where there exists a much richer capability for real-time
> attribute authentication bindings would be at least superfulous .... and at
> worst creating unecessary risks & liability.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06617 for ietf-pkix-bks; Thu, 5 Nov 1998 04:05:52 -0800 (PST)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06613 for <[e-mail]>; Thu, 5 Nov 1998 04:05:50 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 4188"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-27 #29038) with ESMTP id <[e-mail]> for [e-mail]; Thu, 5 Nov 1998 07:08:12 EDT
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <V93G9XRX>; Thu, 05 Nov 1998 07:05:17 -0500
Content-return: allowed
Date: Thu, 05 Nov 1998 07:07:24 -0500
From: "Larowe, Rick" <[e-mail]>
Subject: RE: Scale (and the SRV record)
To: "Kent, Steve-GTEI" <[e-mail]>, Alan Lloyd <[e-mail]>
Cc: "'Paul Koning'" <[e-mail]>, Alan Lloyd <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Anyway, didn't thin clients become less of a goal with the 
> demise of netPCs
> :-)?  All of the software on my desktop and laptop machines is getting
> bigger each year, not smaller.

But let's not forget about PDAs, smart phones, pagers, and even 
watches.  They'll be the next targets. 

-rick
-----------------------------------------------------------------
Rick LaRowe
GTE Internetworking  -  CyberTrust Solutions, Inc.            
77 "A" Street,  Needham, MA   02194-2892  
781-455-5970 (voice)  781-455-3105 (fax)
[e-mail]
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02948 for ietf-pkix-bks; Wed, 4 Nov 1998 22:34:25 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02944 for <[e-mail]>; Wed, 4 Nov 1998 22:34:24 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA09770; Thu, 5 Nov 1998 01:37:12 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27919; Thu, 5 Nov 1998 01:37:10 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0029A237 ; Thu, 5 Nov 1998 01:33:12 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:36:00 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

for the most part routers now use PPP on point-to-point links (i.e. point
to point protocol)  .... typically having modems ... these modem links can
vary from the 14.4 modem banks at a ISP ... to a T3 WAN connection into the
backbone (if you configure you companies router connection into an ISP ...
you could be asked to specify various sorts of PPP parameters for the WAN
connection).

I first used radius on the livingston portmaster with a bank of 14.4 modems
... and it was typically deployed with radius server code running on a unix
login machine .... where the unix machine was configured with
userids/passwords for everything that was allowed to access the portmaster.
The radius server code originally did a unix password operation for the
indicated userid ... to verify a valid portmaster connection.

If you want to see more on radius .... see:

               http://www.garlic.com/~lynn/rfcietf.html

(or pick up the pointer from the RFC editor's page), then click on frames
version, then click on "Term". The Term abbreviations will include Radius
which you can click on ... which will give you list of all the RFC
concerning Radius

from 2058 ....

Managing dispersed serial line and modem pools for large numbers of
   users can create the need for significant administrative support.
   Since modem pools are by definition a link to the outside world, they
   require careful attention to security, authorization and accounting.
   This can be best achieved by managing a single "database" of users,
   which allows for authentication (verifying user name and password) as
   well as configuration information detailing the type of service to
   deliver to the user (for example, SLIP, PPP, telnet, rlogin).

   Key features of RADIUS are:


Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers..




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02838 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:08 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02828 for <[e-mail]>; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08862; Thu, 5 Nov 1998 01:17:50 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27779; Thu, 5 Nov 1998 01:17:48 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BB8 ; Thu, 5 Nov 1998 01:13:46 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 21:38:00 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

if the public key is already bound to attributes in an account record then
the certificate represents duplicate function from what is in the account
record (i.e. since the attributes and the public key would already be in
the account record .... then having to send in the certificate at all is
superfulous ... as well as validating if the certificate is still good,
validating the CA-signing key on the certificate, validating the CA
certificate, validating if the CA certificate is still good, validating the
CA-CA-signing key on the CA-certificate, ... on up to the root
certificate).

For authentication, there needs to be owners digital signature on at least
the account-number and time-stamp or sequence number  (i.e. the owner has
to sign something to show that it possesses the corresponding private key
and that it isn't a replay). Also sending the certificate is superfulous if
the account record has to be accessed (also containing the public key).

Including the certificate can have additional downside (in addition to
being superfolous):
    1) unecessary increased bandwidth
    2) increased systemic risk because of uncessary dependency on
CA-infrastructure
    3) possible attacks based on attributes duplicated in the certificate
that have real-time characteristics and become stale. .... and trying to
precipitate authorization decisions based on the stale data.

Furthermore attributes/information in the




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02837 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:07 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02830 for <[e-mail]>; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08850; Thu, 5 Nov 1998 01:17:46 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27770; Thu, 5 Nov 1998 01:17:44 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BCF ; Thu, 5 Nov 1998 01:13:47 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:02:24 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

I've seen clients fail SSL connection because the supplied server
certificate wasn't manufactored by a CA in the included browswer list.

I've yet to see a client fail an SSL connection because it was the first
time it had ever encountered a particular server certificate ... had
absolutely no record of the particular server certificate or prior
knowledge of the particular server (the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list).

URL is better than nothing ... but it just says that the URL and the
certificate is the same. Most instances of https invokation is a button on
a web-page. It is possible to make sure that the button does in fact invoke
a URL that matches the certificate ... and it still be an exploit.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02829 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02821 for <[e-mail]>; Wed, 4 Nov 1998 22:15:04 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08867; Thu, 5 Nov 1998 01:17:52 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27783; Thu, 5 Nov 1998 01:17:51 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BF0 ; Thu, 5 Nov 1998 01:13:53 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "Al Arsenault" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:16:33 -0800
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

an issue was binding of real-time attributes ... needing real-time access
to the account record .... or in a CA model the real-time invalidation &
real-time re-issue of a certificate anytime any of the real-time attributes
changed (i.e. like everytime you bank account balance changed ... which
possibly opens up the privacy issue of all this attribute information
flying around the world).

if the attributes have to be accessed to complete the transaction ... then
the account record can be used in lieu of certificate to create a binding
between a public key and the attributes in question. If the transaction has
to touch the account record where the binding between the real-time
attributes and public key is located .... then a certificate with (possibly
stale) duplicate binding is superfulous to include in such a transaction.

fundamentailly there are business requirements for authentication bindings
.... (passwords, shared secrets, public key, etc). this has been implemeted
and deployed for a very long time in the account-based world. one could
characterize certificates as having been created to extend a similar
capability into an offline environment. trying to propogate the offline
(relatively static/stale) certificate solution back into an online
environment where there exists a much richer capability for real-time
attribute authentication bindings would be at least superfulous .... and at
worst creating unecessary risks & liability.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02822 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:05 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02816 for <[e-mail]>; Wed, 4 Nov 1998 22:15:04 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08858; Thu, 5 Nov 1998 01:17:48 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27776; Thu, 5 Nov 1998 01:17:47 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BC6 ; Thu, 5 Nov 1998 01:13:47 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 21:42:55 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

you must live on another part of the internet than i do.

I've seen clients fail SSL connection because the supplied server
certificate wasn't manufactored by a CA in the included browswer list.

I've yet to see a client fail an SSL connection because it was the first
time it had ever encountered a particular server certificate ... had
absolutely no record of the particular server certificate or prior
knowledge of the particular server (the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list).





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02622 for ietf-pkix-bks; Wed, 4 Nov 1998 21:40:45 -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 VAA02617 for <[e-mail]>; Wed, 4 Nov 1998 21:40:41 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSLX>; Thu, 5 Nov 1998 16:38:08 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'Paul Koning'" <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 16:38:07 +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

Thanks Steve Comments in line.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 9:29
> To:	Alan Lloyd
> Cc:	'Paul Koning'; Alan Lloyd; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
> Alan,
> 
> >The real issue is that some protocols (not simple or lightweight
> ones)
> >provide system selection features (chaining/replication selection
> >control) and the use of these assist with system operation and
> >information integrity ie. improve reliability and trust.
> >regards alan
> 
> Neither trust nor robustness is necessarily improved by introducing
> more
> players into the cert validaton process.  Replicated copies of CRLs in
> a
> variety of repositories are more robust than a single copy in one
> database,
> all else being equal. 
	[Alan Lloyd]  The issue raised is of inconsistency in
master/replica CRLs and not being able to select the master with LDAP.
ie. the master may have a new CRL, the replica has not seen any of this
yet.

>   However, relying on a network of directories to
> perform operations on which the security of a communication  depends,
> may
> easily be less robust and less secure.  I am especially concerned
> about the
> notion of a thin client relying on servers to validate certs.
	[Alan Lloyd]  Concern is good. But some customers want them. At
the opposite end is the worst evil. 10 or so complex validation path
processes all tied to different CA or service vendors.

> Anyway, didn't thin clients become less of a goal with the demise of
> netPCs
> :-)?  All of the software on my desktop and laptop machines is getting
> bigger each year, not smaller.
	[Alan Lloyd]  Yes - but its the dependency issue. We dont want
CA company X to change a few validation path conditions or add a cros
cert and all the clients to be updated - do we?
	regards alan
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02598 for ietf-pkix-bks; Wed, 4 Nov 1998 21:35:21 -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 VAA02594 for <[e-mail]>; Wed, 4 Nov 1998 21:35:18 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSLV>; Thu, 5 Nov 1998 16:32:48 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4EF@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Alan Lloyd <[e-mail]>
Cc: "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 16:32:46 +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

But where to these local caches and hard copy books come from. How do
they get into order. What is the registration or allocation process.

AND

If there was an online directory service would they use that instead.

If directory technology has been designed to be distributed and scale
and solves lots of people keeping lots of outdated copies - why not use
it?

People work with the tools to hand. New tools should solve todays
problems. And when we use them people will work differently.

regards alan


> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 9:24
> To:	Alan Lloyd
> Cc:	'Phillip M Hallam-Baker'; Russ Housley; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
> Alan,
> 
> >I think of CAs as functions and certs that are applied to real life
> >entities which are represented as attributes of objects in a business
> >level directory system.
> >
> >Bashing DNS records into certs and CA operations and validation paths
> >just complicates life with a higher operational costs and does not
> use
> >the utility of distributed information infrastructures. Its like
> >configuring every phone with every one elses phone number. When in
> fact
> >we use the distributed telephone network and its directory system to
> >avoid that.
> >
> 
> In the US few people I know regularly use directory assistance; they
> most
> often use local caches (address books) and hard copy phone
> directories.
> So, this analogy seems a bit questionable.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02558 for ietf-pkix-bks; Wed, 4 Nov 1998 21:29:29 -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 VAA02550 for <[e-mail]>; Wed, 4 Nov 1998 21:29:22 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSL4>; Thu, 5 Nov 1998 16:26:52 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4EE@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: Phillip M Hallam-Baker <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 5 Nov 1998 16:26: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

Steve I think the response missed the issue. The issue Lynn describes is
one of optimising information management and keeping all things
pertinent to a User in one place (inc its certs) and that over a
distributed business, different users will be stored in different
places. Its not a question of "real time" because directories can be
real time, thats sizing. Its not a question of caching, because the data
has to come from somewhere in the first place. 
 The common approach to User and user authentication is a single record
- in a distributed "data store" - a directory system  and that a CA
directory is part of the directory cloud and that User entries have User
certs in for authentication.
 IMHO Its the information management and administration optimisation
that drive the directory requirements for the larger organisations.

regards alan

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 10:21
> To:	[e-mail]
> Cc:	Phillip M Hallam-Baker; Alan Lloyd; Al Arsenault;
> [e-mail]
> Subject:	RE: A different architecture? (was Re: certificate path
> services 	[ was RE: NEW Data type for certificate selection ? ])
> 
> Lynn,
> 
> >there are business operations with account-based systems with
> >100million
> >entries and raw
> >data in tens of terabytes. for business process that have to access
> the
> >account record to complete the transaction, splitting responsibility
> for
> >the transaction between an account infrastructure and a PKI
> infrastructure
> >... doesn't improve availability ... it actually lowers it since now
> there
> >has to be two things that are operational for transaction completion
> i.e.
> >availability to complete is the product of the availability of the
> two
> >infrastructures; for availability to improve, transaction would have
> to be
> >able to complete even if the whole PKI infrastructure or the whole
> account
> >infrastructure was not operational (and since the original premise
> was that
> >at least the account infrastructure has to be operational for the
> >transaction to complete; adding a PKI infrastructure can't improve
> the
> >availibitliy)
> 
> I agree with the overall observation, but note that for many of these
> sorts
> of applications, realtime exchange of certs and CRLs, and/or caching,
> may
> obviate the need for realtime directory access and thus remove the
> availability concern you cite here.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02409 for ietf-pkix-bks; Wed, 4 Nov 1998 21:10:48 -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 VAA02405 for <[e-mail]>; Wed, 4 Nov 1998 21:10:47 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00785; Thu, 5 Nov 1998 00:13:17 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170bb26681ed9aba@[128.89.31.126]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Nov 1998 17:15:06 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Russ Housley'" <[e-mail]>, "Alan Lloyd" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rich,

>>Denial of service is allways an issue; it is a concern in
>>all of the possible repository alternatives.
>
>At the risk of stating the obvious, a denial of service that
>prevents you from getting revocation information (such as a
>CRL) can be Very Bad, given the implementation quality of most
>network services that I've seen...

True, but note that in many applications one can exchange CRLs; it is not
always necessary to retrieve them from ANY repository.  In that case, the
worst that happens is that one's peers sends a CRL that should be currently
valid, but for which an unscheduled successor has been issued.  In many
applications, and with frequent CRL (e.g., daily) issuance, this is a
reasonable risk to accept.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02400 for ietf-pkix-bks; Wed, 4 Nov 1998 21:10:38 -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 VAA02396 for <[e-mail]>; Wed, 4 Nov 1998 21:10:36 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00794; Thu, 5 Nov 1998 00:13:20 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011721b266b0faff4f@[128.89.31.126]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Nov 1998 20:40:48 -0500
To: "Simonetti David" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: keyIdentifiers
Cc: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Sorry I didn't jump in earlier, but I've been out of town and out of touch
for a while.

Key identifiers were motivated as a hueristic to solve the problem of which
of several certs (presumably with different keys) belonging to a CA should
be used to validate a cert that was signed by that CA.  This means that the
IDs need only be unique relative to the CA in question, since the scope of
the "search" was just the set of certs associated with that CA. Note that
CA name and serial number also are an acceptable alternative for this
purpose.

Some have suggested using these IDs are a "key" for database searches for
cert chain construction, etc., but this is not within the scope of the
extension, and thus I would advise against design decisions based on
presumed global uniqueness, even though the odds are in your favor for many
values of "global" ;-).  S/MIME does rely on the likely global uniqueness
of this value, if I recall correctly, using it as a tag for per-recipient
tokens.  This is a carryover from the MSP design, where we had a key
material ID that was guaranteed to be unique and which could be used for
this purpose.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02386 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09:44 -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 VAA02381 for <[e-mail]>; Wed, 4 Nov 1998 21:09:43 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00717; Thu, 5 Nov 1998 00:12:02 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011727b266d062c373@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 22:55:00 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>while the current common certificate infrastructure model is SSL ... which
>baiscally checks if the certificate has been manufactored by somebody in
>the list of known certificate manufactors/issuers (aka CAs) .... the common
>authentication model on the internet is logging on to the service provider.

Well, that depends.  For most corporate Internet users, this model is not
at all common.  For redidential subscribers, it is.

>This one is basically somebody signs up for an account and establishes a
>password. When they want to use the internet ... they contact the router,
>give their account name and proof of password. The router is likely running
>something like radius ... in which case it forwards the account name and
>password to an account authenticator.

You contact something like a PPP server, not a router per se.  The RADIUS
server is likely running elsewhere; after all, it's a server.

>For PKIX to address the most fundamental of internet authentication
>requirements ... could involve the ISP issuing a relying party certificate
>with just the account name (sidestepping liability and privacy issues). The
>choice now would be would the ISP router accept the certificate
>authentication at face-value ... or would it use a PKI flavor of radius to
>contact an account authenticator .... for instance to have more timely
>information on whether the account is in good standing.

Because not all subscribers necessarily have the same privileges, mere
verification of the cert provides authentication, but not authorization. So
it would be quite reasonable for the ISP to check a database to see such
things as where the user is allowed to connect, what QoS features he may
elect, etc.  That check against an access control database is a fine time
to check for revocation, precisely because the ISP is both the CA and the
consumer of the cert.

>This is possibly the most fundamental current internet requirement ... and
>it illustrates again the extremely short step from relying party
>certificates to the AADS model ... where if the account has to be touched
>as part of the authentication/authoritization ... then it is easily shown
>that shipping the certificate with the transaction is superfulous (if
>somebody gives you a copy of something .... how many million times do you
>have to send the same copy back to them ... before they realize that they
>don't have to see the copy if they are already looking at the original
>stored in the account record).

Note that my example still differentiates between authentication and
authorization.  Sending in the user's cert is just a convenient way to
package the public key and the ID it represents.  Nothing wrong with that.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02377 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09: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 VAA02373 for <[e-mail]>; Wed, 4 Nov 1998 21:09:34 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00735; Thu, 5 Nov 1998 00:12:18 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011709b2667633b778@[128.89.31.126]>
In-Reply-To: <000401be0291$3c8dec00$[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
Date: Wed, 4 Nov 1998 17:17:52 -0500
To: "Phillip M Hallam-Baker" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02365 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09:24 -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 VAA02361 for <[e-mail]>; Wed, 4 Nov 1998 21:09:23 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00712; Thu, 5 Nov 1998 00:11:57 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011712b26691a19938@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:21:11 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "Al Arsenault" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>there are business operations with account-based systems with >100million
>entries and raw
>data in tens of terabytes. for business process that have to access the
>account record to complete the transaction, splitting responsibility for
>the transaction between an account infrastructure and a PKI infrastructure
>... doesn't improve availability ... it actually lowers it since now there
>has to be two things that are operational for transaction completion  i.e.
>availability to complete is the product of the availability of the two
>infrastructures; for availability to improve, transaction would have to be
>able to complete even if the whole PKI infrastructure or the whole account
>infrastructure was not operational (and since the original premise was that
>at least the account infrastructure has to be operational for the
>transaction to complete; adding a PKI infrastructure can't improve the
>availibitliy)

I agree with the overall observation, but note that for many of these sorts
of applications, realtime exchange of certs and CRLs, and/or caching, may
obviate the need for realtime directory access and thus remove the
availability concern you cite here.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02359 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09: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 VAA02355 for <[e-mail]>; Wed, 4 Nov 1998 21:09:16 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00705; Thu, 5 Nov 1998 00:11:49 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170ab26681276c13@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 17:12:31 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>spent a lot of time on the SSL portion of the web ... 94/95 working out how
>to do/deploy electronic commerce operations. Current SSL infrastructure
>uses server certificate for key exchange ... not for authentication. To the
>extent that there is authentication done ... it consists of checking the
>certificate issuer against a list that has typically pre-installed in the
>browser (not checking on the certificate owner). It is one of the reasons
>that I coined the term certificate manufactoring .... to highlight
>manufactoring and distributing certificates is typically only a small part
>of what has become to be considered part of a PKI infrastructure.

I disagree wuth this last observation.  As I mentioned in a recent posting,
browsers do check for a match between the server URL and it's cert, which
is precisely an authentication function.

>I got possibly the first mutual authentication SSL deployed ... before it
>was called SSL3. Again authentication was limited to verifying the
>certificate issuer. The server certificate was essentially a comfort device
>for all the clients ... the client certificates started out essentially
>being "relying party" certificates .... but to do more than simple
>certificate issuer authenitcation ... i had to check the certificate owner
>information against an account database. At that point it became evident
>that even relying party certificates were superfulous in the transaction
>since I needed to reference the account record (which already had copy of
>the public key, lots of attribute binding ... as well as up-to-date
>real-time status).

If you chosen the IDs in the client certs to match the account record keys,
the authentication capability of client certs would have been useful.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02350 for ietf-pkix-bks; Wed, 4 Nov 1998 21:08:12 -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 VAA02346 for <[e-mail]>; Wed, 4 Nov 1998 21:08:11 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00579; Thu, 5 Nov 1998 00:10:40 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011711b26691297cfe@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:19:34 -0500
To: Elliott Ginsburg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fwd: Re: A different architecture
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Elliott,

>I'm adding to my own message. Someone also stated on the list that we do
>not want to have a directory between our apps and our PKI services. But,
>again, how often today do we have DNS between our apps and our network
>communication services?

We already need the DNS to make the existing Internet protocols work. In
many apps, we don't need a directory to support certs/CRLs, so the
introduction of an additional directory system for that purpose introduces
new failure modes.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02325 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02319 for <[e-mail]>; Wed, 4 Nov 1998 21:07:52 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00567; Thu, 5 Nov 1998 00:10:36 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011710b26691047432@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:17:39 -0500
To: Elliott Ginsburg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Elliott,

>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?

DNS is very simple compared to an X.500 or LDAP directory system, and thus
people do question whether thye Internet will succeed in building a
parallel directory structure of this latter sort.  That doesn't mean it
won't happen, but it is by no means certain.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02329 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02324 for <[e-mail]>; Wed, 4 Nov 1998 21:07:53 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00539; Thu, 5 Nov 1998 00:10:10 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011719b266a5d4610c@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC083114@DSG1>
Date: Wed, 4 Nov 1998 23:02:52 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture?  (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'Al Arsenault '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alan,

>snip
>One of the biggest features of a well designed PKI is that it embodies a
>distributed security model that scales through simple replication of
>static
>data, a problem we know how to solve.
>
>
>Alan: However a major weakness in any system occurs when one replicates
>data - particularly when that data forms a linkages to a point of trust
>- and in the path there are other objects that may or may not exist (eg
>CRLs) that could be placed in these paths in non uniform ways...
>EG LDAP -  one of the major deficiencies cannot ask for master data from
>a CA directory ie. If a CRL has been placed in the master but not yet
>propagated to replicas, then a client could consider the cert being
>validated - valid if it (without its knowlege - accesses the replica).

I'm not an LDAP fan and I keep observing that one does not always require
directory systems to support a PKI.

>(ie. why talk of trust and how one achieves trust in a distributed and
>replicated information system and then use a protocol that has so many
>untrusted deficiencies???? eg. LDAP.

See comments re LDAP above.
>
> It also has the property that to
>spoof the identity of an end entity, one ought to have to subvert the CA
>that issued the cert to that entity, although sloppy cross certification
>and bad choices for PKI structure can make this situation worse.
>
>Alan: Bad PKI designs come from weaknesses and complexities in the CA
>and the related client information model and service interaction
>software - as one adds complexity the components that work with an ill
>defined and variable information model, then all things get into a mess.
>EG LDAP - no system service model, add and extension here there and
>everywhere. Outcome - LDAP is not universal anymore - an operational
>mess.

Aw, come on now.  Stop using LDAP as a strawman to make more complex
directory systems seem like the only (preferred?) answer. Complex cert
models are bad, I agree, but they are bad whether one has to deal with them
in fat clients or in fat, fancy validation servers.

>Limited scale systems, complex clients and weak/variable CA information
>models is what we have. Its better to have consistency in service and
>place trust in the implementation of that service. There is no point in
>discussing trust in theoretical Objects and certificates and the
>processes that might happen in someones CA or "cert server".

We have poor examples of PKIs now, but I reject the view that we cannot
make them better, or that we have to fundamentally change the model
underlying X.509 to address these problems.

>
>The notion of cert validation servers is thus very disturbing.
>
>Alan:
>If a client goes to a CAs directory to get a cert in the path and the
>directory provides the wrong one and therefore user to user transaction
>is invalidated - then denial of service happens.
>Something - somewhere in the system has to be trusted. And in my book
>its the implementation that is trusted not theoretical models.

If a directory provides the wrong cert in response to a READ, this is
immediately apparent to the client and thus the bug/attack can be detected.
Implementations must be correct to make things work, but good
implementations of an insecure model are not necessarily better than
mediocre implementations of a secure model.

>eg. I can build a highy trusted directory system that does cert
>matching, has bullet proof access controls, has trusted processes that
>generate valid flags from processing CRLs...for the client.

Maybe, but I am not convinced.  We may have good client implementatins and
bad ones.  Even bad ones may have to be attacked individually to subvert
the security for a lot of users, whereas a successful attack against a good
server that many users rely upon would be much more devastating, and that
makes it more worthwhile to attack it.

>OR I could  write sloppy, bug ridden, fragile process that serves no
>purpose in terms of trust.

You could write it, but I may not choose to buy it. :-)  Be careful here;
if you push too far one might ask whether it's worthwhile having a high
quality cert validation process at all (distributed or centralized) if all
of the clients are running a vulnerable OS anyway!

>OR I could promote a protocol to a server without any distributed,
>directory relevant CA information model and say that solves the problem.
>
What protocol?  OCSP?  We're still working on the scope of the model, but
if the OCSP responder is the CA for the cert in question, we have a fine,
simple, model.

>In the above the following observations MUST be made.
>Using good directory technology, with sound information services to
>support CA functions provide scaleability and measureable trust models.

"measurable trust models?"  What metrics do we use?

>Using bad anything .. provides no trust
>
>Having a protocol to a server without any notion of the CA function and
>the directory support that CAs need or any notion of scaling or how it
>deals with multiple CA domains or the complexity of the client,  only
>generates problems.
>
>IE.
>IMHO Talking of trust in the CA/X.509/directory environment without any
>reference to implemtation and system design qualitative characteristics
>becomes an endless debate - without resolution.

Well, we can terminate this debate now, to avoid falling into that trap.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02317 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02313 for <[e-mail]>; Wed, 4 Nov 1998 21:07:26 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00505; Thu, 5 Nov 1998 00:09:56 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170db26684b00897@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BE@DSG1>
Date: Wed, 4 Nov 1998 17:29:21 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Paul Koning'" <[e-mail]>, Alan Lloyd 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>The real issue is that some protocols (not simple or lightweight ones)
>provide system selection features (chaining/replication selection
>control) and the use of these assist with system operation and
>information integrity ie. improve reliability and trust.
>regards alan

Neither trust nor robustness is necessarily improved by introducing more
players into the cert validaton process.  Replicated copies of CRLs in a
variety of repositories are more robust than a single copy in one database,
all else being equal.  However, relying on a network of directories to
perform operations on which the security of a communication  depends, may
easily be less robust and less secure.  I am especially concerned about the
notion of a thin client relying on servers to validate certs.

Anyway, didn't thin clients become less of a goal with the demise of netPCs
:-)?  All of the software on my desktop and laptop machines is getting
bigger each year, not smaller.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02311 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02307 for <[e-mail]>; Wed, 4 Nov 1998 21:07:18 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00490; Thu, 5 Nov 1998 00:09:49 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170cb26682c7cdfa@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
Date: Wed, 4 Nov 1998 17:24:08 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>I think of CAs as functions and certs that are applied to real life
>entities which are represented as attributes of objects in a business
>level directory system.
>
>Bashing DNS records into certs and CA operations and validation paths
>just complicates life with a higher operational costs and does not use
>the utility of distributed information infrastructures. Its like
>configuring every phone with every one elses phone number. When in fact
>we use the distributed telephone network and its directory system to
>avoid that.
>

In the US few people I know regularly use directory assistance; they most
often use local caches (address books) and hard copy phone directories.
So, this analogy seems a bit questionable.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02305 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07:09 -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 VAA02301 for <[e-mail]>; Wed, 4 Nov 1998 21:07:08 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00474; Thu, 5 Nov 1998 00:09:34 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170eb2668eb0e84e@[128.89.31.126]>
In-Reply-To: <[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Date: Wed, 4 Nov 1998 18:14:08 -0500
To: Al Arsenault <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Al,

>This is one of the areas where the SPKI folk make sense.  There is not, and
>will not ever be, a single, unified, global directory where everything has
>a name that fits into the schema.  There are instead "directories" of
>information that apply to a specific "domain".  In PKIX's case, it's the
>information that applies to the Internet.  The namespace covers those
>things that are important in the Internet context, and nothing else.  To
>me, that's (right now), IP addresses, domain names, port numbers, service
>names, user names/mailbox names, and maybe one or two other things. If the
>Internet expands to cover toll plazas, then a naming space will have to be
>developed for them, and after it's defined and standardized we can figure
>out how to put the proper names in certificates.

The notion of no single, unique, name that is appropriate for every context
is not unqiue to SPKI;  I've been preaching this notion for at least 3
years and gave talks on this at a DIMACS workshop in 1996 and at the RSA
conference in 1997, before publishing a paper on the topic in MILCOM 97.
The SDSI model says that the names in certs are not useful except very
locally, and hence emphasizes the idea of the key as an ID.  What we are
talkin g about does not share that notion.  DNS names, 822 addresses, IP
addresses, URLs, etc. have widespread semantics, even though they are not
universal.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13576 for ietf-pkix-bks; Wed, 4 Nov 1998 12:18:27 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13571 for <[e-mail]>; Wed, 4 Nov 1998 12:18:25 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA16B4; Wed, 4 Nov 1998 15:21:01 -0500
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 15:21:18 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]> <[e-mail]> <[e-mail]>
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 MAA13572
Sender: [e-mail]
Precedence: bulk

X.509 states, for Subject Key Identifier, "A key identifier shall be
unique with respect to all key identifiers for the subject with which it
is used."  

For Authority Key Identifier, it states, "A key identifier shall be
unique with respect to all key identifiers for the issuing authority for
the certificate or CRL containing the extension."

This sounds to me like the key identifier need only be unique to the
subject or issuer, respectively.  Seems like 60 bits would be
sufficiently effective.

Dave S.

Ambarish Malpani wrote:
> 
> I don't think the key identifier was meant to be universally unique
> (although I would like it to be so).
> 
> The use of key idenfiers, AFAIK, is as follows:
> 
> A CA includes a subject key identifier in its cert. It includes that
> subject key identifier as authority key identifier in all certs that
> it issues. This allows an application to find the CA cert - useful
> where an application may have more than one CA cert with the same
> name - for example, when the CA is going through key rollover.
> 
> Hope this helps (and is correct),
> 
> Ambarish

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14450 for ietf-pkix-bks; Wed, 4 Nov 1998 14:20:34 -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 OAA14446 for <[e-mail]>; Wed, 4 Nov 1998 14:20:32 -0800 (PST)
Received: from stefans (t3o68p90.telia.com [62.20.139.90]) by maila.telia.com (8.8.8/8.8.8) with SMTP id XAA25164; Wed, 4 Nov 1998 23:22:54 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 04 Nov 1998 23:19:04 +0100
To: "Tammy Carter" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 OAA14447
Sender: [e-mail]
Precedence: bulk

I would suggest that all cases #1, #2 and #3 could be valid and should be
considered good practice as long as the certified information is correct.

All certificates are individual statements with individual liabilities. 

We have also identified several scenarios where the same public key can be
associated with different subject names as long as they are associated with
the same subject. The only "wrong" case I can see is if the same public key
is certified to separate individuals in different certificates.

It will be the relying party who in the end will decide if a particular
certificate is suitable for the present case, taking all factors in
consideration. In this decision the relying party shall not have to be
aware of any other related certificate for the same subject or key.

In cases of name change it would also be OK to re-issue the same
certificate with the new name as long as the old certificate is revoked (if
the old name is invalid).

For those interested in liabilities and the legal jungle associated with
digital signatures, I would highly recommend to take a look at INCITRALs;
"Planning of future work on electronic commerce: digital signatures,
certification authorities and related legal issues", found at:
http://www.un.or.at/uncitral/en-index.htm

/Stefan

At 12:28 PM 11/4/98 -0700, Tammy Carter wrote:
>Bill, 
>
>I hope that you are right that your case #3 is the prevalent case.  However,
>my question is more along the lines of what a CA should do in cases #1 and
#2.
>And, should client software be built to support case #2?
>
>
>>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
>See comments below.
>
>> -----Original Message-----
>> From:	Tammy Carter [SMTP:[e-mail]] 
>> Sent:	Tuesday, November 03, 1998 6:24 PM
>> To:	[e-mail] 
>> Subject:	Is certificate renewal a good idea?
>> 
>> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
>> others have mentioned 
>> certificate renewal.  I had found this topic conspicuously absent from any
>> of the PKIX drafts and 
>> had assumed that renewing certificates was considered bad practice.  Can
>> someone enlighten 
>> me?
>> 
>> It seems as though there are two cases to consider:
>> 1)  Same CA, same public key, different subject name
>> 2)  Same CA, same public key, same subject name, 
>>       different information in the certificate (e.g., alternative names,
>> validity period, CP/CPS)
>> 
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
>	[snip]
>
>> Comments?
>> 
>	Above.
>
>> Tammy Green Carter
>> [e-mail] 
>> 
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
>Defense Information Systems Agency      Fax:           [phone] 
>Information Assurance Office (JED)      DSN:                      761      
>5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
>Falls Church, VA 22041-2717        Internet:  <[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 PAA00456 for ietf-pkix-bks; Wed, 4 Nov 1998 15:21:43 -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 PAA00452 for <[e-mail]>; Wed, 4 Nov 1998 15:21:39 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSJR>; Thu, 5 Nov 1998 10:19:06 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4E0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'David Boyce'" <[e-mail]>, Al Arsenault <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: A PKI for the Internet (was RE: Scale (and the SRV record))
Date: Thu, 5 Nov 1998 10:19:05 +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

Thanks David - Access Controls without Authentication are not  much use
are they. Perhaps when one looks at PKI and realises that X.509 is used
for "Authentication" of Users - one then may take the next step to say
that this is coupled with ACI for getting at the business data (in the
directories), etc. Then the PKI starts to have some utility.
If the PKI is just used for signing messages, then its limited. But if
its also used for directory access/authentication - then its doing what
X.500 designed it for.

Also - Make that two implementations :-)

regards alan
> -----Original Message-----
> From:	David Boyce [SMTP:[e-mail]]
> Sent:	Saturday, 31 October 1998 2:22
> To:	Al Arsenault
> Cc:	Alan Lloyd; 'Bill Burr'; 'Phillip M Hallam-Baker'; Russ Housley;
> [e-mail]
> Subject:	Re: A PKI for the Internet (was RE: Scale (and the SRV
> record))
> 
> Al Arsenault writes:
> >>
> >>	Isnt it odd that X.509 is used for PKI and X.500 is discounted? 
> >>
> >
> >AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI 
> business.
> >X.509 is not used for its original, X.500-based purpose, which was 
> actually
> >to control access to the directory for the purpose of limiting who 
> could
> >modify entries.
> 
> I'm sorry, Al, but it is factually incorrect to say that X.509 is not
> used for its original, X.500-based purpose.  There is at least one
> commercial implementation of X.500 which supports strong
> authentication
> using X.509 certificates, and makes use of the fact for Access Control
> purposes.
> 
> I'll grant that X.509 is being used beyond its original purpose, but
> that's just a measure of its utility.
> 
> David.
> -- 
> David Boyce
> 
> Tel:	[phone]		Richmond, Surrey, ENGLAND
> Email:	[e-mail]	Isode's WWW:
> http://www.isode.com/
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00239 for ietf-pkix-bks; Wed, 4 Nov 1998 14:47:44 -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 OAA00244 for <[e-mail]>; Wed, 4 Nov 1998 14:34:05 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSJK>; Thu, 5 Nov 1998 09:31:17 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4DB@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:31:16 +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 OAA00248
Sender: [e-mail]
Precedence: bulk

Comments inline.

Perhaps the answer to most of this is to ask how PKI suppliers are
integrating their non directory solutions into organisations - without
causing yet more islands of services, information and higher operational
costs.

Or why they built X.509 without X.500. Thats a bit like using a data
structure from a database - without using the features of a database.

> -----Original Message-----
> From:	Graham Bland [SMTP:[e-mail]]
> Sent:	Friday, 30 October 1998 20:33
> To:	'Alan Lloyd'; '[e-mail]'
> Subject:	RE: Scale (and the SRV record)
> 
> 
> 
> Large portions of original message deleted for readability, relevant
> sections only maintained with comments in line. 
> Graham Bland 
> > -----Original Message----- 
> > From: Alan Lloyd [ mailto:[e-mail] ] 
> > Sent: 29 October 1998 21:37 
> > To: 'Bill Burr'; Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> 
> > [e-mail] 
> > Subject: RE: Scale (and the SRV record) 
> ...deleted 
> > > I have been saying for some time that don't know of anybody who
> has 
> > > built 
> > > an X.500 directory of a size that convinces me that it is a viable
> 
> > > technology to base a US national PKI, or even a US Federal 
> > > government-wide 
> > > PKI on. I keep asking the question, where are the really big 
> > > distributed 
> > > X.500 directories? Particularly multivendor directories.  
> > But I don't 
> > > seem 
> > > to get any answers.  What I hear are horror stories about the 
> > > difficulties 
> > > of getting any two X.500 products to work together. 
> >       [Alan Lloyd]  
> >       No horror stories from us. 20 million entries, 1000s of
> searches 
> > a second, distributed, multi master, etc We have very scaleable, 
> > distributed technology - that also integrates LDAP servers, etc We
> are 
> > very busy deploying X.500 into major corporate infrastructures who
> are 
> > following the themes I described. Including those in the US. 
> > Please read 
> > our WEB site. "Uses of Directory Services" 
> > 
> Can I access these directories or are they private islands.  If they
> are private islands then they might as well not exist.
	[Alan Lloyd]  
	Thats a narrow view. All systems today are islands in one shape
or another. Thats no reason to say that X.500 or directory systems dont
work. They are - in our books - being applied to many organisations to
consolidate their information systems, provide a direction to having a
single logon and a singlr mail box. And on this we appli PKI
functionality.

	Are you saying the above direction is not happening or you dont
agree with it.


> > >   If the X.500 directory industry builds products that
> interoperate 
> > > and scale 
> > > well, it has done a really bad job of getting the word out.  
> >       [Alan Lloyd]  
> >       My view here is that the LDAP hype has done a really good job
> of 
> > damaging X.500. However, now the LDAP hype has dissipated and
> reality 
> > has set in we are left with a protocol that can only ACCESS a 
> > directory 
> > service ? is twice as big as DAP and has half the functionality. In 
> > addition, getting LDAP only solutions is proving to many that X.500
> is 
> > the way to go because of LDAPs NO distribution and a model 
> > that demands 
> > Replicate everything to everywhere. LDAP has high operational 
> > costs and 
> > gets to a point where it is unworkable. 
> >       So LDAP accessed X.500 in my book is the way to go and is
> being 
> > deployed globally. 
> I think you meant to say DAP accessed X.500 from the flow of the text 
> > 
> > >  Until now, I have also been saying, does anybody have a
> believable 
> > > alternative to the mythological, pervasive X.500 directory
> service? 
> > > It 
> > > seemed almost a rhetorical question.  But I think perhaps Phill
> has 
> > > outlined an alternative, that looks like it probably ought to
> work, 
> > > and is 
> > > based on something, DNS, that we know works well, scales well, and
> 
> > > exists 
> > > now. Moreover, we should be able to create the service we need 
> > > incrementally, by just by adding servers as we need them, one at 
> a 
> > > time. 
> > > And, If I understand the proposal, all we have to do is 
> > agree on some 
> > > simple naming conventions. 
> >       [Alan Lloyd]  I am not against alternative proposals - its all
> a 
> > question of how much effort and implementation goes behind it.
> Phills 
> > solution has to be backed by all the DNS and PKI suppliers on this 
> > planet and DNS then has to become secure - with signed operations, 
> > mutual authentication, access controls, real life naming, and scale
> a 
> > lot better and of course be easy to manage and follow Object
> Oriented 
> > design. (does this mean turning DNS into X.500?) I would vote 
> > for that - 
> > thats more X.500! 
> Why would DNS need to be more secure with signed operations mutual
> authentication etc. Certificates and CRLs are signed objects and their
> security is inherent.   Ignoring denial of service I cannot see any
> attacks from an insecure distribution method.  The whole point of the
> distribution method is that I have no trust relationship with it and
> have no need of a trust relationship be it email, X.500 or anything
> else.
	[Alan Lloyd]  
	I did not raise DNS as being a directory service as it has about
5% of the functionality of X.500. Its just that if DNS wants to become a
directory service - then its fuctionality will end up as X.500 no doubt.

> How is it relevant if DNS follows OO design, why should it.  While I
> agree that OO design and methods have many advantages the relevant
> questions are does it work and how much will it cost, not what its
> internal structure is.
> What is the problem with the scalability of DNS (How many users does
> it support now ?) 
> X.500 is easy to manage? later you say "But LDAP did prove that
> directorys are difficult 
>  and complex and X.500 got most things right."  
	[Alan Lloyd]  Any distributed information system that supports a
major organisation for business is difficult to manage - thats obvious -
it has nothing to do with the technology in most part. Its to do with
operational dynamics, wear and tear and scaling up with usually less
resources.


	In addition we are using our X.500 to back end DNS/DHCP and
RADIUS servers  for large ISPs - now theres a trend eh.

	regards alan

> Graham Bland 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13219 for ietf-pkix-bks; Wed, 4 Nov 1998 11:45:17 -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 LAA13215 for <[e-mail]>; Wed, 4 Nov 1998 11:45:16 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA22435; Wed, 4 Nov 1998 11:45:13 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA04668; Wed, 4 Nov 1998 11:47:26 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Robert Moskowitz" <[e-mail]>, "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: keyIdentifiers
Date: Wed, 4 Nov 1998 14:47:58 -0500
Message-ID: <004701be082c$066024e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> If they need truncation, at least have the
> >length be 96 or so (by the arguments applied to HMAC).
>
> This is an interesting point.  Of course, I THINK the HMAC work post-dates
> the selection of 60 bits by the ECC crowd.  They will have to speak up to
> see if this is a good approach.

The HMAC work is not relevant here. With HMAC the collision problem
is much less severe because there is no requirement for HMACs to be
unique. The requirement is simply to make the discovery of the HMAC
key by brute force to be computationally infeasible.

This means that the HMAC strength is not reduced through the
birthday attack. So the effective cipher strength of 96 bits of
HMAC output is 2^96 - which is in the same ballpark as requiring
generation of 2^80 messages before collision is likely.

2^48 is getting there but in a world with a population of 5,000
billion robots (only 1000 each) the ability to only colonize 50
more solar systems might be constraining.

As Tom Knight once said.. "32 bits is not enough, thats not even
large enough for a phone number" - guess what the venue was??

	Phill


PS, Please, don't feel obliged to remind me there are silicon
lifeforms as well as 9 list members have done this morning. I
did not want to distract from the political point that we should
look beyond the parochial needs of the 1 billion citizens of
the rich countries when designing technology.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13114 for ietf-pkix-bks; Wed, 4 Nov 1998 11:39:47 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13110 for <[e-mail]>; Wed, 4 Nov 1998 11:39:46 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA72AC; Wed, 4 Nov 1998 14:42:22 -0500
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 14:42:38 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: Kevin Kingdon <[e-mail]>, [e-mail]
Subject: Re: keyIdentifiers
References: <003501be080a$78830460$[e-mail]>
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 LAA13111
Sender: [e-mail]
Precedence: bulk

I don't disagree.  The original proposal for a unique key identifier was
for 60 bits of the hash.  PKIX has since added a proposal for use of the
full 160 bits of the SHA-1 hash.

My point is...the key identifier is intended to be unique, using
whatever method you desire to generate it.

Dave S.

Phillip M Hallam-Baker wrote:
> 
> > Kevin,
> >
> > I believe the key identifier is intended to be universally unique.  The
> > profile does not state this.  However, I recall a presentation where
> > someone was proving mathematically that taking 60 bits out of a SHA-1
> > hash of the public key would provide sufficient uniqueness.  What is
> > sufficient?  It was a very, very, very small fraction for a very, very
> > large number of certificates.  Sorry for the generalities, but I'm not a
> > mathematician.
> 
> They would be expecting to issue far fewer than 2^30 (1 billion)
> certificates.
> 
> I'm not sure that is a very good assumption. In fact its a lousy one on
> a planet with 5 billion people.
> 
> We are not so short of bits that we need to skimp on them to create unique
> key IDs.
> 
>                 Phill

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12989 for ietf-pkix-bks; Wed, 4 Nov 1998 11:26:46 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA12985 for <[e-mail]>; Wed, 4 Nov 1998 11:26:45 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Nov 1998 12:28:58 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 04 Nov 1998 12:28:39 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 LAA12986
Sender: [e-mail]
Precedence: bulk

Bill, 

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and #2.
And, should client software be built to support case #2?


>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
See comments below.

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]] 
> Sent:	Tuesday, November 03, 1998 6:24 PM
> To:	[e-mail] 
> Subject:	Is certificate renewal a good idea?
> 
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned 
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and 
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten 
> me?
> 
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name, 
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
> 
	Actually, the most prevalent case is likely to be:
	3) Same CA, different public key, same CN

	[snip]

> Comments?
> 
	Above.

> Tammy Green Carter
> [e-mail] 
> 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12341 for ietf-pkix-bks; Wed, 4 Nov 1998 10:15:18 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12337 for <[e-mail]>; Wed, 4 Nov 1998 10:15:17 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA243; Wed, 4 Nov 1998 13:17:59 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 13:17:21 -0500
To: Paul Koning <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <003501be080a$78830460$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 01:02 PM 11/4/98 -0500, Paul Koning wrote:
>>>>>> "Robert" == Robert Moskowitz <[e-mail]> writes:
>
> >> We are not so short of bits that we need to skimp on them to
> >> create unique key IDs.
> >> 
> Robert> Some people are bandwidth conservative.  Some devices are
> Robert> indeed bandwidth limited.
>
>I think lots of mistakes in protocol design have been made in the name
>of a misguided goal of saving a few bytes.  I was just looking at one
>yesterday -- a certain well known protocol throwing off all alignment
>for the sake of saving ONE lousy byte.

I agree with your assessment.  I fought a derived IV for IPsec like PPTP
uses (and I think L2TP) to save 4 bytes per packet for 'slow links' and
potentially have IVs with low haming distance or require prior packet
delivery.  Some byte squeezing costs more than is gained.

>Anyway, if you're dealing with certs, you already have big blobs of
>bytes.  And if a few bytes is really that big a deal, isn't the right
>answer to make key IDs optional?  But if supplied they should be good, 
>and I agree with Phillip that there is no sensible reason to truncate
>them to such tiny lengths.  If they need truncation, at least have the 
>length be 96 or so (by the arguments applied to HMAC).

This is an interesting point.  Of course, I THINK the HMAC work post-dates
the selection of 60 bits by the ECC crowd.  They will have to speak up to
see if this is a good approach.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12201 for ietf-pkix-bks; Wed, 4 Nov 1998 10:01:16 -0800 (PST)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12195 for <[e-mail]>; Wed, 4 Nov 1998 10:01:15 -0800 (PST)
Received: from xedia.com by relay2.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfobo19001; Wed, 4 Nov 1998 13:02:49 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07715; Wed, 4 Nov 98 13:00:59 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA16108; Wed, 4 Nov 1998 13:02:47 -0500
Date: Wed, 4 Nov 1998 13:02:47 -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: keyIdentifiers
References: <[e-mail]> <003501be080a$78830460$[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

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

 >> We are not so short of bits that we need to skimp on them to
 >> create unique key IDs.
 >> 
 Robert> Some people are bandwidth conservative.  Some devices are
 Robert> indeed bandwidth limited.

I think lots of mistakes in protocol design have been made in the name
of a misguided goal of saving a few bytes.  I was just looking at one
yesterday -- a certain well known protocol throwing off all alignment
for the sake of saving ONE lousy byte.

Anyway, if you're dealing with certs, you already have big blobs of
bytes.  And if a few bytes is really that big a deal, isn't the right
answer to make key IDs optional?  But if supplied they should be good, 
and I agree with Phillip that there is no sensible reason to truncate
them to such tiny lengths.  If they need truncation, at least have the 
length be 96 or so (by the arguments applied to HMAC).

	paul



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12066 for ietf-pkix-bks; Wed, 4 Nov 1998 09:47:07 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA12062 for <[e-mail]>; Wed, 4 Nov 1998 09:47:06 -0800 (PST)
Received: (qmail 19365 invoked from network); 4 Nov 1998 17:34:28 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 4 Nov 1998 17:34:28 -0000
Received: (qmail 1716 invoked from network); 4 Nov 1998 17:49:47 -0000
Received: from unknown (HELO valicert.com) (10.0.0.101) by 10.0.0.4 with SMTP; 4 Nov 1998 17:49:47 -0000
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 09:50:16 -0800
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

I don't think the key identifier was meant to be universally unique
(although I would like it to be so).

The use of key idenfiers, AFAIK, is as follows:

A CA includes a subject key identifier in its cert. It includes that
subject key identifier as authority key identifier in all certs that
it issues. This allows an application to find the CA cert - useful
where an application may have more than one CA cert with the same
name - for example, when the CA is going through key rollover.

Hope this helps (and is correct),

Ambarish


Simonetti David wrote:
> 
> Kevin,
> 
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.
> 
> Dave S.
> 
> Kevin Kingdon wrote:
> >
> > One issue that does affect applications is the scope of a key identifier. Is
> > it unique for a given subject, a given CA, or globally unique? In other
> > words, can I build a certificate chain using just key identifiers, or do I
> > have to use some combination of subject + identifier or issuer + (subject)
> > identifier to build the chain? X.509 says the first case (unique only with
> > respect to a given subject). Does PKIX expand the scope of the identifier to
> > one of the other two levels I mentioned?
> >
> > -----Original Message-----
> > From: Marc Branchaud [mailto:[e-mail]]
> > Sent: Tuesday, November 03, 1998 11:59 AM
> > To: [e-mail]
> > Subject: Re: keyIdentifiers
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Content-Type: text/plain; charset=us-ascii
> >
> > Robert Moskowitz <[e-mail]> scrawled:
> > >
> > > Not according to a presentation Chicani gave to the federal PKI TWG back
> > in
> > > the spring.  He was quite clear that it was an APP issue to use
> > > keyIdentifiers to build a cert chain.
> > >
> >
> > Sure, but the app doesn't have to construct any key identifiers, just use
> > the ones that are already in the certs.
> >
> > > Then last week Mike Myers was pointing out how an app can use keyIdentifer
> > > for simpler processing for renewals.  Mike could better discuss this then
> > > me remember it.
> > >
> >
> > That's a different, and new, usage for key identifiers which I haven't
> > heard of before.
> >
> > My point is that s'far as chain construction goes, apps don't need to know
> > how to create key identifiers.  If key IDs are to be used for other
> > purposes, then some standard method of construction is probably a good
> > idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> > identifiers, not apps.
> >
> >                 Marc
> >
> > +------------------------------------------------------------------------+
> >  Marc Branchaud                                  \/
> >  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> >  [e-mail]        PKI References page:              www.xcert.com
> >  604-640-6227          www.xcert.com/~marcnarc/PKI/
> > +------------------------------------------------------------------------+
> >   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> >
> > iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> > YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> > F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> > =Itvv
> > -----END PGP SIGNATURE-----
> 
> --
> David Simonetti, Booz·Allen & Hamilton Inc.

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11329 for ietf-pkix-bks; Wed, 4 Nov 1998 08:20:18 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11325 for <[e-mail]>; Wed, 4 Nov 1998 08:20:16 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA95; Wed, 4 Nov 1998 11:22:52 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 11:23:11 -0500
To: "Phillip M Hallam-Baker" <[e-mail]>, "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: <[e-mail]>
In-Reply-To: <003501be080a$78830460$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:47 AM 11/4/98 -0500, Phillip M Hallam-Baker wrote:
>
>They would be expecting to issue far fewer than 2^30 (1 billion)
>certificates.
>
>I'm not sure that is a very good assumption. In fact its a lousy one on
>a planet with 5 billion people.

But you are counting carbon based life forms.  There will be many factors
more of silicon based life forms that will need certificates.  Mike O'dell,
in his comments on bandwidth consumption has already named all of these
various systems (PCSs, pagers, heart monitors, toasters, refigs) as silicon
cockroaches.

>We are not so short of bits that we need to skimp on them to create unique
>key IDs.
>
Some people are bandwidth conservative.  Some devices are indeed bandwidth
limited.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11003 for ietf-pkix-bks; Wed, 4 Nov 1998 07:45:09 -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 HAA10999 for <[e-mail]>; Wed, 4 Nov 1998 07:45:08 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA15850; Wed, 4 Nov 1998 07:44:59 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA15266; Wed, 4 Nov 1998 07:47:15 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: keyIdentifiers
Date: Wed, 4 Nov 1998 10:47:47 -0500
Message-ID: <003501be080a$78830460$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Kevin,
>
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.

They would be expecting to issue far fewer than 2^30 (1 billion)
certificates.

I'm not sure that is a very good assumption. In fact its a lousy one on
a planet with 5 billion people.

We are not so short of bits that we need to skimp on them to create unique
key IDs.

		Phill



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10796 for ietf-pkix-bks; Wed, 4 Nov 1998 07:13:20 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10792 for <[e-mail]>; Wed, 4 Nov 1998 07:13:19 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA309; Wed, 4 Nov 1998 10:16:03 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 10:11:20 -0500
To: "Flanigan, Bill" <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail] a.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 08:31 AM 11/4/98 -0500, Flanigan, Bill wrote:
>> 
>> It seems as though there are two cases to consider:
>> 1)  Same CA, same public key, different subject name
>> 2)  Same CA, same public key, same subject name, 
>>       different information in the certificate (e.g., alternative names,
>> validity period, CP/CPS)
>> 
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
Really?  I always thought it would be validity date.  Of course this would
be about 18 months after PKI rollout.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA10058 for ietf-pkix-bks; Wed, 4 Nov 1998 05:28:27 -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 FAA10054 for <[e-mail]>; Wed, 4 Nov 1998 05:28:26 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV169PQ>; Wed, 4 Nov 1998 08:31:19 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Wed, 4 Nov 1998 08:31:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

See comments below.

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Tuesday, November 03, 1998 6:24 PM
> To:	[e-mail]
> Subject:	Is certificate renewal a good idea?
> 
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned 
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and 
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten 
> me?
> 
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name, 
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
> 
	Actually, the most prevalent case is likely to be:
	3) Same CA, different public key, same CN

	[snip]

> Comments?
> 
	Above.

> Tammy Green Carter
> [e-mail] 
> 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA03745 for ietf-pkix-bks; Tue, 3 Nov 1998 17:25:40 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA03741 for <[e-mail]>; Tue, 3 Nov 1998 17:25:39 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA65; Tue, 3 Nov 1998 20:28:21 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 20:20:15 -0500
To: Kevin Kingdon <[e-mail]>, "'Simonetti David'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 04:19 PM 11/3/98 -0800, Kevin Kingdon wrote:
>In a population of 2^30 certificates, there is a probability of ~50% that
>some two of them will have the same 60-bit identifier. This works out to ~1
>billion on my slide rule -- a large, but not unimaginable, population of
>"Internet" certificates.
>
This is why I prefer the full 160bit hash and damn the 25 byte hit on cert
size.

Speaking of cert size, what are people actually seeing in cert sizes?


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03431 for ietf-pkix-bks; Tue, 3 Nov 1998 16:38:19 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA03427 for <[e-mail]>; Tue, 3 Nov 1998 16:38:18 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Nov 1998 17:40:29 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 03 Nov 1998 16:23:41 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Subject: Is certificate renewal a good idea?
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 QAA03428
Sender: [e-mail]
Precedence: bulk

In the recent thread about keyIdentifiers, Robert Moskowitz and a few others have mentioned 
certificate renewal.  I had found this topic conspicuously absent from any of the PKIX drafts and 
had assumed that renewing certificates was considered bad practice.  Can someone enlighten 
me?

It seems as though there are two cases to consider:
1)  Same CA, same public key, different subject name
2)  Same CA, same public key, same subject name, 
      different information in the certificate (e.g., alternative names, validity period, CP/CPS)

It would seem to me that case #1 should be prohibited by a PKIX-compliant CA.  It would also
seem, on the surface, that case #2 should be discouraged as "bad practice."  Of course, case 
#2 cannot be prohibited by a CA since that would mean that a CA would have to store all of the 
certificates it ever generated and look through them each time it generated a new certificate.

Case #2 is troubling to me, however.  What would stop a subordinate (non-root) CA from doing 
the following:
A)  Get a certificate from a root CA with a CPS indicating that the subordinate CA assumed  
       a large amount of liability for certificates that it issued
B)  Collect lots of money issuing certificates to end entities
C)  Renew it's certificate using the same root CA with a different CPS indicating that the 
       subordinate CA assumed no liability for any certificates it issues, and set the validity 
       period in the certificate to be the same as in the previous certificate
In such a case, it would seem that the users who paid lots of money for their "high quality 
certificates" have just been swindled!  

Comments?


Tammy Green Carter
[e-mail] 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03320 for ietf-pkix-bks; Tue, 3 Nov 1998 16:16:44 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03316 for <[e-mail]>; Tue, 3 Nov 1998 16:16:42 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA335; Tue, 3 Nov 1998 19:19:23 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 19:18:10 -0500
To: "Simonetti David" <[e-mail]>, Kevin Kingdon <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 06:21 PM 11/3/98 -0500, Simonetti David wrote:
>
>I believe the key identifier is intended to be universally unique.  The
>profile does not state this.  However, I recall a presentation where
>someone was proving mathematically that taking 60 bits out of a SHA-1
>hash of the public key would provide sufficient uniqueness.  What is
>sufficient?  It was a very, very, very small fraction for a very, very
>large number of certificates.  Sorry for the generalities, but I'm not a
>mathematician.
>
Dave,

I heard that was for a smaller, Elliptic Curve, key pair.  Not an RSA 1024
(let alone an RSA 2048) key pair.  In fact Tim mentioned the development of
SHA2 for a larger hash...

So the choice of hashing scheme, by the CA, is related to the key
algorithm, selected for global uniqueness.  Full 160 bits for RSA 1024 and
60 bits for little EC.

I guess.

Therefor I am, I guess.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03283 for ietf-pkix-bks; Tue, 3 Nov 1998 16:14:14 -0800 (PST)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA03279 for <[e-mail]>; Tue, 3 Nov 1998 16:14:12 -0800 (PST)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 4 Nov 1998 00:30:52 UT
Received: by lobester.rsa.com with Internet Mail Service (5.5.2232.9) id <VQHAWM6L>; Tue, 3 Nov 1998 16:20:00 -0800
Message-ID: <[e-mail]>
From: Kevin Kingdon <[e-mail]>
To: "'Simonetti David'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers
Date: Tue, 3 Nov 1998 16:19: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

In a population of 2^30 certificates, there is a probability of ~50% that
some two of them will have the same 60-bit identifier. This works out to ~1
billion on my slide rule -- a large, but not unimaginable, population of
"Internet" certificates.

-----Original Message-----
From: Simonetti David [mailto:[e-mail]]
Sent: Tuesday, November 03, 1998 3:21 PM
To: Kevin Kingdon
Cc: '[e-mail]'
Subject: Re: keyIdentifiers


Kevin,

I believe the key identifier is intended to be universally unique.  The
profile does not state this.  However, I recall a presentation where
someone was proving mathematically that taking 60 bits out of a SHA-1
hash of the public key would provide sufficient uniqueness.  What is
sufficient?  It was a very, very, very small fraction for a very, very
large number of certificates.  Sorry for the generalities, but I'm not a
mathematician.

Dave S.

[Snip]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03198 for ietf-pkix-bks; Tue, 3 Nov 1998 16:01:03 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03191 for <[e-mail]>; Tue, 3 Nov 1998 16:01:02 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-113-61.s61.tnt5.ann.erols.com [207.172.113.61]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id TAA22102; Tue, 3 Nov 1998 19:03:28 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "Kevin Kingdon" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Robert Moskowitz" <[e-mail]>
Subject: Re: keyIdentifiers 
Date: Tue, 3 Nov 1998 19:01:17 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

If you're referring to ANSI X9.45, it relies on uniqueness
of (issuer + serial #), rather than key identifier.

Regards,
Rich

----------
> From: Robert Moskowitz <[e-mail]>
> To: Kevin Kingdon <[e-mail]>; '[e-mail]'
> Subject: RE: keyIdentifiers 
> Date: Tuesday, November 03, 1998 4:29 PM
> 
> At 12:45 PM 11/3/98 -0800, Kevin Kingdon wrote:
> >One issue that does affect applications is the scope of a key
identifier. Is
> >it unique for a given subject, a given CA, or globally unique? In other
> >words, can I build a certificate chain using just key identifiers, or do
I
> >have to use some combination of subject + identifier or issuer +
(subject)
> >identifier to build the chain? X.509 says the first case (unique only
with
> >respect to a given subject). Does PKIX expand the scope of the
identifier to
> >one of the other two levels I mentioned?
> >
> I have been in discussions where there is an ASSUMPTION that the scope is
> fairly broad, provided that the users use a different key pair for all of
> their certs.  In fact, if I remember right about one aspect of the X.9
> attribute cert doc, it puts a lot of reliance on uniqueness of
> keyIdentifer.  Now I could be remembering wrong; I can't pull the doc
right
> now, and it was not necessarily the final markup version.
> 
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03199 for ietf-pkix-bks; Tue, 3 Nov 1998 16:01:03 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03189 for <[e-mail]>; Tue, 3 Nov 1998 16:01:02 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-113-61.s61.tnt5.ann.erols.com [207.172.113.61]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id TAA22143; Tue, 3 Nov 1998 19:03:35 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: keyIdentifiers
Date: Tue, 3 Nov 1998 19:04:34 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

I'm concerned that this is changing what's in X.509; people (not
CertCo:-) may have implemented to that.  It would be better to
define a separate extension for a unique key ID...

Regards,
Rich

----------
> From: Simonetti David <[e-mail]>
> To: Kevin Kingdon <[e-mail]>
> Cc: '[e-mail]'
> Subject: Re: keyIdentifiers
> Date: Tuesday, November 03, 1998 6:21 PM
> 
> Kevin,
> 
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.
> 
> Dave S.
> 
> Kevin Kingdon wrote:
> > 
> > One issue that does affect applications is the scope of a key
identifier. Is
> > it unique for a given subject, a given CA, or globally unique? In other
> > words, can I build a certificate chain using just key identifiers, or
do I
> > have to use some combination of subject + identifier or issuer +
(subject)
> > identifier to build the chain? X.509 says the first case (unique only
with
> > respect to a given subject). Does PKIX expand the scope of the
identifier to
> > one of the other two levels I mentioned?
> > 
> > -----Original Message-----
> > From: Marc Branchaud [mailto:[e-mail]]
> > Sent: Tuesday, November 03, 1998 11:59 AM
> > To: [e-mail]
> > Subject: Re: keyIdentifiers
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 
> > Content-Type: text/plain; charset=us-ascii
> > 
> > Robert Moskowitz <[e-mail]> scrawled:
> > >
> > > Not according to a presentation Chicani gave to the federal PKI TWG
back
> > in
> > > the spring.  He was quite clear that it was an APP issue to use
> > > keyIdentifiers to build a cert chain.
> > >
> > 
> > Sure, but the app doesn't have to construct any key identifiers, just
use
> > the ones that are already in the certs.
> > 
> > > Then last week Mike Myers was pointing out how an app can use
keyIdentifer
> > > for simpler processing for renewals.  Mike could better discuss this
then
> > > me remember it.
> > >
> > 
> > That's a different, and new, usage for key identifiers which I haven't
> > heard of before.
> > 
> > My point is that s'far as chain construction goes, apps don't need to
know
> > how to create key identifiers.  If key IDs are to be used for other
> > purposes, then some standard method of construction is probably a good
> > idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> > identifiers, not apps.
> > 
> >                 Marc
> > 
> >
+------------------------------------------------------------------------+
> >  Marc Branchaud                                  \/
> >  Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
> >  [e-mail]        PKI References page:             
www.xcert.com
> >  604-640-6227          www.xcert.com/~marcnarc/PKI/
> >
+------------------------------------------------------------------------+
> >   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A
E1
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> > 
> > iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> > YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> > F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> > =Itvv
> > -----END PGP SIGNATURE-----
> 
> -- 
> David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02927 for ietf-pkix-bks; Tue, 3 Nov 1998 15:18:41 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02923 for <[e-mail]>; Tue, 3 Nov 1998 15:18:40 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA66BA; Tue, 3 Nov 1998 18:21:13 -0500
Message-ID: <[e-mail]>
Date: Tue, 03 Nov 1998 18:21:27 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Kevin Kingdon <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: keyIdentifiers
References: <[e-mail]>
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 PAA02924
Sender: [e-mail]
Precedence: bulk

Kevin,

I believe the key identifier is intended to be universally unique.  The
profile does not state this.  However, I recall a presentation where
someone was proving mathematically that taking 60 bits out of a SHA-1
hash of the public key would provide sufficient uniqueness.  What is
sufficient?  It was a very, very, very small fraction for a very, very
large number of certificates.  Sorry for the generalities, but I'm not a
mathematician.

Dave S.

Kevin Kingdon wrote:
> 
> One issue that does affect applications is the scope of a key identifier. Is
> it unique for a given subject, a given CA, or globally unique? In other
> words, can I build a certificate chain using just key identifiers, or do I
> have to use some combination of subject + identifier or issuer + (subject)
> identifier to build the chain? X.509 says the first case (unique only with
> respect to a given subject). Does PKIX expand the scope of the identifier to
> one of the other two levels I mentioned?
> 
> -----Original Message-----
> From: Marc Branchaud [mailto:[e-mail]]
> Sent: Tuesday, November 03, 1998 11:59 AM
> To: [e-mail]
> Subject: Re: keyIdentifiers
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Robert Moskowitz <[e-mail]> scrawled:
> >
> > Not according to a presentation Chicani gave to the federal PKI TWG back
> in
> > the spring.  He was quite clear that it was an APP issue to use
> > keyIdentifiers to build a cert chain.
> >
> 
> Sure, but the app doesn't have to construct any key identifiers, just use
> the ones that are already in the certs.
> 
> > Then last week Mike Myers was pointing out how an app can use keyIdentifer
> > for simpler processing for renewals.  Mike could better discuss this then
> > me remember it.
> >
> 
> That's a different, and new, usage for key identifiers which I haven't
> heard of before.
> 
> My point is that s'far as chain construction goes, apps don't need to know
> how to create key identifiers.  If key IDs are to be used for other
> purposes, then some standard method of construction is probably a good
> idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> identifiers, not apps.
> 
>                 Marc
> 
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>  [e-mail]        PKI References page:              www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
> 
> iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> =Itvv
> -----END PGP SIGNATURE-----

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02762 for ietf-pkix-bks; Tue, 3 Nov 1998 15:00:58 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA02758 for <[e-mail]>; Tue, 3 Nov 1998 15:00:56 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Nov 1998 16:02:53 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 03 Nov 1998 16:02:36 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: A different architecture
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 PAA02759
Sender: [e-mail]
Precedence: bulk

Bill,

Just a clarifying note:  Novell's directory (called NDS) __is__ 
an X.500 directory.

Tammy Green Carter
[e-mail] 


>>> Bill Burr <[e-mail]> 11-2-98 8:30:55 AM >>>
Elliot,

But DNS is a rather specialized sort of directory.  I don't know that it
follows that, because we can build a very specialized global DNS service,
that proves it is practical to build a very general global X.500 directory
service.  Nor does the success of DNS establish that the specific X.500
standard itself is workable on a global scale, or even a local scale.  It
doesn't make a business case for creating a global X.500 PKI directory,even
if we have X.500 directory products that could do the job. It may be that
we should take the contrary lesson: that to be successful, a global service
must be lean and mean and focused, rather than grand and all encompassing.

I don't have any certain answers here.  What bothers me as much as anything
is that PKI seems now to bear the main burden of the X.500 directory.  An
X.509 PKI would be relatively straightforward if there were an in-being
pervasive X.500 directory service, but is PKI a sufficient application to
drive the creation of a global X.500 directory service?  If the main reason
we are building a global X.500 directory service is PKI, maybe there are
simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
be one.

Another somewhat distressing thing is that, while directories seem to be
becoming central to distributed applications, and network operating
systems, they don't seem to be X.500 directories.  Netscape, Microsoft
(with NT 5.0) and Novell all seem to be relying on directories to glue
things together effectively, and hold configuration information.  But I
don't believe that any of them are X.500 directories.  So, in the real
world, most of us are going to have a directory of some sort, but it isn't
necessarily going to be an X.500 directory.  And it isn't obvious how we're
going to chain them all together, or even that we want to.

What does seem to be constant I think, even for "proper X.500" directories,
is some flavor (but which flavor?) of LDAP access.  

It isn't obvious that you want to let outsiders into the Active X
directory, or NDS directory that is near the core of your own system.
Maybe we need separate "border directories" and maybe those could be X.500
directories, all chained together.  But do we then have to maintain two
kinds of directory products, one internal and one external?  And how do we
manage the shadowing of the internal directory by the external directory?
Maybe we can manage this for DoD, or most of the Federal government, but
will the rest of the world go this way?

Another point: the apparatus for X.500 distinguished name assignment and
management, does apparently exist, but it seems to be expensive and few
folks actually seem to know how to get a DN, or to have done it.  Managing
a consistent global DIT for the Federal Gov. seems possible if not trivial,
but can we expand that to the country or the world?  It may be primitive,
in some ways, but the DNS management does exist (although I guess it's
changing a bit), it's cheap to get a domain name, practically any ISP will
do it for you, and even I know how to get one this afternoon, if I want to.

Perhaps the best thing about Phill's proposal, as I understand it, is that
it doesn't really seem to demand or ask anything of the DNS that it isn't
already doing, and it seems like that extra load on the DNS would be very
small.

Maybe the worst thing is accepting Internet domain names as the foundation
of PKI naming.  But perhaps that's also a good thing, in that it is bowing
to reality: on the Internet it is domain names that matter.

Regards,

Bill Burr




At 08:00 AM 11/3/98 -0500, you wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01887 for ietf-pkix-bks; Tue, 3 Nov 1998 13:27:01 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01883 for <[e-mail]>; Tue, 3 Nov 1998 13:27:00 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA312; Tue, 3 Nov 1998 16:29:39 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 16:29:42 -0500
To: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers 
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 12:45 PM 11/3/98 -0800, Kevin Kingdon wrote:
>One issue that does affect applications is the scope of a key identifier. Is
>it unique for a given subject, a given CA, or globally unique? In other
>words, can I build a certificate chain using just key identifiers, or do I
>have to use some combination of subject + identifier or issuer + (subject)
>identifier to build the chain? X.509 says the first case (unique only with
>respect to a given subject). Does PKIX expand the scope of the identifier to
>one of the other two levels I mentioned?
>
I have been in discussions where there is an ASSUMPTION that the scope is
fairly broad, provided that the users use a different key pair for all of
their certs.  In fact, if I remember right about one aspect of the X.9
attribute cert doc, it puts a lot of reliance on uniqueness of
keyIdentifer.  Now I could be remembering wrong; I can't pull the doc right
now, and it was not necessarily the final markup version.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01577 for ietf-pkix-bks; Tue, 3 Nov 1998 12:46:04 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01573 for <[e-mail]>; Tue, 3 Nov 1998 12:46:03 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA334; Tue, 3 Nov 1998 15:48:42 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 15:48:47 -0500
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers 
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Nov 1998 14:34:25 EST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 07:58 PM 11/3/98 +0000, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Robert Moskowitz <[e-mail]> scrawled:
>> 
>> Not according to a presentation Chicani gave to the federal PKI TWG back in
>> the spring.  He was quite clear that it was an APP issue to use
>> keyIdentifiers to build a cert chain.
>> 
>
>Sure, but the app doesn't have to construct any key identifiers, just use 
>the ones that are already in the certs.

My understanding also.  Your earlier message came through poorly formatted
and I did not read it carefully.  the CA creates the hash, and the app just
uses it.

I think another usage of the hash (if I remember right) is the index for
attribute certs.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01508 for ietf-pkix-bks; Tue, 3 Nov 1998 12:39:52 -0800 (PST)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01503 for <[e-mail]>; Tue, 3 Nov 1998 12:39:51 -0800 (PST)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 3 Nov 1998 20:56:30 UT
Received: by lobester.rsa.com with Internet Mail Service (5.5.2232.9) id <VQHAWMK4>; Tue, 3 Nov 1998 12:45:38 -0800
Message-ID: <[e-mail]>
From: Kevin Kingdon <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers 
Date: Tue, 3 Nov 1998 12:45:27 -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

One issue that does affect applications is the scope of a key identifier. Is
it unique for a given subject, a given CA, or globally unique? In other
words, can I build a certificate chain using just key identifiers, or do I
have to use some combination of subject + identifier or issuer + (subject)
identifier to build the chain? X.509 says the first case (unique only with
respect to a given subject). Does PKIX expand the scope of the identifier to
one of the other two levels I mentioned?

-----Original Message-----
From: Marc Branchaud [mailto:[e-mail]]
Sent: Tuesday, November 03, 1998 11:59 AM
To: [e-mail]
Subject: Re: keyIdentifiers 


-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Robert Moskowitz <[e-mail]> scrawled:
> 
> Not according to a presentation Chicani gave to the federal PKI TWG back
in
> the spring.  He was quite clear that it was an APP issue to use
> keyIdentifiers to build a cert chain.
> 

Sure, but the app doesn't have to construct any key identifiers, just use 
the ones that are already in the certs.

> Then last week Mike Myers was pointing out how an app can use keyIdentifer
> for simpler processing for renewals.  Mike could better discuss this then
> me remember it.
> 

That's a different, and new, usage for key identifiers which I haven't 
heard of before.

My point is that s'far as chain construction goes, apps don't need to know
how to create key identifiers.  If key IDs are to be used for other
purposes, then some standard method of construction is probably a good
idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
identifiers, not apps.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
=Itvv
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01201 for ietf-pkix-bks; Tue, 3 Nov 1998 11:56:51 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01197 for <[e-mail]>; Tue, 3 Nov 1998 11:56:50 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id TAA10074 for <[e-mail]>; Tue, 3 Nov 1998 19:58:39 GMT
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: [e-mail]
Subject: Re: keyIdentifiers 
In-Reply-To: Your message of "Tue, 03 Nov 1998 14:34:25 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 19:58:39 +0000
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Robert Moskowitz <[e-mail]> scrawled:
> 
> Not according to a presentation Chicani gave to the federal PKI TWG back in
> the spring.  He was quite clear that it was an APP issue to use
> keyIdentifiers to build a cert chain.
> 

Sure, but the app doesn't have to construct any key identifiers, just use 
the ones that are already in the certs.

> Then last week Mike Myers was pointing out how an app can use keyIdentifer
> for simpler processing for renewals.  Mike could better discuss this then
> me remember it.
> 

That's a different, and new, usage for key identifiers which I haven't 
heard of before.

My point is that s'far as chain construction goes, apps don't need to know
how to create key identifiers.  If key IDs are to be used for other
purposes, then some standard method of construction is probably a good
idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
identifiers, not apps.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
=Itvv
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01077 for ietf-pkix-bks; Tue, 3 Nov 1998 11:31:31 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01073 for <[e-mail]>; Tue, 3 Nov 1998 11:31:30 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA329; Tue, 3 Nov 1998 14:34:06 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 14:34:25 -0500
To: Marc Branchaud <[e-mail]>, "Simonetti David" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers 
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Nov 1998 09:39:25 EST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 05:29 PM 11/3/98 +0000, Marc Branchaud wrote:

Not according to a presentation Chicani gave to the federal PKI TWG back in
the spring.  He was quite clear that it was an APP issue to use
keyIdentifiers to build a cert chain.

Then last week Mike Myers was pointing out how an app can use keyIdentifer
for simpler processing for renewals.  Mike could better discuss this then
me remember it.

>
>Further to this, doesn't end-entity software treat a key identifier as a =
>
>black blob?  In other words, it's up to the CA to include these things in=
> =
>
>its certs, and if they're there then the end-entity app just grabs the =
>
>value and looks for a match in other certs.  That app has no business =
>
>conjuring up a key ID from the public key in a cert and trying to match i=
>t =
>
>to other conjured-up key IDs -- it would be better off just matching up =
>
>the keys directly anyway.
>
>If the CA wants its PKI to use key IDs, it'll put them in its certs and
>that'll be that.  The PKIX recommendations for key ID derivation are for =
>
>CAs to follow, as in they choose one method and stick to it.  End-entity =
>
>apps need not concern themselves with such arcane matters.
>
>		Marc
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNj89flrdFXNdDxPlAQGbhAL9Gk0lN063hZodHTvdGi3A8l1ijyANrJp/
>POHaCLC8qfB41awFY4lPx8bwlSecnMbgu6HRc3RLIRlkNQ2sjPsNLL39x8kE2+lz
>oQ+60LGoKxuBjyeCHxi1SSB7tbNXot6K
>=yK7A
>-----END PGP SIGNATURE-----

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29888 for ietf-pkix-bks; Tue, 3 Nov 1998 09:29:03 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29884 for <[e-mail]>; Tue, 3 Nov 1998 09:29:02 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id RAA03060; Tue, 3 Nov 1998 17:29:34 GMT
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "Simonetti David" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: keyIdentifiers 
In-Reply-To: Your message of "Tue, 03 Nov 1998 09:39:25 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 17:29:34 +0000
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


"Simonetti David" <[e-mail]> scrawled:
> =

> Peter,
> =

> The text you pasted from the profile is one of two recommended methods
> for generating a key identifier.  However, neither is required.  I thin=
k
> the current text mostly accomodates your suggestions.
> =


Further to this, doesn't end-entity software treat a key identifier as a =

black blob?  In other words, it's up to the CA to include these things in=
 =

its certs, and if they're there then the end-entity app just grabs the =

value and looks for a match in other certs.  That app has no business =

conjuring up a key ID from the public key in a cert and trying to match i=
t =

to other conjured-up key IDs -- it would be better off just matching up =

the keys directly anyway.

If the CA wants its PKI to use key IDs, it'll put them in its certs and
that'll be that.  The PKIX recommendations for key ID derivation are for =

CAs to follow, as in they choose one method and stick to it.  End-entity =

apps need not concern themselves with such arcane matters.

		Marc



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj89flrdFXNdDxPlAQGbhAL9Gk0lN063hZodHTvdGi3A8l1ijyANrJp/
POHaCLC8qfB41awFY4lPx8bwlSecnMbgu6HRc3RLIRlkNQ2sjPsNLL39x8kE2+lz
oQ+60LGoKxuBjyeCHxi1SSB7tbNXot6K
=yK7A
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29763 for ietf-pkix-bks; Tue, 3 Nov 1998 09:14:11 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29759 for <[e-mail]>; Tue, 3 Nov 1998 09:14:09 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id MAA03718; Tue, 3 Nov 1998 12:16:49 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA11845; Tue, 3 Nov 1998 12:16:48 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 12:19:04 -0500
To: Bill Burr <[e-mail]>
From: Elliott Ginsburg <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I did not advocate an X.500 directory, only that we are capable of creating
and administering a global directory space. I myself am looking at various
technologies. DNS is a great model for what can be done and for the value
of a global directory, but it may or not be overloading DNS to expect it to
take on another directory task. 

As far as DNs for naming, its too big a subject for me to tackle at this
time. Suffice it to say that I personally want my personal identity, based
upon which all kinds of conclusions will be drawn, to be as meaningful a
representation as possible, and not bound to domain naming constraints and
mnemonic email addresses.

Elliott

At 10:30 AM 11/2/98 , Bill Burr wrote:
>Elliot,
>
>But DNS is a rather specialized sort of directory.  I don't know that it
>follows that, because we can build a very specialized global DNS service,
>that proves it is practical to build a very general global X.500 directory
>service.  Nor does the success of DNS establish that the specific X.500
>standard itself is workable on a global scale, or even a local scale.  It
>doesn't make a business case for creating a global X.500 PKI directory,even
>if we have X.500 directory products that could do the job. It may be that
>we should take the contrary lesson: that to be successful, a global service
>must be lean and mean and focused, rather than grand and all encompassing.
>
>I don't have any certain answers here.  What bothers me as much as anything
>is that PKI seems now to bear the main burden of the X.500 directory.  An
>X.509 PKI would be relatively straightforward if there were an in-being
>pervasive X.500 directory service, but is PKI a sufficient application to
>drive the creation of a global X.500 directory service?  If the main reason
>we are building a global X.500 directory service is PKI, maybe there are
>simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
>be one.
>
>Another somewhat distressing thing is that, while directories seem to be
>becoming central to distributed applications, and network operating
>systems, they don't seem to be X.500 directories.  Netscape, Microsoft
>(with NT 5.0) and Novell all seem to be relying on directories to glue
>things together effectively, and hold configuration information.  But I
>don't believe that any of them are X.500 directories.  So, in the real
>world, most of us are going to have a directory of some sort, but it isn't
>necessarily going to be an X.500 directory.  And it isn't obvious how we're
>going to chain them all together, or even that we want to.
>
>What does seem to be constant I think, even for "proper X.500" directories,
>is some flavor (but which flavor?) of LDAP access.  
>
>It isn't obvious that you want to let outsiders into the Active X
>directory, or NDS directory that is near the core of your own system.
>Maybe we need separate "border directories" and maybe those could be X.500
>directories, all chained together.  But do we then have to maintain two
>kinds of directory products, one internal and one external?  And how do we
>manage the shadowing of the internal directory by the external directory?
>Maybe we can manage this for DoD, or most of the Federal government, but
>will the rest of the world go this way?
>
>Another point: the apparatus for X.500 distinguished name assignment and
>management, does apparently exist, but it seems to be expensive and few
>folks actually seem to know how to get a DN, or to have done it.  Managing
>a consistent global DIT for the Federal Gov. seems possible if not trivial,
>but can we expand that to the country or the world?  It may be primitive,
>in some ways, but the DNS management does exist (although I guess it's
>changing a bit), it's cheap to get a domain name, practically any ISP will
>do it for you, and even I know how to get one this afternoon, if I want to.
>
>Perhaps the best thing about Phill's proposal, as I understand it, is that
>it doesn't really seem to demand or ask anything of the DNS that it isn't
>already doing, and it seems like that extra load on the DNS would be very
>small.
>
>Maybe the worst thing is accepting Internet domain names as the foundation
>of PKI naming.  But perhaps that's also a good thing, in that it is bowing
>to reality: on the Internet it is domain names that matter.
>
>Regards,
>
>Bill Burr
>
>
>
>
>At 08:00 AM 11/3/98 -0500, you wrote:
>>I think it was on this thread that someone stated that 'we would never have
>>a global distributed directory'. But we already have one (DNS), so why is
>>it inconceivable that we would have another? I don't advocate stretching
>>DNS for this prupose, but it does suggest that we can create global
>>directories. Am I missing something here?
>>
>>Elliott Ginsburg
>>
>>
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29579 for ietf-pkix-bks; Tue, 3 Nov 1998 08:56:02 -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 IAA29575 for <[e-mail]>; Tue, 3 Nov 1998 08:56:00 -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 FAA32715; Wed, 4 Nov 1998 05:58:26 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91011230600046>; Wed, 4 Nov 1998 05:58:26 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: email oid
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 4 Nov 1998 05:58:26 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

David Wilson <[e-mail]> writes:
 
>>There are currently at least three different locations for specifying the
>>email address:
>>
>>  altName.rfc822Name (the correct one which noone actually uses)
>>  emailAddress (officially deprecated, but everyone uses it anyway)
>>  rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial
>>        fricative to anyone who can explain the origin of the rfc822Mailbox
>>        OID without referring the question to one of the RFC's authors.
>>        Answers on the back of a postcard to ...  I'll post the explanation in
>>        a week or so if anyone cares)
 
>I do not know of any standard X.500 schema that defines an attribute called
>altName.rfc822Name. Is there a schema which defines an X.500 attribute which
>uses the GeneralName ASN.1 syntax?
 
I meant the rfc822Name component of the subject/issuerAltName GeneralName.
PKIX requires that the email address be stored there instead of the various
places in which legacy implementations put it (that's PKIX part 1's words, not
mine :-).
 
>Since the much of the early work of this was done University College, London,
>the OIDs allocated to this were under the UCL arc. This is allocated according
>to a scheme based on IPSS X.25 addresses. The 2342 is the DNIC for the U.K.,
>and 234219200300 is the IPSS address for UCL.
 
Congratulations, you win the PKIX trivia quiz.  Would you like your fricative
emailed or via FTP?
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28299 for ietf-pkix-bks; Tue, 3 Nov 1998 07:29:13 -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 HAA28295 for <[e-mail]>; Tue, 3 Nov 1998 07:29:03 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA08852; Tue, 3 Nov 1998 10:29:47 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 02 Nov 1998 10:30:55 -0500
To: Elliott Ginsburg <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Elliot,

But DNS is a rather specialized sort of directory.  I don't know that it
follows that, because we can build a very specialized global DNS service,
that proves it is practical to build a very general global X.500 directory
service.  Nor does the success of DNS establish that the specific X.500
standard itself is workable on a global scale, or even a local scale.  It
doesn't make a business case for creating a global X.500 PKI directory,even
if we have X.500 directory products that could do the job. It may be that
we should take the contrary lesson: that to be successful, a global service
must be lean and mean and focused, rather than grand and all encompassing.

I don't have any certain answers here.  What bothers me as much as anything
is that PKI seems now to bear the main burden of the X.500 directory.  An
X.509 PKI would be relatively straightforward if there were an in-being
pervasive X.500 directory service, but is PKI a sufficient application to
drive the creation of a global X.500 directory service?  If the main reason
we are building a global X.500 directory service is PKI, maybe there are
simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
be one.

Another somewhat distressing thing is that, while directories seem to be
becoming central to distributed applications, and network operating
systems, they don't seem to be X.500 directories.  Netscape, Microsoft
(with NT 5.0) and Novell all seem to be relying on directories to glue
things together effectively, and hold configuration information.  But I
don't believe that any of them are X.500 directories.  So, in the real
world, most of us are going to have a directory of some sort, but it isn't
necessarily going to be an X.500 directory.  And it isn't obvious how we're
going to chain them all together, or even that we want to.

What does seem to be constant I think, even for "proper X.500" directories,
is some flavor (but which flavor?) of LDAP access.  

It isn't obvious that you want to let outsiders into the Active X
directory, or NDS directory that is near the core of your own system.
Maybe we need separate "border directories" and maybe those could be X.500
directories, all chained together.  But do we then have to maintain two
kinds of directory products, one internal and one external?  And how do we
manage the shadowing of the internal directory by the external directory?
Maybe we can manage this for DoD, or most of the Federal government, but
will the rest of the world go this way?

Another point: the apparatus for X.500 distinguished name assignment and
management, does apparently exist, but it seems to be expensive and few
folks actually seem to know how to get a DN, or to have done it.  Managing
a consistent global DIT for the Federal Gov. seems possible if not trivial,
but can we expand that to the country or the world?  It may be primitive,
in some ways, but the DNS management does exist (although I guess it's
changing a bit), it's cheap to get a domain name, practically any ISP will
do it for you, and even I know how to get one this afternoon, if I want to.

Perhaps the best thing about Phill's proposal, as I understand it, is that
it doesn't really seem to demand or ask anything of the DNS that it isn't
already doing, and it seems like that extra load on the DNS would be very
small.

Maybe the worst thing is accepting Internet domain names as the foundation
of PKI naming.  But perhaps that's also a good thing, in that it is bowing
to reality: on the Internet it is domain names that matter.

Regards,

Bill Burr




At 08:00 AM 11/3/98 -0500, you wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27641 for ietf-pkix-bks; Tue, 3 Nov 1998 06:36:48 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27637 for <[e-mail]>; Tue, 3 Nov 1998 06:36:47 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA2FD; Tue, 3 Nov 1998 09:39:11 -0500
Message-ID: <[e-mail]>
Date: Tue, 03 Nov 1998 09:39:25 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]>
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 GAA27638
Sender: [e-mail]
Precedence: bulk

Peter,

The text you pasted from the profile is one of two recommended methods
for generating a key identifier.  However, neither is required.  I think
the current text mostly accomodates your suggestions.

Dave S.

Peter Gutmann wrote:
> 
> Someone has just pointed out to me that the newer PKIX drafts have changed the
> keyIdentifier derivation to:
> 
> >      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
> >      value of the BIT STRING subjectPublicKey (excluding the tag,
> >      length, and number of unused bits).
> 
> Since this excludes the algorithm type and parameters, it can lead to
> identifier clashes in cases where the subjectPublicKey consists of just a
> single integer (which is the case for a number of algorithm types).  This
> means that someone could construct a key for a different algorithm which would
> appear identical using the current PKIX interpretation of the keyIdentifier,
> but distinct with other interpretations.  There are various denial-of-service
> attacks possible with this (chaining works with a non-PKIX implementation but
> not a PKIX-compliant one, assuming you're chaining off the keyIdentifier which
> noone actually seems to do at the moment).
> 
> Trawling through my collection of profiles I've found that:
> 
>   X.509v3 allows you to use both types of identifier, but other standards and
>   profiles recommend against this.  Various profiles have at various times
>   required the use of the SHA-1 hash of the public key (whatever that
>   constitutes), the SHA-1 hash of the subjectPublicKeyInfo data (for some
>   reason this has to be done *without* the tag and length at the start), the
>   SHA-1 hash of the subjectPublicKey (again without the tag, length, and
>   unused bits portion of the BIT STRING, which leaves just the raw public key
>   data but omits the algorithm identifier and parameters so that two keys for
>   different algorithms with different parameters which happen to share the
>   same public key field end up with the same hash), a 60-bit hash of the
>   subjectPublicKeyInfo (presumably with the tag and length), a 64-bit hash of
>   the subjectPublicKey (again with tag and length) with the first four bits
>   set to 0100 to indicate the use of SHA-1, and some sort of unique value such
>   as a monotonically increasing sequence.  Several newer profiles have pretty
>   much given up on this and simply specify "a unique value".
> 
> Given the wide selection of choices, it might be better to just include some
> general guidelines on how to generate the keyIdentifier, including a note that
> the input to the hash should include all the parameters for the key (including
> algorithm type and whatnot), and to warn implementors not to expect any
> particular format for the keyIdentifier.
> 
> In addition, moving from a MUST to a MAY also seems to be a good idea, since
> (a) there's no consensus on what to put in there so you'll see all sorts of
> odd stuff, and (b) most implementations either ignore this value entirely or
> function just as well without it.  I don't really see why this has to be a
> MUST anyway, a MAY makes much more sense since it may be required for
> disambiguation in some cases but certainly isn't needed (or used) by virtually
> everything which is currently out there - it's just more useless baggage to
> cart around in a cert.
> 
> Peter.
> 

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27123 for ietf-pkix-bks; Tue, 3 Nov 1998 05:13:57 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27118 for <[e-mail]>; Tue, 3 Nov 1998 05:13:56 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id IAA03808 for <[e-mail]>; Tue, 3 Nov 1998 08:16:35 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA20537; Tue, 3 Nov 1998 08:16:32 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 08:18:48 -0500
To: [e-mail]
From: Elliott Ginsburg <[e-mail]>
Subject: Fwd: Re: A different architecture
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I'm adding to my own message. Someone also stated on the list that we do
not want to have a directory between our apps and our PKI services. But,
again, how often today do we have DNS between our apps and our network
communication services?

Elliott Ginsburg


>X-Sender: [e-mail]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Tue, 03 Nov 1998 08:00:45 -0500
>To: [e-mail]
>From: Elliott Ginsburg <[e-mail]>
>Subject: Re: A different architecture
>Sender: [e-mail]
>
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27098 for ietf-pkix-bks; Tue, 3 Nov 1998 05:08:18 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27094 for <[e-mail]>; Tue, 3 Nov 1998 05:08:16 -0800 (PST)
Received: from isode.com (actually sirius.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 3 Nov 1998 13:10:16 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: email oid 
In-reply-to: Your message of "Tue, 03 Nov 1998 16:20:52." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 13:10:10 +0000
Message-ID: <[e-mail]>
From: David Wilson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I have been forward this by a colleague, so I'm not exactly sure of the 
context...

> >The other day in trying to accommodate a legacy pki, I ran into a problem 
> >with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1 specifies 
> >that the oid used for an email address in the distinguished name is 
> >1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and 
> >others have been using 0.9.2342.19200300.100.1.3 which is for internet mail 
> >as specified in RFC1274.
>  
> There are currently at least three different locations for specifying the 
> email address:
>  
>   altName.rfc822Name (the correct one which noone actually uses)
>   emailAddress (officially deprecated, but everyone uses it anyway)
>   rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial 
>         fricative to anyone who can explain the origin of the rfc822Mailbox 
>         OID without referring the question to one of the RFC's authors.  
>         Answers on the back of a postcard to ...  I'll post the explanation in 
>         a week or so if anyone cares)
>  
> Peter.
>  
> 

I do not know of any standard X.500 schema that defines an attribute called 
altName.rfc822Name. Is there a schema which defines an X.500 attribute which 
uses the GeneralName ASN.1 syntax?

emailAddress and rfc822Mailbox are X.500 (and therefore LDAP) attributes. 

rfc822Mailbox is the common attribute type used for Internet email addresses 
in X.500/LDAP entries (going under a variety of names for LDAP). It is not 
normally used for naming, so the value is not normally in an RDN. The 
intention of the attribute is that its use is within a 'white pages' entry 
for an individual. It would be used by an Email client, for instance, when 
the client enables (L)DAP lookup, and gives the Email address to use.

It has been around for many years, certainly predating LDAP. It is an X.500 
Pilot attribute. Since the much of the early work of this was done University 
College, London, the OIDs allocated to this were under the UCL arc. This is 
allocated according to a scheme based on IPSS X.25 addresses. The 2342 is the 
DNIC for the U.K., and 234219200300 is the IPSS address for UCL.

(O.K. one of the authors is my boss, but I knew this anyway). 

David Wilson                                        [e-mail]
Isode Ltd.                                       Tel: [phone]
http://www.isode.com                             Fax: [phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27040 for ietf-pkix-bks; Tue, 3 Nov 1998 04:55:55 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27036 for <[e-mail]>; Tue, 3 Nov 1998 04:55:54 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA29071 for <[e-mail]>; Tue, 3 Nov 1998 07:58:33 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA18569; Tue, 3 Nov 1998 07:58:29 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 08:00:45 -0500
To: [e-mail]
From: Elliott Ginsburg <[e-mail]>
Subject: Re: A different architecture
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I think it was on this thread that someone stated that 'we would never have
a global distributed directory'. But we already have one (DNS), so why is
it inconceivable that we would have another? I don't advocate stretching
DNS for this prupose, but it does suggest that we can create global
directories. Am I missing something here?

Elliott Ginsburg



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA26928 for ietf-pkix-bks; Tue, 3 Nov 1998 04:29:13 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA26924 for <[e-mail]>; Tue, 3 Nov 1998 04:29:11 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA312; Tue, 3 Nov 1998 07:31:39 -0500
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 03 Nov 1998 07:31:41 -0500
To: [e-mail], [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <19981103123139725.AAA312@rgm>
Sender: [e-mail]
Precedence: bulk

At 09:27 PM 11/3/98 +0000, Peter Gutmann wrote:
> 
>Given the wide selection of choices, it might be better to just include some 
>general guidelines on how to generate the keyIdentifier, including a note
that 
>the input to the hash should include all the parameters for the key
(including 
>algorithm type and whatnot), and to warn implementors not to expect any 
>particular format for the keyIdentifier.  

I am not able to comment on this part of your observations, but...
 
>In addition, moving from a MUST to a MAY also seems to be a good idea, since 
>(a) there's no consensus on what to put in there so you'll see all sorts of 
>odd stuff, and (b) most implementations either ignore this value entirely or 
>function just as well without it.  I don't really see why this has to be a 
>MUST anyway, a MAY makes much more sense since it may be required for 
>disambiguation in some cases but certainly isn't needed (or used) by
virtually 
>everything which is currently out there - it's just more useless baggage to 
>cart around in a cert.
> 
I have seen two reasons for keyIdentifiers.

The first is by Chichani as a powerful way to build a cert chain.  Now this
is definitely a MAY and not a MUST, it would seem.

The second was brought to my attention by Myers as a clean way to handle
key renewal.  Since little of your field usage has dealt with renewals, we
have not seen this one yet.  But with the emergence of silicon based life
forms (eg IPsec devices), this will become more real in a year.

We need informational RFCs on the use of keyIdentifier for the PKIX
consuming market, ie S/MIME, TLS, and IPsec for starters.  This came out
load and clear last week at the IPsec workshop, where we were nailing down
which cert objects were important to implementors.

I fully intend to include keyIndentifiers (both subject and issuer) in the
ANX PKI and recommend other PKI builders to also push for clearification on
these objects.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20287 for ietf-pkix-bks; Tue, 3 Nov 1998 00:24:46 -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 AAA20280 for <[e-mail]>; Tue, 3 Nov 1998 00:24:44 -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 VAA27224 for <[e-mail]>; Tue, 3 Nov 1998 21:27:19 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91008163927679>; Tue, 3 Nov 1998 21:27:19 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: keyIdentifiers
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 3 Nov 1998 21:27:19 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Someone has just pointed out to me that the newer PKIX drafts have changed the 
keyIdentifier derivation to:
 
>      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
>      value of the BIT STRING subjectPublicKey (excluding the tag,
>      length, and number of unused bits).
 
Since this excludes the algorithm type and parameters, it can lead to 
identifier clashes in cases where the subjectPublicKey consists of just a 
single integer (which is the case for a number of algorithm types).  This 
means that someone could construct a key for a different algorithm which would 
appear identical using the current PKIX interpretation of the keyIdentifier, 
but distinct with other interpretations.  There are various denial-of-service 
attacks possible with this (chaining works with a non-PKIX implementation but 
not a PKIX-compliant one, assuming you're chaining off the keyIdentifier which 
noone actually seems to do at the moment).
 
Trawling through my collection of profiles I've found that:
 
  X.509v3 allows you to use both types of identifier, but other standards and 
  profiles recommend against this.  Various profiles have at various times 
  required the use of the SHA-1 hash of the public key (whatever that 
  constitutes), the SHA-1 hash of the subjectPublicKeyInfo data (for some 
  reason this has to be done *without* the tag and length at the start), the 
  SHA-1 hash of the subjectPublicKey (again without the tag, length, and 
  unused bits portion of the BIT STRING, which leaves just the raw public key 
  data but omits the algorithm identifier and parameters so that two keys for 
  different algorithms with different parameters which happen to share the 
  same public key field end up with the same hash), a 60-bit hash of the 
  subjectPublicKeyInfo (presumably with the tag and length), a 64-bit hash of 
  the subjectPublicKey (again with tag and length) with the first four bits 
  set to 0100 to indicate the use of SHA-1, and some sort of unique value such 
  as a monotonically increasing sequence.  Several newer profiles have pretty 
  much given up on this and simply specify "a unique value".
 
Given the wide selection of choices, it might be better to just include some 
general guidelines on how to generate the keyIdentifier, including a note that 
the input to the hash should include all the parameters for the key (including 
algorithm type and whatnot), and to warn implementors not to expect any 
particular format for the keyIdentifier.  
 
In addition, moving from a MUST to a MAY also seems to be a good idea, since 
(a) there's no consensus on what to put in there so you'll see all sorts of 
odd stuff, and (b) most implementations either ignore this value entirely or 
function just as well without it.  I don't really see why this has to be a 
MUST anyway, a MAY makes much more sense since it may be required for 
disambiguation in some cases but certainly isn't needed (or used) by virtually 
everything which is currently out there - it's just more useless baggage to 
cart around in a cert.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00243 for ietf-pkix-bks; Mon, 2 Nov 1998 19:20:46 -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 TAA00292 for <[e-mail]>; Mon, 2 Nov 1998 19:18:29 -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 QAA20102; Tue, 3 Nov 1998 16:20:52 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91006325228585>; Tue, 3 Nov 1998 16:20:52 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: email oid
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 3 Nov 1998 16:20:52 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>The other day in trying to accommodate a legacy pki, I ran into a problem 
>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1 specifies 
>that the oid used for an email address in the distinguished name is 
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and 
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail 
>as specified in RFC1274.
 
There are currently at least three different locations for specifying the 
email address:
 
  altName.rfc822Name (the correct one which noone actually uses)
  emailAddress (officially deprecated, but everyone uses it anyway)
  rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial 
        fricative to anyone who can explain the origin of the rfc822Mailbox 
        OID without referring the question to one of the RFC's authors.  
        Answers on the back of a postcard to ...  I'll post the explanation in 
        a week or so if anyone cares)
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05714 for ietf-pkix-bks; Mon, 2 Nov 1998 08:14:20 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05710 for <[e-mail]>; Mon, 2 Nov 1998 08:14:18 -0800 (PST)
Received: from klerer.basit.com (shiva119 [128.209.144.119]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id LAA22965; Mon, 2 Nov 1998 11:15:24 -0500 (EST)
Message-ID: <005001be067c$107b9b00$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: "Miklos, Sue A." <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>, <[e-mail]>
Subject: Re: email oid
Date: Mon, 2 Nov 1998 11:15:49 -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.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

Sandi,  If we want to do a complete job we need to widen the survey a
little.  We have three sets of names to deal with:  LDAP attribute name,
x.500 OID and RDN tag.  The places where an email address has been put (that
I have found in my wonderings around PKI) for secure email (which is
converging on SMIME) are as follows:

OID's:
1.2.840.113549.1.9.1
0.9.2342.19200300.100.1.3

LDAP attribute names:
mail
email
InternetAddress
RFC822mailbox
LabeledURI  (occasionally misspelled as LabelledURI)

RDN tags:
EA
EM

The syntax for LabeledURI is different than the others and may hold
information other than email address.  We can go through "who does what",
but I'm not sure that helpful since the mappings between the name sets are
all controllable.

Since I live in the x.500 world, I would prefer a single OID and can
tolerate as many LDAP (textual) synonyms as others require.  I would suspect
those running LDAP repositories may have a different opinion.  The variance
in RDN tag is a little disconcerting from a PKI point of view since the
x.500 name, to which a certificate binds a key, may change depending on how
the certificate viewer maps RDN OIDs to RDN tags.

Robert
-----Original Message-----
From: Miklos, Sue A. <[e-mail]>
To: 'Russ Housley' <[e-mail]>; 'Robert Klerer' <[e-mail]>
Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
<[e-mail]>
Date: Monday, November 02, 1998 10:31 AM
Subject: RE: email oid


>Robert, in a brief look at the Internet Person draft from netscape, it
>appears they are using the 'rfc822mailbox' oid ('mail' for short).  I
>was told that a quick search with netscape navigator and outlook express
>(LDAP interfaces) appear to search for the 'mail' attribute - mapped to
>rfc822mailbox?
>
>Could either the outlook or netscape folks tell us what they are
>searching on?  "mail" or "emailAddress"?  Is Entrust using the pkcs 9
>oid?
>
>I would like to ensure the specs we are generating capture the
>concensus.
>
>Thanks,
>Sandi
>
>>----------
>>From: Robert Klerer[SMTP:[e-mail]]
>>Sent: Friday, October 30, 1998 4:47 PM
>>To: Miklos, Sue A.; 'Russ Housley'
>>Cc: 'ietf-pkix'; [e-mail]
>>Subject: Re: email oid
>>
>>Sue,
>>
>>Adding the additional OID would not be the optimum solution.  Since if I
>>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>>problem.  pkix should NOT perpetuate the problem by again calling the same
>>thing two different names.
>>
>>Robert
>>
>>-----Original Message-----
>>From: Miklos, Sue A. <[e-mail]>
>>To: 'Russ Housley' <[e-mail]>
>>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
<[e-mail]>;
>>'[e-mail]' <[e-mail]>
>>Date: Friday, October 30, 1998 2:34 PM
>>Subject: RE: email oid
>>
>>
>>>Russ, and others, may I then request that it be included or is that not
>>>possible?
>>>
>>>Sandi
>>>
>>>>----------
>>>>From: Russ Housley[SMTP:[e-mail]]
>>>>Sent: Friday, October 30, 1998 1:35 PM
>>>>To: Miklos, Sue A.
>>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>>Subject: Re: email oid
>>>>
>>>>Sandi:
>>>>
>>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>>
>>>>Russ
>>>>
>>>>
>>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>>All,
>>>>>In the specifications for the schema for an international defense
>>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>>registered
>>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>>I would like to request that this remain in whatever documentation you
>>>>>develop.
>>>>>
>>>>>Thanks,
>>>>>Sandi Miklos
>>>>>>
>>>>>>
>>>>>>----------
>>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>>Subject: RE: email oid
>>>>>>
>>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>>if there is a demand for it.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>>To: [e-mail]
>>>>>>Subject: email oid
>>>>>>
>>>>>>
>>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>>problem
>>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>>specifies
>>>>>>that the oid used for an email address in the distinguished name is
>>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I
and
>>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>>mail
>>>>>>as specified in RFC1274.
>>>>>>
>>>>>>Since I believe that the intention is for both of these oids are meant
>>to
>>>>>>represent attributes that hold the same information, this discrepancy
>>may
>>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>>change part1 to refer to the more commonly used OID.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05599 for ietf-pkix-bks; Mon, 2 Nov 1998 07:57:03 -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 HAA05595 for <[e-mail]>; Mon, 2 Nov 1998 07:57:02 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA07408 for <[e-mail]>; Mon, 2 Nov 1998 10:59:24 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Mon, 02 Nov 1998 10:58:59 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Scale (and the SRV record)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>[e-mail] wrote:
>> 
>> >If someone spoofed DNS the worst that would happen is that I would
>> >recieve a certificate I didn't trust (and would ignore) or no >certificate
>> at all.
>> 
>> Well, if you're only fetching certificates, probably.
>> 
>> But if you're fetching CRL's, then no.  Suppose a cert is compromised,
>> and CRLn is issued before the "next update" time purely because of
>> that compromise.  The adversary could spoof DNS and just send out
>> the valid, but outdated CRL(n-1) and potentially have quite a
>> window of opportunity.

>From what I've been reading here and elsewhere, it appears that many people
wish to require that relying parties always use the most up-to-date CRL when
performing a validation. I think this is a bad idea.

In general, a CRL provides the revocation status of a large number of
certificates
and is designed to be cached. If a relying party must check with a repository
for the freshest available revocation information each time it performs a
validation,
then a scheme, such as OCSP, which only provides the revocation status of
the certificate to be validated makes more sense.

If CRLs are to be used, then the CA must allow for validations to be performed
based on "old" revocation information. If the CA wishes to insure that
validations
are never performed using revocation information that is more than 4 hours old
then it should issue CRLs AT LEAST once every 4 hours with each CRL having
a nextUpdate field set to 4 hours after the time of issuance. The CA must then
accept that some relying parties will base validations on CRLs that may
have been
replaced by fresher CRLs, even when the new CRLs were issued as a result of
a compromise.

At 03:53 PM 11/2/98 +0100, Andreas Berger wrote:
>That is if you assume that a CA is allowed to have several CRLs valid at
>a given point in time.
>
>Andreas

I most definitely want to allow a CA to have several CRLs valid at the same
time, but not for security reasons. I have been doing some work recently on
modeling the distribution of revocation information. The goal of the work
is to
determine, for any given situation, the best way to distribute revocation
information in order to minimize the peak load on the repository.

Suppose that a CA wishes to insure that relying parties always validate based
on revocation information that is at most 4 hours old. One option would be to
issue one CRL every 4 hours. However, if instead the CA issues one CRL every
hour, but still makes each CRL valid for 4 hours, the peak request rate to
the repository from relying parties will be lower. In general, the more
often new
CRLs are issued the lower the peak request rate. But, this reduction only
happens
if relying parties cache and continue to use the CRLs they download until the
time specified in nextUpdate is reached, not if they download a new CRL each
time a new one is issued.

David Cooper



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05385 for ietf-pkix-bks; Mon, 2 Nov 1998 07:28:23 -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 HAA05381 for <[e-mail]>; Mon, 2 Nov 1998 07:28:22 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA05956 for <[e-mail]>; Mon, 2 Nov 1998 10:30:57 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA05943 for <[e-mail]>; Mon, 2 Nov 1998 10:30:56 -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 KAA00456 for <[e-mail]>; Mon, 2 Nov 1998 10:30:00 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 02 Nov 1998 10:30:44 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Mon, 2 Nov 1998 10:30:45 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Robert Klerer'" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: email oid
Date: Mon, 2 Nov 1998 10:30:44 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Robert, in a brief look at the Internet Person draft from netscape, it
appears they are using the 'rfc822mailbox' oid ('mail' for short).  I
was told that a quick search with netscape navigator and outlook express
(LDAP interfaces) appear to search for the 'mail' attribute - mapped to
rfc822mailbox? 

Could either the outlook or netscape folks tell us what they are
searching on?  "mail" or "emailAddress"?  Is Entrust using the pkcs 9
oid?

I would like to ensure the specs we are generating capture the
concensus.

Thanks,
Sandi

>----------
>From: 	Robert Klerer[SMTP:[e-mail]]
>Sent: 	Friday, October 30, 1998 4:47 PM
>To: 	Miklos, Sue A.; 'Russ Housley'
>Cc: 	'ietf-pkix'; [e-mail]
>Subject: 	Re: email oid
>
>Sue,
>
>Adding the additional OID would not be the optimum solution.  Since if I
>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>problem.  pkix should NOT perpetuate the problem by again calling the same
>thing two different names.
>
>Robert
>
>-----Original Message-----
>From: Miklos, Sue A. <[e-mail]>
>To: 'Russ Housley' <[e-mail]>
>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>'[e-mail]' <[e-mail]>
>Date: Friday, October 30, 1998 2:34 PM
>Subject: RE: email oid
>
>
>>Russ, and others, may I then request that it be included or is that not
>>possible?
>>
>>Sandi
>>
>>>----------
>>>From: Russ Housley[SMTP:[e-mail]]
>>>Sent: Friday, October 30, 1998 1:35 PM
>>>To: Miklos, Sue A.
>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>Subject: Re: email oid
>>>
>>>Sandi:
>>>
>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>
>>>Russ
>>>
>>>
>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>All,
>>>>In the specifications for the schema for an international defense
>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>registered
>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>I would like to request that this remain in whatever documentation you
>>>>develop.
>>>>
>>>>Thanks,
>>>>Sandi Miklos
>>>>>
>>>>>
>>>>>----------
>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>Subject: RE: email oid
>>>>>
>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>if there is a demand for it.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>To: [e-mail]
>>>>>Subject: email oid
>>>>>
>>>>>
>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>problem
>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>specifies
>>>>>that the oid used for an email address in the distinguished name is
>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>mail
>>>>>as specified in RFC1274.
>>>>>
>>>>>Since I believe that the intention is for both of these oids are meant
>to
>>>>>represent attributes that hold the same information, this discrepancy
>may
>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>change part1 to refer to the more commonly used OID.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05291 for ietf-pkix-bks; Mon, 2 Nov 1998 07:18:41 -0800 (PST)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05287 for <[e-mail]>; Mon, 2 Nov 1998 07:18:40 -0800 (PST)
From: [e-mail]
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24762 for <[e-mail]>; Mon, 2 Nov 1998 10:21:02 -0500
Received: from rampal.raleigh.ibm.com (rampal.raleigh.ibm.com [9.37.178.98]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA24920 for <[e-mail]>; Mon, 2 Nov 1998 10:21:03 -0500
Received: by rampal.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15972; Mon, 2 Nov 1998 10:20:57 -0500
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.5 12/11/95
To: [e-mail]
Subject: PKI-LDAP interaction questions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Nov 98 10:20:57 -0500
Sender: [e-mail]
Precedence: bulk

All,
 
I have some basic questions on storing pki certificates on 
LDAP servers (am new to this stuff so apologise if I am 
missing something straightforward). 


1. Seems like several possible objectclasses can be used to store
certificates on an LDAP directory. draft-ietf-pkix-LDAPv2-schema-02.txt
mentions that the classes pkiUser and pkiCA MAY be used as part of other
objects to store certificates. The netscape directory server has objects like
strongAuthenticationUser and inetOrgPerson which contain attributes for 
certificates. It would appear that there is no standard objectClass 
which a PKI entity can use to search for on a directory. So, PKI entities
should know the exact DN of the entry (which is known out of band) to 
contain the certificate they are looking for (and not search for a 
particular object class), correct ? 

2. Are PKI entities supposed to know the format under which a certificate
is stored in a directory entry ? or is it always mandated to be DER ? 
(note: the netscape directory server has two kinds of attributes 
userCertificate and userCertificate;binary ...). 

3. The DN which a PKI entity uses to request a certificate from a CA need 
not be related in any way to the DN of the entry in which it is stored in the 
LDAP directory (though it might be convenient for them to be the same)
correct ?

4. The process by which a certificate published by a CA is installed on an 
LDAP directory is essentially expected to be out of band correct ? 
(though some CAs may provide the facility to include an LDAP client and 
directly load the certificate onto a specified directory server (if provided
the LDAP bind and DN information etc...).


Thanks,

Sanjeev.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05148 for ietf-pkix-bks; Mon, 2 Nov 1998 06:51:12 -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 GAA05144 for <[e-mail]>; Mon, 2 Nov 1998 06:51:06 -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 PAA25739; Mon, 2 Nov 1998 15:52:44 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 02 Nov 1998 15:53:37 +0100
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: [e-mail]
CC: "'Phillip M Hallam-Baker'" <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

[e-mail] wrote:
> 
> >If someone spoofed DNS the worst that would happen is that I would
> >recieve a certificate I didn't trust (and would ignore) or no >certificate
> at all.
> 
> Well, if you're only fetching certificates, probably.
> 
> But if you're fetching CRL's, then no.  Suppose a cert is compromised,
> and CRLn is issued before the "next update" time purely because of
> that compromise.  The adversary could spoof DNS and just send out
> the valid, but outdated CRL(n-1) and potentially have quite a
> window of opportunity.
That is if you assume that a CA is allowed to have several CRLs valid at
a given point in time.

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 MAA18722 for ietf-pkix-bks; Mon, 30 Nov 1998 12:03:46 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18718 for <[e-mail]>; Mon, 30 Nov 1998 12:03:45 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id PAA07957; Mon, 30 Nov 1998 15:08:30 -0500
Message-Id: <4.1.19981201030259.00a5f700@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 03:06:49 -0500
To: Santosh Chokhani <[e-mail]>, "Grall, Cynthia" <[e-mail]>, "'Russ Housley'" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E23D875@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Santosh,

	You are correct - in my haste, I missed the statement two paragraphs above
the one being discussed, which is:

		The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred to as p, q, and g. 
		When omitted, the parameters component shall be omitted entirely. That
is, the AlgorithmIdentifier shall be a SEQUENCE 
		of one component - the OBJECT IDENTIFIER id-dsa.

	Thus, the NULL value is not permitted in this field of PKIX-compliant
certificates.  Given that, I agree that the sentence about "distributed by
other means" should be dropped.

			Al Arsenault




At 02:35 PM 11/30/98 -0500, Santosh Chokhani wrote:
>Al:
>
>I think whether the parameter value of NULL is valid is driven by the
>Algorithm OID registration.  For example, RSA algorithm OIDs registered
>would have NULL parameter value.
>
>Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
>parameters.  But, it is recommended only for the algorithm OID in the
>issuer signature and SIGNED MACRO fields.
>
>I think the point regarding the NULL is not germane to this discussion.
>
>> -----Original Message-----
>> From:	Al Arsenault [SMTP:[e-mail]]
>> Sent:	Tuesday, December 01, 1998 2:00 AM
>> To:	Grall, Cynthia; 'Santosh Chokhani'; 'Russ Housley'
>> Cc:	[e-mail]; [e-mail]
>> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> 
>> If I recall correctly, this paragraph is actually trying to address
>> the
>> fact that the parameters field is optional, and even if it's there, it
>> might be NULL.  The relevant wording is:
>> 
>> > If the DSA algorithm parameters are absent 
>> > from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
>> 
>> > the subject certificate using a signature algorithm other than DSA, 
>> > then  the subject's DSA parameters are distributed by other means.
>> If 
>> > the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
>> > parameters component and the CA signed the subject with a signature 
>> > algorithm other than DSA, then clients shall reject the certificate.
>> 
>> > 
>> 
>> 
>> This is poorly worded, I admit, but it tries to address two different
>> cases:
>> 
>> 	case 1:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
>> end-entity need not reject the certificate, but it has to get the
>> parameter
>> values from some place other than the certificate.
>> 
>> 	case 2:  the CA used an algorithm other than DSA, the end-entity
>> cert has
>> a DSA key, and the parameters component of the subjectPublicKeyInfo
>> AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no
>> field.
>>  In this case, the end-entity has to reject the certificate.
>> 
>> (There was actually a long discussion in the S/MIME WG in Chicago
>> about
>> whether this field should be there and be set to NULL, or left out
>> altogether. You can see the S/MIME meeting minutes/mailing list for
>> all the
>> gory details.)
>> 
>> Before figuring out the wording that would make this clearer, the
>> important
>> question is:  is this correct?  That is, should the actions be
>> different in
>> these 2 cases (including the field & setting it to NULL, and omitting
>> the
>> field altogether), or should they be the same?  If they're the same,
>> which
>> should they be - reject the cert, or go get the parameters from
>> somewhere else?
>> 
>> In my opinion, the proper action in both cases is to look for the
>> parameter
>> values first, before rejecting the certificate, but that's just a
>> personal
>> preference.  Other opinions are welcome (and I'm confident they'll
>> come :-)  
>> 
>> 			Al Arsenault
>> 
>> 
>> 
>> 
>> At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
>> >I agree.  If the intent is to disgard a subject certificate if the
>> DSA
>> >param's are not present AND the CA used a signature algorithm other
>> than
>> >DSA, then this sentence (especially the phrase "distributed by other
>> means")
>> >is confusing.  To me it directly contradicts the next sentence which
>> states
>> >"...then clients shall reject the certificate."
>> >
>> >Cindy
>> >-------------
>> >Cindy Grall
>> >Network Associates, Inc.                    [e-mail]
>> >3415 s. Sepulvida Blvd. suite 700       phone: [phone]
>> >Los Angeles, CA 90034                       fax: [phone]
>> >
>> >> -----Original Message-----
>> >> From:	Santosh Chokhani [SMTP:[e-mail]]
>> >> Sent:	Monday, November 30, 1998 7:15 AM
>> >> To:	'Russ Housley'; [e-mail]
>> >> Cc:	[e-mail]; [e-mail]
>> >> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> >> 
>> >> Russ and Tim Polk:
>> >> 
>> >> I think the following sentence is confusing and may mislead:
>> >> 
>> >> 	"If the DSA  algorithm parameters are absent from the
>> >> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>> subject
>> >> certificate using a signature algorithm other than DSA, then the
>> >> subject's DSA parameters are distributed by other means." 
>> >> 
>> >> It does not seem to lead to any processing requirements.  Thus, I
>> >> suggest we delete it from PKIX part 1.
>> >> 
>> >> 
>> >> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18514 for ietf-pkix-bks; Mon, 30 Nov 1998 11:33:17 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18510 for <[e-mail]>; Mon, 30 Nov 1998 11:33:14 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HPK>; Mon, 30 Nov 1998 14:35:20 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D875@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, "Grall, Cynthia" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 14:35:18 -0500
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

Al:

I think whether the parameter value of NULL is valid is driven by the
Algorithm OID registration.  For example, RSA algorithm OIDs registered
would have NULL parameter value.

Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
parameters.  But, it is recommended only for the algorithm OID in the
issuer signature and SIGNED MACRO fields.

I think the point regarding the NULL is not germane to this discussion.

> -----Original Message-----
> From:	Al Arsenault [SMTP:[e-mail]]
> Sent:	Tuesday, December 01, 1998 2:00 AM
> To:	Grall, Cynthia; 'Santosh Chokhani'; 'Russ Housley'
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> If I recall correctly, this paragraph is actually trying to address
> the
> fact that the parameters field is optional, and even if it's there, it
> might be NULL.  The relevant wording is:
> 
> > If the DSA algorithm parameters are absent 
> > from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> 
> > the subject certificate using a signature algorithm other than DSA, 
> > then  the subject's DSA parameters are distributed by other means.
> If 
> > the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> > parameters component and the CA signed the subject with a signature 
> > algorithm other than DSA, then clients shall reject the certificate.
> 
> > 
> 
> 
> This is poorly worded, I admit, but it tries to address two different
> cases:
> 
> 	case 1:  the CA used an algorithm other than DSA, the end-entity
> cert has
> a DSA key, and the parameters component of the subjectPublicKeyInfo
> AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
> end-entity need not reject the certificate, but it has to get the
> parameter
> values from some place other than the certificate.
> 
> 	case 2:  the CA used an algorithm other than DSA, the end-entity
> cert has
> a DSA key, and the parameters component of the subjectPublicKeyInfo
> AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no
> field.
>  In this case, the end-entity has to reject the certificate.
> 
> (There was actually a long discussion in the S/MIME WG in Chicago
> about
> whether this field should be there and be set to NULL, or left out
> altogether. You can see the S/MIME meeting minutes/mailing list for
> all the
> gory details.)
> 
> Before figuring out the wording that would make this clearer, the
> important
> question is:  is this correct?  That is, should the actions be
> different in
> these 2 cases (including the field & setting it to NULL, and omitting
> the
> field altogether), or should they be the same?  If they're the same,
> which
> should they be - reject the cert, or go get the parameters from
> somewhere else?
> 
> In my opinion, the proper action in both cases is to look for the
> parameter
> values first, before rejecting the certificate, but that's just a
> personal
> preference.  Other opinions are welcome (and I'm confident they'll
> come :-)  
> 
> 			Al Arsenault
> 
> 
> 
> 
> At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
> >I agree.  If the intent is to disgard a subject certificate if the
> DSA
> >param's are not present AND the CA used a signature algorithm other
> than
> >DSA, then this sentence (especially the phrase "distributed by other
> means")
> >is confusing.  To me it directly contradicts the next sentence which
> states
> >"...then clients shall reject the certificate."
> >
> >Cindy
> >-------------
> >Cindy Grall
> >Network Associates, Inc.                    [e-mail]
> >3415 s. Sepulvida Blvd. suite 700       phone: [phone]
> >Los Angeles, CA 90034                       fax: [phone]
> >
> >> -----Original Message-----
> >> From:	Santosh Chokhani [SMTP:[e-mail]]
> >> Sent:	Monday, November 30, 1998 7:15 AM
> >> To:	'Russ Housley'; [e-mail]
> >> Cc:	[e-mail]; [e-mail]
> >> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> >> 
> >> Russ and Tim Polk:
> >> 
> >> I think the following sentence is confusing and may mislead:
> >> 
> >> 	"If the DSA  algorithm parameters are absent from the
> >> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
> subject
> >> certificate using a signature algorithm other than DSA, then the
> >> subject's DSA parameters are distributed by other means." 
> >> 
> >> It does not seem to lead to any processing requirements.  Thus, I
> >> suggest we delete it from PKIX part 1.
> >> 
> >> 
> >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18185 for ietf-pkix-bks; Mon, 30 Nov 1998 10:57:08 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18181 for <[e-mail]>; Mon, 30 Nov 1998 10:57:06 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA05029; Mon, 30 Nov 1998 14:01:37 -0500
Message-Id: <4.1.19981201014809.00a67610@209.172.119.98>
X-Sender: aarsenault#207.212.34.30@209.172.119.98
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 02:00:21 -0500
To: "Grall, Cynthia" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

If I recall correctly, this paragraph is actually trying to address the
fact that the parameters field is optional, and even if it's there, it
might be NULL.  The relevant wording is:

> If the DSA algorithm parameters are absent 
> from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 
> the subject certificate using a signature algorithm other than DSA, 
> then  the subject's DSA parameters are distributed by other means. If 
> the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> parameters component and the CA signed the subject with a signature 
> algorithm other than DSA, then clients shall reject the certificate. 
> 


This is poorly worded, I admit, but it tries to address two different cases:

	case 1:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
end-entity need not reject the certificate, but it has to get the parameter
values from some place other than the certificate.

	case 2:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no field.
 In this case, the end-entity has to reject the certificate.

(There was actually a long discussion in the S/MIME WG in Chicago about
whether this field should be there and be set to NULL, or left out
altogether. You can see the S/MIME meeting minutes/mailing list for all the
gory details.)

Before figuring out the wording that would make this clearer, the important
question is:  is this correct?  That is, should the actions be different in
these 2 cases (including the field & setting it to NULL, and omitting the
field altogether), or should they be the same?  If they're the same, which
should they be - reject the cert, or go get the parameters from somewhere else?

In my opinion, the proper action in both cases is to look for the parameter
values first, before rejecting the certificate, but that's just a personal
preference.  Other opinions are welcome (and I'm confident they'll come :-)  

			Al Arsenault




At 07:49 AM 11/30/98 -0800, Grall, Cynthia wrote:
>I agree.  If the intent is to disgard a subject certificate if the DSA
>param's are not present AND the CA used a signature algorithm other than
>DSA, then this sentence (especially the phrase "distributed by other means")
>is confusing.  To me it directly contradicts the next sentence which states
>"...then clients shall reject the certificate."
>
>Cindy
>-------------
>Cindy Grall
>Network Associates, Inc.                    [e-mail]
>3415 s. Sepulvida Blvd. suite 700       phone: [phone]
>Los Angeles, CA 90034                       fax: [phone]
>
>> -----Original Message-----
>> From:	Santosh Chokhani [SMTP:[e-mail]]
>> Sent:	Monday, November 30, 1998 7:15 AM
>> To:	'Russ Housley'; [e-mail]
>> Cc:	[e-mail]; [e-mail]
>> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
>> 
>> Russ and Tim Polk:
>> 
>> I think the following sentence is confusing and may mislead:
>> 
>> 	"If the DSA  algorithm parameters are absent from the
>> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
>> certificate using a signature algorithm other than DSA, then the
>> subject's DSA parameters are distributed by other means." 
>> 
>> It does not seem to lead to any processing requirements.  Thus, I
>> suggest we delete it from PKIX part 1.
>> 
>> 
>> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16685 for ietf-pkix-bks; Mon, 30 Nov 1998 07:42:32 -0800 (PST)
Received: from europe.std.com (europe.std.com [199.172.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16680 for <[e-mail]>; Mon, 30 Nov 1998 07:42:28 -0800 (PST)
Received: from world.std.com by europe.std.com (8.7.6/BZS-8-1.0) id KAA23880; Mon, 30 Nov 1998 10:47:05 -0500 (EST)
Received: by world.std.com (TheWorld/Spike-2.0) id AA04125; Mon, 30 Nov 1998 10:47:04 -0500
Message-Id: <[e-mail]>
To: Carlisle Adams <[e-mail]>
Cc: [e-mail]
Subject: Re: generation of private keys 
In-Reply-To: Your message of "Fri, 27 Nov 1998 12:46:26 EST." <[e-mail]> 
Date: Mon, 30 Nov 1998 10:47:03 -0500
From: Dan Geer <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    > What could have happened in the past couple of years to cause you
    > to alter your view so radically?
    
"Do I contradict myself?
Very well then....I contradict myself;
I am large....I contain multitudes."
       --Walt Whitman

As to the point about marking who generated the keys,
either it has to be a falsifiable hypothesis or it has
to carry warranty of/by the CA.  Since there is no way
to make the hypothesis falsifiable and since the CA is
in the random warranty business anyway (or the RA is,
small difference), then this is the CA's opinion and
either it stands behind it (warranty) or it does not.
I certainly wouldn't treat it as a hint -- who the 
hell would take a hint on something as crucial as 
whether this set of keys was gen'd by XYZ?  Of course,
whether gen'd on the up-and-up or not, incompetently
escrowed trumps competently gen'd any day.

Bottom line:
one bit answer to _CA_takes_responsibility_for_key_gen?_

contradictorily speaking,

--dan



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16667 for ietf-pkix-bks; Mon, 30 Nov 1998 07:40:52 -0800 (PST)
Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16663 for <[e-mail]>; Mon, 30 Nov 1998 07:40:51 -0800 (PST)
Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2232.9) id <WY0KLH76>; Mon, 30 Nov 1998 07:40:38 -0800
Message-ID: <[e-mail]>
From: "Grall, Cynthia" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, "Grall, Cynthia" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 07:49:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.  If the intent is to disgard a subject certificate if the DSA
param's are not present AND the CA used a signature algorithm other than
DSA, then this sentence (especially the phrase "distributed by other means")
is confusing.  To me it directly contradicts the next sentence which states
"...then clients shall reject the certificate."

Cindy
-------------
Cindy Grall
Network Associates, Inc.                    [e-mail]
3415 s. Sepulvida Blvd. suite 700       phone: [phone]
Los Angeles, CA 90034                       fax: [phone]

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[e-mail]]
> Sent:	Monday, November 30, 1998 7:15 AM
> To:	'Russ Housley'; [e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> Russ and Tim Polk:
> 
> I think the following sentence is confusing and may mislead:
> 
> 	"If the DSA  algorithm parameters are absent from the
> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
> certificate using a signature algorithm other than DSA, then the
> subject's DSA parameters are distributed by other means." 
> 
> It does not seem to lead to any processing requirements.  Thus, I
> suggest we delete it from PKIX part 1.
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16457 for ietf-pkix-bks; Mon, 30 Nov 1998 07:12:53 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA16453 for <[e-mail]>; Mon, 30 Nov 1998 07:12:51 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HJC>; Mon, 30 Nov 1998 10:15:00 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D86C@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Mon, 30 Nov 1998 10:14:57 -0500
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

Russ and Tim Polk:

I think the following sentence is confusing and may mislead:

	"If the DSA  algorithm parameters are absent from the
subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
certificate using a signature algorithm other than DSA, then the
subject's DSA parameters are distributed by other means." 

It does not seem to lead to any processing requirements.  Thus, I
suggest we delete it from PKIX part 1.


> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Monday, November 30, 1998 9:45 AM
> To:	[e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> Cindy:
> 
> This is trying to explain parameter inheritance.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using
> DSA,
> the CA's parameters are inherited by the issued certificate.  This is
> done
> to reduce the size of the certificate.  The parameters are more than
> twice
> the size of the public key, so to reduce the number of certificates
> that
> include them.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using an
> algorithm other than DSA, the CA's parameters cannot be inherited.  To
> avoid this situaltion, the parameters should be put in the
> certificate.  If
> they are not in the certificate, it should be rejected.
> 
> Russ
> 
> 
> > The following paragraph seems to have two conflicting sentences:
> > 
> > 7.3.3  DSA Signature Keys
> > 
> > ...
> > 
> >    If the DSA algorithm parameters are absent from the
> subjectPublicKey-
> >    Info AlgorithmIdentifier and the CA signed the subject
> certificate
> >    using DSA, then the certificate issuer's DSA parameters apply to
> the
> >    subject's DSA key.  If the DSA algorithm parameters are absent
> from
> >    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> the
> >    subject certificate using a signature algorithm other than DSA,
> then
> >    the subject's DSA parameters are distributed by other means.  If
> the
> >    subjectPublicKeyInfo AlgorithmIdentifier field omits the
> parameters
> >    component and the CA signed the subject with a signature
> algorithm
> >    other than DSA, then clients shall reject the certificate.
> > 
> > I understand the second sentence to mean if the CA cert. has a (for
> > example) RSA key, and the EE cert. has a DSA key with no parameters,
> > then the EE cert. is okay and I have to find the parameters
> somewhere
> > else.  
> > 
> > The third sentence says if the CA cert. has (for example) a RSA key,
> > and the EE cert. has a DSA key with no parameters, then I should
> reject
> > the EE cert.
> > 
> > Is there something I'm missing here?  If these do conflict, which is
> the
> > correct statement?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16249 for ietf-pkix-bks; Mon, 30 Nov 1998 06:39:49 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16245 for <[e-mail]>; Mon, 30 Nov 1998 06:39:48 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA25910; Mon, 30 Nov 1998 09:44:36 -0500
Message-Id: <4.1.19981130092904.0098f320@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 30 Nov 1998 09:45:29 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Cc: [e-mail], [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E23D867@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Cindy:

This is trying to explain parameter inheritance.

When the DSA algorithm parameters are absent from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using DSA,
the CA's parameters are inherited by the issued certificate.  This is done
to reduce the size of the certificate.  The parameters are more than twice
the size of the public key, so to reduce the number of certificates that
include them.

When the DSA algorithm parameters are absent from the subjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using an
algorithm other than DSA, the CA's parameters cannot be inherited.  To
avoid this situaltion, the parameters should be put in the certificate.  If
they are not in the certificate, it should be rejected.

Russ


> The following paragraph seems to have two conflicting sentences:
> 
> 7.3.3  DSA Signature Keys
> 
> ...
> 
>    If the DSA algorithm parameters are absent from the subjectPublicKey-
>    Info AlgorithmIdentifier and the CA signed the subject certificate
>    using DSA, then the certificate issuer's DSA parameters apply to the
>    subject's DSA key.  If the DSA algorithm parameters are absent from
>    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>    subject certificate using a signature algorithm other than DSA, then
>    the subject's DSA parameters are distributed by other means.  If the
>    subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters
>    component and the CA signed the subject with a signature algorithm
>    other than DSA, then clients shall reject the certificate.
> 
> I understand the second sentence to mean if the CA cert. has a (for
> example) RSA key, and the EE cert. has a DSA key with no parameters,
> then the EE cert. is okay and I have to find the parameters somewhere
> else.  
> 
> The third sentence says if the CA cert. has (for example) a RSA key,
> and the EE cert. has a DSA key with no parameters, then I should reject
> the EE cert.
> 
> Is there something I'm missing here?  If these do conflict, which is the
> correct statement?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA02028 for ietf-pkix-bks; Sun, 29 Nov 1998 00:42:36 -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 AAA02010 for <[e-mail]>; Sun, 29 Nov 1998 00:39:39 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id AAA24812; Sun, 29 Nov 1998 00:41:18 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id AAA29918; Sun, 29 Nov 1998 00:42:56 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLAXVF>; Sun, 29 Nov 1998 00:42:57 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Sun, 29 Nov 1998 00:42:49 -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

Carlisle:

Thanks for pointing this out. When the book is revised, I'll ensure that
that passage is reworded to address the other options that are now apparent.

Warwick

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:46 AM
To: 'Warwick Ford'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi Warwick,

A couple of quotes (from W. Ford, "Computer Communications Security:
Principles, Standard Protocols and Techniques", pp.97-98):

"To minimize vulnerabilities, the key generation process is best carried out
either within the owner system or within the certification authority system,
thereby necessitating only one protected key transfer."

"If keys are generated with the certification authority system, transfer of
the private key to the owner system will require both integrity and
confidentiality protection.  In either case, if key archiving is required,
reliable copies of both keys will need to be sent to an archiving system
(which may be co-located with the certification authority system)..."

Not a word about "highly undesirable", "questionable security practice", or
"might be O.K., subject to complete risk analysis".  What could have
happened in the past couple of years to cause you to alter your view so
radically?


In any case, we are in full agreement that all options should be left open
(in order to suit the needs of all environments).  I'm not sure what
"technical protocol" you're referring to below, since Stefan's suggestion
was simply to add an extension to a Certificate, but an enumeration rather
than a Boolean is perfectly fine with me.

Carlisle.


-----Original Message-----
From: Warwick Ford [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:29 AM
To: 'Carlisle Adams'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11118 for ietf-pkix-bks; Fri, 27 Nov 1998 13:38:10 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11114 for <[e-mail]>; Fri, 27 Nov 1998 13:38:06 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1HAR>; Fri, 27 Nov 1998 16:40:43 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E23D867@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Grall, Cynthia'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Minor confusion in PKIX part 1, section 7.3.3
Date: Fri, 27 Nov 1998 16:40:43 -0500
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

Cindy:

You are correct that the two sentences are contradictory.  The safer
thing to do is to reject the certificate since with the X.509
authentication framework and certificate path there is no guarantee as
to what the parameters are.  Thus, the first sentence should be deleted
from PKIX Part 1.

May be the editors of PKIX Part 1 can shed some light on it also.

> -----Original Message-----
> From:	Grall, Cynthia [SMTP:[e-mail]]
> Sent:	Tuesday, November 24, 1998 11:43 AM
> To:	'[e-mail]'
> Subject:	FW: Minor confusion in PKIX part 1, section 7.3.3
> 
> 
> > The following paragraph seems to have two conflicting sentences:
> > 
> > 7.3.3  DSA Signature Keys
> > 
> > ...
> > 
> >    If the DSA algorithm parameters are absent from the
> subjectPublicKey-
> >    Info AlgorithmIdentifier and the CA signed the subject
> certificate
> >    using DSA, then the certificate issuer's DSA parameters apply to
> the
> >    subject's DSA key.  If the DSA algorithm parameters are absent
> from
> >    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed
> the
> >    subject certificate using a signature algorithm other than DSA,
> then
> >    the subject's DSA parameters are distributed by other means.  If
> the
> >    subjectPublicKeyInfo AlgorithmIdentifier field omits the
> parameters
> >    component and the CA signed the subject with a signature
> algorithm
> >    other than DSA, then clients shall reject the certificate.
> > 
> > I understand the second sentence to mean if the CA cert. has a (for
> > example) RSA key, and the EE cert. has a DSA key with no parameters,
> > then the EE cert. is okay and I have to find the parameters
> somewhere
> > else.  
> > 
> > The third sentence says if the CA cert. has (for example) a RSA key,
> > and the EE cert. has a DSA key with no parameters, then I should
> reject
> > the EE cert.
> > 
> > Is there something I'm missing here?  If these do conflict, which is
> the
> > correct statement?
> > 
> > Cindy
> > ----------
> > Cindy Grall                       [e-mail]
> > Network Associates, Inc.          phone: [phone]
> > 3415 S. Sepulvida Blvd.           fax:   [phone]
> > Los Angeles, California 90034


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA10070 for ietf-pkix-bks; Fri, 27 Nov 1998 09:49:40 -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 JAA10066 for <[e-mail]>; Fri, 27 Nov 1998 09:49:38 -0800 (PST)
Received: 	id MAA29461; Fri, 27 Nov 1998 12:51:16 -0500
Received: by gateway id <XNGHBSNR>; Fri, 27 Nov 1998 12:46:28 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Warwick Ford'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Fri, 27 Nov 1998 12:46:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Warwick,

A couple of quotes (from W. Ford, "Computer Communications Security:
Principles, Standard Protocols and Techniques", pp.97-98):

"To minimize vulnerabilities, the key generation process is best carried out
either within the owner system or within the certification authority system,
thereby necessitating only one protected key transfer."

"If keys are generated with the certification authority system, transfer of
the private key to the owner system will require both integrity and
confidentiality protection.  In either case, if key archiving is required,
reliable copies of both keys will need to be sent to an archiving system
(which may be co-located with the certification authority system)..."

Not a word about "highly undesirable", "questionable security practice", or
"might be O.K., subject to complete risk analysis".  What could have
happened in the past couple of years to cause you to alter your view so
radically?


In any case, we are in full agreement that all options should be left open
(in order to suit the needs of all environments).  I'm not sure what
"technical protocol" you're referring to below, since Stefan's suggestion
was simply to add an extension to a Certificate, but an enumeration rather
than a Boolean is perfectly fine with me.

Carlisle.


-----Original Message-----
From: Warwick Ford [mailto:[e-mail]]
Sent: Friday, November 27, 1998 9:29 AM
To: 'Carlisle Adams'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA08453 for ietf-pkix-bks; Fri, 27 Nov 1998 06:25:14 -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 GAA08449 for <[e-mail]>; Fri, 27 Nov 1998 06:25:13 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA07797; Fri, 27 Nov 1998 06:26:49 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id GAA04101; Fri, 27 Nov 1998 06:29:19 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLAWQ6>; Fri, 27 Nov 1998 06:29:21 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Fri, 27 Nov 1998 06:29: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

Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.

Warwick


-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 3:11 PM
To: 'Warwick Ford'
Cc: '[e-mail]'
Subject: RE: generation of private keys


Hi Warwick,

:-----Original Message-----
:From: Warwick Ford [mailto:[e-mail]]
:Sent: Wednesday, November 25, 1998 9:36 AM
:To: '[e-mail]'; [e-mail]; [e-mail]
:Subject: RE: generation of private keys
:
:I think the case of a CA generating key pairs is the least 
:interesting of
:all.  Generally, for security separation purposes, it is 
:considered highly
:undesirable for a CA to generate user key pairs.  


The above sentence should probably be clarified because it is misleading as
it stands (which I'm sure was not your intention).  I prefer "Generally, for
security separation purposes, it is considered highly undesirable for a CA
to generate user key pairs when the CA is at 'arm's length' from the user.",
or something similar.  In particular, a CA that is external to an
organization (e.g., a CA service provider) may have nothing in its CPS
discussing such functionality and may take no legal responsibility for user
key pair generation.  This is a case where separation of duties makes sense.

However, for other environments the CA, the RA, and the key generation
facility may effectively be the same entity within an organization.
Separation of duties need not be required in such cases and there is no
reason for it to be "undesirable" for this entity to perform both key
generation and CA functions.


:Having the key pair
:generated by an RA or another "authority" devoted to key 
:management, maybe
:within the same enterprise, are better.  


Absolutely.  "Better" if the CA is outside the enterprise.  Not necessarily
"better" for any inherent reason if the CA is within the enterprise.


:In the case of an RA or other
:authority, there is generally an established trust 
:relationship between the
:CA and that entity, supported, for example, by their inherent 
:organizational
:relationship or by a contractual relationship, plus trusted 
:communications
:paths.  Hence, it is likely quite reasonable for a CA to have 
:confidence
:that, when an RA or key management authority says it generated 
:a particular
:key pair, it did, in fact, generate that key pair.
:
:Warwick


Does this, then, argue for Stefan's original suggestion of an extension
specifying the location of key generation?  Do you think that because of
such relationships, trusted communications paths, etc., the CA can have
sufficient confidence in the location to encode it into a certificate and
stand by it in a legal sense?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02403 for ietf-pkix-bks; Thu, 26 Nov 1998 21:43:51 -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 VAA02399 for <[e-mail]>; Thu, 26 Nov 1998 21:43:47 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2QJBW>; Fri, 27 Nov 1998 16:47:03 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A67@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: [e-mail]
Subject: RE: some comments on OCSP vs 7
Date: Fri, 27 Nov 1998 16:47:00 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

If the purpose of this RFP is to quickly find / identify a specific
certificate and its status, rather than trawl through CRLs, then it
seems to me that that rather than adding additional protocol and trust
management to validate certificates, that some of this could be moved
back into the CA and directories, as follows: -

*  When a certificate is revoked, put a CRL style wrapper around the
individual certificate (rather than just its Issuer & Serial), with
Revocation DateTime, Reason Codes etc and the CA signs it, to create a
RevokedCertificateObject
 
*  This RevokedCertificateObject can be stored into a nominated arc of a
DIT along with all other revokedcertificatesobjects

*  I would tend to add additional attributes into the directory's
representation of this object, to improve searchability i.e. SubjectDn,
Validity Date / Time,    MD5 Hash Fingerprint), KeyUsage periods etc as
this is a simpler alternative than implementing certificate matching
rules on the server and helps with reporting / summarisation.

The benefits of the approach are as follows: -

* Existing LDAP / DAP protocols can be used for queries

* Existing directory functions are used to quickly retrieve an object.
If its not found, its not revoked, if its   found the reason codes and
CA signature are readily accessible as part of the object.  Matching on
the client side is easy because you retrieve a copy of the certficate
and can do a compare, as well as all validations.

* Backend DISP / DSP are available for shadowing and distributed queries
is possible, respectively, although I would probably use something with
more guaranteed service than DISP.

* The CA's private key does not need to be available to a Responder
task.  Signing of revoked certificates is a behind the scenes / trusted
function.

* The complexity of Designated Responder key management is avoided

* Online real-time certificate validity checking is available through
online real-time directory support, without needing to invent a new
protocol.

* The user receives an object of real value, because they could archive
/ keep it for proof of revocation, without requiring the whole list.

CRLs have their place as a list of revoked certs and are good for the
process of batch distrubution, but I have always felt that they do not
make for
good online / realtime retrieval purposes.

Directories are pretty fast and reliable now, so we should leverage
their capabilities by adding to information models over existing
protocols.

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15756 for ietf-pkix-bks; Wed, 25 Nov 1998 15:28:09 -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 PAA15752 for <[e-mail]>; Wed, 25 Nov 1998 15:28:08 -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 PAA13698 for <[e-mail]>; Wed, 25 Nov 1998 15:32:32 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 25 Nov 1998 15:31:21 -0800
To: [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: generation of private keys
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:57 AM 11/25/98 +0100, you wrote:
>Tony,
>
>> >Interesting question.  My initial reaction is to wonder if a new certificate
>> >extension is really the right solution for this.  If the CA generates the
>> >key pair, it can certainly populate such an extension with confidence.
>> >However, if the CA did not generate the key pair, how will it distinguish
>> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
>> >the actual key pair generation so that it can populate the extension)?
>> >
>> >Carlisle.
>>
>> It seems the most a CA could do is indicate either that it did, or did not
>> generate the keypair, correct?
>
>You're probably right. So it comes down to a boolean indicator. Do you agree
>that such an indicator would be a useful enhancement?
>
>If we don't use an extension, what other means would we have to indicate
>the key generation location?
>
>Cheers,
>
>        Stefan.

Stefan,

Beign unfamiliar with the German Dig-Sig Law, it is hard to say.
I can see no harm from such an extension.  In the case where "law"
requires that "key-gen-authorhood" be positively identified, this
would tend to make CA-key-generation somewhat mandatory, but then
law is law.

I was trying to think of some way that keys, (or simply random
numbers) could be generated in a way that each generator "inserts"
its ID into each number, while not affecting the randomness (i.e.,
predictability) in any significant way.

I'm still thinking...;)

___tony___


Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15629 for ietf-pkix-bks; Wed, 25 Nov 1998 15:14:30 -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 PAA15624 for <[e-mail]>; Wed, 25 Nov 1998 15:14:24 -0800 (PST)
Received: 	id SAA03629; Wed, 25 Nov 1998 18:15:29 -0500
Received: by gateway id <XNGHB3RD>; Wed, 25 Nov 1998 18:10:44 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Warwick Ford'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 18:10:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Warwick,

:-----Original Message-----
:From: Warwick Ford [mailto:[e-mail]]
:Sent: Wednesday, November 25, 1998 9:36 AM
:To: '[e-mail]'; [e-mail]; [e-mail]
:Subject: RE: generation of private keys
:
:I think the case of a CA generating key pairs is the least 
:interesting of
:all.  Generally, for security separation purposes, it is 
:considered highly
:undesirable for a CA to generate user key pairs.  


The above sentence should probably be clarified because it is misleading as
it stands (which I'm sure was not your intention).  I prefer "Generally, for
security separation purposes, it is considered highly undesirable for a CA
to generate user key pairs when the CA is at 'arm's length' from the user.",
or something similar.  In particular, a CA that is external to an
organization (e.g., a CA service provider) may have nothing in its CPS
discussing such functionality and may take no legal responsibility for user
key pair generation.  This is a case where separation of duties makes sense.

However, for other environments the CA, the RA, and the key generation
facility may effectively be the same entity within an organization.
Separation of duties need not be required in such cases and there is no
reason for it to be "undesirable" for this entity to perform both key
generation and CA functions.


:Having the key pair
:generated by an RA or another "authority" devoted to key 
:management, maybe
:within the same enterprise, are better.  


Absolutely.  "Better" if the CA is outside the enterprise.  Not necessarily
"better" for any inherent reason if the CA is within the enterprise.


:In the case of an RA or other
:authority, there is generally an established trust 
:relationship between the
:CA and that entity, supported, for example, by their inherent 
:organizational
:relationship or by a contractual relationship, plus trusted 
:communications
:paths.  Hence, it is likely quite reasonable for a CA to have 
:confidence
:that, when an RA or key management authority says it generated 
:a particular
:key pair, it did, in fact, generate that key pair.
:
:Warwick


Does this, then, argue for Stefan's original suggestion of an extension
specifying the location of key generation?  Do you think that because of
such relationships, trusted communications paths, etc., the CA can have
sufficient confidence in the location to encode it into a certificate and
stand by it in a legal sense?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15426 for ietf-pkix-bks; Wed, 25 Nov 1998 14:43:25 -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 OAA15422 for <[e-mail]>; Wed, 25 Nov 1998 14:43:22 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2Q2YH>; Thu, 26 Nov 1998 09:46:23 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A5F@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, Andrew Probert <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Time stamp request
Date: Thu, 26 Nov 1998 09:46:07 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I was thing thinking Notary when I wrote my comment, and a combined
standard for both purposed, thanks for clarifying the context.


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA09247 for ietf-pkix-bks; Wed, 25 Nov 1998 08:21:09 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA09243 for <[e-mail]>; Wed, 25 Nov 1998 08:21:08 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1G49>; Wed, 25 Nov 1998 11:23:16 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9114@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Time stamp request
Date: Wed, 25 Nov 1998 11:23:15 -0500
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

We have built a TimeStamping Authority for a client of ours. This TSA
has been undergoing field trials and tests since June, 1998 and is now
relatively stable. I would like to share our experiences on the topic of
hash versus entire message.

We built the first version of our TSA by having the entire message sent
to the TSA. The TSA computed the hash of the message and created the
token and signed it. In looking at the problem more carefully, we
realized that sending the entire message has several drawbacks, e.g. the
bandwidth availability problem, and the liability problem for the TSA
since it now has a copy of the actual message, etc. In later versions of
our product, we are sending just the hash of the message to the TSA,
since it has all of the advantages, without many of the disadvantages,
of sending the entire message. 

In general, I would agree with Denis, Paul and Robert that there appears
to be no benefit to sending the entire message instead of an imprint of
the message. 

On the other hand, currently (in draft-ietf-pkix-time-stamp-00.txt), the
MessageImprint data structure seems to imply that only a cryptographic
hash of the message is permitted. However, it would be relatively easy
to accommodate other types of message imprints, including the actual
message (there is no better imprint of a message than the message
itself!!) and arithmetic checksums, etc. 

- Sarbari Gupta
=================================
Sarbari Gupta, PhD
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================
-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 9:33 AM
To: 'Denis Pinkas'; Carmen Garcia; 'Andrew Probert'
Cc: [e-mail]; [e-mail]
Subject: RE: Time stamp request


Andrew;

In your response to Denis you said:

> ----------
> From: 	Andrew Probert[SMTP:[e-mail]]
> Sent: 	Tuesday, November 24, 1998 5:53 PM
> To: 	'Denis Pinkas'; Carmen Garcia
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: 
> 
> This standard seems to be restricting capability based upon a
bandwidth
> assumption.  With the right business case, the bandwith may well be
> available?
> 
Actually, I don't think we are restricting capability based upon a
bandwidth
assumption.  I would like to draw your attention to something Denis
said.

> > Another advantage is that the TSA does not see the
> > content of the message and it cannot disclose the content to
anybody:
> > it places less trust in the TSA. For, at least,
> > theses reasons, the message itself is never sent to the TSA.
> 
And also to one of our assumptions in the TSA draft:

The TSA is required:
     3. not to examine the imprint being time stamped in any way. 

In order to distinguish between a Time Stamp Authority and a "notary"
(or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed
that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document
within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have
to
hash any message that is contained in the request, regardless of its
content
(because it cannot examine the message in any way) and place the
resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the
document.
This is not a problem, except for the fact that given just the document
and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used
to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was
unacceptable.
Therefore, we decided that the TSA would not create the message imprint,
the
requester would.  This allows the TSA to be totally unaware of what is
being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08089 for ietf-pkix-bks; Wed, 25 Nov 1998 07:04:38 -0800 (PST)
Received: from hq.ljl.COM (hq.ljl.com [206.151.234.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA08085 for <[e-mail]>; Wed, 25 Nov 1998 07:04:37 -0800 (PST)
Received: from larry.ljl.com by hq.ljl.COM. with smtp id aa09768; Wed, 25 Nov 1998 09:09:14 -0600
Received: by localhost with Microsoft MAPI; Wed, 25 Nov 1998 09:09:19 -0600
Message-ID: <[e-mail]>
From: Larry Layten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Stefan Kelm'" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 09:09:18 -0600
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

It would seem to me that if an RA is certifying information to
be contained in a certificate, to be signed by a CA, that policy
could be implemented that would also allow it to certify that
it did in fact create the key-pairs -- or to take it further, to 
certify the strength of the token that the subject is using,
which also should be of interest.

Larry

-----Original Message-----
From:	Stefan Kelm [SMTP:[e-mail]]
Sent:	Wednesday, November 25, 1998 3:57 AM
To:	[e-mail]; [e-mail]
Cc:	[e-mail]
Subject:	RE: generation of private keys

Tony,

> >Interesting question.  My initial reaction is to wonder if a new certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07753 for ietf-pkix-bks; Wed, 25 Nov 1998 06:38:35 -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 GAA07748 for <[e-mail]>; Wed, 25 Nov 1998 06:38:32 -0800 (PST)
Received: 	id JAA20928; Wed, 25 Nov 1998 09:38:00 -0500
Received: by gateway id <XNGHBLPK>; Wed, 25 Nov 1998 09:33:15 -0500
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>, "'Andrew Probert'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Time stamp request
Date: Wed, 25 Nov 1998 09:33:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Andrew;

In your response to Denis you said:

> ----------
> From: 	Andrew Probert[SMTP:[e-mail]]
> Sent: 	Tuesday, November 24, 1998 5:53 PM
> To: 	'Denis Pinkas'; Carmen Garcia
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: 
> 
> This standard seems to be restricting capability based upon a bandwidth
> assumption.  With the right business case, the bandwith may well be
> available?
> 
Actually, I don't think we are restricting capability based upon a bandwidth
assumption.  I would like to draw your attention to something Denis said.

> > Another advantage is that the TSA does not see the
> > content of the message and it cannot disclose the content to anybody:
> > it places less trust in the TSA. For, at least,
> > theses reasons, the message itself is never sent to the TSA.
> 
And also to one of our assumptions in the TSA draft:

The TSA is required:
     3. not to examine the imprint being time stamped in any way. 

In order to distinguish between a Time Stamp Authority and a "notary" (or
what we have called a Data Certification Server in our draft), we had to
make some assumptions about what the TSA can and can't do.  We assumed that
the TSA would not be allowed to examine at all what it is time stamping.

It is unreasonable to expect the TSA to include the entire document within
the time stamp token.  It will only include a hash (or equivalently, a
message imprint).  Given our assumption above, the TSA would then have to
hash any message that is contained in the request, regardless of its content
(because it cannot examine the message in any way) and place the resulting
imprint in the token.  However, if the request already contained just a
message imprint, the token would contain the hash of a hash of the document.
This is not a problem, except for the fact that given just the document and
the token one could not verify that the token applies to the document
without additional information identifying which hash function was used to
create the original imprint in the request.  Since we considered it
important that a token be self-contained, we thought this was unacceptable.
Therefore, we decided that the TSA would not create the message imprint, the
requester would.  This allows the TSA to be totally unaware of what is being
time stamped.  Plus, there are all the other advantages that Denis
mentioned.

	Robert Zuccherato.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07691 for ietf-pkix-bks; Wed, 25 Nov 1998 06:32:54 -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 GAA07687 for <[e-mail]>; Wed, 25 Nov 1998 06:32:53 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA07147; Wed, 25 Nov 1998 06:33:39 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id GAA15214; Wed, 25 Nov 1998 06:36:08 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <XQDLATJR>; Wed, 25 Nov 1998 06:36:11 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: generation of private keys
Date: Wed, 25 Nov 1998 06:36:07 -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

I think the case of a CA generating key pairs is the least interesting of
all.  Generally, for security separation purposes, it is considered highly
undesirable for a CA to generate user key pairs.  Having the key pair
generated by an RA or another "authority" devoted to key management, maybe
within the same enterprise, are better.  In the case of an RA or other
authority, there is generally an established trust relationship between the
CA and that entity, supported, for example, by their inherent organizational
relationship or by a contractual relationship, plus trusted communications
paths.  Hence, it is likely quite reasonable for a CA to have confidence
that, when an RA or key management authority says it generated a particular
key pair, it did, in fact, generate that key pair.

Warwick

-----Original Message-----
From: Stefan Kelm [mailto:[e-mail]]
Sent: Wednesday, November 25, 1998 1:57 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: generation of private keys


Tony,

> >Interesting question.  My initial reaction is to wonder if a new
certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who
did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

____________________________________________________________________________
__
Stefan Kelm            PGP key: "finger [e-mail]" or via key
server
DFN-PCA, University of Hamburg
<[e-mail]>
Vogt-Koelln-Str. 30
http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]
2241


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07589 for ietf-pkix-bks; Wed, 25 Nov 1998 06:22:17 -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 GAA07585 for <[e-mail]>; Wed, 25 Nov 1998 06:22:16 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfran28365; Wed, 25 Nov 1998 09:25:29 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26455; Wed, 25 Nov 98 09:23:15 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA12732; Wed, 25 Nov 1998 09:25:27 -0500
Date: Wed, 25 Nov 1998 09:25:27 -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], [e-mail]
Subject: RE: 
References: <C13ABC20EDDAD111B29E0000B456EABC053A57@SPRINGFIELD>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Andrew" == Andrew Probert <[e-mail]> writes:

 Andrew> This standard seems to be restricting capability based upon a
 Andrew> bandwidth assumption.  With the right business case, the
 Andrew> bandwith may well be available?

 >> -----Original Message----- From: Denis Pinkas
 >> 
 >> > Hi all, > > We are involved in a time stamp project.  > > We
 >> need to send a request for a timestamp to the Time Stamping
 >> Authority including in the request itself alternatively the hash
 >> value of the data or the entire document. 

I don't see the bandwidth argument as the primary argument.  Instead,
it seems that the main arguments are (a) there is no benefit to
sending the whole message, (b) it introduces extra risks, and yes also 
(c) it consumes extra bandwidth.

Having an option to use the extra bandwidth would be fine if there
were some benefit, but I can see no benefit at all, only extra danger, 
so why do it?

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA28984 for ietf-pkix-bks; Wed, 25 Nov 1998 01:53:59 -0800 (PST)
Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA28980 for <[e-mail]>; Wed, 25 Nov 1998 01:53:57 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id KAA19473; Wed, 25 Nov 1998 10:57:20 +0100 (MET)
Date: Wed, 25 Nov 1998 10:57:20 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: generation of private keys
Cc: [e-mail]
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk

Tony,

> >Interesting question.  My initial reaction is to wonder if a new certificate
> >extension is really the right solution for this.  If the CA generates the
> >key pair, it can certainly populate such an extension with confidence.
> >However, if the CA did not generate the key pair, how will it distinguish
> >between EE, RA, and "other" (i.e., how will it know (with certainty) who did
> >the actual key pair generation so that it can populate the extension)?
> >
> >Carlisle.
>
> It seems the most a CA could do is indicate either that it did, or did not
> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA23869 for ietf-pkix-bks; Tue, 24 Nov 1998 23:48:42 -0800 (PST)
Received: from mail.latinmail.com (smtp.latinmail.com [209.2.135.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA23863 for <[e-mail]>; Tue, 24 Nov 1998 23:48:41 -0800 (PST)
Message-Id: <[e-mail]>
Received: from latinmail.com [209.2.135.54] by mail.latinmail.com (SMTPD32-4.07) id A8152330150; Wed, 25 Nov 1998 02:56:05 EST
To: [e-mail]
From: Carmen Garcia <[e-mail]>
Date: Wed, 25 Nov 98 02:54:00 -0500
Subject: TimeStamp request
X-Mailer: LatinMail v3.0 -- http://www.latinmail.com
Sender: [e-mail]
Precedence: bulk

Hi all,

We are involved in a time stamp project. 
We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.

At this point we have two questions to propose you for discussion.

1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint OPTIONAL 
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message. If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way? 

Obviously the second point influences the format of the response described in the draft if we want
to receive in a unique response all the required timestamps.

Regards,

Carmen Garcia.

__________________________________________________
Carmen Garcia
Software Engineer
__________________________________________________






________________________________________________________
http://www.latinmail.com. Tu correo gratuito en español.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08946 for ietf-pkix-bks; Tue, 24 Nov 1998 14:50: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 OAA08941 for <[e-mail]>; Tue, 24 Nov 1998 14:50:43 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XFP2Q24C>; Wed, 25 Nov 1998 09:53:16 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A57@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Carmen Garcia <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: 
Date: Wed, 25 Nov 1998 09:53:08 +1100
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 OAA08943
Sender: [e-mail]
Precedence: bulk

This standard seems to be restricting capability based upon a bandwidth
assumption.  With the right business case, the bandwith may well be
available?

Why not have the MessageImprint as a PKCS#7 construct, in that way you
could service many options.

1)   SignedData with empty content (detached signature) would meet
current requirement
2)   SignedData with content would meet your request
3)   EnvelopedData sent in for timestamping would allow encrypted
content i.e. solving trust issue in TSA
3)a Specific encoding of PKCS#7 => SMIME payloads

Regards

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[e-mail]]
> Sent:	Wednesday, November 25, 1998 1:11 PM
> To:	Carmen Garcia
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: 
> 
> > Hi all,
> >
> > We are involved in a time stamp project.
> >
> > We need to send a request for a timestamp to the Time Stamping
> Authority including in the request itself alternatively the hash value
> of the data or the entire document.
> > Further we could ask for more than one timestamp, thus we need to
> put, in the same request, the number of required timestamps that the
> TSA should give back.
> >
> > At this point we have two questions to propose you for discussion.
> >
> > 1. In the time stamping request described into the draft "Internet
> X.509 Public Key Infrastructure Time Stamp Protocols" (at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt
> )....
> >
> > TimeStampReq ::= SEQUENCE  {
> >      version                      Integer  { v1(0) },
> >      reqPolicy                    PolicyInformation OPTIONAL,
> >      tdas                         SEQUENCE OF GeneralName OPTIONAL,
> >      nonce                        Integer,
> >      messageImprint               MessageImprint OPTIONAL
> >        --a hash algorithm OID and the hash value of the data to be
> >        --time stamped
> > }
> >
> > ....there is no reference to the possibility to send the ENTIRE
> DOCUMENT to be timestamped, instead of  the hash of the message.
> 
> This choice was deliberate. It saves bandwith, e.g. if the message is
> 2 Mbytes long, you do not send the whole message to the TSA, but only
> the imprint (160 or 128 bits). It also allows better performance for
> the Time Stamping server (responding to short messages improves
> performance). Another advantage is that the TSA does not see the
> content of the message and it cannot disclose the content to anybody:
> it places less trust in the TSA. For, at least,
> theses reasons, the message itself is never sent to the TSA.
> 
> > If we want to have the possibility to send the whole document into
> the request, how can be done? Can we include into the request another
> optional field in order to send the whole document? What kind of
> interoperability implications with others implementations could occur?
> Is this one the right way or are there other solutions?
> 
> See above.
> 
> > 2. As above, there is no a specific field to hold the NUMBER OF
> REQUESTED TIMESTAMPS. Can we work in the same way?
> >
> 
> You can send multiple such elementary requests in a single message:
> the transport layer is not mandated.
> 
> Regards,
> 
> Denis
> 
> 
> > Obviously the second point influences the format of the response
> described in the draft if we want
> > to receive in a unique response all the required timestamps.
> >
> > Regards,
> >
> > Carmen Garcia.
> >
> > _____________________________________________
> > Carmen Garcia
> > Software Engineer
> > _____________________________________________
> >
> > ________________________________________________________
> > http://www.latinmail.com. Tu correo gratuito en español.
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08541 for ietf-pkix-bks; Tue, 24 Nov 1998 13:53:16 -0800 (PST)
Received: from yafa.alquds.org (alquds.org [208.162.200.234] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08537 for <[e-mail]>; Tue, 24 Nov 1998 13:53:13 -0800 (PST)
Received: from localhost (adel@localhost) by yafa.alquds.org (8.8.5/8.8.5) with SMTP id PAA14398; Tue, 24 Nov 1998 15:42:01 -0600 (CST)
Date: Tue, 24 Nov 1998 15:42:00 -0600 (CST)
From: Adel Jaber <[e-mail]>
To: Adel Jaber <[e-mail]>
cc: [e-mail]
Subject: DSA Source Code
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Trying to obtain the source code for the DSA algorithm.

Will appreciate any pointers.

Regards

Adel Jaber



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08325 for ietf-pkix-bks; Tue, 24 Nov 1998 13:22:16 -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 NAA08320 for <[e-mail]>; Tue, 24 Nov 1998 13:22:15 -0800 (PST)
Received: 	id QAA27147; Tue, 24 Nov 1998 16:20:03 -0500
Received: by gateway id <XNGHB28Q>; Tue, 24 Nov 1998 16:15:19 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Adel Jaber'" <[e-mail]>
Subject: RE: x.509v3
Date: Tue, 24 Nov 1998 16:15:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The final text of the 1997 edition of X.509 can be found at:

ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

That is the latest approved standard.

There is an ongoing project that is defining a set of future enhancements
which you can find a pointer to in a message posted to this list by Hoyt
Kesterson yesterday.



> ----------
> From: 	Adel Jaber[SMTP:[e-mail]]
> Sent: 	November 24, 1998 2:49 PM
> To: 	[e-mail]
> Subject: 	x.509v3
> 
> 
> I need to download the latest ITU Recommendation X.509.
> I think it is on a Bull site but I am failing to locate
> it.
> 
> Can any body help?
> 
> Thanks
> 
> Adel Jaber
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07738 for ietf-pkix-bks; Tue, 24 Nov 1998 12:00:11 -0800 (PST)
Received: from yafa.alquds.org (alquds.org [208.162.200.234] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07734 for <[e-mail]>; Tue, 24 Nov 1998 12:00:10 -0800 (PST)
Received: from localhost (adel@localhost) by yafa.alquds.org (8.8.5/8.8.5) with SMTP id NAA14186 for <[e-mail]>; Tue, 24 Nov 1998 13:49:11 -0600 (CST)
Date: Tue, 24 Nov 1998 13:49:11 -0600 (CST)
From: Adel Jaber <[e-mail]>
To: [e-mail]
Subject: x.509v3
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I need to download the latest ITU Recommendation X.509.
I think it is on a Bull site but I am failing to locate
it.

Can any body help?

Thanks

Adel Jaber



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07152 for ietf-pkix-bks; Tue, 24 Nov 1998 10:41:12 -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 KAA07148 for <[e-mail]>; Tue, 24 Nov 1998 10:41:11 -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 KAA05903; Tue, 24 Nov 1998 10:45:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 24 Nov 1998 10:44:13 -0800
To: Carlisle Adams <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: generation of private keys
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:54 AM 11/24/98 -0500, Carlisle Adams wrote:
>Hi Stefan,
>> In a legal context (esp. the German Signature law) a relying 
>> party might want
>> to know who generated the key pair of another end entity 
>> before deciding to
>> enter a contractual relationship with this entity. One might 
>> place trust
>> in another subject's certificate based on that question so 
>> wouldn't it make
>> sense to specify an optional certificate extension that indicates who
>> performed the process of key generation (eg. EE, CA, RA, other)?

>Interesting question.  My initial reaction is to wonder if a new certificate
>extension is really the right solution for this.  If the CA generates the
>key pair, it can certainly populate such an extension with confidence.
>However, if the CA did not generate the key pair, how will it distinguish
>between EE, RA, and "other" (i.e., how will it know (with certainty) who did
>the actual key pair generation so that it can populate the extension)?
>
>Carlisle.

It seems the most a CA could do is indicate either that it did, or did not
generate the keypair, correct?

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06452 for ietf-pkix-bks; Tue, 24 Nov 1998 09:08:09 -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 JAA06441 for <[e-mail]>; Tue, 24 Nov 1998 09:08:05 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id SAA31715; Tue, 24 Nov 1998 18:10:29 +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 SAA27658; Tue, 24 Nov 1998 18:13:05 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 24 Nov 1998 18:11:20 -0800
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Carmen Garcia <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: 
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

> Hi all,
>
> We are involved in a time stamp project.
>
> We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
> Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.
>
> At this point we have two questions to propose you for discussion.
>
> 1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….
>
> TimeStampReq ::= SEQUENCE  {
>      version                      Integer  { v1(0) },
>      reqPolicy                    PolicyInformation OPTIONAL,
>      tdas                         SEQUENCE OF GeneralName OPTIONAL,
>      nonce                        Integer,
>      messageImprint               MessageImprint OPTIONAL
>        --a hash algorithm OID and the hash value of the data to be
>        --time stamped
> }
>
> ….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message.

This choice was deliberate. It saves bandwith, e.g. if the message is 2 Mbytes long, you do not send the whole message to the TSA, but only the imprint (160 or 128 bits). It also allows better performance for the Time Stamping server (responding to short messages improves performance). Another advantage is that the TSA does not see the content of the message and it cannot disclose the content to anybody: it places less trust in the TSA. For, at least,
theses reasons, the message itself is never sent to the TSA.

> If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

See above.

> 2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way?
>

You can send multiple such elementary requests in a single message: the transport layer is not mandated.

Regards,

Denis


> Obviously the second point influences the format of the response described in the draft if we want
> to receive in a unique response all the required timestamps.
>
> Regards,
>
> Carmen Garcia.
>
> _____________________________________________
> Carmen Garcia
> Software Engineer
> _____________________________________________
>
> ________________________________________________________
> http://www.latinmail.com. Tu correo gratuito en español.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06043 for ietf-pkix-bks; Tue, 24 Nov 1998 08:34:07 -0800 (PST)
Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06039 for <[e-mail]>; Tue, 24 Nov 1998 08:34:06 -0800 (PST)
Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2232.9) id <WY0KH7T2>; Tue, 24 Nov 1998 08:33:39 -0800
Message-ID: <[e-mail]>
From: "Grall, Cynthia" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: Minor confusion in PKIX part 1, section 7.3.3
Date: Tue, 24 Nov 1998 08:42:58 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

> The following paragraph seems to have two conflicting sentences:
> 
> 7.3.3  DSA Signature Keys
> 
> ...
> 
>    If the DSA algorithm parameters are absent from the subjectPublicKey-
>    Info AlgorithmIdentifier and the CA signed the subject certificate
>    using DSA, then the certificate issuer's DSA parameters apply to the
>    subject's DSA key.  If the DSA algorithm parameters are absent from
>    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>    subject certificate using a signature algorithm other than DSA, then
>    the subject's DSA parameters are distributed by other means.  If the
>    subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters
>    component and the CA signed the subject with a signature algorithm
>    other than DSA, then clients shall reject the certificate.
> 
> I understand the second sentence to mean if the CA cert. has a (for
> example) RSA key, and the EE cert. has a DSA key with no parameters,
> then the EE cert. is okay and I have to find the parameters somewhere
> else.  
> 
> The third sentence says if the CA cert. has (for example) a RSA key,
> and the EE cert. has a DSA key with no parameters, then I should reject
> the EE cert.
> 
> Is there something I'm missing here?  If these do conflict, which is the
> correct statement?
> 
> Cindy
> ----------
> Cindy Grall                       [e-mail]
> Network Associates, Inc.          phone: [phone]
> 3415 S. Sepulvida Blvd.           fax:   [phone]
> Los Angeles, California 90034


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05761 for ietf-pkix-bks; Tue, 24 Nov 1998 08:01:29 -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 IAA05757 for <[e-mail]>; Tue, 24 Nov 1998 08:01:25 -0800 (PST)
Received: 	id KAA04009; Tue, 24 Nov 1998 10:59:14 -0500
Received: by gateway id <XNGHBG0S>; Tue, 24 Nov 1998 10:54:28 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: generation of private keys
Date: Tue, 24 Nov 1998 10:54:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:[e-mail]]
> Sent: Tuesday, November 24, 1998 8:28 AM
> To: [e-mail]
> Subject: CMP: generation of private keys
> 
> 
> I do not want to start the discussions about key generation 
> again but the
> following paragraph from draft-ietf-pkix-ipki3cmp-08.txt 
> raises a question
> to me:
> 
> : 2.2.1.3 Location of key generation
> :
> : In this specification, "key generation" is regarded as occurring
> : wherever either the public or private component of a key pair first
> : occurs in a PKIMessage. Note that this does not preclude a 
> centralized
> : key generation service - the actual key pair MAY have been generated
> : elsewhere and transported to the end entity, RA, or CA using a
> : (proprietary or standardized) key generation 
> request/response protocol
> : (outside the scope of this specification).
> :
> : There are thus three possibilities for the location of "key
> : generation":  the end entity, an RA, or a CA.
> 
> In a legal context (esp. the German Signature law) a relying 
> party might want
> to know who generated the key pair of another end entity 
> before deciding to
> enter a contractual relationship with this entity. One might 
> place trust
> in another subject's certificate based on that question so 
> wouldn't it make
> sense to specify an optional certificate extension that indicates who
> performed the process of key generation (eg. EE, CA, RA, other)?
> 
> I don't think this is merely a policy/CPS issue since the CA might not
> address this issue in its policy. The German Signature law 
> profile, for
> example, in principle allows for the key material to be 
> generated by either
> the CA or the end entity (although the latter is very 
> unlikely to happen
> due to the technical requirements). So the relying party 
> wouldn't get an
> answer from reading the policy/CPS.
> 
> Comments?


Interesting question.  My initial reaction is to wonder if a new certificate
extension is really the right solution for this.  If the CA generates the
key pair, it can certainly populate such an extension with confidence.
However, if the CA did not generate the key pair, how will it distinguish
between EE, RA, and "other" (i.e., how will it know (with certainty) who did
the actual key pair generation so that it can populate the extension)?

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05469 for ietf-pkix-bks; Tue, 24 Nov 1998 07:18:54 -0800 (PST)
Received: from mail.latinmail.com (smtp.latinmail.com [209.2.135.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05464 for <[e-mail]>; Tue, 24 Nov 1998 07:18:53 -0800 (PST)
Message-Id: <[e-mail]>
Received: from latinmail.com [209.2.135.54] by mail.latinmail.com (SMTPD32-4.07) id A005DA0146; Tue, 24 Nov 1998 10:25:57 EST
To: [e-mail]
CC: [e-mail]
From: Carmen Garcia <[e-mail]>
Date: Tue, 24 Nov 98 10:23:55 -0500
X-Mailer: LatinMail v3.0 -- http://www.latinmail.com
Sender: [e-mail]
Precedence: bulk

Hi all,

We are involved in a time stamp project. 

We need to send a request for a timestamp to the Time Stamping Authority including in the request itself alternatively the hash value of the data or the entire document.
Further we could ask for more than one timestamp, thus we need to put, in the same request, the number of required timestamps that the TSA should give back.

At this point we have two questions to propose you for discussion.

1. In the time stamping request described into the draft "Internet X.509 Public Key Infrastructure Time Stamp Protocols" (at http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt )….

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint OPTIONAL 
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

….there is no reference to the possibility to send the ENTIRE DOCUMENT to be timestamped, instead of  the hash of the message. If we want to have the possibility to send the whole document into the request, how can be done? Can we include into the request another optional field in order to send the whole document? What kind of interoperability implications with others implementations could occur? Is this one the right way or are there other solutions?

2. As above, there is no a specific field to hold the NUMBER OF REQUESTED TIMESTAMPS. Can we work in the same way? 

Obviously the second point influences the format of the response described in the draft if we want
to receive in a unique response all the required timestamps.

Regards,

Carmen Garcia.

_____________________________________________
Carmen Garcia
Software Engineer
_____________________________________________




________________________________________________________
http://www.latinmail.com. Tu correo gratuito en español.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04610 for ietf-pkix-bks; Tue, 24 Nov 1998 05:24:28 -0800 (PST)
Received: from procert.cert.dfn.de ([e-mail] [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04603 for <[e-mail]>; Tue, 24 Nov 1998 05:23:43 -0800 (PST)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id OAA03230 for [e-mail]; Tue, 24 Nov 1998 14:27:37 +0100 (MET)
Date: Tue, 24 Nov 1998 14:27:37 +0100 (MET)
From: Stefan Kelm <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CMP: generation of private keys
Reply-To: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk

I do not want to start the discussions about key generation again but the
following paragraph from draft-ietf-pkix-ipki3cmp-08.txt raises a question
to me:

: 2.2.1.3 Location of key generation
:
: In this specification, "key generation" is regarded as occurring
: wherever either the public or private component of a key pair first
: occurs in a PKIMessage. Note that this does not preclude a centralized
: key generation service - the actual key pair MAY have been generated
: elsewhere and transported to the end entity, RA, or CA using a
: (proprietary or standardized) key generation request/response protocol
: (outside the scope of this specification).
:
: There are thus three possibilities for the location of "key
: generation":  the end entity, an RA, or a CA.

In a legal context (esp. the German Signature law) a relying party might want
to know who generated the key pair of another end entity before deciding to
enter a contractual relationship with this entity. One might place trust
in another subject's certificate based on that question so wouldn't it make
sense to specify an optional certificate extension that indicates who
performed the process of key generation (eg. EE, CA, RA, other)?

I don't think this is merely a policy/CPS issue since the CA might not
address this issue in its policy. The German Signature law profile, for
example, in principle allows for the key material to be generated by either
the CA or the end entity (although the latter is very unlikely to happen
due to the technical requirements). So the relying party wouldn't get an
answer from reading the policy/CPS.

Comments?

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [e-mail]" or via key server
DFN-PCA, University of Hamburg                               <[e-mail]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: [phone] / Fax: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06560 for ietf-pkix-bks; Mon, 23 Nov 1998 12:01:05 -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 MAA06556 for <[e-mail]>; Mon, 23 Nov 1998 12:01:03 -0800 (PST)
From: [e-mail]
Received: by us-mta1.ma02.bull.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997))  id 852566C5.006E1BEE ; Mon, 23 Nov 1998 15:02:41 -0500
X-Lotus-FromDomain: BULL
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1998 12:59:48 -0700
Subject: pdam registration of the certificate extensions document
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

hello

sharon boeyen, the editor of the certificate extensions document, has made
the revisions asked of her during the document review

i have seen no objection to registering the pdam for certificate
extensions. therefore i have sent it to the sc6 secretariat requesting she
begin the ballot as soon as possible. prior to doing so i have assigned
some object identifier values for new attributes, object classes, and
matching rules.

the revised text, CertificateExtensionsPDAM, is in .doc and .pdf format at
ftp://ftp.bull.com/pub/OSIdirectory/BeijingVancouver98Output

note that the ballot period will be 3 months and that we will resolve
comments at an editing meeting in orlando soon after the ballot close date.

i expect that this document will have comments from international liaison
organizations such as the ietf and tc68. i am the iso/iec directory liaison
to those organizations. ballot comments from international liaison
organizations should be sent to the sc6 secretariat, jean shildneck (
[e-mail]). to allow sufficient time for review before the editing
meeting, those comments should also be sent to [e-mail].
comments from organization with a country should be consolidated  by the
responsible organization for that country.

i want to thank sharon for quickly handling the comments brought up in the
review period.

     hoyt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13491 for ietf-pkix-bks; Fri, 20 Nov 1998 14:46:31 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13487 for <[e-mail]>; Fri, 20 Nov 1998 14:46:30 -0800 (PST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <XJR0VD36>; Fri, 20 Nov 1998 14:44:13 -0800
Message-ID: <39ADCF833E74D111A2D700805F1951EF056BA008@RED-MSG-06>
From: Brian LaMacchia <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Fri, 20 Nov 1998 14:44:10 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk

Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list, 
>taken from the thread on NT SP4 fixes:
> 
>>Does your end-entity cert have a basicConstraints extension in it?  When
we
>>have to pick a default certificate store for a particular cert we first
try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
 
I'm the author of the CryptoAPI-L message Peter's quoting here, so let me
give you my perspective on the basicConstraints question.  I agree with
Peter that the PKIX-1 position that BC SHOULD NOT be included in EE certs is
wrong.  If anything, I would expect PKIX to say BC SHOULD be included
(cA=FALSE, no pathLen of course) but not mandate it.  

For our products, the issue is primarily one of backward compatibility with
the universe of CA certificates in existence that do not contain a BC
extension (and there are plenty out there that do not.)  Since PKIX-1
mandates the presence of a critical BC extension in all CA certs, it's
certainly the case that in a world consisting of only PKIX-compliant CAs and
EEs I can distinguish between the two types of certs and not consider EE
certs during the path discovery process.  But that's not a reasonable
position for a product to take because there *are* certs in use that don't
meet this spec.  Lack of a BC extension in a cert cannot preclude that cert
from potentially being a CA cert.  It's the same situation as that we faced
with the introduction of extended key usage (EKU); lack of an EKU extension
implies "all" not "none".

My comment to the CryptoAPI list mixed together two specific instances when
determining whether a cert is an EE or a CA cert is important, which I
should explicitly separate.  First, of course, is path development and chain
validation policy, where I care about the universe of possible parent
certificates as I walk through the cert graph and overall pathLen
constraints in found paths.  Second, from a product perspective I may want
to be able to distinguish between EE and CA certs in the user interface when
presenting collections of certs to users.  Products may make distinctions in
how they store and present EE certs vs. CA certs.  Since I have to assume
that a cert w/o BC is a potential CA cert, I have to treat it that way in
the UI as well or I'll have inconsistent behavior.

I'm afraid I don't understand Tim's arguments (dealing with out-of-band
designation of an EE cert as acceptable as a cert issuer) as justification
for the current text.  Certainly any user can build his own trust policies
and designate any cert (self-signed root, intermediate CA or EE) as a
trusted root of cert paths.   But since that's a client-based policy
decision, I can do that anyway, even if the cert contains a basicConstraints
extension.  (I probably won't have any recourse against the issuer should
something go wrong, but that's my choice.)

As for our current/upcoming crop of products, we always include a BC
extension in certs we issue, EE or CA.  If a BC extension is present in a
cert we use and respect that information, whether or not it's marked
critical.  Lack of a BC extension implies the possibility that the cert
could be an old CA cert, and we therefore must consider that possibility.

Bottom line: we seem to be going out of our way here to break old CA certs.
That doesn't seem reasonable, especially when we jump through hoops in other
areas of the draft to explicitly grandfather old certs forward.

					--Brian LaMacchia
					  [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13269 for ietf-pkix-bks; Fri, 20 Nov 1998 14:02:09 -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 OAA13265 for <[e-mail]>; Fri, 20 Nov 1998 14:02:08 -0800 (PST)
Received: 	id RAA28476; Fri, 20 Nov 1998 17:02:50 -0500
Received: by gateway id <XFCQWMMB>; Fri, 20 Nov 1998 16:58:09 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: [e-mail], "'Tammy Carter'" <[e-mail]>
Subject: RE: Entrust certificate storage
Date: Fri, 20 Nov 1998 16:58:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Hi,

Entrust transfers the certificate and other signed objects within the LDAP
protocol using the binary DER encoding. It is also possible to configure the
Entrust software to use an ASCII representation of the DER encoding instead.
In this case, the ASCII encoding is applied after the DER encoding has been
rendered so that the DER encoding is preserved. The ASCII representation is
supported for interoperability with directory systems which do not support
binary attribute syntaxes. If you would like to follow-up further, let's
take the discussion off the list, since it is not a PKIX issue. Please feel
free to contact me directly.

-----------------------------------------
Chris Oliva
Entrust Technologies

[phone]
[e-mail]
http://www.entrust.com
-----------------------------------------

> ----------
> From: 	Tammy Carter[SMTP:[e-mail]]
> Sent: 	Friday, November 20, 1998 2:12 PM
> To: 	[e-mail]
> Subject: 	Entrust certificate storage
> 
> My understanding of X.509 is that certificates should be stored in an
> X.500 directory in their binary DER encoded format.  However, after
> talking with a person who has been using Entrust to store user
> certificates in the directory (in the userCertificate attribute), it
> appears that Entrust stores a user's certificates in some kind of ASCII
> translation of the DER encoding?  My source reports that a dump of what is
> actually being stored via LDAP is "{ASN1}..." followed by a translation of
> the hex into ASCII.  Apparently, Entrust also reads out any certificates
> stored in a binary DER encoding in the attribute, translates them to
> ASCII, and then writes them back to the directory.
> 
> Is my understanding of X.509 correct?  Is Entrust following some kind of
> standard?  Has anyone else noticed this behavior?
> 
> Tammy Green Carter
> [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12247 for ietf-pkix-bks; Fri, 20 Nov 1998 11:10:37 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA12243 for <[e-mail]>; Fri, 20 Nov 1998 11:10:36 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 20 Nov 1998 12:14:11 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 20 Nov 1998 12:12:25 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Subject: Entrust certificate storage
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 LAA12244
Sender: [e-mail]
Precedence: bulk

My understanding of X.509 is that certificates should be stored in an X.500 directory in their binary DER encoded format.  However, after talking with a person who has been using Entrust to store user certificates in the directory (in the userCertificate attribute), it appears that Entrust stores a user's certificates in some kind of ASCII translation of the DER encoding?  My source reports that a dump of what is actually being stored via LDAP is "{ASN1}..." followed by a translation of the hex into ASCII.  Apparently, Entrust also reads out any certificates stored in a binary DER encoding in the attribute, translates them to ASCII, and then writes them back to the directory.

Is my understanding of X.509 correct?  Is Entrust following some kind of standard?  Has anyone else noticed this behavior?

Tammy Green Carter
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09342 for ietf-pkix-bks; Fri, 20 Nov 1998 05:48:26 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09338 for <[e-mail]>; Fri, 20 Nov 1998 05:48:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA09487; Fri, 20 Nov 1998 08:52:25 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 19 Nov 1998 17:27:00 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

You are being inconsistent.  You said: " ... PKIX requires that CA certs
have a critical  basicConstraints extension present if the cert is a CA
cert ...". I agree.  So, where is PKIX's "take a guess at the CA status"?
If there is not a basicConstraints extension with the cA bit set to TRUE,
then the certificate belongs to a CA, otherwise it belongs to an EE.  No
guessing.

Russ


At 02:54 PM 11/19/98 +0000, Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list, 
>taken from the thread on NT SP4 fixes:
> 
>>Does your end-entity cert have a basicConstraints extension in it?  When we
>>have to pick a default certificate store for a particular cert we first try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
> 
>I'll repeat again my assertion that omitting basicConstraints from a cert
is a 
>very dangerous practice because it leaves the interpretation of the certs CA 
>status entirely to chance.  Users will use whatever the default for the 
>software is, and the default for a lot of software is exactly the opposite of 
>what is intended by PKIX.
> 
>[BTW the claim that leaving it out lets you use the cert as a CA cert if you 
> like is incorrect, since PKIX requires that CA certs have a critical 
> basicConstraints extension present if the cert is a CA cert, which should 
> exclude a cert without basicConstraints from acting as a CA if you follow
the 
> PKIX interpretation.  I guess the user could always override this (meaning 
> that interpretation of the cert is at the whim of the user), and who knows 
> how the various pieces of software out there at the moment will handle it].
> 
>To comment on the claim that users must have out-of-band verification of
CA's, 
>a few months ago a group of people ran a test using an ISP's web pages to see 
>how many people, when given an unknown CA cert, would accept it without 
>question.  As far as they could tell, *everyone* accepted it (some may have 
>accepted rejected it but connected to the following SSL'd page anyway despite 
>the warning about a bad signature on the server cert).  This means that using 
>the PKIX interpretation, any end entity can pass themselves off as a CA, and 
>it'll work close to 100% of the time.
> 
>When it comes to cert fingerprints, there are German banks who have gone so 
>far as to refuse to publish fingerprints because "it'll confuse the users" 
>(which for about 99.99% of users is probably correct).  This upset some 
>computer security types because it wouldn't allow out-of-band verification so 
>they took it up with the banks, who after escalating it up several levels
said 
>they wouldn't publish the fingerprints, end of story.  Again, this doesn't 
>bode well for PKIX's "take a guess at the CA status" interpretation.
>
>I guess I've now said my bit on this topic... I still think doing this is a 
>serious mistake, and reserve the right to dance around singing "I told you
so" 
>six months down the track :-).
> 
>Peter.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08535 for ietf-pkix-bks; Thu, 19 Nov 1998 15:53:51 -0800 (PST)
Received: from shell.tsoft.com ([e-mail] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08531 for <[e-mail]>; Thu, 19 Nov 1998 15:53:51 -0800 (PST)
Received: from [209.133.59.210] (briank.ppp.tsoft.com.59.133.209.in-addr.arpa [209.133.59.210] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id PAA21285; Thu, 19 Nov 1998 15:56:12 -0800 (PST)
X-Sender: briank@pop
Message-Id: <l03110721b27a6012fdff@[209.133.59.210]>
In-Reply-To:  <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Nov 1998 16:01:50 -0800
To: "Flanigan, Bill" <[e-mail]>
From: Brian Korver <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

At 3:57 PM -0500 11/19/98, Flanigan, Bill wrote:
>Not really.  Although it, of course, depends on the application (not the PKI
>per se), Basic Constraints, well, constrain EEs from acting as CAs; Key
>Usage bit set(s) indicate(s), well, key usage.  What would happen if an
>app's certs have BC = not used (or c=no), and KU = keyCertSign, cRLSign?
>Since every EE can now be its own CA, I'll let you guess!

Bill,

In theory, not what you think -- such a cert is malformed.

According to my copy of the amendments DAM (section 12.2.2.3 "Key usage
field"):

   The bits keyCertSign and cRLSign are for use in CA-certificates only,
   and if the basic constraints extension (see 12.4.2.1) is present in
   the same certificate the values in the subjectType field of that
   extension and in the key usage restriction shall not conflict.

So, according to X.509 law, "BC=not used" cannot legally appear with
"K=keyCertSign,cRLSign".


-brian
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06284 for ietf-pkix-bks; Thu, 19 Nov 1998 12:53:09 -0800 (PST)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06280 for <[e-mail]>; Thu, 19 Nov 1998 12:53:08 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <W0QG69VX>; Thu, 19 Nov 1998 15:57:50 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Brian Korver'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Thu, 19 Nov 1998 15:57:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Not really.  Although it, of course, depends on the application (not the PKI
per se), Basic Constraints, well, constrain EEs from acting as CAs; Key
Usage bit set(s) indicate(s), well, key usage.  What would happen if an
app's certs have BC = not used (or c=no), and KU = keyCertSign, cRLSign?
Since every EE can now be its own CA, I'll let you guess!

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  

> -----Original Message-----
> From:	Brian Korver [SMTP:[e-mail]]
> Sent:	Thursday, November 19, 1998 1:58 AM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Re: Problem with PKIX part 1 basicConstraints
> 
	[snip]

> Don't forget about the KeyUsage extention.  When this extention is
> present,
> the BasicConstraints extension is redundant in EE certifications.
> 
	[snip]

> -brian
> [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA05712 for ietf-pkix-bks; Thu, 19 Nov 1998 11:52: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 LAA05708 for <[e-mail]>; Thu, 19 Nov 1998 11:52:12 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA12700; Thu, 19 Nov 1998 11:53:14 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA25275; Thu, 19 Nov 1998 11:55:41 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 19 Nov 1998 11:55:40 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Aram,

The Authenticode CA's slipped my mind.  I'll let the list know when this
page has been updated.

Thanks!
Alex

Aram Perez wrote:
> 
> Hi Alex,
> 
> [snip]
> >
> >> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> >> certificates and Navigotor lists 6 Verisign certificates. Where are the
> >> fingerprints for those "extra" certificates?
> >
> >The rest of the CA certs you see are subordinate CA's signed by the one
> >of the VeriSign roots.  Applications should determine the
> >trustworthyness of these subordinate CA certs by "walking the chain" and
> >validating signatures up to one of these trusted root certs.
> 
> IE lists the following certs:
> 1) VeriSign Class 1 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
> (This one does not match any information from the URL).
> 2) VeriSign Class 2 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
> 3) VeriSign Commercial Software Publishers CA, Expires: Wed, Jan 7, 2004
> 4) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
> 5) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
> (This is is a duplicate, don't know why Microsoft would do that :(
> 6) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
> 7) VeriSign Individual Software Publishers CA, Expires: Wed, Jan 7, 2004
> 8) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
> (Another duplicate)
> 
> Navigator lists the following certs:
> 1) Verisign Class 1 Primary CA, Expires: Fri Dec 31, 1999 (This one matches
> except it states the cert is valid starting Mon Jan 29, 1996)
> 2) Verisign Class 1 Primary CA, Expires: Tue Jan 7, 2020 (This one matches
> except for 'Tue' not 'Mon' and it has a serial number which you do not list)
> 3) Verisign Class 2 Primary CA (similar to 1 above, also it appears that
> Navigator main list of certificates only shows the "main" name, but when you
> try to "Edit" the certificate, Navigator lets you chose one of two
> certificates with the same name).
> 4) Verisign Class 3 Primary CA
> 5) Verisign Class 4 Primary CA (Not listed on the URL)
> 6) Verisign/RSA Commercial CA (Not listed on the URL)
> 7) Verisign/RSA Secure Server CA
> 
> Regards,
> Aram


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA25035 for ietf-pkix-bks; Wed, 18 Nov 1998 22:50:39 -0800 (PST)
Received: from shell.tsoft.com ([e-mail] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA25030 for <[e-mail]>; Wed, 18 Nov 1998 22:50:37 -0800 (PST)
Received: from [209.133.59.210] (briank.ppp.tsoft.com.59.133.209.in-addr.arpa [209.133.59.210] (may be forged)) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id WAA17033; Wed, 18 Nov 1998 22:53:06 -0800 (PST)
X-Sender: briank@pop
Message-Id: <l03110704b279715f72d9@[209.133.59.210]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Nov 1998 22:57:44 -0800
To: [e-mail]
From: Brian Korver <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 2:54 PM +0000 11/19/98, Peter Gutmann wrote:
>I've just been forwarded the following message from the MS CryptoAPI list,
>taken from the thread on NT SP4 fixes:
>
>>Does your end-entity cert have a basicConstraints extension in it?  When we
>>have to pick a default certificate store for a particular cert we first try
>>to figure out whether we're looking at an EE or a CA cert.  If there's no
>>basicConstraints extension present then the cert could be either and we
>>default to treating the cert as a CA cert in this case.
>
>I'll repeat again my assertion that omitting basicConstraints from a cert
>is a
>very dangerous practice because it leaves the interpretation of the certs CA
>status entirely to chance.  Users will use whatever the default for the
>software is, and the default for a lot of software is exactly the opposite of
>what is intended by PKIX.
>
>[BTW the claim that leaving it out lets you use the cert as a CA cert if you
> like is incorrect, since PKIX requires that CA certs have a critical
> basicConstraints extension present if the cert is a CA cert, which should
> exclude a cert without basicConstraints from acting as a CA if you follow
>the
> PKIX interpretation.  I guess the user could always override this (meaning
> that interpretation of the cert is at the whim of the user), and who knows
> how the various pieces of software out there at the moment will handle it].
>
>To comment on the claim that users must have out-of-band verification of
>CA's,
>a few months ago a group of people ran a test using an ISP's web pages to see
>how many people, when given an unknown CA cert, would accept it without
>question.  As far as they could tell, *everyone* accepted it (some may have
>accepted rejected it but connected to the following SSL'd page anyway despite
>the warning about a bad signature on the server cert).  This means that using
>the PKIX interpretation, any end entity can pass themselves off as a CA, and
>it'll work close to 100% of the time.

Don't forget about the KeyUsage extention.  When this extention is present,
the BasicConstraints extension is redundant in EE certifications.


>
>When it comes to cert fingerprints, there are German banks who have gone so
>far as to refuse to publish fingerprints because "it'll confuse the users"
>(which for about 99.99% of users is probably correct).  This upset some
>computer security types because it wouldn't allow out-of-band verification so
>they took it up with the banks, who after escalating it up several levels
>said
>they wouldn't publish the fingerprints, end of story.  Again, this doesn't
>bode well for PKIX's "take a guess at the CA status" interpretation.
>
>I guess I've now said my bit on this topic... I still think doing this is a
>serious mistake, and reserve the right to dance around singing "I told you
>so"
>six months down the track :-).
>
>Peter.


-brian
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04913 for ietf-pkix-bks; Wed, 18 Nov 1998 17:50: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 RAA04909 for <[e-mail]>; Wed, 18 Nov 1998 17:50: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 OAA23083 for <[e-mail]>; Thu, 19 Nov 1998 14:54:11 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91144045125598>; Thu, 19 Nov 1998 14:54:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 19 Nov 1998 14:54:11 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've just been forwarded the following message from the MS CryptoAPI list, 
taken from the thread on NT SP4 fixes:
 
>Does your end-entity cert have a basicConstraints extension in it?  When we
>have to pick a default certificate store for a particular cert we first try
>to figure out whether we're looking at an EE or a CA cert.  If there's no
>basicConstraints extension present then the cert could be either and we
>default to treating the cert as a CA cert in this case.
 
I'll repeat again my assertion that omitting basicConstraints from a cert is a 
very dangerous practice because it leaves the interpretation of the certs CA 
status entirely to chance.  Users will use whatever the default for the 
software is, and the default for a lot of software is exactly the opposite of 
what is intended by PKIX.
 
[BTW the claim that leaving it out lets you use the cert as a CA cert if you 
 like is incorrect, since PKIX requires that CA certs have a critical 
 basicConstraints extension present if the cert is a CA cert, which should 
 exclude a cert without basicConstraints from acting as a CA if you follow the 
 PKIX interpretation.  I guess the user could always override this (meaning 
 that interpretation of the cert is at the whim of the user), and who knows 
 how the various pieces of software out there at the moment will handle it].
 
To comment on the claim that users must have out-of-band verification of CA's, 
a few months ago a group of people ran a test using an ISP's web pages to see 
how many people, when given an unknown CA cert, would accept it without 
question.  As far as they could tell, *everyone* accepted it (some may have 
accepted rejected it but connected to the following SSL'd page anyway despite 
the warning about a bad signature on the server cert).  This means that using 
the PKIX interpretation, any end entity can pass themselves off as a CA, and 
it'll work close to 100% of the time.
 
When it comes to cert fingerprints, there are German banks who have gone so 
far as to refuse to publish fingerprints because "it'll confuse the users" 
(which for about 99.99% of users is probably correct).  This upset some 
computer security types because it wouldn't allow out-of-band verification so 
they took it up with the banks, who after escalating it up several levels said 
they wouldn't publish the fingerprints, end of story.  Again, this doesn't 
bode well for PKIX's "take a guess at the CA status" interpretation.

I guess I've now said my bit on this topic... I still think doing this is a 
serious mistake, and reserve the right to dance around singing "I told you so" 
six months down the track :-).
 
Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03323 for ietf-pkix-bks; Wed, 18 Nov 1998 14:36:21 -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 OAA03319 for <[e-mail]>; Wed, 18 Nov 1998 14:36:14 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XDTQ826Y>; Thu, 19 Nov 1998 09:37:38 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A3F@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Aram Perez'" <[e-mail]>, Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Thu, 19 Nov 1998 09:37:36 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

As I recall, Verisign rolled out a new set of certs about 6 months ago
to superseed older certs from the IE3 era.

Rotek's TrustedNet Smart Card Enabled S/MIME Secure Email

WINS

"INTERACT 98  BEST INTERNET, INTRANET & EXTRANET SOLUTION"

See our Web Site for details

Rotek Consulting 
Melbourne, Australia 
[phone] 
[phone] (Fax) 
www.rotek.com.au 


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Aram Perez [SMTP:[e-mail]]
> Sent:	Thursday, November 19, 1998 3:58 AM
> To:	Alex Deacon
> Cc:	Tim Polk; [e-mail]; [e-mail]
> Subject:	Re: Problem with PKIX part 1 basicConstraints
> 
> Hi Alex,
> 
> Thanks for the URL. I had previously found it, but like I said it was
> "very
> hard". My questions to Verisign are:
> 
> 1) Why isn't there a link to the URL on your home page?
> 2) There are only 4 certificates listed on the page but IE lists 8
> Verisign
> certificates and Navigotor lists 6 Verisign certificates. Where are
> the
> fingerprints for those "extra" certificates?
> 
> Regards,
> Aram
> 
> P.S. Please say hello to Hoa Ly (I believe she still works for
> Verisign).
> 
> 
> >> I also find it ironic that it is
> >> very hard to find out Verisign's fingerprints from their Web site. 
> >
> >See https://www.verisign.com/repository/root.html fingerprints of
> >VeriSign's root certificates.
> >
> >Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03198 for ietf-pkix-bks; Wed, 18 Nov 1998 14:30:49 -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 OAA03194 for <[e-mail]>; Wed, 18 Nov 1998 14:30:45 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <XDTQ826S>; Thu, 19 Nov 1998 09:32:19 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A3E@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'David Sweigert'" <[e-mail]>, Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Thu, 19 Nov 1998 09:32:17 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In a former life (about a year ago), I went down this path and had
hardware crypto integrated to an NT / IIS3 server, to implement 128 bit
crypto.

The primary reason for this was for improving trust / key management.  

As it turned out, software based crypto in SSL is awfully fast (but a
bit variable depending on which vendor you get it from), so unless you
are careful you may end up implementing hardware decelleration.  The
approach we took was to have Server Private Key and Certs in hardware
board and the rest was done in software i.e. SHA1, RC4, MD5 et al.

I think your best bet for performance numbers will be with the vendors
of said crypto accelerator boards.    

Also, you could exchange emails with the guys of SSLEAY fame (Eric Young
and Tim Hudson) as they have trod these paths.


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	David Sweigert [SMTP:[e-mail]]
> Sent:	Wednesday, November 18, 1998 10:10 AM
> To:	Trevor Freeman; 'John Hughes'; [e-mail]
> Subject:	RE: LDAP Schema
> 
> 
> Has anyone in the group run across sources of information
> RE: use of digital certificates with Web SSL and the accompanying
> server performance problems and need for hardware accelerators ?
> 
> Dave Sweigert
>  
> 
> At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
> >Hi John,
> >The Exchange schema is not extensible so you cannot add these
> classes.
> >however, the mailbox objects do already have a UserCertificate
> attribute
> >and there is also a CertificateAuthority object in these schema which
> has
> >most of the required attributes such as CACertificate and
> >certificateRevocationList etc. If you open the directory in Raw mode
> you can
> >see these objects and all of their attributes. 
> >
> >Trevor
> >
> >
> >-----Original Message-----
> >From: John Hughes [mailto:[e-mail]]
> >Sent: Tuesday, November 17, 1998 6:38 AM
> >To: [e-mail]
> >Subject: LDAP Schema
> >
> >
> >Has any one tried to configure Exchange Directory Server 5.5 to
> support the
> >pkiUser and pkiCA object classes.  Is it possible?
> >
> >
> >John
> >
> >
> >
> > -------------------------------------------------------------------
> >| John Hughes             [e-mail]                 |
> >| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
> >|                         Home Fax No:           [phone]  |
> >|                         Main Office Tel:       [phone] |
> >| www.entegrity.com       Mobile:                [phone]   |
> > ------------------------------------------------------------------- 
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01941 for ietf-pkix-bks; Wed, 18 Nov 1998 12:20:21 -0800 (PST)
Received: from isis.wu-wien.ac.at (isis.wu-wien.ac.at [137.208.127.33]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01937 for <[e-mail]>; Wed, 18 Nov 1998 12:20:19 -0800 (PST)
Received: from wu-wien.ac.at (snoopy.wu-wien.ac.at [137.208.224.121]) by isis.wu-wien.ac.at (8.8.7/8.8.7) with ESMTP id VAA02798emf [e-mail]; Wed, 18 Nov 1998 21:23:37 +0100 (MEZ)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 21:23:46 +0100
From: Michael Fritscher <[e-mail]>
Reply-To: [e-mail]
Organization: WU-Wien
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alex Deacon <[e-mail]>
CC: Aram Perez <[e-mail]>, Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Alex Deacon wrote:
> 
> Aram Perez wrote:
> >
...
> 
> > 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> > certificates and Navigotor lists 6 Verisign certificates. Where are the
> > fingerprints for those "extra" certificates?
> 
> The rest of the CA certs you see are subordinate CA's signed by the one
> of the VeriSign roots.  Applications should determine the
> trustworthyness of these subordinate CA certs by "walking the chain" and
> validating signatures up to one of these trusted root certs.
> 

When I look at Netscape, this point is true for only one CA certificate of
Verisign. The others whoose Fingerprints are not on Verisign Website are also
self-signed certificates (as the "Class 4 Public Primary Certification
Authority" or the "Commercial Certification Authority").

Michael

--
-----------------------------------------------------------
| Michael Fritscher
| Department of Management Information Systems
| Vienna University of Economics And Business Administration
| mailto:[e-mail]
| http://wwwi.wu-wien.ac.at/finanz/
| "An APPLE a day keeps WINDOWS.95 away..."
------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01439 for ietf-pkix-bks; Wed, 18 Nov 1998 11:29:13 -0800 (PST)
Received: from atlas.arc.nasa.gov (atlas-ops.arc.nasa.gov [198.123.8.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01435 for <[e-mail]>; Wed, 18 Nov 1998 11:29:12 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-49-113.s113.tnt14.ann.erols.com [207.172.49.113]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with SMTP id LAA14332; Wed, 18 Nov 1998 11:33:00 -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: Wed, 18 Nov 1998 11:28:00 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I believe the PKIX text is correct.  Many implementations need to make
modification to align with PKIX Part 1.

Russ


> ----------
> From: 	Tim Polk[SMTP:[e-mail]]
> Sent: 	November 17, 1998 9:49 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: Problem with PKIX part 1 basicConstraints
> 
> Peter,
> 
> Both MSIE and Netscape are relying on the user's judgement: the user
> *must*
> have out-of-band information that the subject is a trustworthy CA, or
> they
> wouldn't install it as a site certificate, would they??? (If I could
> remember how to make a smiley face, I'd insert it here!)
> 
> The basicConstraints extension does not fix this problem, though.  If
> NIST
> used that extension (and marked it critical) in end entity
> certificates,
> that prevents me from using my NIST certificate to claim CA status.  I
> don't really need that for the browser scenario.  If I can generate
> new
> certs, I can generate my own.  When I generate my self-signed
> certificate I
> might as well include the basicConstraints extension. If I could get
> folks
> to accept it without that extension, they'll certainly accept with
> that
> extension.
> 
> Clearly, the safest choice would be to select a single trusted CA (or
> a
> very small number) as the beginning (end?) of all valid paths and only
> accept a subject as a CA if the basicConstraints extension is present.
> (That is, never accept a subject as CA based on out-of-band
> information.)
> User selected trust points are always fraught with danger.  The
> solutions
> are to improve the client software and educate the users, in my
> opinion.
> 
> How?  Now that's a tough question!
> 
> Tim
> 
> 
> At 01:08 PM 11/17/98, Peter Gutmann wrote:
> >Tim Polk <[e-mail]> wrote:
> >
> >>If the basic constraints extension is not present, certificate
> processing
> >>is consistent with v1 or v2 certificates.  If out-of-band
> information
> >>specifies the subject is a CA, it's a CA.  If out of band
> information is
> >>not available, the user of the certificate assumes the subject is
> NOT a
> >>CA.
> >
> >Assertion: If basicConstraints is not present, current software
> typically
> >           assumes the subject is a CA.
> >Proof: Create a self-signed certificate without basicConstraints,
> load it
> >       into MSIE or Netscape, and see what happens.
> >
> >>3) If an end entity wishes to accept a certificate without a
> >>basicConstraints extension as a CA certificate, it must rely on
> >>out-of-band information.  In this case, the responsibility lies on
> the
> >>certificate user and the source of the out-of-band information, not
> on
> >>the certificate issuer.  The certificate issuer attests to the
> binding of
> >>subject and key, not the subject's status as a CA.
> >
> >Both MSIE and Netscape treat self-signed certs without
> basicConstraits as 
> >CA's by default (in fact I don't know of any way to get them to *not*
> 
> >treat the cert owners as CA's).
> >
> >MSIE: "You have been offered a new site certificate to place in your
> list
> >       of trusted issuers..."
> >Netscape: "You are about to go through the process of accepting a
> >           certificate authority..."
> >
> >Leaving out the basicConstraints makes the assumption that relying
> parties
> >are using PKIX-compliant software, and that the software will DTRT
> when it
> >finds one of these certs.  I think this is leaving what could be a
> critical
> >security issue more or less to chance - all I need to do is find some
> >software which happens to not follow PKIX's implied behaviour and I
> can go
> >ahead and issue my own certs and let the entire world in the door.
> >
> >Peter.
> >
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00733 for ietf-pkix-bks; Wed, 18 Nov 1998 10:12:49 -0800 (PST)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00729 for <[e-mail]>; Wed, 18 Nov 1998 10:12:48 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA36110 for <[e-mail]>; Wed, 18 Nov 1998 10:02:12 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 18 Nov 1998 10:01:58 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id KAA62850; Wed, 18 Nov 1998 10:01:53 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Wed, 18 Nov 1998 10:01:56 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Alex,

[snip]
>
>> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
>> certificates and Navigotor lists 6 Verisign certificates. Where are the
>> fingerprints for those "extra" certificates?
>
>The rest of the CA certs you see are subordinate CA's signed by the one
>of the VeriSign roots.  Applications should determine the
>trustworthyness of these subordinate CA certs by "walking the chain" and
>validating signatures up to one of these trusted root certs.   

IE lists the following certs:
1) VeriSign Class 1 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
(This one does not match any information from the URL).
2) VeriSign Class 2 CA - Individual Subsriber, Expires: Sun Jun 27, 1999
3) VeriSign Commercial Software Publishers CA, Expires: Wed, Jan 7, 2004
4) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
5) VeriSign Commercial Software Publishers CA, Expires: Fri, Dec 31, 1999
(This is is a duplicate, don't know why Microsoft would do that :(
6) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
7) VeriSign Individual Software Publishers CA, Expires: Wed, Jan 7, 2004
8) VeriSign Individual Software Publishers CA, Expires: Fri, Dec 31, 1999
(Another duplicate)

Navigator lists the following certs:
1) Verisign Class 1 Primary CA, Expires: Fri Dec 31, 1999 (This one matches
except it states the cert is valid starting Mon Jan 29, 1996)
2) Verisign Class 1 Primary CA, Expires: Tue Jan 7, 2020 (This one matches
except for 'Tue' not 'Mon' and it has a serial number which you do not list)
3) Verisign Class 2 Primary CA (similar to 1 above, also it appears that
Navigator main list of certificates only shows the "main" name, but when you
try to "Edit" the certificate, Navigator lets you chose one of two
certificates with the same name).
4) Verisign Class 3 Primary CA
5) Verisign Class 4 Primary CA (Not listed on the URL)
6) Verisign/RSA Commercial CA (Not listed on the URL)
7) Verisign/RSA Secure Server CA

Regards,
Aram



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00243 for ietf-pkix-bks; Wed, 18 Nov 1998 09:15:48 -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 JAA00239 for <[e-mail]>; Wed, 18 Nov 1998 09:15:47 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA10560; Wed, 18 Nov 1998 09:16:44 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA22212; Wed, 18 Nov 1998 09:19:11 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 09:19:12 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Aram Perez wrote:
> 
> Hi Alex,
> 
> Thanks for the URL. I had previously found it, but like I said it was "very
> hard". My questions to Verisign are:
> 
> 1) Why isn't there a link to the URL on your home page?

I agree that it is not easy to find.  I'll forward this issue to our web
people.

> 2) There are only 4 certificates listed on the page but IE lists 8 Verisign
> certificates and Navigotor lists 6 Verisign certificates. Where are the
> fingerprints for those "extra" certificates?

The rest of the CA certs you see are subordinate CA's signed by the one
of the VeriSign roots.  Applications should determine the
trustworthyness of these subordinate CA certs by "walking the chain" and
validating signatures up to one of these trusted root certs.   

Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29981 for ietf-pkix-bks; Wed, 18 Nov 1998 08:58:14 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29977 for <[e-mail]>; Wed, 18 Nov 1998 08:58:13 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id IAA35264 for <[e-mail]>; Wed, 18 Nov 1998 08:58:17 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Wed, 18 Nov 1998 08:58:06 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id IAA62940; Wed, 18 Nov 1998 08:58:00 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Wed, 18 Nov 1998 08:58:04 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Alex Deacon <[e-mail]>
Cc: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Alex,

Thanks for the URL. I had previously found it, but like I said it was "very
hard". My questions to Verisign are:

1) Why isn't there a link to the URL on your home page?
2) There are only 4 certificates listed on the page but IE lists 8 Verisign
certificates and Navigotor lists 6 Verisign certificates. Where are the
fingerprints for those "extra" certificates?

Regards,
Aram

P.S. Please say hello to Hoa Ly (I believe she still works for Verisign).


>> I also find it ironic that it is
>> very hard to find out Verisign's fingerprints from their Web site. 
>
>See https://www.verisign.com/repository/root.html fingerprints of
>VeriSign's root certificates.
>
>Alex



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29545 for ietf-pkix-bks; Wed, 18 Nov 1998 08:26:57 -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 IAA29541 for <[e-mail]>; Wed, 18 Nov 1998 08:26:56 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA09116; Wed, 18 Nov 1998 08:27:53 -0800 (PST)
Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA19162; Wed, 18 Nov 1998 08:30:18 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 08:30:20 -0800
From: Alex Deacon <[e-mail]>
Organization: VeriSign, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Aram Perez <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> I also find it ironic that it is
> very hard to find out Verisign's fingerprints from their Web site. 

See https://www.verisign.com/repository/root.html fingerprints of
VeriSign's root certificates.

Alex


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28618 for ietf-pkix-bks; Wed, 18 Nov 1998 07:18:50 -0800 (PST)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28614 for <[e-mail]>; Wed, 18 Nov 1998 07:18:45 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <W0QG6BRX>; Wed, 18 Nov 1998 10:23:13 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'David Sweigert'" <[e-mail]>, Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Wed, 18 Nov 1998 10:23:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yes we have.  But the list is long and constantly changing (mostly due to
newly discovered problems--found another one just this morning!).  Sorry,
but I don't have the time right now to go into all this on the list.  Maybe
we can sit down and chat a bit in Orlando.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	David Sweigert [SMTP:[e-mail]]
> Sent:	Tuesday, November 17, 1998 6:10 PM
> To:	Trevor Freeman; 'John Hughes'; [e-mail]
> Subject:	RE: LDAP Schema
> 
> 
> Has anyone in the group run across sources of information
> RE: use of digital certificates with Web SSL and the accompanying
> server performance problems and need for hardware accelerators ?
> 
> Dave Sweigert
>  
> 
> At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
> >Hi John,
> >The Exchange schema is not extensible so you cannot add these classes.
> >however, the mailbox objects do already have a UserCertificate attribute
> >and there is also a CertificateAuthority object in these schema which has
> >most of the required attributes such as CACertificate and
> >certificateRevocationList etc. If you open the directory in Raw mode you
> can
> >see these objects and all of their attributes. 
> >
> >Trevor
> >
> >
> >-----Original Message-----
> >From: John Hughes [mailto:[e-mail]]
> >Sent: Tuesday, November 17, 1998 6:38 AM
> >To: [e-mail]
> >Subject: LDAP Schema
> >
> >
> >Has any one tried to configure Exchange Directory Server 5.5 to support
> the
> >pkiUser and pkiCA object classes.  Is it possible?
> >
> >
> >John
> >
> >
> >
> > -------------------------------------------------------------------
> >| John Hughes             [e-mail]                 |
> >| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
> >|                         Home Fax No:           [phone]  |
> >|                         Main Office Tel:       [phone] |
> >| www.entegrity.com       Mobile:                [phone]   |
> > ------------------------------------------------------------------- 
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA25632 for ietf-pkix-bks; Wed, 18 Nov 1998 04:49:35 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA25628 for <[e-mail]>; Wed, 18 Nov 1998 04:49:34 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id HAA31427 for <[e-mail]>; Wed, 18 Nov 1998 07:53:23 -0500
Message-Id: <4.1.19981118073654.00a50ea0@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 18 Nov 1998 07:46:55 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Can we now kill CMMF?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In describing the new version of the CMC document, Michael Myers wrote that
version 2

>2. Reduces the need for readers to refer to multiple documents by replacing
>references to CMMF with direct specification of functional equivalents.
>

So - I suggest that we now kill the CMMF document, as it serves no useful
purpose.

Approximately one year ago, at the Washington IETF, it was announced that
the CRMF and CMMF documents would be developed to contain the message
formats  to be used by cert management protocols.  This was one of the
resolutions to the CMP vs. then-CRS (now CMC) issue.  It was stated that
the best way to proceed was to specify the common message formats first,
and then let any protocol you wanted to use reference those formats.

Now, however, we find that all of the formats defined in CMMF are
explicitly contained in both CMP and CMC.  Thus, the message format
definitions in CMMF are redundant, and that document serves no apparent
purpose.  (Unless, of course, you want to allow for the possibility that
somebody will develop a third protocol for certificate management, and use
those formats, but I really hope that nobody gets that bright idea.)

So, given this, can we now just let the current CMMF draft expire, and not
do any further work on it?  

(Warning:  hidden agenda alert:  I'm also going to propose down the road
that we take the CRMF definition, put it in CMP and CMC, and let the CRMF
I-D die.  I've never understood why, other than timing concerns, that
occupied a whole different document.)

Comments, dissenting opinions, etc., are welcome.

				Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA03629 for ietf-pkix-bks; Tue, 17 Nov 1998 13:14:20 -0800 (PST)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03625 for <[e-mail]>; Tue, 17 Nov 1998 13:14:19 -0800 (PST)
Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id NAA28918 for <[e-mail]>; Tue, 17 Nov 1998 13:06:27 -0800
Received: from scv4.apple.com (scv4.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 17 Nov 1998 13:06:14 -0800
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id NAA34174; Tue, 17 Nov 1998 13:06:09 -0800
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.02 (298) 
Date: Tue, 17 Nov 1998 13:06:11 -0800
Subject: Re: Problem with PKIX part 1 basicConstraints
From: "Aram Perez" <[e-mail]>
To: Tim Polk <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Another soapbox sermon ;-)

[Stand on soapbox]
PKI is a "key management solution" that greatly eases the key management
problems associated with cryptography but it does not eliminate all of them.
Symmetric cryptography, when using good key management principles (i.e. only
two parties share the same symmetric key), has the inherent problem that the
number of keys needed for a given set of parties grows geometrically. For
example, two parties need 1 key, three parties need 3 keys, four parties
need 6 keys, five parties need 10 keys, etc. Another problem is that a key
has to be manually exchanged, usually by some sort of face-to-face contact
or via a trusted third party (or parties).

When Diffie-Hellman first proposed public key encryption, the idea was that
an individual could "publish" his/her public key (after all, it is "public")
so that it would solve the manual key distribution problem. First, a party
only needs a public key pair (for key exchange) no matter how many parties
are involved. And it would no longer be necessary to have a face-to-face key
exchange since two parties could use each other's public keys to exchange a
symmetric key. Well in theory this works fine but not in practice. Why,
because if both parties are communicating purely electronically, how do they
know that they received the correct public key for the other party and not
the public key from a "man-in-the-middle"?

Well, we being engineers, came up with an easy solution, we created
"certificate authorities" (CAs) which sign public keys so that the keys can
be "trusted". So now a party receiving a public key (in a certificate) can
verify the key by following the chain (or web) of signers to the the CA.
This still leaves the problem of how do you know that the CAs public key
(i.e. the root certificate) is valid and therefore "trusted". I maintain
that the only way of trusting a root certificate is via some sort of manual
(i.e. out-of-band) method. There is no purely electronic way of verifying
root certificates. But I would rather manually verify a "handful" of root
certificates than a large number of public and/or symmetric keys.

Most people who download a browser that comes with root certificates
(whether IE, Navigator or whichever) do not know that they should "manually"
verify the root certificates by checking "fingerprints". If I download IE
from a non-Microsoft site, how do I know that the root certificates have not
been modified (or a bogus one inserted)? I also find it ironic that it is
very hard to find out Verisign's fingerprints from their Web site. Ditto for
GTE CyberTrust.

In conclusion (before the tomatoes start flying ;-), whether you have an
extension or not, you need to manually verify root certificates with some
out-of-band information. And like Tim wrote: "The solutions are to improve
the client software and educate the users". (But the how is not easy.)

[Get down from soapbox]

Regards,
Aram Perez


>Peter,
>
>Both MSIE and Netscape are relying on the user's judgement: the user *must*
>have out-of-band information that the subject is a trustworthy CA, or they
>wouldn't install it as a site certificate, would they??? (If I could
>remember how to make a smiley face, I'd insert it here!)
>
>The basicConstraints extension does not fix this problem, though.  If NIST
>used that extension (and marked it critical) in end entity certificates,
>that prevents me from using my NIST certificate to claim CA status.  I
>don't really need that for the browser scenario.  If I can generate new
>certs, I can generate my own.  When I generate my self-signed certificate I
>might as well include the basicConstraints extension. If I could get folks
>to accept it without that extension, they'll certainly accept with that
>extension.
>
>Clearly, the safest choice would be to select a single trusted CA (or a
>very small number) as the beginning (end?) of all valid paths and only
>accept a subject as a CA if the basicConstraints extension is present.
>(That is, never accept a subject as CA based on out-of-band information.)
>User selected trust points are always fraught with danger.  The solutions
>are to improve the client software and educate the users, in my opinion.
>
>How?  Now that's a tough question!
>
>Tim
>
>
>At 01:08 PM 11/17/98, Peter Gutmann wrote:
>>Tim Polk <[e-mail]> wrote:
>>
>>>If the basic constraints extension is not present, certificate processing
>>>is consistent with v1 or v2 certificates.  If out-of-band information
>>>specifies the subject is a CA, it's a CA.  If out of band information is
>>>not available, the user of the certificate assumes the subject is NOT a
>>>CA.
>>
>>Assertion: If basicConstraints is not present, current software typically
>>           assumes the subject is a CA.
>>Proof: Create a self-signed certificate without basicConstraints, load it
>>       into MSIE or Netscape, and see what happens.
>>
>>>3) If an end entity wishes to accept a certificate without a
>>>basicConstraints extension as a CA certificate, it must rely on
>>>out-of-band information.  In this case, the responsibility lies on the
>>>certificate user and the source of the out-of-band information, not on
>>>the certificate issuer.  The certificate issuer attests to the binding of
>>>subject and key, not the subject's status as a CA.
>>
>>Both MSIE and Netscape treat self-signed certs without basicConstraits as 
>>CA's by default (in fact I don't know of any way to get them to *not* 
>>treat the cert owners as CA's).
>>
>>MSIE: "You have been offered a new site certificate to place in your list
>>       of trusted issuers..."
>>Netscape: "You are about to go through the process of accepting a
>>           certificate authority..."
>>
>>Leaving out the basicConstraints makes the assumption that relying parties
>>are using PKIX-compliant software, and that the software will DTRT when it
>>finds one of these certs.  I think this is leaving what could be a critical
>>security issue more or less to chance - all I need to do is find some
>>software which happens to not follow PKIX's implied behaviour and I can go
>>ahead and issue my own certs and let the entire world in the door.
>>
>>Peter.
>>
>>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00618 for ietf-pkix-bks; Tue, 17 Nov 1998 15:10:53 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA00614 for <[e-mail]>; Tue, 17 Nov 1998 15:10:52 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa19579; 17 Nov 98 18:12 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 17 Nov 1998 18:10:27 -0500
To: Trevor Freeman <[e-mail]>, "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
From: David Sweigert <[e-mail]>
Subject: RE: LDAP Schema
In-Reply-To: <2F2DC5CE035DD1118C8E00805FFE354C0509BB1E@RED-MSG-56>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Has anyone in the group run across sources of information
RE: use of digital certificates with Web SSL and the accompanying
server performance problems and need for hardware accelerators ?

Dave Sweigert
 

At 10:21 AM 11/17/98 -0800, Trevor Freeman wrote:
>Hi John,
>The Exchange schema is not extensible so you cannot add these classes.
>however, the mailbox objects do already have a UserCertificate attribute
>and there is also a CertificateAuthority object in these schema which has
>most of the required attributes such as CACertificate and
>certificateRevocationList etc. If you open the directory in Raw mode you can
>see these objects and all of their attributes. 
>
>Trevor
>
>
>-----Original Message-----
>From: John Hughes [mailto:[e-mail]]
>Sent: Tuesday, November 17, 1998 6:38 AM
>To: [e-mail]
>Subject: LDAP Schema
>
>
>Has any one tried to configure Exchange Directory Server 5.5 to support the
>pkiUser and pkiCA object classes.  Is it possible?
>
>
>John
>
>
>
> -------------------------------------------------------------------
>| John Hughes             [e-mail]                 |
>| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
>|                         Home Fax No:           [phone]  |
>|                         Main Office Tel:       [phone] |
>| www.entegrity.com       Mobile:                [phone]   |
> ------------------------------------------------------------------- 
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02532 for ietf-pkix-bks; Tue, 17 Nov 1998 11:03:23 -0800 (PST)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02528 for <[e-mail]>; Tue, 17 Nov 1998 11:03:22 -0800 (PST)
Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id <XC3N7WGP>; Tue, 17 Nov 1998 10:21:13 -0800
Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0509BB1E@RED-MSG-56>
From: Trevor Freeman <[e-mail]>
To: "'John Hughes'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: LDAP Schema
Date: Tue, 17 Nov 1998 10:21:05 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: [e-mail]
Precedence: bulk

Hi John,
The Exchange schema is not extensible so you cannot add these classes.
however, the mailbox objects do already have a UserCertificate attribute
and there is also a CertificateAuthority object in these schema which has
most of the required attributes such as CACertificate and
certificateRevocationList etc. If you open the directory in Raw mode you can
see these objects and all of their attributes. 

Trevor


-----Original Message-----
From: John Hughes [mailto:[e-mail]]
Sent: Tuesday, November 17, 1998 6:38 AM
To: [e-mail]
Subject: LDAP Schema


Has any one tried to configure Exchange Directory Server 5.5 to support the
pkiUser and pkiCA object classes.  Is it possible?


John



 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01443 for ietf-pkix-bks; Tue, 17 Nov 1998 08:57:55 -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 IAA01439 for <[e-mail]>; Tue, 17 Nov 1998 08:57:54 -0800 (PST)
Received: 	id LAA06061; Tue, 17 Nov 1998 11:52:24 -0500
Received: by gateway id <W59RVZJ5>; Tue, 17 Nov 1998 11:49:20 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], [e-mail], "'Tim Polk'" <[e-mail]>
Subject: RE: Problem with PKIX part 1 basicConstraints
Date: Tue, 17 Nov 1998 11:47:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I believe the PKIX text is correct the way it is. It is consistent with
X.509 and takes it one step further. I don't think any change is
warranted here.

> ----------
> From: 	Tim Polk[SMTP:[e-mail]]
> Sent: 	November 17, 1998 9:49 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: Problem with PKIX part 1 basicConstraints
> 
> Peter,
> 
> Both MSIE and Netscape are relying on the user's judgement: the user
> *must*
> have out-of-band information that the subject is a trustworthy CA, or
> they
> wouldn't install it as a site certificate, would they??? (If I could
> remember how to make a smiley face, I'd insert it here!)
> 
> The basicConstraints extension does not fix this problem, though.  If
> NIST
> used that extension (and marked it critical) in end entity
> certificates,
> that prevents me from using my NIST certificate to claim CA status.  I
> don't really need that for the browser scenario.  If I can generate
> new
> certs, I can generate my own.  When I generate my self-signed
> certificate I
> might as well include the basicConstraints extension. If I could get
> folks
> to accept it without that extension, they'll certainly accept with
> that
> extension.
> 
> Clearly, the safest choice would be to select a single trusted CA (or
> a
> very small number) as the beginning (end?) of all valid paths and only
> accept a subject as a CA if the basicConstraints extension is present.
> (That is, never accept a subject as CA based on out-of-band
> information.)
> User selected trust points are always fraught with danger.  The
> solutions
> are to improve the client software and educate the users, in my
> opinion.
> 
> How?  Now that's a tough question!
> 
> Tim
> 
> 
> At 01:08 PM 11/17/98, Peter Gutmann wrote:
> >Tim Polk <[e-mail]> wrote:
> >
> >>If the basic constraints extension is not present, certificate
> processing
> >>is consistent with v1 or v2 certificates.  If out-of-band
> information
> >>specifies the subject is a CA, it's a CA.  If out of band
> information is
> >>not available, the user of the certificate assumes the subject is
> NOT a
> >>CA.
> >
> >Assertion: If basicConstraints is not present, current software
> typically
> >           assumes the subject is a CA.
> >Proof: Create a self-signed certificate without basicConstraints,
> load it
> >       into MSIE or Netscape, and see what happens.
> >
> >>3) If an end entity wishes to accept a certificate without a
> >>basicConstraints extension as a CA certificate, it must rely on
> >>out-of-band information.  In this case, the responsibility lies on
> the
> >>certificate user and the source of the out-of-band information, not
> on
> >>the certificate issuer.  The certificate issuer attests to the
> binding of
> >>subject and key, not the subject's status as a CA.
> >
> >Both MSIE and Netscape treat self-signed certs without
> basicConstraits as 
> >CA's by default (in fact I don't know of any way to get them to *not*
> 
> >treat the cert owners as CA's).
> >
> >MSIE: "You have been offered a new site certificate to place in your
> list
> >       of trusted issuers..."
> >Netscape: "You are about to go through the process of accepting a
> >           certificate authority..."
> >
> >Leaving out the basicConstraints makes the assumption that relying
> parties
> >are using PKIX-compliant software, and that the software will DTRT
> when it
> >finds one of these certs.  I think this is leaving what could be a
> critical
> >security issue more or less to chance - all I need to do is find some
> >software which happens to not follow PKIX's implied behaviour and I
> can go
> >ahead and issue my own certs and let the entire world in the door.
> >
> >Peter.
> >
> >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00602 for ietf-pkix-bks; Tue, 17 Nov 1998 06:50:18 -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 GAA00598 for <[e-mail]>; Tue, 17 Nov 1998 06:50:16 -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 JAA16729; Tue, 17 Nov 1998 09:47:03 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Tue, 17 Nov 1998 09:49:13 -0500
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter,

Both MSIE and Netscape are relying on the user's judgement: the user *must*
have out-of-band information that the subject is a trustworthy CA, or they
wouldn't install it as a site certificate, would they??? (If I could
remember how to make a smiley face, I'd insert it here!)

The basicConstraints extension does not fix this problem, though.  If NIST
used that extension (and marked it critical) in end entity certificates,
that prevents me from using my NIST certificate to claim CA status.  I
don't really need that for the browser scenario.  If I can generate new
certs, I can generate my own.  When I generate my self-signed certificate I
might as well include the basicConstraints extension. If I could get folks
to accept it without that extension, they'll certainly accept with that
extension.

Clearly, the safest choice would be to select a single trusted CA (or a
very small number) as the beginning (end?) of all valid paths and only
accept a subject as a CA if the basicConstraints extension is present.
(That is, never accept a subject as CA based on out-of-band information.)
User selected trust points are always fraught with danger.  The solutions
are to improve the client software and educate the users, in my opinion.

How?  Now that's a tough question!

Tim


At 01:08 PM 11/17/98, Peter Gutmann wrote:
>Tim Polk <[e-mail]> wrote:
>
>>If the basic constraints extension is not present, certificate processing
>>is consistent with v1 or v2 certificates.  If out-of-band information
>>specifies the subject is a CA, it's a CA.  If out of band information is
>>not available, the user of the certificate assumes the subject is NOT a
>>CA.
>
>Assertion: If basicConstraints is not present, current software typically
>           assumes the subject is a CA.
>Proof: Create a self-signed certificate without basicConstraints, load it
>       into MSIE or Netscape, and see what happens.
>
>>3) If an end entity wishes to accept a certificate without a
>>basicConstraints extension as a CA certificate, it must rely on
>>out-of-band information.  In this case, the responsibility lies on the
>>certificate user and the source of the out-of-band information, not on
>>the certificate issuer.  The certificate issuer attests to the binding of
>>subject and key, not the subject's status as a CA.
>
>Both MSIE and Netscape treat self-signed certs without basicConstraits as 
>CA's by default (in fact I don't know of any way to get them to *not* 
>treat the cert owners as CA's).
>
>MSIE: "You have been offered a new site certificate to place in your list
>       of trusted issuers..."
>Netscape: "You are about to go through the process of accepting a
>           certificate authority..."
>
>Leaving out the basicConstraints makes the assumption that relying parties
>are using PKIX-compliant software, and that the software will DTRT when it
>finds one of these certs.  I think this is leaving what could be a critical
>security issue more or less to chance - all I need to do is find some
>software which happens to not follow PKIX's implied behaviour and I can go
>ahead and issue my own certs and let the entire world in the door.
>
>Peter.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00449 for ietf-pkix-bks; Tue, 17 Nov 1998 06:32:11 -0800 (PST)
Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA00445 for <[e-mail]>; Tue, 17 Nov 1998 06:32:10 -0800 (PST)
Received: from m5pqp [195.99.52.123]  by neodymium.btinternet.com with smtp (Exim 1.70 #1) id 0zfmCo-0003ir-00; Tue, 17 Nov 1998 14:34:11 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 17 Nov 1998 14:38:13 +0000
To: "[e-mail]" <[e-mail]>
From: John Hughes <[e-mail]>
Subject: LDAP Schema
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Has any one tried to configure Exchange Directory Server 5.5 to support the
pkiUser and pkiCA object classes.  Is it possible?


John



 -------------------------------------------------------------------
| John Hughes             [e-mail]                 |
| ENTEGRITY Solutions     Home Office Tel:       [phone]  |
|                         Home Fax No:           [phone]  |
|                         Main Office Tel:       [phone] |
| www.entegrity.com       Mobile:                [phone]   |
 ------------------------------------------------------------------- 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA25539 for ietf-pkix-bks; Mon, 16 Nov 1998 21:31:21 -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 VAA25535 for <[e-mail]>; Mon, 16 Nov 1998 21:31:13 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LNT>; Tue, 17 Nov 1998 16:28:40 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D50A@DSG1>
From: Alan Lloyd <[e-mail]>
To: [e-mail]
Subject: some comments on OCSP vs 7
Date: Tue, 17 Nov 1998 16:28:37 +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

A quick review - and some operational issues.

Also agree with discussion re Explicit tags. I am not concerned re bytes
on the wire - but they are not consistenly used and make the ASN.1
"clunky".


General comments - from a system perspective is the usual Hows and When
issues.

3.2 
1) an OCSP responder can have the same (private) key as the CA who
issues the certs being validated.
There may be more than one OCSP responder and there may be many CAs who
want to use them so that a client can be simplified in a multi cert
domain environment. This just requiresprivate key distribution and
management. Not good IMHO.

2) CA designated responder - this means that the clients requesting
validation by an OCSP responder must also validate the responder - in
the same way they would have validated the CA if the OCSP responder was
not there.


3) The "good" state para is a worry re "a good state does not
necessarily indicate that the certficate was ever issued" ???! All this
engineering and no trust.

4) The "Unknown" state - I suppose that means that the client goes back
to directory based validation or gives up.


3.3
1) Internal Error - OCSP responder in an inconsistent state - try
another server.
If the extensions in the certs contain AuthorityInfoAccess - with a
sequence of entries, then by defintion the client could go through a
sequence of responders - This does mean however, that a system's fault
tolerant strategy and its system configuration is cryptographically tied
to a cert. This is not good as it means a very inflexible system and a
lot of pre knowledge.
If on the other hand this extension is not used - then the fault
management strategy is a client configuration issue. My concern is that
this scenario is a bit like a telephone being configured with all the
PABXs it can talk to. ie. lots of hand configs and not generally
applied.

2) Try Later - Hmmm
left for a long time will cause a failure in the transaction being
verified.
tried rapidly and frequently will cause protocols and servers to burn
out.

How is "try later" applied to make it operationally useful. I get
concerned that timers and counters (as used in lower layer protocols) to
stop looping for ever, are not included in the spec. ie. these things
also need common configuration definition.

3.4
Updates - 
What does the client do if next update is set to an hour or so infront
of the current time.
Should all client software have a "window" in which requests can be
fired off to the OCSP server and valid responses seen - AND that if the
next update is greater than nnnn it does something about it? What is the
process here under these conditions?

3.6. 
1) The client must check that if the OCSP server signature is not that
of the cert issuer, then it must check the OCSP server cert to see if
the extended key usage is set and the the fact that the OCSP server
cert's Issuer CA is a valid signature for the OCSP server's cert. HMMM


3.7
1) This must be corrected as its very bad to have a trusted function?
that "knows" a CA key has been compromised and the MAY mention the fact
to the supported clients.
a) Does the spec need to say how this key knowledge is provided and it
MUST invalidate all.
Otherwise the text has no substance.

4.1
Issue re crypto binding of system config knowledge is IMHO not a good
idea - or otherwise configure the client software - for any server that
will be used by many CAs/originiators of signed transactions. This does
represent a scaling issue in the making.

Thoughts are welcome. But the concerns are of scaling and the multitude
of conditions that need to be dealt with and  at the end of the day, the
client will probably still have to validate the OCSP's sig  cert path
and other certs via the normal method... via directories.

regards alan









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23253 for ietf-pkix-bks; Mon, 16 Nov 1998 17:47:36 -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 RAA23248 for <[e-mail]>; Mon, 16 Nov 1998 17:47:33 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LM7>; Tue, 17 Nov 1998 12:45:03 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D504@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Elliott Ginsburg <[e-mail]>
Cc: [e-mail]
Subject: RE: Fwd: Re: A different architecture
Date: Tue, 17 Nov 1998 12:45:02 +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

Stephen - I think you are to late - Big organisations and the hundreds
if not thousands of people I work with are actually deploying large
scale - application level, business and CA oriented X.500 directory
systems.

If you want the same functionality from DNS as X.500 - one will have to
upgrade it to X.500.
Or one can just put DNS interfaces/servers onto an X.500 system and
migrate DNS to X.500 - see DEN - re DHCP/DNS/RADIUS coupled to X.500.
regards alan

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 10:20
> To:	Elliott Ginsburg
> Cc:	[e-mail]
> Subject:	Re: Fwd: Re: A different architecture
> 
> Elliott,
> 
> >I'm adding to my own message. Someone also stated on the list that we
> do
> >not want to have a directory between our apps and our PKI services.
> But,
> >again, how often today do we have DNS between our apps and our
> network
> >communication services?
> 
> We already need the DNS to make the existing Internet protocols work.
> In
> many apps, we don't need a directory to support certs/CRLs, so the
> introduction of an additional directory system for that purpose
> introduces
> new failure modes.
> 
> steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22513 for ietf-pkix-bks; Mon, 16 Nov 1998 16:22:01 -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 QAA22504 for <[e-mail]>; Mon, 16 Nov 1998 16:21:58 -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 NAA17859 for <[e-mail]>; Tue, 17 Nov 1998 13:08:11 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91126129111896>; Tue, 17 Nov 1998 13:08:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 17 Nov 1998 13:08:11 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tim Polk <[e-mail]> wrote:

>If the basic constraints extension is not present, certificate processing
>is consistent with v1 or v2 certificates.  If out-of-band information
>specifies the subject is a CA, it's a CA.  If out of band information is
>not available, the user of the certificate assumes the subject is NOT a
>CA.

Assertion: If basicConstraints is not present, current software typically
           assumes the subject is a CA.
Proof: Create a self-signed certificate without basicConstraints, load it
       into MSIE or Netscape, and see what happens.

>3) If an end entity wishes to accept a certificate without a
>basicConstraints extension as a CA certificate, it must rely on
>out-of-band information.  In this case, the responsibility lies on the
>certificate user and the source of the out-of-band information, not on
>the certificate issuer.  The certificate issuer attests to the binding of
>subject and key, not the subject's status as a CA.

Both MSIE and Netscape treat self-signed certs without basicConstraits as 
CA's by default (in fact I don't know of any way to get them to *not* 
treat the cert owners as CA's).

MSIE: "You have been offered a new site certificate to place in your list
       of trusted issuers..."
Netscape: "You are about to go through the process of accepting a
           certificate authority..."

Leaving out the basicConstraints makes the assumption that relying parties
are using PKIX-compliant software, and that the software will DTRT when it
finds one of these certs.  I think this is leaving what could be a critical
security issue more or less to chance - all I need to do is find some
software which happens to not follow PKIX's implied behaviour and I can go
ahead and issue my own certs and let the entire world in the door.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22336 for ietf-pkix-bks; Mon, 16 Nov 1998 16:01:16 -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 QAA22331 for <[e-mail]>; Mon, 16 Nov 1998 16:01:10 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LL8>; Tue, 17 Nov 1998 10:58:40 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F6@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: More problems with OCSP
Date: Tue, 17 Nov 1998 10:58:39 +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

> -----Original Message-----
> From:	Peter Gutmann [SMTP:[e-mail]]
> Sent:	Saturday, 7 November 1998 22:19
> To:	[e-mail]; [e-mail]
> Subject:	Re: More problems with OCSP
> 
	[Alan Lloyd]  snip
>   Given a query with an arbitrary
> CertID, it's not possible for an OCSP responder to provide a useful
> response.
	[Alan Lloyd]  Yes - thats precisely why I said OCSP is a
mechanism - not a system design. No information or system model or HOW
it relats to the real world of scaleable systems and their knowledge
properties - makes OCSP a "mechanism".
	regards alan 
> Peter.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22163 for ietf-pkix-bks; Mon, 16 Nov 1998 15:34:01 -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 PAA22159 for <[e-mail]>; Mon, 16 Nov 1998 15:33:58 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <W9M12LLT>; Tue, 17 Nov 1998 10:31:26 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F2@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Tue, 17 Nov 1998 10:31:24 +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

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Friday, 6 November 1998 14:16
> To:	[e-mail]; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
	[Alan Lloyd]  snip

> [Purely in order to forestall the inevitable comments about "it won't
> scale 
>  and there's no replication and it's not distributed and you can't get
> it with 
>  fuzzy dice and ...", I'll reiterate what I said above: The users
> don't care.  
	[Alan Lloyd]  Its always this line that gets me when its used to
negate the engineering issues of dealing with information (or any)
infrastructure for large scale systems.

	Users of the telephone service dont care about undersea cables,
sats, switches, plesiochronous digital hierarchies, etc But the
engineering and the people that biuld the system do.

	Yes Use what you want.

	I work with many large customers that do care about their
infrastructures and how they deal with services, information and
certificates - and naturally because I am involved with them its
distributed X.500 (with LDAP access).

>   Given the choice, they've gone for the easy-to-use, widely-available
> solution 
>  which does the job. 
	[Alan Lloyd]  These arenot engineering terms - the phone system
or building a large corporate information system is NOT and never will
be a product that is easy to apply - if you want it easy to use) eg
phone systems and what is the job here?

>  I'll continue to support whatever's around and let the
>  users make their own choice, but when it comes to key storage
> mechanisms they 
>  sure aren't choosing X.500 or anything derived from it]
	[Alan Lloyd]  Thats a view - but it depend what you are building
- islands of information for islands of users with simple products or
scaleable, distributed, coherent, secure, large scale, service based
information infrastructures.

	regards alan 
> Peter.
>  
> [0] So-called because it both sucks and blows.
>  


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21419 for ietf-pkix-bks; Mon, 16 Nov 1998 13:50:52 -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 NAA21415 for <[e-mail]>; Mon, 16 Nov 1998 13:50:51 -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 QAA09955; Mon, 16 Nov 1998 16:54:20 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 16 Nov 1998 16:56:28 -0500
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Problem with PKIX part 1 basicConstraints
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter,


I believe that the PKIX part 1 basicConstraints text is okay.


X.509 v3 does not require that the basicConstraints extension appear in
each certificate.  It simply specifies the processing rules if it is, or
is not, present.  The "NOTES" at the end of the section state:

 

>>>>

<excerpt>1	If this extension is not present or is flagged non-critical
and is not recognized by a certificate-using system, then that system
should use other means to determine if the certified public key may be
used to verify certificate signatures.


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.

</excerpt><<<<<<<<


I believe the current PKIX text is not only consistent with X.509, but
specifies the appropriate practices.  Here's my "logic":


If the basic constraints extension is not present, certificate processing
is consistent with v1 or v2 certificates.  If out-of-band information
specifies the subject is a CA, it's a CA.  If out of band information is
not available, the user of the certificate assumes the subject is NOT a
CA.


If the basic constraints extension appears and is critical, certificate
processing may *only* consider the subject as specified in the
extension.


If the basic constraints extension is present, but is not critical,
certificate processors may honor the specified value, but are not
required to.


So, a certificate's subject is an end entity by default.  Using basic
constraints to specify that the subject is not a CA is a preventive
measure.  Out-of-band information specifying the entity is not a CA is
redundant.


The basic constraints extension OR out-of-band information can specify a
subject is a CA.


Section 4.2.10 requires the extension appear in all CA certificates, and
be marked critical.  The text recommends against placing this extension
in end entity certificates.


This has a few nice properties:

<paraindent><param>left</param>1) CA certificates are explicitly
specified by PKIX compliant CAs.  As a result, out-of-band information is
restricted to the idnetity of the "trusted CA(s)".

2) End entity certificates simply default to end entities.  This means
the majority of certificates will be a little simpler.

3) If an end entity wishes to accept a certificate without a
basicConstraints extension as a CA certificate, it must rely on
out-of-band information.  In this case, the responsibility lies on the
certificate user and the source of the out-of-band information, not on
the certificate issuer.  The certificate issuer attests to the binding of
subject and key, not the subject's status as a CA.

4) If CA wishes to ensure that the certificate user doesn't use the
certificate with out-of-band information to build a longer certificate
path, it may include a critical basicContraints extension stating this.

</paraindent>

Property 3) is actually very useful.  Here's a scenario:  NIST issues
certificates to NIST employees, but not contractors.  NIST issues
certificates to NIST employees, including me, omitting the
basicConstraints extension.  I issue certificates to contractors working
in the PKI lab.  Other folks on the NIST PKI project use out-of-band
information to determine that I'm a CA, and trust those certificates. 
It's not the NIST CA's concern, since the remainder of NIST is not fooled
into trusting those certificates.


By omitting the extension, we leave lots of flexibility.  The NIST PKI
maintains revocation information for me; if my key is compromised, the
NIST CA revokes my certificate and even the NIST PKI project team rejects
the contractors' certificates.


I don't know if anyone will use this feature, but it is conceptually
quite attractive.


Property 4) is also useful.  As a commercial vendor, I might charge more
to issue certificates to CAs than end entities.  By inserting a critical
basicConstraints extension, I keep my customers from ripping me off.


All in all, I think the PKIX profile for basicConstraints works correctly
and is consistent with X.509v3.



The FPKI profile predated the PKIX profile, and is out of synch in
several areas.  Now that PKIX is stable, the editor plans to modify the
FPKI profile to be more consistent.  The group that "owns" that document
met last week, and approved the changes.  I believe this is one of the
changes he plans, but I can't find my notes.  I will try to find them and
confirm that.


Thanks,


Tim



At 02:58 PM 11/16/98, Peter Gutmann wrote:

>Section 4.2.1.10 says

> 

>>This extension MUST appear as a critical extension in all CA
certificates.

>>This extension SHOULD NOT appear in end entity certificates.

> 

>This is wrong, because without the basicConstraint to say the subject
isn't a

>CA, a relying party doesn't know how to treat the cert - you need to
have an

>empty sequence there for end entities.  Looking at some other profiles,
both

>X.509v3 (section 14.4.2.1) and the FPKI profile (to take the top two
lying on

>the stack) require an empty sequence for end entities.

> 

>Peter.

> 

>

>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16524 for ietf-pkix-bks; Mon, 16 Nov 1998 05:40:54 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16520 for <[e-mail]>; Mon, 16 Nov 1998 05:40:53 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA00813; Mon, 16 Nov 1998 05:44:06 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 16 Nov 1998 08:37:21 -0500
To: "Tammy Carter" <[e-mail]>, <[e-mail]>, "Dwight Arthur" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Tammy,

	It's the CA's responsibility to track keys.  Comments in line:


At 01:01 PM 11/11/98 -0700, Tammy Carter wrote:
>Al,
>
>How can a piece of software tell if the key's useful lifetime has expired?  
>The onus 
>for such a check must logically be upon (1) the CA, or (2) the client 
>software.  
>[Here I'm assuming that it is unreasonable to expect users to remember when 
>the key in each of their certificates was first created.]
>
>It doesn't seem obvious to me that a CA should make the determination.
>If a CA kept a database containing tuples of 
><public key, subject name, date of issue>, the CA could find that it had 
>issued a certificate with the same public key and the same subject name X
>days/months/years ago given only a CSR (or similar request).  This doesn't
>seem like a good idea for two reasons: 
>(1)  Not all CAs will be able to keep information about every certificate it 
>has
>       ever issued and be able to search it in a reasonable amount of time 
>before
>       issuing a new certificate.

AWA:  Tammy, it's the CA's job to track certificates and do renewals, if
appropriate.  In our system, the CA keeps a database of all certificates it
issued.  Included in each certificate record are things like a copy of the
actual certificate, the date it was originally issued, the key validity
period, how to contact the subject of the certificate,  whether this
certificate has already been renewed, whether this certificate has been
revoked, and some other stuff.  The CA software automatically does the
record creation/update every time the CA takes some action, so the
information is there.  In general, the CA is not allowed to delete records
from the database until they have been "archived" - preserved for long-term
storage via an explicit action. You should only archive records that you
don't actively care about - the certificates have been revoked, or have
expired, or...  So, unless a CA (human being) is being deliberately
malicious or truly imcompetent, there's not a problem searching for and
finding a certficate when a renewal request takes place. 

Renewal can be either pro-active or re-active.  The CA has the capability
to scan the database and find all of the certificates that are about to
expire, say within 30 days or some other window.  The CA can look at these
certs and contact the subjects to see if anything has changed.  If the CA
is satisfied that renewal is appropriate, she can renew the certificate and
send the new one to the user via some appropriate channel - e.g., e-mailing
it, or posting it to a directory.

Alternately, the user can notice that her cert is about to expire, and send
in a renewal request.  The CA will decide whether or not to approve the
request; if it's approved, the CA will do the renewal and send back the new
cert.

>(2)  In order for a user to determine that the key has passed its useful 
>lifetime,
>       they user must try to renew the certificate _with_the_same_CA_ which 
>is not
>       always possible.
>

AWA:  Only the CA that issued a certificate can renew it.  You as a user
can ask a different CA for a *new* certificate with a public key that's
already in another certificate you have.  That new CA (which may not even
know that the public key is one that's already in a different certificate
you have) will make a decision about whether to issue that new certificate.
 But that's not a renewal, because it changes a field other than validity
period, serial number, or signature value.


>That means that the client software should do it.  But, I just don't see how 
>the 
>client software can keep track either.  Well, unless some state is kept with 
>each
>certificate saying when the key was created.  But, then, where is this state 
>stored?
>Surely it should be protected at least by a signature....  But, does it belong
>in a certificate?
>

AWA:  Again, this is all done at the CA.  We tried not to put any
certificate management tasks on the clients unless we absolutely had to.
With a reasonable database at the CA workstation, it's not a major problem.
 It's not as automated as some customers would like - they'd like the
renewal to be completely transparent - but it works well enough.

>Lack of a good way discover how old the key in a particular certificate is 
>seems an
>excellent reason for client software to enforce a new key for each 
>certificate.  If only
>to protect naive users from keeping the same key for years because they
know no
>better or because they can't remember when they last did a rekey.
>

AWA:  If the users/clients want a new key with each certificate, that's
certainly their option.  We support both.  

				Al Arsenault


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA06686 for ietf-pkix-bks; Mon, 16 Nov 1998 00:50:00 -0800 (PST)
Received: from services.editel.cz (services.editel.cz [194.196.54.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA06682 for <[e-mail]>; Mon, 16 Nov 1998 00:49:54 -0800 (PST)
From: [e-mail]
Received: from editelnt.editel.cz ([172.16.2.120]) by services.editel.cz (8.8.8/0.1) with SMTP id JAA09424 for <[e-mail]>; Mon, 16 Nov 1998 09:51:37 +0100
Date: Mon, 16 Nov 1998 9:51:32 +0100
Message-ID: <[e-mail]>
X-Mailer: Mail602 v.3.32
To: [e-mail]
Reply-To: [e-mail]
Subject: draft-ietf-pkix-ipki-part1-11
Sender: [e-mail]
Precedence: bulk

Hi,

I've just noticed some inconsistence in doc draft-ietf-pkix-ipki-part1-11.txt in appendix D - certs and CRLs samples -

D.4 RSA certificate -

field signatureAlgorithm in Certifikate is here:

0579 30 80           : . SEQUENCE (indefinite length)
0581 06 07          7: . . OID
0583 05 00          0: . . NULL
0585 00 00          0: . . end of contents marker

This look strange - the OID value is missing



Regards

IvanZ 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04024 for ietf-pkix-bks; Mon, 16 Nov 1998 00:15:47 -0800 (PST)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA03996 for <[e-mail]>; Mon, 16 Nov 1998 00:15:38 -0800 (PST)
Received: from kiku.itsise ([e-mail] [192.168.2.2]) by atsgw.cyber.ee (8.8.3/8.7.3) with ESMTP id KAA13627; Mon, 16 Nov 1998 10:19:11 +0200
Received: from pahuvere (pahuvere.itsise [192.168.2.140]) by kiku.itsise (8.9.1a/8.9.1) with SMTP id KAA31084; Mon, 16 Nov 1998 10:15:38 +0200
Received: by localhost with Microsoft MAPI; Mon, 16 Nov 1998 10:18:13 +0200
Message-ID: <[e-mail]>
From: Tarvi Martens <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: SEIS:  EID business model? Was CA certificates on smart cards)
Date: Mon, 16 Nov 1998 10:18:12 +0200
Organization: Cybernetica
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

Just couple of thoughts:

First, about directories and LDAP/DAP/X.500 in particular.
We should assume that delivery of certificates and CRL-s does not
require any special technologies. The public certificate should not
contain any confidential information, not talking about CRL-s. In
this case, just any (secured) WWW service should do. If one could
agree on certain rules on this kind of directory service (eg. WebCAP)
the life could be easier for all of us.

The most problematic thing as of today about X.509v3 certificates
(for me) is DN usage/subordination and usage of v3 extensions.
There are evidently different requirements on DN form and usage
of extensions for different
	- communities
	- usages
	- protcols/applications

By communities I mean CA -> certificate holder relationships eg:
	government -> citizen (EID case)
	government -> company
	government -> government (cross-country certification)
	company -> client
	company -> employee
	company -> company
	person -> person

It is evident that these relationships require different DN form (eg government
cannot tell your O= whether company doest not care much about your nationality 
;)

Some certificates are issued today for very specific usages, eg. "tax 
declaration only"
or "database access only".

Some protocols/applications like SSL, SET and S/MIME define usage of v3 
extensions
pretty clearly. However, they are not the only ones in the world.

Our common goal should be to facilitate growth of digital signature 
technologies
in general. We cannot do this top-down. Instead, we should allow for "everyone"
to start running CA services.

If we just could define a profile, regulating usage of DN attributes and v3 
extensions
depenging on community, usage and protocol... then this protocol would be
profitable to follow in order to get hooked with the overall (national, world, 
...) PKI.

Any thoughts or real activities towards this?

Best regards,

Tarvi Martens
Cybernetica



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA20139 for ietf-pkix-bks; Sun, 15 Nov 1998 17:54:50 -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 RAA20135 for <[e-mail]>; Sun, 15 Nov 1998 17:54:46 -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 OAA01742 for <[e-mail]>; Mon, 16 Nov 1998 14:58:25 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91118150506680>; Mon, 16 Nov 1998 14:58:25 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Problem with PKIX part 1 basicConstraints
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 16 Nov 1998 14:58:25 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Section 4.2.1.10 says
 
>This extension MUST appear as a critical extension in all CA certificates.
>This extension SHOULD NOT appear in end entity certificates.
 
This is wrong, because without the basicConstraint to say the subject isn't a
CA, a relying party doesn't know how to treat the cert - you need to have an
empty sequence there for end entities.  Looking at some other profiles, both
X.509v3 (section 14.4.2.1) and the FPKI profile (to take the top two lying on
the stack) require an empty sequence for end entities.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10704 for ietf-pkix-bks; Sat, 14 Nov 1998 16:31:51 -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 QAA10700 for <[e-mail]>; Sat, 14 Nov 1998 16:31:50 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7R9X>; Sat, 14 Nov 1998 16:34:31 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A9F@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'EKR'" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: RE: I-D ACTION:draft-schaad-dhsign-00.txt
Date: Sat, 14 Nov 1998 16:34:29 -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

Eric,

It appears that I need to get a new set of reviews as they all missed this.
I think you are correct and there is a problem in the draft.  I currently
plan to remove the ephermal scheme from the draft on the next revision.

jim


-----Original Message-----
From: EKR [mailto:[e-mail]]
Sent: Friday, November 13, 1998 3:47 PM
To: Jim Schaad (Exchange)
Cc: IETF-PKIX (E-mail)
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt


"Jim Schaad (Exchange)" <[e-mail]> writes:
> This draft is referenced from the new CMC draft so it should be of
interest
> to the readers of that draft.
Jim, 
First, a meta-comment:
Why do we need this at all? DH keys are suitable for computing
DSA signatures. Wouldn't it be simpler just to compute a DSA
signature over the data? This would eliminate the need for a common
group between the sender and recipient.

Secondly, I don't believe that the ephemeral scheme is strong.
Provided that the attacker has access to the triplet
g,p,Ys (sender's public key), it's trivial for him to compute
a private key Xe such that he knows:
  
Ye^Xe = g^(XsXe) 

This allows him to forge any number of signed messages
Remember, computing the DH shared secret requires access
to only one of the DH private keys.

I hesitate to bring this up because I'm sure I'm missing something
really obvious, but I sure can't see what it is.

Confused,
-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02023 for ietf-pkix-bks; Fri, 13 Nov 1998 17:54: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 RAA02019 for <[e-mail]>; Fri, 13 Nov 1998 17:54: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 RAA14490; Fri, 13 Nov 1998 17:58:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 13 Nov 1998 17:57:05 -0800
To: EKR <[e-mail]>, "Jim Schaad (Exchange)" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <"Jim Schaad's message of "Fri, 13 Nov 1998 12:04:29 -0800"> <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:46 PM 11/13/98 -0800, EKR wrote:

>Secondly, I don't believe that the ephemeral scheme is strong.
>Provided that the attacker has access to the triplet
>g,p,Ys (sender's public key), it's trivial for him to compute
>a private key Xe such that he knows:
>  
>Ye^Xe = g^(XsXe)

Since g^(Xs) = Ys, don't you mean Ys^Xe = g(XsXe) ?

So you use the shared secret Ys^Xe = g(XsXe).  The recipient
must calculate the same shared secret, using the "Xr" of their
own keypair (Xr,Yr), and the (supposed) sender's Ys.  I believe
DH key agreement needs both sides public keys to be "certified"
or otherwise already trusted by both parties.
 
The DSA and DH methods rest upon the "hardness" of inverting
the exponential.  Given you know g, p, and Y (Y = (g^X)mod p)
you should not be able to recover X (in human time, anyway).
But I gather you didn't intend to say you could recover X.
 
>
>This allows him to forge any number of signed messages
>Remember, computing the DH shared secret requires access
>to only one of the DH private keys.

Perhaps I don't understand ALL the issues;)  My understanding:

  Let (Xs,Ys) = sender's keypair
  Let (Xr,Yr) = recipient's keypair
 
  SENDER calculates:     Yr^Xs = g^(XrXs) = SharedSecret1
  RECIPIENT calculates:  Ys^Xr = g^(XsXr) = SharedSecret1

Now, for an impostor to pose as SENDER to the RECIPIENT, they
would need either the sender's Xs or the recipient's Xr.  But
each of these are supposedly secret.

Is the "ephemeral" scheme different than this?
 
>Confused,

Me too.
___tony___

>-Ekr
>
>-- 
>[Eric Rescorla                                   [e-mail]]
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01121 for ietf-pkix-bks; Fri, 13 Nov 1998 15:41:58 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01117 for <[e-mail]>; Fri, 13 Nov 1998 15:41:52 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id PAA19896; Fri, 13 Nov 1998 15:46:40 -0800 (PST)
To: "Jim Schaad (Exchange)" <[e-mail]>
Cc: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: Re: I-D ACTION:draft-schaad-dhsign-00.txt
References: <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
From: EKR <[e-mail]>
Date: 13 Nov 1998 15:46:39 -0800
In-Reply-To: "Jim Schaad's message of "Fri, 13 Nov 1998 12:04:29 -0800"
Message-ID: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Jim Schaad (Exchange)" <[e-mail]> writes:
> This draft is referenced from the new CMC draft so it should be of interest
> to the readers of that draft.
Jim, 
First, a meta-comment:
Why do we need this at all? DH keys are suitable for computing
DSA signatures. Wouldn't it be simpler just to compute a DSA
signature over the data? This would eliminate the need for a common
group between the sender and recipient.

Secondly, I don't believe that the ephemeral scheme is strong.
Provided that the attacker has access to the triplet
g,p,Ys (sender's public key), it's trivial for him to compute
a private key Xe such that he knows:
  
Ye^Xe = g^(XsXe) 

This allows him to forge any number of signed messages
Remember, computing the DH shared secret requires access
to only one of the DH private keys.

I hesitate to bring this up because I'm sure I'm missing something
really obvious, but I sure can't see what it is.

Confused,
-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29507 for ietf-pkix-bks; Fri, 13 Nov 1998 12:01:58 -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 MAA29503 for <[e-mail]>; Fri, 13 Nov 1998 12:01:57 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7L3G>; Fri, 13 Nov 1998 12:04:31 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A96@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "IETF-PKIX (E-mail)" <[e-mail]>
Subject: I-D ACTION:draft-schaad-dhsign-00.txt
Date: Fri, 13 Nov 1998 12:04:29 -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

This draft is referenced from the new CMC draft so it should be of interest
to the readers of that draft.

>To: IETF-Announce: ;
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-schaad-dhsign-00.txt
>Date: Fri, 13 Nov 1998 10:46:45 -0500
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: Diffie-Hellman Signing Algorithm
>	Author(s)	: H. Prafullchandra, J. Schaad
>	Filename	: draft-schaad-dhsign-00.txt
>	Pages		: 8
>	Date		: 12-Nov-98
>	
>This document describes a method 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.  This document
>describes two different flavors of the signature algorithm, one using a
>D-H key from a CA and the other using a temporary key created by the
>signer.
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>	"get draft-schaad-dhsign-00.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-schaad-dhsign-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nic.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[e-mail].  In the body type:
>	"FILE /internet-drafts/draft-schaad-dhsign-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.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-schaad-dhsign-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-schaad-dhsign-00.txt>


--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28185 for ietf-pkix-bks; Fri, 13 Nov 1998 09:41:05 -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 JAA28181 for <[e-mail]>; Fri, 13 Nov 1998 09:41:04 -0800 (PST)
Received: from xedia.com by relay6.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfpis21778; Fri, 13 Nov 1998 12:43:27 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA29586; Fri, 13 Nov 98 12:41:26 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA16934; Fri, 13 Nov 1998 12:43:25 -0500
Date: Fri, 13 Nov 1998 12:43:25 -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: Proposal for a new CRL extension
References: <[e-mail]> <002201be0f1c$71bc0140$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

>>>>> "Phillip" == Phillip M Hallam-Baker <[e-mail]> writes:

 Phillip> I think the idea is a good one, but only up to a point. I
 Phillip> considered an ordered CRL extension at length earlier in the
 Phillip> year when I for some reason I was spending a lot of time
 Phillip> thinking about CRLs.

 Phillip> The problem that was put to me was one of backwards
 Phillip> compatibility. If the extension is to be any use in a legal
 Phillip> sense it has to be marked critical which breaks backwards
 Phillip> compatibility.

I don't understand that.

If you sort the CRL and indicate this, and I don't recognize the
extension, that has to mean that I don't have code that optimizes the
handling of sorted CRLs.  Instead, I treat all CRLs as unsorted.

Nothing bad happens.  Since nothing bad happens, the extension must
not be marked critical.

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27208 for ietf-pkix-bks; Fri, 13 Nov 1998 07:41:59 -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 HAA27204 for <[e-mail]>; Fri, 13 Nov 1998 07:41:58 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11910; Fri, 13 Nov 1998 10:44:55 -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-02.txt
Date: Fri, 13 Nov 1998 10:44:55 -0500
Sender: [e-mail]
Precedence: bulk

--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, B. Fox, J. Weinstein
	Filename	: draft-ietf-pkix-cmc-02.txt
	Pages		: 37
	Date		: 12-Nov-98
	
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].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmc-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-02.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-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-02.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 HAA27186 for ietf-pkix-bks; Fri, 13 Nov 1998 07:39:14 -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 HAA27181; Fri, 13 Nov 1998 07:39:14 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA29270; Fri, 13 Nov 1998 07:39:48 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA06226; Fri, 13 Nov 1998 07:42:09 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Date: Fri, 13 Nov 1998 10:44:05 -0500
Message-ID: <002201be0f1c$71bc0140$[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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk

I think the idea is a good one, but only up to a point. I considered an
ordered CRL extension at length earlier in the year when I for some
reason I was spending a lot of time thinking about CRLs.

The problem that was put to me was one of backwards compatibility. If
the extension is to be any use in a legal sense it has to be marked 
critical which breaks backwards compatibility.

Also I started to go off the idea when I rediscovered scopes for OCDP
since the length of the CRL can then be absolutely bounded to an arbitrary
limit.

The CRL processing problem is much less of a problem IMNSHO as the 'we
can't stuff a darn CRL into our IPSEC handshake' problem.


Its a valid point though and the cost of adding it to the profile would
not be very high. If the list thinks there is value we could add the 
proposal to the OCDP draft, rename it extended certificate processing and
use it as a vehicle for similar CRL optimizations that may turn out to be
usefull.

The application I would envisage is for managing very large archival CRLs
where the cost of a possibly unnecssary extension is not very significant.


		Phill


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Thursday, November 12, 1998 3:16 PM
> To: [e-mail]
> Subject: Proposal for a new CRL extension
> 
> 
> The entries in CRLs are not ordered. This means that a CRL-reading client
> must read the entire CRL to know if a particular certificate is revoked.
> That's pretty wasteful, it seems to me.
> 
> I would like to propose a new non-critical CRL extension that would say
> that the revokedCertificates sequence is in the ascending order either by
> userCertificate or by revocationDate. I don't see any problem with this,
> but wanted input before I wrote up the draft.
> 
> Comments?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17045 for ietf-pkix-bks; Thu, 12 Nov 1998 15:14:49 -0800 (PST)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17041 for <[e-mail]>; Thu, 12 Nov 1998 15:14:49 -0800 (PST)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA26365 for <[e-mail]>; Thu, 12 Nov 1998 15:18:15 -0800 (PST)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <WX1ZQ73A>; Thu, 12 Nov 1998 15:17:19 -0800
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 15:17:17 -0800
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

Paul

Going back to the "you have to read it all anyways argument", it seems to me
that there are several ways to improve the CRL checking speed already
without inventing any new modifiers.  Consider the following:


a)  The size of any given CRL message can be controlled at the CA by simply
assigning the distribution points judiciously.  For example, one could
switch to a new CRL after every 500 certificates, thus putting an absolute
upper bound on the size of any given CRL.

b)  The clever programmer, after retrieving and checking the signature of a
CRL record, can easily construct searchable lists internally using his own
favorite algorithm (B-tree, hash-table, linked lists ... the list is
endless).

I'd say that all of this is an implementation issue, and should not be
present in a standard.

David



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16698 for ietf-pkix-bks; Thu, 12 Nov 1998 14:59:01 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16692; Thu, 12 Nov 1998 14:58:59 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id PAA07307; Thu, 12 Nov 1998 15:03:48 -0800 (PST)
To: Paul Hoffman / IMC <[e-mail]>
Cc: "Kurn, David" <[e-mail]>, [e-mail]
Subject: Re: Proposal for a new CRL extension
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 12 Nov 1998 15:03:46 -0800
In-Reply-To: Paul Hoffman / IMC's message of "Thu, 12 Nov 1998 13:36:55 -0800"
Message-ID: <[e-mail]>
Lines: 29
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Paul Hoffman / IMC <[e-mail]> writes:

> >If I am not mistaken, CRL's are signed.  How can you verify the signature
> >unless you read the entire CRL?
> 
> Your read the entire CRL once to verify the signature. You store the CRL
> with some marking that it is valid. You later read it looking for certificates.
> 
> Yes, you could extract and sort the certificates when you validated the
> CRL, but that means many more steps than just keeping the CRL in some place
> that you trust.
Paul,
This really isn't that useful an optimization. Firstly, pretty 
much every ASN.1 codec I know of decodes the entire message
in one shot, so you've got to run over the entire message
anyway. The extra comparisons aren't that expensive.

But, for the sake of argument, let's assume that you have
an ASN.1 codec that is incremental. You still can't use
binary search, because you have to at least partially decode
entry n in order to know where entry n+1 starts. Consequently,
you now have to use linear search, so on average you have to
read half the CRL. This seems like a lot of standardization
work for a factor of two speedup.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15508 for ietf-pkix-bks; Thu, 12 Nov 1998 13:46:58 -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 NAA15503; Thu, 12 Nov 1998 13:46:57 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7CC6>; Thu, 12 Nov 1998 13:49:16 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A8A@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "Kurn, David" <[e-mail]>, [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 13:49: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

Additionally there is a big difference between just running the set of items
on the CRL through a hash function to verify the signature (which can be
done as a binary stream), and parsing the contents of the list and doing
comparisions of the serial numbers on each item in the list.   Having the
list sorted allows one to optimize the search and reduce the number of
comparisons done.

jim schaad

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Thursday, November 12, 1998 1:37 PM
To: Kurn, David; [e-mail]
Subject: RE: Proposal for a new CRL extension


>If I am not mistaken, CRL's are signed.  How can you verify the signature
>unless you read the entire CRL?

Your read the entire CRL once to verify the signature. You store the CRL
with some marking that it is valid. You later read it looking for
certificates.

Yes, you could extract and sort the certificates when you validated the
CRL, but that means many more steps than just keeping the CRL in some place
that you trust.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15271 for ietf-pkix-bks; Thu, 12 Nov 1998 13:35:34 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15236; Thu, 12 Nov 1998 13:33:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 13:34:11 -0800
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Cc: "'Hoyt Kesterson'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:48 PM 11/12/98 -0500, Sharon Boeyen wrote:
>fyi - in the X.509 meeting in Sept, a new extension that does some of
>what you want, was added to to the text that will be issued for PDAM
>ballot shortly.

I'll take this as meaning that I don't need to do the extension draft. I
think someone (probably an implementor) should be keeping track of
extensions to PKIX part 1 that are being added by the PDAM folk so that we
can pull them together in a draft, maybe in six months or so.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15240 for ietf-pkix-bks; Thu, 12 Nov 1998 13:33:59 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15234; Thu, 12 Nov 1998 13:33:57 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 13:36:55 -0800
To: "Kurn, David" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Proposal for a new CRL extension
In-Reply-To: <[e-mail]. tandem.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>If I am not mistaken, CRL's are signed.  How can you verify the signature
>unless you read the entire CRL?

Your read the entire CRL once to verify the signature. You store the CRL
with some marking that it is valid. You later read it looking for certificates.

Yes, you could extract and sort the certificates when you validated the
CRL, but that means many more steps than just keeping the CRL in some place
that you trust.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14623 for ietf-pkix-bks; Thu, 12 Nov 1998 13:02:03 -0800 (PST)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14618; Thu, 12 Nov 1998 13:02:02 -0800 (PST)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA09812; Thu, 12 Nov 1998 13:05:27 -0800 (PST)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <WX1ZQZ6X>; Thu, 12 Nov 1998 13:04:32 -0800
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 13:04:30 -0800
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

Paul

If I am not mistaken, CRL's are signed.  How can you verify the signature
unless you read the entire CRL?

David Kurn
Compaq Computer Corp.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Thursday, November 12, 1998 12:16 PM
To: [e-mail]
Subject: Proposal for a new CRL extension


The entries in CRLs are not ordered. This means that a CRL-reading client
must read the entire CRL to know if a particular certificate is revoked.
That's pretty wasteful, it seems to me.

I would like to propose a new non-critical CRL extension that would say
that the revokedCertificates sequence is in the ascending order either by
userCertificate or by revocationDate. I don't see any problem with this,
but wanted input before I wrote up the draft.

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14480 for ietf-pkix-bks; Thu, 12 Nov 1998 12:54:04 -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 MAA14475; Thu, 12 Nov 1998 12:54:01 -0800 (PST)
Received: 	id PAA00436; Thu, 12 Nov 1998 15:53:37 -0500
Received: by gateway id <W1GJNVPF>; Thu, 12 Nov 1998 15:50:40 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail], "'Paul Hoffman / IMC'" <[e-mail]>
Cc: "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: Proposal for a new CRL extension
Date: Thu, 12 Nov 1998 15:48:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Paul,

fyi - in the X.509 meeting in Sept, a new extension that does some of
what you want, was added to to the text that will be issued for PDAM
ballot shortly.

The extension is:

The ordered list extension identifies that a list of revoked
certificates in the revokedCertificates field of a CRL is ordered by
certificate serial number, in increasing order. This field is defined as
follows:
orderedList EXTENSION	::= {
	SYNTAX	BOOLEAN DEFAULT FALSE
	IDENTIFIED BY	id-ce-orderedList }
This extension is always non-critical. 
If orderedList is present and set to TRUE, the list of certificates is
ordered by serial number in increasing order. If orderedList is present
and set to FALSE, the list of certificates is either unordered or in
some order other than increasing by serial number. If orderedList is not
present, no information is provided as to the ordering, if any, of the
list of revoked certificates in the CRL.

I'm still working on the editing from the meeting but the document
should be posted on the Bull ftp site maintained by Hoyt Kesterson
sometime next week.

Although for this particular extension, this is the extent of what was
agreed at that meeting, changes and further enhancements can be made
during the PDAM ballot phase. 

As with the current edition of X.509, input from IETF groups on relevant
parts of that spec will obviously be welcome inputs to the 509 process.
The revocation enhancements will be of particular relevance to the PKIX
WG. 

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[e-mail]]
> Sent: 	November 12, 1998 3:16 PM
> To: 	[e-mail]
> Subject: 	Proposal for a new CRL extension
> 
> The entries in CRLs are not ordered. This means that a CRL-reading
> client
> must read the entire CRL to know if a particular certificate is
> revoked.
> That's pretty wasteful, it seems to me.
> 
> I would like to propose a new non-critical CRL extension that would
> say
> that the revokedCertificates sequence is in the ascending order either
> by
> userCertificate or by revocationDate. I don't see any problem with
> this,
> but wanted input before I wrote up the draft.
> 
> Comments?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13929 for ietf-pkix-bks; Thu, 12 Nov 1998 12:13:09 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA13925 for <[e-mail]>; Thu, 12 Nov 1998 12:13:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 12:16:06 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Proposal for a new CRL extension
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

The entries in CRLs are not ordered. This means that a CRL-reading client
must read the entire CRL to know if a particular certificate is revoked.
That's pretty wasteful, it seems to me.

I would like to propose a new non-critical CRL extension that would say
that the revokedCertificates sequence is in the ascending order either by
userCertificate or by revocationDate. I don't see any problem with this,
but wanted input before I wrote up the draft.

Comments?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10046 for ietf-pkix-bks; Thu, 12 Nov 1998 08:22:00 -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 IAA10039 for <[e-mail]>; Thu, 12 Nov 1998 08:21:59 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA01098; Thu, 12 Nov 1998 08:22:30 -0800 (PST)
Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA27264; Thu, 12 Nov 1998 08:24:51 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 12 Nov 1998 08:24:53 -0800
To: [e-mail]
From: Michael Myers <[e-mail]>
Subject: CMC Update
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

All,

At the Chicago meeting, some issues were raised from the floor regarding
CMC (in WG Last Call).  Follow-up uncovered additional problems, leading
the CMC authors to initiate a comprehensive joint review of the protocol's
requirements and mechanisms.  The draft "draft-ietf-pkix-cmc-02.txt" is the
outcome of our working sessions.  In summary, this draft:

1. Has been reorganized to better reflect its role in meeting user needs,
especially those of the S/MIME, IPSEC and TLS communities. Refinements in
support of dual key operations and automated administration were considered
essential.

2. Reduces the need for readers to refer to multiple documents by replacing
references to CMMF with direct specification of functional equivalents.

3. Maintains interoperability with CRMF via a requirement that CRMF MUST be
implemented at the server while it MAY be implemented in the client.

4. Reinstates the requirement to implement support for standalone PKCS#10,
which had been agreed to long ago by the working group, and was
inadvertently dropped.

5. Clarifies use of the protocol in conjunction with the role of
Registration Authorities.

6. Refines proof of possession requirements and mechanisms to improve
implementability.

7. Proposes an industry-standard method of proving identity based on a
shared secret between the certificate requestor and the verifying authority.

8. Facilitates (optional) end-user emergency key recovery mechanisms
against several constraints and key generation options.

We believe that this draft is a much-improved work product and invite your
comments. A temporary copy is available at
<http://www.imc.org/ietf-pkix/temp-cmc-02.txt>. After the Internet Drafts
editor has posted it to the official drafts directory, it will be available
from the URL that the most up-to-date version is always available, which is
<http://www.imc.org/draft-ietf-pkix-cmc>.



Michael Myers   (VeriSign)			
Xiaoyi Liu      (Cisco)
Barbara Fox     (Microsoft)				
Jeff Weinstein  (Netscape)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA09323 for ietf-pkix-bks; Thu, 12 Nov 1998 07:17:39 -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 HAA09318 for <[e-mail]>; Thu, 12 Nov 1998 07:17:38 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA14619 for <[e-mail]>; Thu, 12 Nov 1998 10:21:02 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA14599 for <[e-mail]>; Thu, 12 Nov 1998 10:20:58 -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 KAA07840 for <[e-mail]>; Thu, 12 Nov 1998 10:20:00 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 12 Nov 1998 10:20:55 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Thu, 12 Nov 1998 10:20:54 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: email oid
Date: Thu, 12 Nov 1998 10:20:53 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Thanks for the information.  

Now, please enlighten me on another (possible mis-) conception that I
have.  Given that there may be a need to validate a certificate path by
relying on information in a repository, what are the implications of
having an object (pkcs#9 email address) as an element of the issuer
and/or subject name, and having the 'corresponding' data object in a
repository identified by the oid for rfc822mailbox?  Does the repository
have to 'map' the two?

My concern is a disconnect between the naming in a certificate and the
storage of potential path information in a repository that requires
additional/complex code. 

Sandi

>----------
>From: 	Russ Housley[SMTP:[e-mail]]
>Sent: 	Tuesday, November 10, 1998 4:09 PM
>To: 	[e-mail]; [e-mail]
>Cc: 	[e-mail]; [e-mail]
>Subject: 	Re: email oid
>
>I just took a look atRFC 1274.  I do not see anything in that document that
>leads me to believe that rfc822mailbox was intended to be used as a
>component of a Distrinuished Name.  It is clearly defining an attribute for
>sotorage in an X.500 directory.
>
>On the other hand, I know that the PKCS#9 emailAddress attribute is used as
>a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone using
>PKCS#9 emailAddress as an attribute in a X.500 directory.
>
>Maybe there is not an issue...
>
>Russ
>
>
>At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
>>Sue,
>>
>>Adding the additional OID would not be the optimum solution.  Since if I
>>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>>problem.  pkix should NOT perpetuate the problem by again calling the same
>>thing two different names.
>>
>>Robert
>>
>>-----Original Message-----
>>From: Miklos, Sue A. <[e-mail]>
>>To: 'Russ Housley' <[e-mail]>
>>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>>'[e-mail]' <[e-mail]>
>>Date: Friday, October 30, 1998 2:34 PM
>>Subject: RE: email oid
>>
>>
>>>Russ, and others, may I then request that it be included or is that not
>>>possible?
>>>
>>>Sandi
>>>
>>>>----------
>>>>From: Russ Housley[SMTP:[e-mail]]
>>>>Sent: Friday, October 30, 1998 1:35 PM
>>>>To: Miklos, Sue A.
>>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>>Subject: Re: email oid
>>>>
>>>>Sandi:
>>>>
>>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>>
>>>>Russ
>>>>
>>>>
>>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>>All,
>>>>>In the specifications for the schema for an international defense
>>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>>registered
>>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>>I would like to request that this remain in whatever documentation you
>>>>>develop.
>>>>>
>>>>>Thanks,
>>>>>Sandi Miklos
>>>>>>
>>>>>>
>>>>>>----------
>>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>>Subject: RE: email oid
>>>>>>
>>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>>if there is a demand for it.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>>To: [e-mail]
>>>>>>Subject: email oid
>>>>>>
>>>>>>
>>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>>problem
>>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>>specifies
>>>>>>that the oid used for an email address in the distinguished name is
>>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>>mail
>>>>>>as specified in RFC1274.
>>>>>>
>>>>>>Since I believe that the intention is for both of these oids are meant
>>to
>>>>>>represent attributes that hold the same information, this discrepancy
>>may
>>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>>change part1 to refer to the more commonly used OID.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01889 for ietf-pkix-bks; Wed, 11 Nov 1998 17:24:03 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01838; Wed, 11 Nov 1998 17:21:23 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA12824; Wed, 11 Nov 1998 17:23:38 -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: Tue, 10 Nov 1998 17:24:42 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Diffie-Hellman Public Key Validation
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 09 Nov 1998 15:45:02 EST."             <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

>> I guess that we will have to determine whether or not the CA performed
>> public key validation prior to certification from the certificate policy
>> OID.  This is not a very nice answer, but I cannot come up with another 
>> answer.
>
>Can you produce some proposed text for this? Is there a fixed set of
>OIDs that are appropriate or do you need an ever-growing lookup table?

For now, I think that we should simply say that the public key validation
does not need to be performed by the end entity if the CA did the
validation at the time the public key was certified.  I think that the PKIX
group should propose a mechanism for indicaing that validation was done in
a certificate.  Once that is specified, we can duplicate the information in
the S/MIME documents before DRAFT standard.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA29253 for ietf-pkix-bks; Wed, 11 Nov 1998 14:20:49 -0800 (PST)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29249 for <[e-mail]>; Wed, 11 Nov 1998 14:20:47 -0800 (PST)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id IAA07424; Thu, 12 Nov 1998 08:22:14 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Santosh Chokhani <[e-mail]>
cc: "'Simonetti David'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: Re: Path Validation Variables 
In-reply-to: Your message of "Tue, 10 Nov 1998 16:22:54 EST." <51BF55C30B4FD1118B4900207812701E20B1AE@WUHER> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 12 Nov 1998 08:22:11 +1000
From: Dean Povey <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA29250
Sender: [e-mail]
Precedence: bulk

>I agree with Dave that the current draft does not permit an application
>force policy checking.
>

Ditto.  I think this is a valid point.  Is it possible for someone to update 
the Certificate profile if there are no other objections?


-- 
Dean Povey,         | e-m: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA27851 for ietf-pkix-bks; Wed, 11 Nov 1998 11:58:39 -0800 (PST)
Received: from cpl-mh.cpl.novell.com (cpl-gw-hub.cpl.novell.com [147.2.71.30]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA27847 for <[e-mail]>; Wed, 11 Nov 1998 11:58:37 -0800 (PST)
Received: from HUB-EMEA2-Message_Server by cpl-mh.cpl.novell.com with Novell_GroupWise; Wed, 11 Nov 1998 21:01:22 +0100
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 11 Nov 1998 21:01:12 +0100
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 LAA27848
Sender: [e-mail]
Precedence: bulk

Al,

How can a piece of software tell if the key's useful lifetime has expired?  The onus 
for such a check must logically be upon (1) the CA, or (2) the client software.  
[Here I'm assuming that it is unreasonable to expect users to remember when 
the key in each of their certificates was first created.]

It doesn't seem obvious to me that a CA should make the determination.
If a CA kept a database containing tuples of 
<public key, subject name, date of issue>, the CA could find that it had 
issued a certificate with the same public key and the same subject name X
days/months/years ago given only a CSR (or similar request).  This doesn't
seem like a good idea for two reasons: 
(1)  Not all CAs will be able to keep information about every certificate it has
       ever issued and be able to search it in a reasonable amount of time before
       issuing a new certificate.
(2)  In order for a user to determine that the key has passed its useful lifetime,
       they user must try to renew the certificate _with_the_same_CA_ which is not
       always possible.

That means that the client software should do it.  But, I just don't see how the 
client software can keep track either.  Well, unless some state is kept with each
certificate saying when the key was created.  But, then, where is this state stored?
Surely it should be protected at least by a signature....  But, does it belong
in a certificate?

Lack of a good way discover how old the key in a particular certificate is seems an
excellent reason for client software to enforce a new key for each certificate.  If only
to protect naive users from keeping the same key for years because they know no
better or because they can't remember when they last did a rekey.

Tammy Green Carter
[e-mail]

>>> Al Arsenault <[e-mail]> 11-5-98 1:26:12 PM >>>
<snip>

> Why use the same key?  Why not - assuming that the useful lifetime hasn't
> expired, it's not a security problem. If the useful lifetime hasn't
> expired, we don't let the cert be renewed.

<snip>

				Al Arsenault




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26008 for ietf-pkix-bks; Wed, 11 Nov 1998 08:31:06 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26004 for <[e-mail]>; Wed, 11 Nov 1998 08:31:05 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id LAA10302 for <[e-mail]>; Wed, 11 Nov 1998 11:39:14 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA01469 for <[e-mail]>; Wed, 11 Nov 1998 11:32:09 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B9.005B9215 ; Wed, 11 Nov 1998 11:40:11 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 17:14:43 +0100
Subject: ASN.1 Toolkit
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Hello Everybody,

does anyone know a free ASN.1 Toolkit for developing ASN.1 specifications and
encoding them. Are there any free resources on the internet?

Thanks for your response
Stefan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20975 for ietf-pkix-bks; Wed, 11 Nov 1998 02:01:11 -0800 (PST)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20959 for <[e-mail]>; Wed, 11 Nov 1998 02:01:05 -0800 (PST)
Received: by relay2.elvis.ru (8.8.5/1.30) id NAA23557; Wed, 11 Nov 1998 13:04:11 +0300 (MSK)
Received: from fangorn(194.190.192.48) by ss10 via smap (V2.0) id xma023533; Wed, 11 Nov 98 13:03:31 +0300
Message-ID: <[e-mail]>
X-Mailer: XFMail 1.3 [p0] on Solaris
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Wed, 11 Nov 1998 07:03:02 -0300 (GMT)
From: Pavel Krylov <[e-mail]>
To: [e-mail]
Subject: Subject & Issuer ( LDAP V2 )
Sender: [e-mail]
Precedence: bulk

Hi All!
I'd like to ask You:
        If You remember in LDAPv2 there may be such ( for example ) subject :
        ...,1.3.6.1.4.1.1466.0=#04024869,... It means that certificate->LDAP
        converter didn't understand some ObjectId, therefore it put 
        AttributeValue ( to LDAP ) in form #04[len][octet_string]...
        So, the question is : When another side received this LDAP message,
        what kind of asn1 encoding does the side must do for attributeValue to
        make a certificate ? ( I mean that encode to OCTET tag or another 
        one? ).





___________________________________________________
Pavel V.Krylov          [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA00613 for ietf-pkix-bks; Tue, 10 Nov 1998 16:22:20 -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 QAA00609 for <[e-mail]>; Tue, 10 Nov 1998 16:22:17 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <VLZFY4S7>; Wed, 11 Nov 1998 11:23:19 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC053A29@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: email oid
Date: Wed, 11 Nov 1998 11:23:18 +1100
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

I think this convention came about when people wanted to represent an
internet mailbox in a 
version 1 certificate i.e. exensions were not available to carry it and
CA's could more easily modify
DN than extensions in the early days.

Netscape were probably the first to do this.

Rotek's TrustedNet Smart Card Enabled S/MIME Secure Email

WINS

"INTERACT 98  BEST INTERNET, INTRANET & EXTRANET SOLUTION"

See our Web Site for details

Rotek Consulting 
Melbourne, Australia 
[phone] 
[phone] (Fax) 
www.rotek.com.au 


Andew Probert
Rotek Consulting 
a Division of Secure Network Services
[phone]

> -----Original Message-----
> From:	Russ Housley [SMTP:[e-mail]]
> Sent:	Wednesday, November 11, 1998 8:09 AM
> To:	[e-mail]; [e-mail]
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: email oid
> 
> I just took a look atRFC 1274.  I do not see anything in that document
> that
> leads me to believe that rfc822mailbox was intended to be used as a
> component of a Distrinuished Name.  It is clearly defining an
> attribute for
> sotorage in an X.500 directory.
> 
> On the other hand, I know that the PKCS#9 emailAddress attribute is
> used as
> a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone
> using
> PKCS#9 emailAddress as an attribute in a X.500 directory.
> 
> Maybe there is not an issue...
> 
> Russ
> 
> 
> At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
> >Sue,
> >
> >Adding the additional OID would not be the optimum solution.  Since
> if I
> >have an RDN of EA=[e-mail], am I referring to the
> RFC822mailbox or
> >the pkcs-9 address?  Whichever choice will be wrong sometimes --
> hence the
> >problem.  pkix should NOT perpetuate the problem by again calling the
> same
> >thing two different names.
> >
> >Robert
> >
> >-----Original Message-----
> >From: Miklos, Sue A. <[e-mail]>
> >To: 'Russ Housley' <[e-mail]>
> >Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
> <[e-mail]>;
> >'[e-mail]' <[e-mail]>
> >Date: Friday, October 30, 1998 2:34 PM
> >Subject: RE: email oid
> >
> >
> >>Russ, and others, may I then request that it be included or is that
> not
> >>possible?
> >>
> >>Sandi
> >>
> >>>----------
> >>>From: Russ Housley[SMTP:[e-mail]]
> >>>Sent: Friday, October 30, 1998 1:35 PM
> >>>To: Miklos, Sue A.
> >>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
> >>>Subject: Re: email oid
> >>>
> >>>Sandi:
> >>>
> >>>"Remain" is the issue.  It is not in PKIX part 1!
> >>>
> >>>Russ
> >>>
> >>>
> >>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
> >>>>All,
> >>>>In the specifications for the schema for an international defense
> >>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
> >>>>registered
> >>>>in RFC 1274. This attribute was also called mail in one Internet
> Draft.
> >>>>I would like to request that this remain in whatever documentation
> you
> >>>>develop.
> >>>>
> >>>>Thanks,
> >>>>Sandi Miklos
> >>>>>
> >>>>>
> >>>>>----------
> >>>>>From: Wang, John[SMTP:[e-mail]]
> >>>>>Sent: Thursday, October 29, 1998 9:17 AM
> >>>>>To: 'Robert Klerer'; [e-mail]
> >>>>>Subject: RE: email oid
> >>>>>
> >>>>>It was my understanding that the RSA-pkcs-9 email address OID
> >>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
> >>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
> >>>>>if there is a demand for it.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Robert Klerer [mailto:[e-mail]]
> >>>>>Sent: Thursday, October 29, 1998 8:19 AM
> >>>>>To: [e-mail]
> >>>>>Subject: email oid
> >>>>>
> >>>>>
> >>>>>The other day in trying to accommodate a legacy pki, I ran into a
> >problem
> >>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The
> ASN.1
> >>>>>specifies
> >>>>>that the oid used for an email address in the distinguished name
> is
> >>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.
> I and
> >>>>>others have been using 0.9.2342.19200300.100.1.3 which is for
> internet
> >mail
> >>>>>as specified in RFC1274.
> >>>>>
> >>>>>Since I believe that the intention is for both of these oids are
> meant
> >to
> >>>>>represent attributes that hold the same information, this
> discrepancy
> >may
> >>>>>cause confusion and failures in the future.  My suggestion would
> be to
> >>>>>change part1 to refer to the more commonly used OID.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29434 for ietf-pkix-bks; Tue, 10 Nov 1998 13:21:46 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29430 for <[e-mail]>; Tue, 10 Nov 1998 13:21:45 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1B73>; Tue, 10 Nov 1998 16:22:56 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E20B1AE@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Simonetti David'" <[e-mail]>, IETF-PKIX <[e-mail]>
Subject: RE: Path Validation Variables
Date: Tue, 10 Nov 1998 16:22:54 -0500
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 NAA29431
Sender: [e-mail]
Precedence: bulk

I agree with Dave that the current draft does not permit an application
force policy checking.

> -----Original Message-----
> From:	Simonetti David [SMTP:[e-mail]]
> Sent:	Tuesday, November 10, 1998 3:02 PM
> To:	IETF-PKIX
> Subject:	Path Validation Variables
> 
> The PKIX Profile provides three elements by which to control
> certificate
> policy processing:  the Certificate Policies and Policy Constraint
> extensions, and a set of initial policy identifiers (X.509 calls this
> initial-policy-set).  
> 
> Based on the Basic Path Validation procedues in Section 6.1, these
> three
> elements may interact in a way that allows the application to
> determine:
>  - whether at least one policy present in the initial-policy-set is
> consistently present in all the certs in the certification path (via a
> critical Certificate Policies extension in EACH cert); or
>  - whether at least one policy present in the initial-policy-set is
> present in each cert in the certification path beginning at some point
> (via a critical (or non-critical?) Policy Constraints extension).
> 
> Notice that policy processing in both of these situations is dependent
> on the CA including the associated extension.  Therefore, if these
> extensions are not included in a certificate, then the relying party
> has
> no contribution to this policy processing (initial-policy-set will be
> ignored).
> 
> This seems counterintuitive.  As the relying party I should be allowed
> to have some input on the policies that I accept.  For example, if I
> want my high assurance financial application to only accept other high
> assurance financial certificates, then my application should be able
> to
> implement this constraint.  
> 
> This could be accomplished by setting the initial value of the
> "explicit
> policy state variable" to zero, and including only the "high assurance
> financial certificates" policy into my initial-policy-set.  However,
> PKIX states that the "explicit policy state variable" is set to n+1,
> where n=cert-path-length.  As a result, the initial-policy-set will
> only
> be checked throughout the cert path if the first cert in the path
> includes a policyConstraints extension with requireExplicitPolicy set
> to
> zero.  As a user I have no control over this.
> 
> Has anyone else analyzed this?  X.509 gets around this issue by not
> indicating any initial value for these variables (at least that leaves
> it ambiguous).  I'd like to know if my analysis is valid, and if so
> propose that either there be no recommended initial value for
> "explicit
> policy state variable", or that an initial value of zero be explicitly
> allowed.
> -- 
> David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29311 for ietf-pkix-bks; Tue, 10 Nov 1998 13:06:52 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29307 for <[e-mail]>; Tue, 10 Nov 1998 13:06:51 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.106]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA23175; Tue, 10 Nov 1998 13:08:11 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 16:09:22 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: email oid
Cc: [e-mail], [e-mail]
In-Reply-To: <006f01be044e$f2061e40$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I just took a look atRFC 1274.  I do not see anything in that document that
leads me to believe that rfc822mailbox was intended to be used as a
component of a Distrinuished Name.  It is clearly defining an attribute for
sotorage in an X.500 directory.

On the other hand, I know that the PKCS#9 emailAddress attribute is used as
a compnent of S/MIME v2 Distinguished Names.  I do not know of anyone using
PKCS#9 emailAddress as an attribute in a X.500 directory.

Maybe there is not an issue...

Russ


At 04:47 PM 10/30/98 -0500, Robert Klerer wrote:
>Sue,
>
>Adding the additional OID would not be the optimum solution.  Since if I
>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>problem.  pkix should NOT perpetuate the problem by again calling the same
>thing two different names.
>
>Robert
>
>-----Original Message-----
>From: Miklos, Sue A. <[e-mail]>
>To: 'Russ Housley' <[e-mail]>
>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>'[e-mail]' <[e-mail]>
>Date: Friday, October 30, 1998 2:34 PM
>Subject: RE: email oid
>
>
>>Russ, and others, may I then request that it be included or is that not
>>possible?
>>
>>Sandi
>>
>>>----------
>>>From: Russ Housley[SMTP:[e-mail]]
>>>Sent: Friday, October 30, 1998 1:35 PM
>>>To: Miklos, Sue A.
>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>Subject: Re: email oid
>>>
>>>Sandi:
>>>
>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>
>>>Russ
>>>
>>>
>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>All,
>>>>In the specifications for the schema for an international defense
>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>registered
>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>I would like to request that this remain in whatever documentation you
>>>>develop.
>>>>
>>>>Thanks,
>>>>Sandi Miklos
>>>>>
>>>>>
>>>>>----------
>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>Subject: RE: email oid
>>>>>
>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>if there is a demand for it.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>To: [e-mail]
>>>>>Subject: email oid
>>>>>
>>>>>
>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>problem
>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>specifies
>>>>>that the oid used for an email address in the distinguished name is
>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>mail
>>>>>as specified in RFC1274.
>>>>>
>>>>>Since I believe that the intention is for both of these oids are meant
>to
>>>>>represent attributes that hold the same information, this discrepancy
>may
>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>change part1 to refer to the more commonly used OID.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28615 for ietf-pkix-bks; Tue, 10 Nov 1998 11:58:35 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28611 for <[e-mail]>; Tue, 10 Nov 1998 11:58:34 -0800 (PST)
Received: from bah.com ([156.80.128.156]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA2C3D for <[e-mail]>; Tue, 10 Nov 1998 15:02:00 -0500
Message-ID: <[e-mail]>
Date: Tue, 10 Nov 1998 15:02:21 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
Subject: Path Validation Variables
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 LAA28612
Sender: [e-mail]
Precedence: bulk

The PKIX Profile provides three elements by which to control certificate
policy processing:  the Certificate Policies and Policy Constraint
extensions, and a set of initial policy identifiers (X.509 calls this
initial-policy-set).  

Based on the Basic Path Validation procedues in Section 6.1, these three
elements may interact in a way that allows the application to determine:
 - whether at least one policy present in the initial-policy-set is
consistently present in all the certs in the certification path (via a
critical Certificate Policies extension in EACH cert); or
 - whether at least one policy present in the initial-policy-set is
present in each cert in the certification path beginning at some point
(via a critical (or non-critical?) Policy Constraints extension).

Notice that policy processing in both of these situations is dependent
on the CA including the associated extension.  Therefore, if these
extensions are not included in a certificate, then the relying party has
no contribution to this policy processing (initial-policy-set will be
ignored).

This seems counterintuitive.  As the relying party I should be allowed
to have some input on the policies that I accept.  For example, if I
want my high assurance financial application to only accept other high
assurance financial certificates, then my application should be able to
implement this constraint.  

This could be accomplished by setting the initial value of the "explicit
policy state variable" to zero, and including only the "high assurance
financial certificates" policy into my initial-policy-set.  However,
PKIX states that the "explicit policy state variable" is set to n+1,
where n=cert-path-length.  As a result, the initial-policy-set will only
be checked throughout the cert path if the first cert in the path
includes a policyConstraints extension with requireExplicitPolicy set to
zero.  As a user I have no control over this.

Has anyone else analyzed this?  X.509 gets around this issue by not
indicating any initial value for these variables (at least that leaves
it ambiguous).  I'd like to know if my analysis is valid, and if so
propose that either there be no recommended initial value for "explicit
policy state variable", or that an initial value of zero be explicitly
allowed.
-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA24936 for ietf-pkix-bks; Tue, 10 Nov 1998 05:04:30 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA24932 for <[e-mail]>; Tue, 10 Nov 1998 05:04:29 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA16451; Tue, 10 Nov 1998 05:07:04 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 08:00:56 -0500
To: Robert Moskowitz <[e-mail]>, "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail]>
References: <000001be0b17$7a9e4a60$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In reply to Dwight Arthur's first comment:


>1. You state "If the useful lifetime hasn't expired, we don't let the cert 
>be renewed .." I assume that if the useful key life _has_ expired you do not 
>let it renew. But what do you do then? Are you implying that the entire 
>account history associated with this person should be abandoned and the 
>person treated as a brand new contact? This seems to present a security 
>hole.

AWA:  yes, I apologize for the typo. If the key's useful lifetime has
expired, a certificate CANNOT be renewed.  At that point, the certificate
must at be "updated." (Remember that updating means that the key is
replaced, and if no other attributes are changed, we just call this a
"rekey" operation.)  No, we don't get rid of the account history.  We just
add a new record to our CA's database with the new certificate and relevant
information, and tie it to the old record, which we keep.  (You can't get
rid of the old record until you've taken the explicit step of 'archiving' it.)


Then, Bob Moskowitz replied to Dwight's second question:
>>
>>2. If you allow renewals with the same key for the duration of the key's
>>useful life, why not just set the certificate validity to the key's useful
>>life? What's the benefit of expiring and renewing if not to force a new key?
>>If you are pushing full CRL's I understand that expiration gives an
>>opportuinity to purge the CRL. But there are other ways to manage this,
>>perhaps less costly and certainly less of a burden on the subject.
>>(Examples, OCSP, delta CRL)
>
>But delta CRLs do not address the size of the CRL which impacts processing
>time and total size.  These are issues for silicon implementations.
>
>Reasonable expire dates also address the nature of people NOT to notifiy
>that they have moved to other jobs or died....
>

AWA:  That's a good summary.  Basically, setting the certificate validity
period shorter than the useful key lifetime allows us to manage a couple of
logistics issues.  First, for many of my customers, the longest we can
count on anybody being in one job under normal circumstances is three
years.  It's usually less than that; often, incumbency is on the order of a
few months.  And, no matter how many processes you want to institute about
check-out sheets and notifying all of the cognizant authorities when
somebody quits/transfers/gets fired, a few are going to slip through the
cracks because humans make mistakes.  The CA is just not going to be
notified a certain percentage of the time when people leave the
organization, and the farther away the CA/RA are from the users, the higher
that percentage is.  Setting a shorter certificate validity period makes
the default behavior "better" in that it requires the user to take a
positive action to retain access, rather than having access continue for a
couple more years unless something is explicitly revoked.  (One of the
sections I always try to read in any vendor's CP/CPS is the section on
revocation, loss of access, etc.  Most CA vendors are smart enough to cover
their tails; they say something like "if the user should no longer have
this certificate and you don't explicitly notify us to revoke the cert,
nothing that happens afterward is our fault."  That limits their liability,
but it doesn't help enforce security.)

As Bob points out, the second advantage is that you can control CRL size.
Since we don't use delta-CRLs in our system, the overall length of the CRL
that gets shipped around the system is a concern. Since a revoked
certificate is on the CRL until after it expires, having all certificates
good for three years can lead to a large CRL if you have to revoke a big
group of certificates.  Having shorter certificate lifetimes constrains the
size of the CRL to some degree.  Even if the CRL does get huge at one time
because of the revocation of a large group of certificates for some reason,
we can limit the amount of time the CRL is huge.

As Bob also points out, even if we did use delta-CRLs, size would still be
a problem.  We wouldn't necessarily be worried about sending multi-megabit
CRL files, because they'd be broken into pieces.  But, the end-entities
still have to reconstitute the entire CRL from the base and delta lists,
and the entire thing has to be stored and checked.  For some of the devices
we're required to support, that can potentially be a problem.


							Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00510 for ietf-pkix-bks; Mon, 9 Nov 1998 19:07:07 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00505 for <[e-mail]>; Mon, 9 Nov 1998 19:07:06 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12586; Mon, 9 Nov 1998 19:09:44 -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: Mon, 09 Nov 1998 12:41:02 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: [e-mail]
In-Reply-To: <[e-mail] rtco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

PKIX Part 1 is quite clear on this topic.  It recommends that e-mail
addresses belong in subjectAltName.  However, it warns implementors that
PKCS#9 emailAddress attributes are used by S/MIME v2 as part of the subject
Distringuished Name.

Russ

At 09:43 AM 11/5/98 -0500, [e-mail] wrote:
>E-mail addresses in Certificates sounds good, but please do not put them
>into the Certificate's subject.
>
>A Certificate's subject is a singular Name. A Name is a CHOICE of one type:
>RDNSequence.
>
>S/MIME embeds two names into subject: a distinguished name and an e-mail
>address. Embedding multiple names into subject works OK for S/MIME, but does
>not scale. Just imagine 20 or 30 names.
>
>Should a Certificate contain multiple names? Why not!
>
>One solution is to add a CHOICE to Name each time a new application naming
>system is defined. This system is pretty efficient and works in a closed
>system. In an open system, this solution does not scale very well and
>requires everyone to update their systems.
>
>Another solution is to leave Name alone (RDNSequence remains the common
>"handle") and let application's define Extension(s) for their naming
>systems. For example, Alice might choose to integrate all her names (and
>identifiers) into one monolithic Certificate (e.g., social security number,
>credit card account number, checking account number, email address, etc.),
>while Bob might choose to use separate certificates.
>
>Frank Balluffi
>CertCo
>
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, November 04, 1998 5:18 PM
>To: Phillip M Hallam-Baker
>Cc: [e-mail]
>Subject: Re: Scale (and the SRV record)
>
>
>Phill,
>
>Although I'm very late getting into this particular debate due to being
>away on travel (mostly not Internet connected) for almost 2 weeks, I concur
>with several of the themes of your observations, although I might prefer
>storing certs and CRLs in the DNS per se, rather than using DNS records as
>pointers to othyer repositories.
>
>The DNS is the only robust, distributed directory system the Internet has.
>That makes it attractive for two things: storing data, such as certs and
>CRLs, and for its naming tree.  Note that anytime we use a name in a cert
>that is not exactly the same as the name we use in an application, we are
>required to perform a mapping between two name spaces, and that introduces
>another database which imposes significant additional management overhead
>and another place to make errors with adverse security implications.  So,
>for example, for IPsec, i really want certs with DNS names and IP
>addresses, since these are the native name forms that the applications
>employ and upon which access control decisions are made.  For SSL, browsers
>check a DNS name in a certificate against the corresponding portion of the
>URL, and ignore the rest of the DN in the subject field.  For e-mail the
>case may not be so strong, since people may mentally map identifies
>irrespective of e-mail addresses, but even there I worry that cognitive
>overload can eaisly set in and cause people to make perception mistakes.
>(If one has an S/MIME system that automatically checks for the
>correspondence between the "from" address and the sender's DN from his
>cert, instead of presenting the subject DN from the certificate, then the
>above arguments apply.) So, here too, I really prefer certs with e-mail
>addresses, which is a change from a stance I adopted years ago when I wrote
>RFC 1422.
>
>Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21584 for ietf-pkix-bks; Mon, 9 Nov 1998 08:57:51 -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 IAA21579 for <[e-mail]>; Mon, 9 Nov 1998 08:57:50 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA19525; Mon, 9 Nov 1998 08:58:09 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA07889; Mon, 9 Nov 1998 09:00:26 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "David Sweigert" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Larowe, Rick" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "'Paul Koning'" <[e-mail]>, <[e-mail]>
Subject: RE: Scale (and the SRV record) 
Date: Mon, 9 Nov 1998 12:00:57 -0500
Message-ID: <000001be0c02$858f9500$[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: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

> This brings up the question of tactical PKI; or digital certs 
> that are "lightweight" -- 1/10th the size of a X.509v3 cert.

Please no! We have explored that particular rathole more than once.

Four years back before there was a large deployed base of X.509v3 on
the Internet the question of encoding format was an open one. Today
there are many toolkits available which perform parsing. The path of
least resistance for an implementer is now to use CAPI or one of the 
numerous third party toolkits.

I don't think the 'handheld' argument is compelling. Having written
a number of X.509 encoders and decoders I don't see writing a 
compact decoder as being much of a problem. If you are willing to
accept a very narrow profile of the PKIX profile a table driven 
decoder can be written in about a Kb of code.

If you profile PKIX very narrowly you can have a certificate with
just the issuer and subject names, a policy attribute and the subject 
key. The overhead over the public key bits being perhaps 100 bytes.

I don't see how a certificate 'a tenth the size' of such a 'liposuctioned'
PKIX cert is going to be possible. The problem with ASN.1 BER and DER
is not the compactness of the representation.


		Phill
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22960 for ietf-pkix-bks; Sun, 8 Nov 1998 06:22:36 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22956 for <[e-mail]>; Sun, 8 Nov 1998 06:22:35 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA95; Sun, 8 Nov 1998 09:25:36 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 08 Nov 1998 09:25:55 -0500
To: "Dwight Arthur" <[e-mail]>, "Al Arsenault" <[e-mail]>, <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <000001be0b17$7a9e4a60$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 07:58 AM 11/8/98 -0500, Dwight Arthur wrote:
>
>2. If you allow renewals with the same key for the duration of the key's
>useful life, why not just set the certificate validity to the key's useful
>life? What's the benefit of expiring and renewing if not to force a new key?
>If you are pushing full CRL's I understand that expiration gives an
>opportuinity to purge the CRL. But there are other ways to manage this,
>perhaps less costly and certainly less of a burden on the subject.
>(Examples, OCSP, delta CRL)

But delta CRLs do not address the size of the CRL which impacts processing
time and total size.  These are issues for silicon implementations.

Reasonable expire dates also address the nature of people NOT to notifiy
that they have moved to other jobs or died....


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22757 for ietf-pkix-bks; Sun, 8 Nov 1998 04:55:40 -0800 (PST)
Received: from dewdrop2.mindspring.com (dewdrop2.mindspring.com [207.69.200.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22753 for <[e-mail]>; Sun, 8 Nov 1998 04:55:39 -0800 (PST)
Received: from NS95LAP005.nscc.com (pool-209-138-0-245.nwrk.grid.net [209.138.0.245]) by dewdrop2.mindspring.com (8.8.5/8.8.5) with SMTP id HAA24836; Sun, 8 Nov 1998 07:58:36 -0500 (EST)
From: "Dwight Arthur" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
Date: Sun, 8 Nov 1998 07:58:26 -0500
Message-ID: <000001be0b17$7a9e4a60$[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.2232.26
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

I have a couple of questions:

1. You state "If the useful lifetime hasn't expired, we don't let the cert
be renewed .." I assume that if the useful key life _has_ expired you do not
letit renew. But what do you do then? Are you implying that the entire
account history associated with this person should be abandoned and the
person treated as a brand new contact? This seems to present a security
hole.

2. If you allow renewals with the same key for the duration of the key's
useful life, why not just set the certificate validity to the key's useful
life? What's the benefit of expiring and renewing if not to force a new key?
If you are pushing full CRL's I understand that expiration gives an
opportuinity to purge the CRL. But there are other ways to manage this,
perhaps less costly and certainly less of a burden on the subject.
(Examples, OCSP, delta CRL)
--------------------------------------------------
p:[phone]                     Dwight Arthur
f:[phone]        Managing Director: Systems
b:[phone]      National Securities Clearing
[e-mail]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
From:	[e-mail] [mailto:[e-mail]] On Behalf Of
Al Arsenault
Sent:	Thursday, November 05, 1998 3:26 PM
To:	Dwight Arthur; [e-mail]
Subject:	RE: Is certificate renewal a good idea?

In the PKI with which I am familiar (which has been operational for more
than 3 and 1/2 years now), we use a couple of different terms:

	renewal:  issue a new certificate with the same DN, the same attributes,
the same key, a different certificate serial number, and a different
validity period

	update:  issue a new certificate with the same DN, but with one or more
new attributes, a new key, a different certificate serial number, and a
different validity period (where here, "attribute" means any field in the
certificate other than the subject DN, issuer DN, certificate serial
number, or validity period).

"Renewal" is used when a user is continuing on in the same job.  E.g.,
certificates are issued for a period of 6 months.  At the end of that time,
the user is in the same job, at the same place, with the same privileges,
etc.  We just give the user a renewed certificate, good for another six
months, because nothing else is changed.  We change the serial number to
distinguish between the old and new certs - it's the issuer/serial number
combination that uniquely identifies the certificate.  And, obviously, the
signature value changes.

Why use the same key?  Why not - assuming that the useful lifetime hasn't
expired, it's not a security problem. If the useful lifetime hasn't
expired, we don't let the cert be renewed.

"Update" is when something else (other than the user's name) has changed -
the user's access authorizations, privileges, etc. In that case, we revoke
the old certificate, because the change may have resulted in the loss of
access, and we want to make sure that the old cert won't work.  We demand a
new key for the same reason.  (Strictly speaking, you wouldn't have to
revoke the old certificate if the change resulted in an increase of access
privileges, but it's administratively easier to just always revoke the old
cert.)

If the only attribute that changes in an "update" is the user's public key,
it's called a "rekey", but the same rules apply.

Note that in a renewal, you can have multiple certificates valid for the
same user at the same time (if you issue the renewal before the old
certificate expires, which is generally considered to be the smart thing to
do).  Since the public key's the same (and thus the associated private
key's the same) it's not a major problem, assuming that the end-entity is
capable of dealing with the fact that there are two certs for the same user
in the repository.

				Al Arsenault


-- these are my opinions only.  They do not necessarily reflect the
opinions of my employer, or of any other organization with which I have a
relationship.




At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>At the National Securities Clearing Corporation we are beginning to face
>renewal requirements. In every case we are talking about same CN, same CA,
>same DN, and different validity period. I would like to say that in all
>cases we will be seeing a new public key, and we would certainly discourage
>the idea or re-certifying the same key, but I cannot guarantee that we will
>never see renewal with the same public key.
>
>Two requirements that we consider critical, but not easily fulfilled given
>the current state of the are, are:
>- DN in renewed certificate is exactly identical to DN in original
>certificate.
>- Start of renewed certificate's validity period is exactly equal to
>expiration of the original certificate's validity period no overlap no gap.
>The renewed certificate would be issued as much as six weeks before the
>start of its validity period.
>--------------------------------------------------
>p:[phone]                     Dwight Arthur
>f:[phone]        Managing Director: Systems
>b:[phone]      National Securities Clearing
>[e-mail]        55 Water Street
>http://www.nscc.com        New York, NY 10041-0082
>
>-----Original Message-----
>>	Actually, the most prevalent case is likely to be:
>>	3) Same CA, different public key, same CN
>>
>Really?  I always thought it would be validity date.  Of course this would
>be about 18 months after PKI rollout.
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA11935 for ietf-pkix-bks; Sat, 7 Nov 1998 15:04:29 -0800 (PST)
Received: from dns05fdr.Firstdatacorp.COM ([170.186.38.195]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA11931 for <[e-mail]>; Sat, 7 Nov 1998 15:04:27 -0800 (PST)
From: [e-mail]
Received: (from smtp@localhost) by dns05fdr.Firstdatacorp.COM (8.9.1a/8.9.1) id QAA19645; Sat, 7 Nov 1998 16:55:03 -0600 (CST)
X-Authentication-Warning: dns05fdr.firstdatacorp.com: smtp set sender to <[e-mail]> using -f
Received: from () by dns05fdr via smap (V2.1) id xma019640; Sat, 7 Nov 98 16:54:58 -0600
Received: by firstdatacorp.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 862566B5.007D9F08 ; Sat, 7 Nov 1998 16:52:07 -0600
X-Lotus-FromDomain: FDC@FDCNOTESPO
To: David Sweigert <[e-mail]>
cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 7 Nov 1998 15:05:15 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

,,,, relying party certificates was something that a european financial
institution brought up at NISSC during e-commerce session (issues addressed
were business issues associated  privacy and liability .... wasn't
technical issue regarding size or bandwidth, etc). In discussions
afterwards .... the processing flow is almost identical to X9.59 and AADS
.... the difference is that one of these certificates flows along with the
transaction and gets to the relying party .... where (if they hadn't
noticed) they had the original (i.e. client was appending a copy of the
certificate to the end of of every transaction sent to the relying pary
.... which had the original ... easy to show it was superfulous).

nissc web site is
                   http://csrc.nist.gov/nissc/1998/

but there is nothing there on that particular discussion.

They also mentioned an evidence server to validate parts of the
infrastructure. That part is also nearly identical to part of an overall
infrastructure that i've been presenting for last 8-9 months (which have
had included europeans in the audience).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11331 for ietf-pkix-bks; Sat, 7 Nov 1998 13:23:23 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA11327 for <[e-mail]>; Sat, 7 Nov 1998 13:23:21 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa11520; 7 Nov 98 16:25 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 07 Nov 1998 16:23:49 -0500
To: [e-mail]
From: David Sweigert <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Lynn:

Sounds very similiar to what you are speaking of.  Is there a formal
articulation of the proposed relying party certificates; and is so
do you have a URL you can point me to ?

Thanks in advance.

dave

At 03:37 PM 11/6/98 -0800, [e-mail] wrote:

>re: tatical certificates; is this similar to or different than the relying
>party certificates that are being proposed (at least in part) because of
>privacy issues (i.e. divulge nothing but an identification number and the
>public key)???
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17288 for ietf-pkix-bks; Fri, 6 Nov 1998 17:47:32 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA17284 for <[e-mail]>; Fri, 6 Nov 1998 17:47:31 -0800 (PST)
Received: (qmail 5102 invoked from network); 7 Nov 1998 01:50:29 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 7 Nov 1998 01:50:29 -0000
Received: (qmail 1448 invoked from network); 7 Nov 1998 01:50:28 -0000
Received: from unknown (HELO rhone) (10.0.0.101) by 10.0.0.4 with SMTP; 7 Nov 1998 01:50:28 -0000
From: "Ambarish Malpani (test)" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: More problems with OCSP
Date: Fri, 6 Nov 1998 17:50:45 -0800
Message-ID: <000c01be09f1$0996aaf0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01BE09AD.FB736AF0"
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

This is a multi-part message in MIME format.

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


Hi Peter,
    Actually, even if you wanted to act as a general OCSP responder,
you would still need to have a set of CAs that you trust - since
you would need to be able to verify their revocation data (or CRL),
to create the OCSP response (except if you assume you have a
trusted directory, whose entries you trust blindly).

Once you have the list of CAs you trust, you should have both their
names and their private keys. So you should be able to act
as a general responder as long as the CAs you trust are a
(improper) superset of the CAs your clients trust.

Ambarish

------=_NextPart_000_000D_01BE09AD.FB736AF0
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Reply-To: <[e-mail]>
From: "Peter Gutmann" <[e-mail]>
Sender: <[e-mail]>
To: <[e-mail]>,
	<[e-mail]>
Subject: Re: More problems with OCSP
Date: Sat, 7 Nov 1998 03:19:25 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz

[I've copied this part of the message back to PKIX because I think it's more
a
 general discussion of OCSP philosophy]

>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.

This only works if you know in advance which CA's you plan to serve.  The
model I had for an OCSP responder is that they work like an SNMP element
manager where your toaster contacts the element manager to ask "is this
thing
valid?".  The element manager then goes out and wanders all over the X.500
directory space pulling out certs and CRL's and whatnot, checks their
validity, and tells the toaster "yes" or "no".  This means that the
responder
will have to be able to process arbitrary certs from arbitrary CA's.  At the
moment the CertID only works if either the OCSP responder is run by the CA
(it
knows which CertID's it has to work with) or is tied to a very small number
of
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary
CertID, it's not possible for an OCSP responder to provide a useful
response.

Peter.


------=_NextPart_000_000D_01BE09AD.FB736AF0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17143 for ietf-pkix-bks; Fri, 6 Nov 1998 17:15:59 -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 RAA17138 for <[e-mail]>; Fri, 6 Nov 1998 17:15:58 -0800 (PST)
Received: (from uucp@localhost) by btec-fw.certco.com (8.8.8/8.8.8) id UAA11630; Fri, 6 Nov 1998 20:18:39 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com(192.168.69.12) by btec-fw.certco.com via smap (V2.1) id xma011628; Fri, 6 Nov 98 20:18:12 -0500
Received: from kar.ma.certco.com ([10.200.200.55]) by nycertco-srv1.ny.certco.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id W1RH1TCR; Fri, 6 Nov 1998 20:18:11 -0500
Received: (from salzr@localhost) by kar.ma.certco.com (8.9.0/8.9.0) id UAA18538; Fri, 6 Nov 1998 20:18:11 -0500 (EST)
Date: Fri, 6 Nov 1998 20:18:11 -0500 (EST)
From: Rich Salz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: More problems with OCSP
Sender: [e-mail]
Precedence: bulk

>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
 This is why I thought it a mistake why removing the ability to send the
 whole cert was a mistake at the end of the OCSP development.  For the
 sake of some network traffic, a severe implmentation constraint was
 imposed.  Unfortunately my view wasn't in the consensus.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16465 for ietf-pkix-bks; Fri, 6 Nov 1998 15:36:53 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16460 for <[e-mail]>; Fri, 6 Nov 1998 15:36:47 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id SAA29918; Fri, 6 Nov 1998 18:39:44 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id SAA05807; Fri, 6 Nov 1998 18:39:42 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.0081A311 ; Fri, 6 Nov 1998 18:35:58 -0500
X-Lotus-FromDomain: FDC
To: David Sweigert <[e-mail]>
cc: [e-mail], Stephen Kent <[e-mail]>, "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 15:37:47 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

re: tatical certificates; is this similar to or different than the relying
party certificates that are being proposed (at least in part) because of
privacy issues (i.e. divulge nothing but an identification number and the
public key)???




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA16200 for ietf-pkix-bks; Fri, 6 Nov 1998 15:00:50 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16196 for <[e-mail]>; Fri, 6 Nov 1998 15:00:45 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id XAA05643; Fri, 6 Nov 1998 23:06:14 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 23:03:42 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
CC: EKR <[e-mail]>
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> "Frank O'Dwyer" <[e-mail]> writes:
> > For most applications the vulnerability is significantly
> > reduced by ensuring that the certificate corresponds to the user
> > interface, and removing any name mappings that are subvertible and
> > hidden from the user.
> The number of applications for which that can be done is shrinking
> rapidly, as users get increasingly divorced from network naming.

All the more reason to stop checking just those names and check the name
forms that are actually visible. (I just mean removing dependency on
those name mappings for security btw., obviously they will still be
present.)

> > > > user clicks on a pepsi logo with a https link, the server certificate
> > > > could contain that logo in an appropriate extension and it could be
> > > > mechanically checked for.
> > > This really can't work, in the face of the n different sizes and color
> > > variants of the logos.
> >
> > That's not true. Images can be scaled in HTML (so you just need the logo
> > in its largest size).
> 1. Images are almost never done in HTML. They're GIFs.

Right, but they are presented by dereferencing and rendering HTML IMG
tags, which may contain scaling attributes. This means that the same
source image can be presented at different scales just by rewriting the
HTML.

> 2. Images aren't CANONICALLY scaled, so this makes the rescaled
> logo unverifiable.

No, that's not correct. If the IMG tag is used to do the scaling, then
the source image is the same string of bits no matter how it is scaled
for presentation. Only the enclosing HTML differs. (Some other image
formats are even designed to render the same image at any scale, but
unfortunately those aren't used by the browsers. I don't know whether
PNG is like that or not.)

> > As far as color and other variants go there will
> > be a small number of those, and in any case only one is necessary to
> > identify a secure service.
> Right, but this requires the web page developer to choose only
> one logo and stick with it. I don't believe it.

The only difficulty I see is where a corporation alters its logo, which
does happen. But that is no different than a corporate or DNS name
change, which also happen -- you just get a new certificate. As for web
developers, they can be made use what ever logos they are given. Given
the current risk of (say) spoofing an online banking service, which is
considerable, there is plenty of incentive for an organisation to make
this happen. Nor would there be any added security risk if the developer
used the wrong logo, either, it would just mean the page would load with
severe security warnings (assuming browsers actually made this check).

> > However the tls-https spec currently has a MUST for using
> > the dns altname if it is present--it's not clear if that simply means it
> > is to be used instead of the common name, or if you are barred from
> > performing other checks instead or additionally.
> It seems clear enough to me. You MUST do the subjectAltName check. It
> certainly doesn't preclude other checks as well.
> Moreover, -02 says
>    If the client has external information as to the expected identity of
>    the server, the hostname check MAY be omitted.
> 
> Your check would fall into this category.

OK, then that is just a misreading on my part. The version I have says
"if a subjectAltName of type dNSName is present, that MUST be used as
the identity". I took that to override the previous paragraph, which
contains your text above.

> > > Except that this is easily spoofed by having the certificate say
> > > "Bank of Mafia" and getting the user to click on "bank" when you
> > > change the page.
> >
> > No, I didn't mean to imply a substring check--I meant actually checking
> > that the phrases exactly matched.
> Yeah, I still don't buy it.
> I don't believe users will carefully check for the difference
> between
> "Bank of Foo"
> and
> "Bank of a Foo"
> for instance.

OK, on one level it's a mechanical check, and the browser would do it.
On another level, yes, the user could confuse the text of the link with
some other name and still be spoofed. The nastiest case of that would be
where two separate organisations actually possess the same name in
different jurisdictions. That is a problem of reliance on global names,
which is a general PKIX problem. Other cases include things like
"Micros0ft", however I can't think of any plausible variant of (say)
"Bank of Ireland" that misdirects to an attacker AND that someone could
get a trustworthy certificate for. ("Bank of 1reland" is the best I can
come up with--and I can't see any trustworthy CA issuing that, unless in
error to the bank itself.) Regardless, this is still a stronger defense
than the hostname check alone. Without this check the user doesn't need
to misread the link at all (it need only be unaware of network names)
and the attacker has to do less work. 

> There are simply too many lookalike variants. Now, if there was only
> one CA, you could expect them to enforce uniqueness across variants,
> as the PTO does (poorly). However, in the face of multiple CAs ,
> I don't believe this will work.

Even if so, a lot of organisations propose to be their own CA. If it
worked for them, that's better than not addressing the problem at all.

> To be blunt, I believe this is a lost cause. I've heard
> a nearly infinite number of such proposals over the years,
> and IMHO none of them stand up to close scrutiny.

Well, the difficulty with that view is that the proposal to only check
the DNS hostname doesn't stand up to close scrutiny either. Why dismiss
the others and accept that? Regardless, if you agree it's a serious
concern and you think it's not fixable, then I think the spec should at
least bring it to people's attention. 

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA15837 for ietf-pkix-bks; Fri, 6 Nov 1998 14:16:40 -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 OAA15833 for <[e-mail]>; Fri, 6 Nov 1998 14:16:38 -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 LAA11075; Sat, 7 Nov 1998 11:19:25 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91039076508924>; Sat, 7 Nov 1998 11:19:25 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: More problems with OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 7 Nov 1998 11:19:25 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[I've copied this part of the message back to PKIX because I think it's more a 
 general discussion of OCSP philosophy]
 
>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
This only works if you know in advance which CA's you plan to serve.  The 
model I had for an OCSP responder is that they work like an SNMP element 
manager where your toaster contacts the element manager to ask "is this thing 
valid?".  The element manager then goes out and wanders all over the X.500 
directory space pulling out certs and CRL's and whatnot, checks their 
validity, and tells the toaster "yes" or "no".  This means that the responder 
will have to be able to process arbitrary certs from arbitrary CA's.  At the 
moment the CertID only works if either the OCSP responder is run by the CA (it 
knows which CertID's it has to work with) or is tied to a very small number of 
CA's whose CertID's it has hardcoded in.  Given a query with an arbitrary 
CertID, it's not possible for an OCSP responder to provide a useful response.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15668 for ietf-pkix-bks; Fri, 6 Nov 1998 13:59:55 -0800 (PST)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15664 for <[e-mail]>; Fri, 6 Nov 1998 13:59:49 -0800 (PST)
Received: from coldhcp1-185.bbn.com by COLUMBIA.BBN.COM id aa00784; 6 Nov 98 16:57 EST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 06 Nov 1998 16:55:35 -0500
To: [e-mail], Stephen Kent <[e-mail]>
From: David Sweigert <[e-mail]>
Subject: Re: Scale (and the SRV record) 
Cc: "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Thu, 05 Nov 1998 18:43:15 EST."             <v0401170bb267e710f05f@[128.33.238.37]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

This brings up the question of tactical PKI; or digital certs 
that are "lightweight" -- 1/10th the size of a X.509v3 cert.

Dave

At 01:57 PM 11/6/98 -0500, Perry E. Metzger wrote:
>
>Stephen Kent writes:
>> Good point, but I'm loathe to skew the current model for the benefit of
>> some of these devices.  The PDAs are getting pretty powerful; phones and
>> pagers do pose more of a problem.  I'm not worried about my watch needing
>> to validate the cert for WWV.
>
>On the other hand, you should be worried about your pacemaker getting
>commands from anyone other than an authorized source.
>
>Within less than ten years, desktop machines are going to start
>dissolving with mobile platforms becoming universal. Those that skoff
>at this are suffering from "Vannevar's Syndrome" -- the inability to
>notice already extant technology (named for Vannevar Bush's famous
>gaffe where he predicted water cooled vacuum tube computers the size
>of skyscrapers substantially after the transistor was already
>invented.) The proofs of concept are already out there.
>
>Right now, you can pack virtually the entire functionality of a
>substantial desktop computer into a pack of cigarettes. People don't
>do that largely because keyboards, CD-ROM drives and displays get in
>the way, so they just build "laptops". Given chord keyboards and
>eyeglass displays, or voice i/o, or one of a dozen other things, the
>issue of keyboards and displays goes away. Given a multi-megabit
>constant mobile internet connection (see the current W-CDMA proposals
>which are already being pushed by serious companies) you no longer
>will really need the CD-ROM (and probably don't need it now.)
>
>In a decade or maybe fifteen years, we're still going to have an
>internet and still going to need digital signature technology, but the
>end points are generally going to be things attached to people which
>are almost unnoticeable in size. I do not believe we actually need to
>alter the models we are working with, but if it turned out that we
>*did* need to alter those models to fit mobile applications, it would
>be foolish to think that we were "skewing the model to deal with rare
>devices" given that these devices will not be rare for long.
>
>Perry
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14018 for ietf-pkix-bks; Fri, 6 Nov 1998 10:55:23 -0800 (PST)
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14014 for <[e-mail]>; Fri, 6 Nov 1998 10:55:21 -0800 (PST)
Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA06413; Fri, 6 Nov 1998 13:57:34 -0500 (EST)
Message-Id: <[e-mail]>
To: Stephen Kent <[e-mail]>
cc: "Larowe, Rick" <[e-mail]>, Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record) 
In-reply-to: Your message of "Thu, 05 Nov 1998 18:43:15 EST." <v0401170bb267e710f05f@[128.33.238.37]> 
Reply-To: [e-mail]
X-Reposting-Policy: redistribute only with permission
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 06 Nov 1998 13:57:33 -0500
From: "Perry E. Metzger" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Stephen Kent writes:
> Good point, but I'm loathe to skew the current model for the benefit of
> some of these devices.  The PDAs are getting pretty powerful; phones and
> pagers do pose more of a problem.  I'm not worried about my watch needing
> to validate the cert for WWV.

On the other hand, you should be worried about your pacemaker getting
commands from anyone other than an authorized source.

Within less than ten years, desktop machines are going to start
dissolving with mobile platforms becoming universal. Those that skoff
at this are suffering from "Vannevar's Syndrome" -- the inability to
notice already extant technology (named for Vannevar Bush's famous
gaffe where he predicted water cooled vacuum tube computers the size
of skyscrapers substantially after the transistor was already
invented.) The proofs of concept are already out there.

Right now, you can pack virtually the entire functionality of a
substantial desktop computer into a pack of cigarettes. People don't
do that largely because keyboards, CD-ROM drives and displays get in
the way, so they just build "laptops". Given chord keyboards and
eyeglass displays, or voice i/o, or one of a dozen other things, the
issue of keyboards and displays goes away. Given a multi-megabit
constant mobile internet connection (see the current W-CDMA proposals
which are already being pushed by serious companies) you no longer
will really need the CD-ROM (and probably don't need it now.)

In a decade or maybe fifteen years, we're still going to have an
internet and still going to need digital signature technology, but the
end points are generally going to be things attached to people which
are almost unnoticeable in size. I do not believe we actually need to
alter the models we are working with, but if it turned out that we
*did* need to alter those models to fit mobile applications, it would
be foolish to think that we were "skewing the model to deal with rare
devices" given that these devices will not be rare for long.

Perry


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13949 for ietf-pkix-bks; Fri, 6 Nov 1998 10:45:58 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13945 for <[e-mail]>; Fri, 6 Nov 1998 10:45:56 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id KAA01074; Fri, 6 Nov 1998 10:47:33 -0800 (PST)
To: "Frank O'Dwyer" <[e-mail]>
Cc: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 06 Nov 1998 10:47:32 -0800
In-Reply-To: "Frank O'Dwyer"'s message of "Fri, 06 Nov 1998 18:13:59 +0000"
Message-ID: <[e-mail]>
Lines: 102
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Frank O'Dwyer" <[e-mail]> writes:
> EKR wrote:
> > "Frank O'Dwyer" <[e-mail]> writes:
> > > The minor flaw may apply to TLS in general, in that UDP/TCP transport
> > > connections are identified by a 4-tuple {source host, source port,
> > > destination host, destination port} but tls-https only authenticates the
> > > destination host, not the port. This leaves scope for one TLS service to
> > > impersonate another, provided they have the same DNS hostname. The same
> > > problem exists for different and seperately-administered HTTPS services
> > > at the same DNS hostname but at different well-known ports. This might
> > > be fixable via appropriate trust criteria on the certificates, but I
> > > think a more straightforward fix is to either include the port number in
> > > the server identity and mechanically check for it, and/or (for backward
> > > compatibility) to forbid reuse of a DNS hostname for TLS services
> > > running on different well-known ports.
> > Yes, this is an issue, but I consider it a much less important one.
> > Primarily, end-node machines should arrange that this can't
> > happen.
> 
> OK, but this should be stated somewhere (perhaps the base TLS spec).
Feel free to tell the TLS editors.

> > > The major problem is hyperlink/web spoofing (see
> > > http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> > > http://www.cs.princeton.edu/sip/).
> > Sure. This has been a problem since day one. But it's basically
> > unfixable. This isn't just a problem with TLS. It's a problem with
> > any system anywhere that's ever purported to verify certificates
> > mechanically. To whit: You need to verify that the user's expectations
> > for who they are talking to match who they are in fact talking to.
> > Except that we don't have direct access to the user's expectations.
> 
> Yes, it's a general problem, and there is no 100% fix, but still some
> certificate checks are better than others (otherwise why specify any
> check at all?). For most applications the vulnerability is significantly
> reduced by ensuring that the certificate corresponds to the user
> interface, and removing any name mappings that are subvertible and
> hidden from the user.
The number of applications for which that can be done is shrinking
rapidly, as users get increasingly divorced from network naming.

> > > This issue should at least be pointed
> > > out in a "security considerations" section or similar. It's difficult to
> > > fix, but in some cases mechanical checks can be made. For example, if a
> > > user clicks on a pepsi logo with a https link, the server certificate
> > > could contain that logo in an appropriate extension and it could be
> > > mechanically checked for.
> > This really can't work, in the face of the n different sizes and color
> > variants of the logos. 
> 
> That's not true. Images can be scaled in HTML (so you just need the logo
> in its largest size).
1. Images are almost never done in HTML. They're GIFs.
2. Images aren't CANONICALLY scaled, so this makes the rescaled
logo unverifiable. 

> As far as color and other variants go there will
> be a small number of those, and in any case only one is necessary to
> identify a secure service.
Right, but this requires the web page developer to choose only
one logo and stick with it. I don't believe it.

> However the tls-https spec currently has a MUST for using
> the dns altname if it is present--it's not clear if that simply means it
> is to be used instead of the common name, or if you are barred from
> performing other checks instead or additionally.
It seems clear enough to me. You MUST do the subjectAltName check. It
certainly doesn't preclude other checks as well.
Moreover, -02 says
   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.

Your check would fall into this category.

> > Except that this is easily spoofed by having the certificate say
> > "Bank of Mafia" and getting the user to click on "bank" when you
> > change the page.
> 
> No, I didn't mean to imply a substring check--I meant actually checking
> that the phrases exactly matched.
Yeah, I still don't buy it. 
I don't believe users will carefully check for the difference
between 
"Bank of Foo"
and 
"Bank of a Foo"

for instance.

There are simply too many lookalike variants. Now, if there was only
one CA, you could expect them to enforce uniqueness across variants,
as the PTO does (poorly). However, in the face of multiple CAs ,
I don't believe this will work.

To be blunt, I believe this is a lost cause. I've heard
a nearly infinite number of such proposals over the years,
and IMHO none of them stand up to close scrutiny.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13643 for ietf-pkix-bks; Fri, 6 Nov 1998 10:11:55 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13639 for <[e-mail]>; Fri, 6 Nov 1998 10:11:49 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id SAA05436; Fri, 6 Nov 1998 18:16:32 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 18:13:59 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> "Frank O'Dwyer" <[e-mail]> writes:
> > The minor flaw may apply to TLS in general, in that UDP/TCP transport
> > connections are identified by a 4-tuple {source host, source port,
> > destination host, destination port} but tls-https only authenticates the
> > destination host, not the port. This leaves scope for one TLS service to
> > impersonate another, provided they have the same DNS hostname. The same
> > problem exists for different and seperately-administered HTTPS services
> > at the same DNS hostname but at different well-known ports. This might
> > be fixable via appropriate trust criteria on the certificates, but I
> > think a more straightforward fix is to either include the port number in
> > the server identity and mechanically check for it, and/or (for backward
> > compatibility) to forbid reuse of a DNS hostname for TLS services
> > running on different well-known ports.
> Yes, this is an issue, but I consider it a much less important one.
> Primarily, end-node machines should arrange that this can't
> happen.

OK, but this should be stated somewhere (perhaps the base TLS spec).

> > The major problem is hyperlink/web spoofing (see
> > http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> > http://www.cs.princeton.edu/sip/).
> Sure. This has been a problem since day one. But it's basically
> unfixable. This isn't just a problem with TLS. It's a problem with
> any system anywhere that's ever purported to verify certificates
> mechanically. To whit: You need to verify that the user's expectations
> for who they are talking to match who they are in fact talking to.
> Except that we don't have direct access to the user's expectations.

Yes, it's a general problem, and there is no 100% fix, but still some
certificate checks are better than others (otherwise why specify any
check at all?). For most applications the vulnerability is significantly
reduced by ensuring that the certificate corresponds to the user
interface, and removing any name mappings that are subvertible and
hidden from the user. For example TLS used with a normal telnet client
would be less vulnerable since a DNS name is what you type in there. 

> > This issue should at least be pointed
> > out in a "security considerations" section or similar. It's difficult to
> > fix, but in some cases mechanical checks can be made. For example, if a
> > user clicks on a pepsi logo with a https link, the server certificate
> > could contain that logo in an appropriate extension and it could be
> > mechanically checked for.
> This really can't work, in the face of the n different sizes and color
> variants of the logos. 

That's not true. Images can be scaled in HTML (so you just need the logo
in its largest size). As far as color and other variants go there will
be a small number of those, and in any case only one is necessary to
identify a secure service. To reduce the size of the extension, a hash
of the image bits could be used instead of the bits themselves.

> Worse yet, the certificate ISN'T in the
> certificate.

That is easily fixed (I assume you mean the logo isn't there today). I'm
not sure if a suitable extension already exists for it (probably not)
but it should be just another alt name form. (It would certainly be more
useful than some of the cruft that is currently allowed in
certificates.) However the tls-https spec currently has a MUST for using
the dns altname if it is present--it's not clear if that simply means it
is to be used instead of the common name, or if you are barred from
performing other checks instead or additionally. The latter
interpretation precludes the use of a superior check if you have one.

> > Similarly, if the user clicks on the phrase
> > "Bank of Foo online banking", the server certificate could contain that
> > phrase and it could be checked for.
> Except that this is easily spoofed by having the certificate say
> "Bank of Mafia" and getting the user to click on "bank" when you
> change the page.

No, I didn't mean to imply a substring check--I meant actually checking
that the phrases exactly matched. You could put a regular expression or
wildcards in the cert but then you'd need to be careful of attacks like
the one you describe. To avoid having to include every hyperlink phrase
used on a https site, or unduly constraining the content of those sites,
this really only needs to be checked when you move from one site to
another. 

Cheers,
Frank O'Dwyer


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13386 for ietf-pkix-bks; Fri, 6 Nov 1998 09:26:30 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13377 for <[e-mail]>; Fri, 6 Nov 1998 09:26:28 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id MAA09792; Fri, 6 Nov 1998 12:28:00 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA21410; Fri, 6 Nov 1998 12:26:36 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.005F76A7 ; Fri, 6 Nov 1998 12:22:42 -0500
X-Lotus-FromDomain: FDC
To: Jun Yoshitake <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 09:18:54 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

there are financial infrastructures that have much higher integrity than
any of the CAs or public key infrastructures (i.e. spending past six years
getting to the point where there is no down time).
When my wife & I were running skunk works in the 80s doing high speed data
transport & high availability product  ... i coined the term disaster
servivability (to distinquish from disaster recovery ... requiring hot
operation with geographic seperation).

Part of insuring the integrity of a financial transaction is having access
to being able to complete every transaction. Places have gone to the point
of guarentee that all information is available in a single place for the
completion of the transaction .... bunkering that single place with
no-single-point-of-failure iredundancy and UPS with diesel back-up; and
then replicating the facility at two additional bunkered sites (any single
system at any single site is sufficient to complete the transaction).

Having transaction completion dependency on any offiste data/function
lowers the integrity ....
availability is the product of all the availability numbers for all things
that must be available for the completion .... redundant availability is
one minus the product of the non-availability numbers.
The financial redundent single site availability number might be five nines
(.99999). Triple redendant geographic survivability then would be
1-(.00001*.00001*.00001). Not having all information stored at each site
necessary to complete the transaction .... implies that at least two sites
have to be operational ... as well as the communication path between them.
The financial infrastructure has availability number of
1-(.00001*.00001*.00001). The communication path ... even with diverse
routing might be three nines (.999) and the 2nd site mght be four nines
(.9999).

The resulting availability for non-single-site-stored-data then is
something like:
                 (1-(.00001*.00001*.00001))*.999*.9999

that can be easily shown to be less than .9999 (since it is the product of
numbers that are all less than one ... and at least one of the numbers is
.9999 or less) ... which was the original unacceptable number for (at least
some) financial infrastructure which prompted the original triple bunkered
site with geographic dispersement in the first place.

The alternative model to reach this level of availability w/o requiring
geographic redundancy with the single-site data model .... is the
simulation of some ECC/FEC possibly R/S 64/80 where all eighty sites have
independent failure modes (some mainframe memory subsystems do 64/80 ECC).
Small problem is resync'ing sites when some have been offline and their
information becomes stale (this is problem in the three site replication
also .... but is somewhat easier with three ... than it would be with
eighty).

In any case, just saying a CA &/or independent certificate directory has
high availability support with no-single-point-of-failure  .... doesn't
necessarily show the whole scope of the issue. Taking an existing operation
that has effectively single-site completion dependency (or even redundnat
single-site completion architecture) ... and move to non-single-site
completion paradigm ... involves (at least) the local site, the
communication modes between the sites, and the 2nd site.

There are also issues of partitioning and locality specific failure modes.
An ISP might cover a geographic locality and provides redundancy to handle
availability levels up to major geogrpahic specific outages .... but
doesn't want to be subject to outages outside local geographic area (i.e.
ISP in california would survive everything up to major earthquake in
california ... but doesn't have to survive a local major earthquake since
all of the
customers would be down also). ISPs with geographic locality coverage only
has to
survive failure  modes that the majority of their customers would also
survive. National or
international ISPs can create gegraphic centered service centers to take
advantage of geographic nature of some failure modes. This gets into an
area of failure mode management
slightly different from the raw statisticaly distribution probability mode
of handling failures.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA13385 for ietf-pkix-bks; Fri, 6 Nov 1998 09:26:29 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13376 for <[e-mail]>; Fri, 6 Nov 1998 09:26:28 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id MAA09783; Fri, 6 Nov 1998 12:27:57 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA21420; Fri, 6 Nov 1998 12:26:38 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B4.005F7664 ; Fri, 6 Nov 1998 12:22:42 -0500
X-Lotus-FromDomain: FDC
To: "Frank O'Dwyer" <[e-mail]>
cc: EKR <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 6 Nov 1998 08:24:51 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

.... and that a spoofer can't obtain the same thumbnail/phrase  in their
certificate extension ...  requiring all CAs (typically valid for the
browser community) to reference a central registry of thumbnail/phrases
(ala copyright or service mark office).

X9.59 standard proposed exactly that for merchant web servers certificates
selling on the internet. There was split between the banks that were
interested in being the CA for such certificates on the part of their
merchants and banks that proposing bank AADS server (did client browser
cross-check service mark with what was in the merchant's certificate
extension ... or did client browser do a online reference to well-know bank
web server checking the service mark, merchant's URL ... and was the bank
still financial responsible party for the merchant). A side issue of
specifying such a thumbnail service mark in a certificate was that X9.59 is
suppose to be for all account-based payments in all electronic environments
(and at least one such electronic environment is point-of-sale where
neither browswer nor certificates are available).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12967 for ietf-pkix-bks; Fri, 6 Nov 1998 08:17:14 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12963 for <[e-mail]>; Fri, 6 Nov 1998 08:17:13 -0800 (PST)
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA24031 for <[e-mail]>; Fri, 6 Nov 1998 10:20:08 -0600 (CST)
Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender [e-mail] )
Received: from csn1.geg.mot.com (csn1.geg.mot.com [137.162.96.72]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id KAA17315 for <[e-mail]>; Fri, 6 Nov 1998 10:20:08 -0600 (CST)
Received: from gegpo1.geg.mot.com (dubtest.geg.mot.com [137.162.17.1]) by csn1.geg.mot.com (8.8.8/8.8.8) with SMTP id JAA14054 for <[e-mail]>; Fri, 6 Nov 1998 09:30:08 -0700 (MST)
Received: by gegpo1.geg.mot.com with Microsoft Mail id <[e-mail]>; Fri, 06 Nov 98 09:20:05 MST
From: Covey Carlin <[e-mail]>
To: ietf-pkix <[e-mail]>
Subject: FW: Is certificate renewal a good idea?
Date: Fri, 06 Nov 98 09:08:00 MST
Message-ID: <[e-mail]>
X-Mailer: Microsoft Mail V3.0
Sender: [e-mail]
Precedence: bulk

It seems to me that cases #2 and #3 are issues that concern the client, but 
case#1
seems to be strictly a registration issue.

case#1:
Since clients will find certificates based upon the DN, it should be 
transparent to the
client whether the same public key appears in another certificate with a 
different DN .
It may matter to the CA, however.  Presumably the CA insists upon proof of 
possession
of the private key when responding to a certification request, to prevent 
someone
hijacking someone else's public key.  The CA may or may not have rules 
concerning
the same user using two different DNs with the same public key.

cases#2 and #3:
The client may need to concern itself with these cases if two certificates 
having the same
CA and same DN are still valid, regardless of whether they have the same 
public key.
If they are encryption certificates and the only difference is the not-after 
date, and both are
still valid, then the client can choose either.  If they are signature 
certificates and both
are still valid and they have the same public key (case#2), then the client 
can pick either.
If the signature certificates have different public keys, then obviously 
only the one that
matches the signature to be verified will be useful.  The client will have 
to concern itself
with the possibility that the first certificate it tries may not work, but 
the second might.

cases#2 and #3 (reprise):
If two valid certificates have the same DN but differ in some other regard 
that is of
concern to the client (e.g. policy OID), the client will have to pay 
attention regardless of
whether the two certificates have the same public key.  The first 
certificate tried may not
have the right attributes, but the second might.
 ----------
From: owner-ietf-pkix
To: ietf-pkix; flanigab
Subject: RE: Is certificate renewal a good idea?
Date: Wednesday, November 04, 1998 12:28PM

Bill,

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and 
#2.
And, should client software be built to support case #2?


>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
See comments below.

> -----Original Message-----
> From: Tammy Carter [SMTP:[e-mail]]
> Sent: Tuesday, November 03, 1998 6:24 PM
> To:   [e-mail]
> Subject:      Is certificate renewal a good idea?
>
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten
> me?
>
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name,
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
>
        Actually, the most prevalent case is likely to be:
        3) Same CA, different public key, same CN

        [snip]

> Comments?
>
        Above.

> Tammy Green Carter
> [e-mail]
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone]
Information Assurance Office (JED)      DSN:                      761
5600 Columbia Pike, Room 632     Voice Mail:           [phone]
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12736 for ietf-pkix-bks; Fri, 6 Nov 1998 07:46:33 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12732 for <[e-mail]>; Fri, 6 Nov 1998 07:46:32 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id HAA06282; Fri, 6 Nov 1998 07:48:12 -0800 (PST)
To: "Frank O'Dwyer" <[e-mail]>
Cc: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 06 Nov 1998 07:48:11 -0800
In-Reply-To: "Frank O'Dwyer"'s message of "Fri, 06 Nov 1998 11:19:53 +0000"
Message-ID: <[e-mail]>
Lines: 62
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Frank O'Dwyer" <[e-mail]> writes:
> EKR wrote:
> > Folks, there is a draft on this topic:
> > draft-ietf-tls-https-02.txt
> > 
> > I believe I've done a reasonable job of covering the appropriate
> > issues, and the TLS-WG has pretty much come to a consensus that
> > the name matching stuff is done correctly. If PKIX people
> > have problems with how it's done, I'd like to hear them.
> 
> I think that there are two flaws in how that's done, one minor and
> reasonably easily fixed, and one major and difficult to fix. I'm working
> off draft-ietf-tls-https-01.txt, though, so maybe something's changed
> meanwhile.
> 
> The minor flaw may apply to TLS in general, in that UDP/TCP transport
> connections are identified by a 4-tuple {source host, source port,
> destination host, destination port} but tls-https only authenticates the
> destination host, not the port. This leaves scope for one TLS service to
> impersonate another, provided they have the same DNS hostname. The same
> problem exists for different and seperately-administered HTTPS services
> at the same DNS hostname but at different well-known ports. This might
> be fixable via appropriate trust criteria on the certificates, but I
> think a more straightforward fix is to either include the port number in
> the server identity and mechanically check for it, and/or (for backward
> compatibility) to forbid reuse of a DNS hostname for TLS services
> running on different well-known ports.
Yes, this is an issue, but I consider it a much less important one.
Primarily, end-node machines should arrange that this can't
happen.

> The major problem is hyperlink/web spoofing (see
> http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
> http://www.cs.princeton.edu/sip/).
Sure. This has been a problem since day one. But it's basically 
unfixable. This isn't just a problem with TLS. It's a problem with
any system anywhere that's ever purported to verify certificates
mechanically. To whit: You need to verify that the user's expectations
for who they are talking to match who they are in fact talking to.
Except that we don't have direct access to the user's expectations.

> This issue should at least be pointed
> out in a "security considerations" section or similar. It's difficult to
> fix, but in some cases mechanical checks can be made. For example, if a
> user clicks on a pepsi logo with a https link, the server certificate
> could contain that logo in an appropriate extension and it could be
> mechanically checked for.
This really can't work, in the face of the n different sizes and color
variants of the logos. Worse yet, the certificate ISN'T in the
certificate.

> Similarly, if the user clicks on the phrase
> "Bank of Foo online banking", the server certificate could contain that
> phrase and it could be checked for.
Except that this is easily spoofed by having the certificate say
"Bank of Mafia" and getting the user to click on "bank" when you
change the page.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12005 for ietf-pkix-bks; Fri, 6 Nov 1998 06:08:13 -0800 (PST)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12000 for <[e-mail]>; Fri, 6 Nov 1998 06:08:11 -0800 (PST)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id WAA01065; Fri, 6 Nov 1998 22:59:10 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA00483; Fri, 6 Nov 98 23:04:20 JST
Received: from elgw.isl.melco.co.jp ([133.141.13.130]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with ESMTP id XAA14193; Fri, 6 Nov 1998 23:18:35 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id XAA20332; Fri, 6 Nov 1998 23:11:06 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id XAA07955; Fri, 6 Nov 1998 23:17:21 +0900 (JST)
Received: from zaku by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA27123; Fri, 6 Nov 1998 23:10:50 +0900
Message-Id: <[e-mail]>
Date: Fri, 06 Nov 1998 23:09:25 +0900
From: Jun Yoshitake <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I am beginning to be afraid we have been thinking
of a differnet situation or application ...
But, anyway, my comments are in line.

[e-mail] wrote:

> 1) registering a public key in a RADIUS account record in lieu of a
> password, modifying the RADIUS serrver to do digital signature
> authentication with the registered public key, and modifying the RADIUS
> client to accept a digital signature (in lieu of a password).

I think you don't necessarily have to register the public key
in your record.
A client can send all the certificates that are needed to
validate the client's certificte.
(I don't know RADIUS, so I am explaining in a general
 PKI case.)

> First off, the transaction in neither mode will complete if the RADIUS
> server and RADIUS account record is unavailable. However, in addition, the
> second mode won't complete if none of the remaining PKI infrastructure is
> unavailable (and/or if it chooses to continue in spite of it being
> unavailble opens up fraud and risk potential completing the operation w/o
> completing the authentication process).

If you are saying, for example, what if no directory servers can be
available to get necessary CRLs, I admit this is a big point.
And this issue - how revocation information is surely provided -
has been one of big points in this mailing list, I think.
I think in a real system a high availability server (for example,
a dual server system) is used for a directory server (if you use
a directory server as a revocation information provider).

> At NISS conference last month a financial institution talked about
> migration to relying party certificates because of privacy and liability
> issues .... i.e. a certificate containing only the account number and
> public key. In this scenerio, the certificate is stored in the account
> record when the public key is registered and a copy returned to the owner.
> This about reduces privacy, liability, complexity, risk, availability and
> fraud exposures to a minimum (associated with using both a certificate and
> an account record). At this point, the question becomes why does the owner
> have to send a digital signature and the certificate to the institution on
> every operation .... if the institution already has the original of the
> certificate.

Again, you don't necessarily have to store a client's certificate.
And I think it depends on an application or a protocol whether
a client has to send its digital signature and its certificate
every time it sends a message to the server.
(SET Protocol might be of some help in this point.)

> The downside risk is that the certificate signing key at least
> becomes a point of attack ...

If you mean "the certificate signing key" is the CA key
which signs a client's certificate, I think the real world CAs
(especially for financial applications) protect thier facilities
including their private keys and  in highly secure and strict
manners.


Regards,

Jun Yoshitake

Mitsubishi Electric Corp.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA11284 for ietf-pkix-bks; Fri, 6 Nov 1998 05:08:38 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA11280 for <[e-mail]>; Fri, 6 Nov 1998 05:08:37 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA05958; Fri, 6 Nov 1998 05:10:56 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 08:05:15 -0500
To: Stephen Kent <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: [e-mail]
In-Reply-To: <v0401170eb2668eb0e84e@[128.89.31.126]>
References: <[e-mail]> <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Steve,

We agree completely on this.  I think that's what Section 5.1.2 of the PKIX
Roadmap document says; it's what we were trying to capture. If we didn't do
a good enough job of it, we can correct it.

I recognize that many non-SPKI-folk share this view.  Hey, I was just
trying to be polite to the folk doing the SPKI work. :-)

			Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.


At 06:14 PM 11/4/98 -0500, Stephen Kent wrote:
>Al,
>
>>This is one of the areas where the SPKI folk make sense.  There is not, and
>>will not ever be, a single, unified, global directory where everything has
>>a name that fits into the schema.  There are instead "directories" of
>>information that apply to a specific "domain".  In PKIX's case, it's the
>>information that applies to the Internet.  The namespace covers those
>>things that are important in the Internet context, and nothing else.  To
>>me, that's (right now), IP addresses, domain names, port numbers, service
>>names, user names/mailbox names, and maybe one or two other things. If the
>>Internet expands to cover toll plazas, then a naming space will have to be
>>developed for them, and after it's defined and standardized we can figure
>>out how to put the proper names in certificates.
>
>The notion of no single, unique, name that is appropriate for every context
>is not unqiue to SPKI;  I've been preaching this notion for at least 3
>years and gave talks on this at a DIMACS workshop in 1996 and at the RSA
>conference in 1997, before publishing a paper on the topic in MILCOM 97.
>The SDSI model says that the names in certs are not useful except very
>locally, and hence emphasizes the idea of the key as an ID.  What we are
>talkin g about does not share that notion.  DNS names, 822 addresses, IP
>addresses, URLs, etc. have widespread semantics, even though they are not
>universal.
>
>Steve

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA11178 for ietf-pkix-bks; Fri, 6 Nov 1998 05:00:20 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA11174 for <[e-mail]>; Fri, 6 Nov 1998 05:00:17 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA05900; Fri, 6 Nov 1998 05:02:35 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 07:56:41 -0500
To: Elliott Ginsburg <[e-mail]>, [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Re: A different architecture
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Well, as the "loudmouth" who started this, let me quickly clarify.  What I
actually wrote was:

"There is not, and will not ever be, a single, unified, global directory where
everything has 
a name that fits into the schema. There are instead "directories" of 
information that apply to a specific "domain"." 

I was responding to previous comments about the X.500 notion of everything
(specific examples cited were toll plazas, toll booth operators, etc.) having a
name that fits into a single global structure - much different from the
(relatively simple) idea of assigning domain names to things that connect to
the Internet.

The DNS is an example of a directory of information that applies to a specific
"domain".  (Yes, I realize that my use of the term 'domain' in the original
post was unfortunate - I'm now overloading the word.  Hopefully, the meaning is
clear from context.)  This is what we meant in Section 5.1.2 of the Roadmap
document, which says:
5.1.2 Scope of Names

The original X.500 work presumed that every subject in the world wouldhave a
globally-unique distinguished name. Thus, every subject could be easily
located, and there would never be a conflict. All that would be needed is a
sufficiently-large name space, and rules for constructing names based on
subordination and location.

Obviously, that is not practical in the real world, for a variety of reasons.
There is no single entity in the world trusted by everybody to reside at the
top of the name space, and there is no way to enforce uniqueness on names for
all entities. (These were among the reasons for the failure of PEM to be widely
implemented.)

This does not mean, however, that a name-based PKI cannot work. It is important
to recognize that the scope of names in PKIX is local; they need to be defined
and unique only within their own domain. 

Suppose for example that a rootCA is established with DN "O=IETF, OU=PKIX,
CN=PKIX_CA". That CA will then issue certificates for names subordinate to it.
The only requirement - and this can be enforced procedurally - is that no two
distinct entities beneath this rootCA have the same name. We can't prevent
somebody else in the world from creating her own CA, called "O=IETF, OU=PKIX,
CN=PKIX_CA", and it is not necessary to do so. Within the domain of the
original rootCA, there will be no conflict, and the fact that there is another
CA of the same name in some other domain is irrelevant.

This is analogous to the current DNS or IP address situations. On the Internet,
there is only one node called www.ietf.org. The fact that there might be 10
different intranets, each with a host given the DNS name www.ieft.org, is
irrelevant and causes no interoperability problems- those are different
domains. However, if there were to be another node on the Internet with domain
name www.ietf.org, then there would be a problem due to name duplication.

The same applies for IP addresses. As long as only one node on the Internet
responds to the IP address 130.85.1.3, there is no problem, despite the fact
that there are 100 different corporate Intranets, each using that same IP
address. However, if two different nodes on the Internet each responded to the
IP address 130.85.1.3, there would be a problem.



Since Bill Burr did an excellent job of answering the original post, I'll add
that I agree with Bill, and let it go at that.

(Request:  any other comments on the Roadmap - on the above section or any
other part of the document - would be appreciated.)

                        Al Arsenault

--  these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



At 08:00 AM 11/3/98 -0500, Elliott Ginsburg wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09766 for ietf-pkix-bks; Fri, 6 Nov 1998 03:17:33 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.166]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA09761 for <[e-mail]>; Fri, 6 Nov 1998 03:17:29 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id LAA05113; Fri, 6 Nov 1998 11:22:27 GMT
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 11:19:53 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: EKR <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

EKR wrote:
> Folks, there is a draft on this topic:
> draft-ietf-tls-https-02.txt
> 
> I believe I've done a reasonable job of covering the appropriate
> issues, and the TLS-WG has pretty much come to a consensus that
> the name matching stuff is done correctly. If PKIX people
> have problems with how it's done, I'd like to hear them.

I think that there are two flaws in how that's done, one minor and
reasonably easily fixed, and one major and difficult to fix. I'm working
off draft-ietf-tls-https-01.txt, though, so maybe something's changed
meanwhile.

The minor flaw may apply to TLS in general, in that UDP/TCP transport
connections are identified by a 4-tuple {source host, source port,
destination host, destination port} but tls-https only authenticates the
destination host, not the port. This leaves scope for one TLS service to
impersonate another, provided they have the same DNS hostname. The same
problem exists for different and seperately-administered HTTPS services
at the same DNS hostname but at different well-known ports. This might
be fixable via appropriate trust criteria on the certificates, but I
think a more straightforward fix is to either include the port number in
the server identity and mechanically check for it, and/or (for backward
compatibility) to forbid reuse of a DNS hostname for TLS services
running on different well-known ports.

The major problem is hyperlink/web spoofing (see
http://www.brd.ie/papers/sslpaper/sslpaper.html/ and
http://www.cs.princeton.edu/sip/). This issue should at least be pointed
out in a "security considerations" section or similar. It's difficult to
fix, but in some cases mechanical checks can be made. For example, if a
user clicks on a pepsi logo with a https link, the server certificate
could contain that logo in an appropriate extension and it could be
mechanically checked for. Similarly, if the user clicks on the phrase
"Bank of Foo online banking", the server certificate could contain that
phrase and it could be checked for.

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09322 for ietf-pkix-bks; Fri, 6 Nov 1998 03:10:31 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA09317 for <[e-mail]>; Fri, 6 Nov 1998 03:10:23 -0800 (PST)
Received: (qmail 362 invoked from network); 6 Nov 1998 10:56:21 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 6 Nov 1998 10:56:21 -0000
Received: (qmail 13043 invoked from network); 6 Nov 1998 10:11:07 -0000
Received: from unknown (HELO valicert.com) (10.0.0.101) by internal-mail.valicert.com with SMTP; 6 Nov 1998 10:11:07 -0000
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 02:11:31 -0800
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Peter,
    Thanks for the comments - actually, this is a great review. Let
me try and justify the various points:

Peter Gutmann wrote:
> 
> I've just spent the afternoon (trying to) implement this weeks version of
> OCSP.  There are some problems with this, here they are in rough order of
> severity:
> 
> - In the ResponseData there's a clash of tags between responseExtensions and
>   responderID.byName

This clash shouldn't cause any problems in either encoding or decoding,
since the responderID and Extensions are separated by more than one
required fields.

Is this still an issue? Dan W. had actually pointed out the clash
between Version and ResponderID, which both had a tag of 0 and were
adjacent to each other. That was the reason for changing the tags.
However, I am not sure why the clash of non-adjacent tags is bad.

> 
> - The certStatus is communicated by the tag on the encoded data rather than an
>   actual value, which means that unless you've got some hand-hacked ASN.1
>   decoder you can't tell what the status is because it's stripped out by the
>   decoding layer - you end up having to poke around to see what parts of the
>   XXXInfo you've wound up with and then try to guess the cert status from that.
>   This should be:
> 
>    ...
>    certStatus           ENUMERATED,
>    certStatusInfo       CertStatusInfo OPTIONAL
>    ...
> 
>    CertStatusInfo ::= SEQUENCE {
>       [revocationTime etc]
>       }

Actually, I thought this was a pretty neat idea (all the credit goes to
Slava for this one). I would think most people would encode a CHOICE as
a union and have something to distinguish which field of the union is
in use. Given that, it is unclear why we need to have a separate
certStatus field. Actually, I would think it make software more error
prone - what if the enumerated and the tag that tells you what the
field of the union is don't match?

It is possible, I suppose that one uses a void * instead of a union.
In that case, you would need to keep something telling you what the
type of the data is.


> 
> - The responseBytes are encoded using the dreaded OCTET STRING black hole, for
>   no good reason.  Instead of the current:
> 
>    ResponseBytes ::=       SEQUENCE {
>        responseType   OBJECT IDENTIFIER,
>        response       OCTET STRING }
> 
>   it should be:
> 
>    ResponseBytes ::=       SEQUENCE {
>        responseType   OBJECT IDENTIFIER,
>        response       ANY DEFINED BY responseType }
> 
>   (using the 1988 syntax, replace with the '93 version as required).

Got my syntax from the definition of Extensions - "Monkey see, monkey
do", I suppose :-)

> 
> Finally, the entire set of PDU's are defined using an incredible amount of
> gratuitous and unnecessary tagging - were the authors being paid by the tag
> for this or something? :-).  You can strip out almost every tag in the spec
> without any adverse effects.  For example the OCSPRequest can be rewritten
> from:
> 
>    OCSPRequest     ::=     SEQUENCE {
>        tbsRequest                  TBSRequest,
>        optionalSignature   [0]     EXPLICIT Signature OPTIONAL }
> 
>    TBSRequest      ::=     SEQUENCE {
>        version             [0]     EXPLICIT Version DEFAULT v1,
>        requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
>        requestList                 SEQUENCE OF Request,
>        requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
> 
>    Signature       ::=     SEQUENCE {
>        signatureAlgorithm      AlgorithmIdentifier,
>        signature               BIT STRING,
>        certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
> 
>    Request         ::=     SEQUENCE {
>        reqCert                     CertID,
>        singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
> 
> to
> 
>    OCSPRequest     ::=     SEQUENCE {
>        tbsRequest                  TBSRequest,
>        optionalSignature           Signature OPTIONAL }
> 
>    TBSRequest      ::=     SEQUENCE {
>        version                     Version DEFAULT v1,
>        requestorName       [0]     GeneralName OPTIONAL,
>        requestList                 SEQUENCE OF Request,
>        requestExtensions           Extensions OPTIONAL }
> 
>    Signature       ::=     SEQUENCE {
>        signatureAlgorithm      AlgorithmIdentifier,
>        signature               BIT STRING,
>        certs                   SEQUENCE OF Certificate OPTIONAL }
> 
>    Request         ::=     SEQUENCE {
>        reqCert                     CertID,
>        singleRequestExtensions     Extensions OPTIONAL }
> 
> This is functionally completely identical to the previous version, but:
> 
>  - It's easier to read
>  - It's easier to encode
>  - It's easier to decode
>  - It's smaller when encoded
> 
> The same goes for the response format (with the exception of the responderID I
> can't find a single context-specific tag which is actually necessary).  Is
> there any reason why all the unnecessary tagging has to be there?

I think you are making 2 points here:
1. Why am I tagging things I didn't need to.
2. Why am I using explicit tagging.

Here are the reasons:
I actually like following simple rules that don't make me think too
much :-). Here are the two choices:
a. Tag only if you have two optional fields (actually only if they are
	adjacent (and of the same type))
b. Tag any time a field is optional.

Choice a. is more difficult to follow and more error prone as the spec
changes and people add/remove fields.

If you buy the previous argument, then, EXPLICIT tagging actually
helps me debug, because with IMPLICIT tagging, I lose the
actual type of the field and run something like your asn1dump,
or SSLeay's asn1parse doesn't actually give me a very useful
output.

I did assume that given that you already have the overhead of a
128 byte signature with the response, the few extra bytes
added by EXPLICIT encoding wouldn't be too bad.

Is that a reasonable argument, or could I have had my cake and
eaten it too and save some bytes all at the same time?

> 
> Peter.
> 

Regards,
Ambarish

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA03178 for ietf-pkix-bks; Fri, 6 Nov 1998 01:00:17 -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 BAA03173 for <[e-mail]>; Fri, 6 Nov 1998 01:00:15 -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 WAA02055 for <[e-mail]>; Fri, 6 Nov 1998 22:03:08 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91034298701348>; Fri, 6 Nov 1998 22:03:07 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: More problems with OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 22:03:07 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I knew there was something I forgot in the previous message...
 
The use of CertID isn't at all clear.  Firstly, I assume that "hash of the 
subject key field" means a hash of the subjectPublicKey rather than the 
subjectPublicKeyInfo (is this correct)?  However once you've done that, there 
isn't really much you can do with the result.  How are you supposed to look up 
a certificate with the resulting OCTET STRINGs and whatnot without enumerating 
each one and hashing whatever you need until you find a match?  The only way I 
can see for doing this is by adding a whole series of extra attributes to your 
key database/directory containing every possible combination of hash algorithm 
and hash type for the different fields - each cert would need to be stored 
with the hash of issuer DN and key for every conceivable hash algorithm type 
which someone might use in a request.
 
I'm assuing here that the OCSP server acts as a go-between between some CA/CRL 
repository and the user (ie that it consults some sort of directory for 
certificate information and uses that to build a local cache of info which it 
doles out to requestors).  However since you can't consult a directory based 
on a CertID you don't really get very far unless the OCSP server is run by the 
issuer, who has an unambiguous means of mapping a serialNumber to a 
certificate which it issued.  For anyone else, a random octet string and 
integer as a cert ID aren't useful for anything because finding the issuer 
involves reversing the hash function.
 
Has anyone actually tried to implement OCSP before?
 
[If you need a way to uniquely identify a cert, might I suggest the 160-bit 
 SHA-1 hash of:
 
  SEQUENCE {
    issuerKey           SubjectPublicKeyInfo,
    serialNumber        CertificateSerialNumber
    }
 
 Then define a new attribute certificateID and get everyone to store this 
 alongside the cert.  Given the unhealthy practice of renewing keys, it may be 
 necessary to include some sort of generational qualifier as well]
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA28620 for ietf-pkix-bks; Thu, 5 Nov 1998 23:31:50 -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 XAA28611 for <[e-mail]>; Thu, 5 Nov 1998 23:31:48 -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 UAA00783 for <[e-mail]>; Fri, 6 Nov 1998 20:34:40 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91033768003596>; Fri, 6 Nov 1998 20:34:40 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Comments on OCSP
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 20:34:40 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've just spent the afternoon (trying to) implement this weeks version of 
OCSP.  There are some problems with this, here they are in rough order of 
severity:
 
- In the ResponseData there's a clash of tags between responseExtensions and 
  responderID.byName
 
- The certStatus is communicated by the tag on the encoded data rather than an 
  actual value, which means that unless you've got some hand-hacked ASN.1 
  decoder you can't tell what the status is because it's stripped out by the 
  decoding layer - you end up having to poke around to see what parts of the 
  XXXInfo you've wound up with and then try to guess the cert status from that.
  This should be:
 
   ...
   certStatus           ENUMERATED,
   certStatusInfo       CertStatusInfo OPTIONAL
   ...
 
   CertStatusInfo ::= SEQUENCE {
      [revocationTime etc]
      }
 
- The responseBytes are encoded using the dreaded OCTET STRING black hole, for 
  no good reason.  Instead of the current:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }
 
  it should be:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       ANY DEFINED BY responseType }
 
  (using the 1988 syntax, replace with the '93 version as required).
 
Finally, the entire set of PDU's are defined using an incredible amount of 
gratuitous and unnecessary tagging - were the authors being paid by the tag 
for this or something? :-).  You can strip out almost every tag in the spec 
without any adverse effects.  For example the OCSPRequest can be rewritten 
from:
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
 
to
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature           Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version                     Version DEFAULT v1,
       requestorName       [0]     GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions           Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs                   SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     Extensions OPTIONAL }
 
This is functionally completely identical to the previous version, but:
                        
 - It's easier to read
 - It's easier to encode
 - It's easier to decode
 - It's smaller when encoded
 
The same goes for the response format (with the exception of the responderID I 
can't find a single context-specific tag which is actually necessary).  Is 
there any reason why all the unnecessary tagging has to be there?
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA19189 for ietf-pkix-bks; Thu, 5 Nov 1998 21:06:13 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA19178 for <[e-mail]>; Thu, 5 Nov 1998 21:06:11 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id VAA02188; Thu, 5 Nov 1998 21:10:17 -0800 (PST)
To: "Phillip M Hallam-Baker" <[e-mail]>
Cc: "Frank O'Dwyer" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: Re: Scale (and the SRV record)
References: <006601be0911$320d9ec0$[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 21:10:16 -0800
In-Reply-To: "Phillip M Hallam-Baker"'s message of "Thu, 5 Nov 1998 18:08:27 -0500"
Message-ID: <[e-mail]>
Lines: 28
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Phillip M Hallam-Baker" <[e-mail]> writes:

> > I think this is an extremely important point--any mapping between name
> > spaces must be done securely and where such mapping can be avoided then
> > all the better.
> 
> Frank makes some excellent points. What he is addressing is the 
> interface between PKIX and SSL (TLS). Is this a PKIX-WG issue or a
> TLS-WG issue?
> 
> I think it is something which TLS should address since it naming
> is an issue which must be handled separately by each 'PKIX aware'
> protocol. The naming issues of S/MIME are very different for example.
> Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
> different.
Folks, there is a draft on this topic:
draft-ietf-tls-https-02.txt

I believe I've done a reasonable job of covering the appropriate
issues, and the TLS-WG has pretty much come to a consensus that
the name matching stuff is done correctly. If PKIX people
have problems with how it's done, I'd like to hear them.

-Ekr


-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA15773 for ietf-pkix-bks; Thu, 5 Nov 1998 17:58:45 -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 RAA15769 for <[e-mail]>; Thu, 5 Nov 1998 17:58:44 -0800 (PST)
Received: from [128.33.238.127] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id VAA22039; Thu, 5 Nov 1998 21:01:10 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170bb267e710f05f@[128.33.238.37]>
In-Reply-To:  <[e-mail]>
Date: Thu, 5 Nov 1998 18:43:15 -0500
To: "Larowe, Rick" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: Alan Lloyd <[e-mail]>, "'Paul Koning'" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

At 7:07 AM -0500 11/5/98, Larowe, Rick wrote:
>> -----Original Message-----
>> From: Stephen Kent [mailto:[e-mail]]
>> Anyway, didn't thin clients become less of a goal with the
>> demise of netPCs
>> :-)?  All of the software on my desktop and laptop machines is getting
>> bigger each year, not smaller.
>
>But let's not forget about PDAs, smart phones, pagers, and even
>watches.  They'll be the next targets.

Good point, but I'm loathe to skew the current model for the benefit of
some of these devices.  The PDAs are getting pretty powerful; phones and
pagers do pose more of a problem.  I'm not worried about my watch needing
to validate the cert for WWV.  If we go down this path too far, we might
next decide to create "lite" certs because regular X.509 certs are too big,
have uncessarily complex name forms, etc.  People sometimes tell me that
every lightbulb in my house needs to have an IP address and that's why IPv6
needs to be deployed. Maybe not.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13426 for ietf-pkix-bks; Thu, 5 Nov 1998 15:22:01 -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 PAA13422 for <[e-mail]>; Thu, 5 Nov 1998 15:22:00 -0800 (PST)
Received: from stefans (t1o68p64.telia.com [62.20.138.64]) by maila.telia.com (8.8.8/8.8.8) with SMTP id AAA16070; Fri, 6 Nov 1998 00:24:41 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 06 Nov 1998 00:20:45 +0100
To: Al Arsenault <[e-mail]>, "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 PAA13423
Sender: [e-mail]
Precedence: bulk

Al,

I agree with your definitions.

What you provide is som useful labels which I find sound and useful. I
would encourage labels like these to be defined for different types of
practices. Maybe something for the roadmap ?

One case that seems to be missing is the case where one certificate of one
type is used to apply for another certificate of another type. They may use
same key, different naming attributes, identify different privilages, maybe
issued by different CA:s, but they are both individual statements valid at
the same time. 
In physical life we do this all the time. We may use our ID-card to apply
for a petrol card or a credit card. We use the same key (our signature in
hand writing). Still the context will make clear which certificate to use
in any given occasion. I would not use my ID-card to by petrol and not the
petrol card in the Bank. They are not even cross certified, they are just
individual statements by the issuer according to their policies.

The "Qualified Certificate" may be used in this context to carry the
function of an electronic ID-card, thus may considerably enhance initial
registration to other CA:s such as SET CA:s, elelctronic trade CA:s, helth
care CA:s, other private domain CA:s etc.

But in all this I hope that we don't confuse this with the problem of
defining what is good or bad practice for a particular CA. As long as a
certificate is suitable for its intended usage, it's good parctice. And
what is suitable or not is a pure policy issue which requires a clear
context to be evaluated.

/Stefan

At 03:26 PM 11/5/98 -0500, Al Arsenault wrote:
>In the PKI with which I am familiar (which has been operational for more
>than 3 and 1/2 years now), we use a couple of different terms:
>
>	renewal:  issue a new certificate with the same DN, the same attributes,
>the same key, a different certificate serial number, and a different
>validity period
>
>	update:  issue a new certificate with the same DN, but with one or more
>new attributes, a new key, a different certificate serial number, and a
>different validity period (where here, "attribute" means any field in the
>certificate other than the subject DN, issuer DN, certificate serial
>number, or validity period).
>
>"Renewal" is used when a user is continuing on in the same job.  E.g.,
>certificates are issued for a period of 6 months.  At the end of that time,
>the user is in the same job, at the same place, with the same privileges,
>etc.  We just give the user a renewed certificate, good for another six
>months, because nothing else is changed.  We change the serial number to
>distinguish between the old and new certs - it's the issuer/serial number
>combination that uniquely identifies the certificate.  And, obviously, the
>signature value changes. 
>
>Why use the same key?  Why not - assuming that the useful lifetime hasn't
>expired, it's not a security problem. If the useful lifetime hasn't
>expired, we don't let the cert be renewed.
>
>"Update" is when something else (other than the user's name) has changed -
>the user's access authorizations, privileges, etc. In that case, we revoke
>the old certificate, because the change may have resulted in the loss of
>access, and we want to make sure that the old cert won't work.  We demand a
>new key for the same reason.  (Strictly speaking, you wouldn't have to
>revoke the old certificate if the change resulted in an increase of access
>privileges, but it's administratively easier to just always revoke the old
>cert.)
>
>If the only attribute that changes in an "update" is the user's public key,
>it's called a "rekey", but the same rules apply.
>
>Note that in a renewal, you can have multiple certificates valid for the
>same user at the same time (if you issue the renewal before the old
>certificate expires, which is generally considered to be the smart thing to
>do).  Since the public key's the same (and thus the associated private
>key's the same) it's not a major problem, assuming that the end-entity is
>capable of dealing with the fact that there are two certs for the same user
>in the repository.
>
>				Al Arsenault
>
>
>-- these are my opinions only.  They do not necessarily reflect the
>opinions of my employer, or of any other organization with which I have a
>relationship.
>
>
>
>
>At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>>At the National Securities Clearing Corporation we are beginning to face
>>renewal requirements. In every case we are talking about same CN, same CA,
>>same DN, and different validity period. I would like to say that in all
>>cases we will be seeing a new public key, and we would certainly discourage
>>the idea or re-certifying the same key, but I cannot guarantee that we will
>>never see renewal with the same public key.
>>
>>Two requirements that we consider critical, but not easily fulfilled given
>>the current state of the are, are:
>>- DN in renewed certificate is exactly identical to DN in original
>>certificate.
>>- Start of renewed certificate's validity period is exactly equal to
>>expiration of the original certificate's validity period no overlap no gap.
>>The renewed certificate would be issued as much as six weeks before the
>>start of its validity period.
>>--------------------------------------------------
>>p:[phone]                     Dwight Arthur
>>f:[phone]        Managing Director: Systems
>>b:[phone]      National Securities Clearing
>>[e-mail]        55 Water Street
>>http://www.nscc.com        New York, NY 10041-0082
>>
>>-----Original Message-----
>>>	Actually, the most prevalent case is likely to be:
>>>	3) Same CA, different public key, same CN
>>>
>>Really?  I always thought it would be validity date.  Of course this would
>>be about 18 months after PKI rollout.
>>
>
>
>
>
-------------------------------------------------------------------
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 PAA13181 for ietf-pkix-bks; Thu, 5 Nov 1998 15:05:38 -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 PAA13177 for <[e-mail]>; Thu, 5 Nov 1998 15:05:37 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id PAA25460; Thu, 5 Nov 1998 15:05:38 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id PAA07024; Thu, 5 Nov 1998 15:07:55 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Frank O'Dwyer" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 18:08:27 -0500
Message-ID: <006601be0911$320d9ec0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I think this is an extremely important point--any mapping between name
> spaces must be done securely and where such mapping can be avoided then
> all the better.

Frank makes some excellent points. What he is addressing is the 
interface between PKIX and SSL (TLS). Is this a PKIX-WG issue or a
TLS-WG issue?

I think it is something which TLS should address since it naming
is an issue which must be handled separately by each 'PKIX aware'
protocol. The naming issues of S/MIME are very different for example.
Indeed the naming issues of TLS-HTTP and TLS-LDAP could well be
different.


	Phill


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12994 for ietf-pkix-bks; Thu, 5 Nov 1998 14:50:16 -0800 (PST)
Received: from toby.brd.ie ([e-mail] [193.120.3.56]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12989 for <[e-mail]>; Thu, 5 Nov 1998 14:50:12 -0800 (PST)
Received: from brd.ie (mofo.brd.ie [10.0.0.3]) by toby.brd.ie (8.9.0/8.9.0) with ESMTP id WAA04680; Thu, 5 Nov 1998 22:55:08 GMT
Message-ID: <[e-mail]>
Date: Thu, 05 Nov 1998 22:52:32 +0000
From: "Frank O'Dwyer" <[e-mail]>
Organization: Rainbow Diamond Limited
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Phillip M Hallam-Baker <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1> <v04011709b2667633b778@[128.89.31.126]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Stephen Kent wrote:
> The DNS is the only robust, distributed directory system the Internet has.
> That makes it attractive for two things: storing data, such as certs and
> CRLs, and for its naming tree.  Note that anytime we use a name in a cert
> that is not exactly the same as the name we use in an application, we are
> required to perform a mapping between two name spaces, and that introduces
> another database which imposes significant additional management overhead
> and another place to make errors with adverse security implications.  So,
> for example, for IPsec, i really want certs with DNS names and IP
> addresses, since these are the native name forms that the applications
> employ and upon which access control decisions are made. For SSL, browsers
> check a DNS name in a certificate against the corresponding portion of the
> URL, and ignore the rest of the DN in the subject field.   

I think this is an extremely important point--any mapping between name
spaces must be done securely and where such mapping can be avoided then
all the better. However I think it's important to understand that the
important native name forms are those that appear on the user interfaces
of applications, which are not necessarily those used deep in the
technical undergrowth. In fact, SSL as used for web browsing got that
wrong and is vulnerable as a result; it authenticated DNS names whereas
most users click on icons and natural language hyperlinks. The linkage
between those hyperlinks and DNS names is not supplied securely and thus
web spoofing is possible. (The situation is even worse today, since now
the browsers automatically map keywords when you type them into the
location bar.)  

The whole issue of naming is critical for PKI security, however I think
it's fair to say that even among experts there is no common
understanding of how PKI naming works in detail, and that does not augur
well for the security of PKI applications. The "end-to-end" naming
solution you describe above (native names in certificates) removes many
vulnerabilities, but I think you need to be sure that the names really
go end-to-end, in the sense of going all the way up onto the user's
screen, and from the user's keyboard. The issue of local vs. global
names raised by the SPKI group is also highly relevant, and really needs
to be taken on board here--for example the existence of NAT and network
10 addresses makes it staringly obvious that many distinct machines will
have the same IP address in their certificates, therefore they cannot
share the same namespace. Or will public CAs issue certs for 10.0.0.0?

For e-mail the
> case may not be so strong, since people may mentally map identifies
> irrespective of e-mail addresses, but even there I worry that cognitive
> overload can eaisly set in and cause people to make perception mistakes.
> (If one has an S/MIME system that automatically checks for the
> correspondence between the "from" address and the sender's DN from his
> cert, instead of presenting the subject DN from the certificate, then the
> above arguments apply.) So, here too, I really prefer certs with e-mail
> addresses, which is a change from a stance I adopted years ago when I wrote
> RFC 1422.

Unfortunately that still suffers from a name mapping problem. I
occasionally receive emails from people who have confused me with some
other Frank O'Dwyer on the Internet. I also have a friend who has the
same name as another person in the company where he works; he regularly
receives email about the golf society his namesake belongs to--I had to
phone him to verify his email address. The risks for encrypted email
should be obvious. The difficulty is that authenticating the email
address is insufficient if the email address itself is not obtained
securely (i.e. if it does not correspond to the user's understanding of
the name presented on the mailer's user interface). Another way of
looking at it is that securely mapping an email address to a key is only
one half of the problem; the other half is securely mapping a warm body
(or a machine recipient) to an email address.

Cheers,
Frank O'Dwyer.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12955 for ietf-pkix-bks; Thu, 5 Nov 1998 14:44:52 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12951 for <[e-mail]>; Thu, 5 Nov 1998 14:44:50 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19X1AN3>; Thu, 5 Nov 1998 17:45:20 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E20B189@WUHER>
From: Santosh Chokhani <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Simonetti David <[e-mail]>
Cc: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers
Date: Thu, 5 Nov 1998 17:45:18 -0500
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

I agree with Steve for the most part.

Please note that with all due respect to X.509, even if the key
identifiers were not unique to a single subject or authority, it does
not cause any security or interoperability problem.

Please further note that use of the DN, serial number tuple for
authority key identifier is a bad idea.  It does not help with path
discovery for two reasons: 1 The syntax of subject key identifier does
not accommodate it; this becomes an issue since authority of a given
certificate is the subject of the previous certificate in a trust chain.
2.  If an authority is certified by multiple authorities, which tuple
should it put in the authKeyID field of the certificates it signs.
Putting one does not help discovering (actual it inhibits) paths going
through other authorities.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Wednesday, November 04, 1998 8:41 PM
> To:	Simonetti David
> Cc:	Kevin Kingdon; '[e-mail]'
> Subject:	Re: keyIdentifiers
> 
> Folks,
> 
> Sorry I didn't jump in earlier, but I've been out of town and out of
> touch
> for a while.
> 
> Key identifiers were motivated as a hueristic to solve the problem of
> which
> of several certs (presumably with different keys) belonging to a CA
> should
> be used to validate a cert that was signed by that CA.  This means
> that the
> IDs need only be unique relative to the CA in question, since the
> scope of
> the "search" was just the set of certs associated with that CA. Note
> that
> CA name and serial number also are an acceptable alternative for this
> purpose.
> 
> Some have suggested using these IDs are a "key" for database searches
> for
> cert chain construction, etc., but this is not within the scope of the
> extension, and thus I would advise against design decisions based on
> presumed global uniqueness, even though the odds are in your favor for
> many
> values of "global" ;-).  S/MIME does rely on the likely global
> uniqueness
> of this value, if I recall correctly, using it as a tag for
> per-recipient
> tokens.  This is a carryover from the MSP design, where we had a key
> material ID that was guaranteed to be unique and which could be used
> for
> this purpose.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA11155 for ietf-pkix-bks; Thu, 5 Nov 1998 12:29:34 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11151 for <[e-mail]>; Thu, 5 Nov 1998 12:29:33 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA26281; Thu, 5 Nov 1998 12:31:46 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 05 Nov 1998 15:26:12 -0500
To: "Dwight Arthur" <[e-mail]>, <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <000801be08ed$9d1f5420$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

In the PKI with which I am familiar (which has been operational for more
than 3 and 1/2 years now), we use a couple of different terms:

	renewal:  issue a new certificate with the same DN, the same attributes,
the same key, a different certificate serial number, and a different
validity period

	update:  issue a new certificate with the same DN, but with one or more
new attributes, a new key, a different certificate serial number, and a
different validity period (where here, "attribute" means any field in the
certificate other than the subject DN, issuer DN, certificate serial
number, or validity period).

"Renewal" is used when a user is continuing on in the same job.  E.g.,
certificates are issued for a period of 6 months.  At the end of that time,
the user is in the same job, at the same place, with the same privileges,
etc.  We just give the user a renewed certificate, good for another six
months, because nothing else is changed.  We change the serial number to
distinguish between the old and new certs - it's the issuer/serial number
combination that uniquely identifies the certificate.  And, obviously, the
signature value changes. 

Why use the same key?  Why not - assuming that the useful lifetime hasn't
expired, it's not a security problem. If the useful lifetime hasn't
expired, we don't let the cert be renewed.

"Update" is when something else (other than the user's name) has changed -
the user's access authorizations, privileges, etc. In that case, we revoke
the old certificate, because the change may have resulted in the loss of
access, and we want to make sure that the old cert won't work.  We demand a
new key for the same reason.  (Strictly speaking, you wouldn't have to
revoke the old certificate if the change resulted in an increase of access
privileges, but it's administratively easier to just always revoke the old
cert.)

If the only attribute that changes in an "update" is the user's public key,
it's called a "rekey", but the same rules apply.

Note that in a renewal, you can have multiple certificates valid for the
same user at the same time (if you issue the renewal before the old
certificate expires, which is generally considered to be the smart thing to
do).  Since the public key's the same (and thus the associated private
key's the same) it's not a major problem, assuming that the end-entity is
capable of dealing with the fact that there are two certs for the same user
in the repository.

				Al Arsenault


-- these are my opinions only.  They do not necessarily reflect the
opinions of my employer, or of any other organization with which I have a
relationship.




At 01:53 PM 11/5/98 -0500, Dwight Arthur wrote:
>At the National Securities Clearing Corporation we are beginning to face
>renewal requirements. In every case we are talking about same CN, same CA,
>same DN, and different validity period. I would like to say that in all
>cases we will be seeing a new public key, and we would certainly discourage
>the idea or re-certifying the same key, but I cannot guarantee that we will
>never see renewal with the same public key.
>
>Two requirements that we consider critical, but not easily fulfilled given
>the current state of the are, are:
>- DN in renewed certificate is exactly identical to DN in original
>certificate.
>- Start of renewed certificate's validity period is exactly equal to
>expiration of the original certificate's validity period no overlap no gap.
>The renewed certificate would be issued as much as six weeks before the
>start of its validity period.
>--------------------------------------------------
>p:[phone]                     Dwight Arthur
>f:[phone]        Managing Director: Systems
>b:[phone]      National Securities Clearing
>[e-mail]        55 Water Street
>http://www.nscc.com        New York, NY 10041-0082
>
>-----Original Message-----
>>	Actually, the most prevalent case is likely to be:
>>	3) Same CA, different public key, same CN
>>
>Really?  I always thought it would be validity date.  Of course this would
>be about 18 months after PKI rollout.
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA11109 for ietf-pkix-bks; Thu, 5 Nov 1998 12:23:50 -0800 (PST)
Received: from slack.lne.com ([e-mail] [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11105 for <[e-mail]>; Thu, 5 Nov 1998 12:23:48 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id MAA25218; Thu, 5 Nov 1998 12:26:42 -0800
From: Eric Murray <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Is certificate renewal a good idea?
To: [e-mail] (Dwight Arthur)
Date: Thu, 5 Nov 1998 12:26:42 -0800 (PST)
Cc: [e-mail]
In-Reply-To: <000801be08ed$9d1f5420$[e-mail]> from "Dwight Arthur" at Nov 5, 98 01:53:44 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Dwight Arthur writes:
> 
> At the National Securities Clearing Corporation we are beginning to face
> renewal requirements. In every case we are talking about same CN, same CA,
> same DN, and different validity period. I would like to say that in all
> cases we will be seeing a new public key, and we would certainly discourage
> the idea or re-certifying the same key, but I cannot guarantee that we will
> never see renewal with the same public key.
> 
> Two requirements that we consider critical, but not easily fulfilled given
> the current state of the are, are:
> - DN in renewed certificate is exactly identical to DN in original
> certificate.
> - Start of renewed certificate's validity period is exactly equal to
> expiration of the original certificate's validity period no overlap no gap.
> The renewed certificate would be issued as much as six weeks before the
> start of its validity period.


Perhaps I'm missing something, but this doesn't seem that hard to me.
Just send a copy of the old certificate along with the renewal
request  (and something signed with the corresponding private key)
for the CA to use to fill in the Subject and calculate
the new Validity from.


However, what happens if a user signs a message with the old cert/key
right before it expires, and the new cert has a new key?  Then the
recipient of the signed message can't verify it because the certificate
has expired.  Unless your protocol has a way to deal with this, I'd
suggest overlapping Validity periods and/or using KeyUsagePeriod to
restrict the use of the private key to a shorter period than the cert is
valid for.


-- 
Eric Murray          N*Able Technologies                    www.nabletech.com
(email:  ericm  at the sites lne.com or nabletech.com)     PGP keyid:E03F65E5


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10875 for ietf-pkix-bks; Thu, 5 Nov 1998 11:49:59 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10871 for <[e-mail]>; Thu, 5 Nov 1998 11:49:58 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA26222; Thu, 5 Nov 1998 14:52:49 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA20434; Thu, 5 Nov 1998 14:52:47 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.006CD6DA ; Thu, 5 Nov 1998 14:48:48 -0500
X-Lotus-FromDomain: FDC
To: Francois Rousseau <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 11:50:39 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

one account attribute is the account balance in your bank account. would a
attribute certificate be re-issued and the previous one(s) invalidated
everytime the account balance changed. would you present an account balance
attribute certificate everytime you executed a financial transactions.
would a new CRL have to be sent out to all parties that you might possibly
ever do a financial transaction with everytime the value in your bank
account changed (either increased or decreased). Could you imagine an
optimization where you only sent out a CRL for decreases ... and not
necessarily for increases. What would be the protocol between you, your
bank, and the CA for issuing new validated attribute certificates everytime
your bank account changed. Because of privacy concerns are you really
interested in broadcasting your current account balance in an attribute
certificate on every financial transaction?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10765 for ietf-pkix-bks; Thu, 5 Nov 1998 11:39:52 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10761 for <[e-mail]>; Thu, 5 Nov 1998 11:39:51 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA21921; Thu, 5 Nov 1998 14:42:41 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA19983; Thu, 5 Nov 1998 14:41:15 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.006BC84E ; Thu, 5 Nov 1998 14:37:16 -0500
X-Lotus-FromDomain: FDC
To: EKR <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 11:40:05 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

x9.59 attacked different parts of the problem .... in the case of the
common useage of SSL for the buy button .... X9.59 was designed to insure
the integrity of the financial infrastructure using only digital signature
for authentication and not requiring any encryption.

... i.e. while the SSL URL (& certificate) check is interesting ... the
common useage for SSL is encryption connection between the client and
browser to protect something.

x9.59 insures the integrity of the financial infrastructure w/o requiring
SSL/encryption for protection.
it has the advantage of doing end-to-end integrity eliminating a lot of the
opportunity for fraud (security 101 teaches that any time you seperate
authentication and authorization .... holes/opportunities for fraud open
up). x9.59 also has the advantage that it works for all electronic
environments (not simply limited to internet).

one approach to the area that SSL URL checking addresses would be having
ISP boundary routers doing address filtering on origin address of incoming
packets. this can reduce many of the spoofing related attacks (not just the
one caught by the SSL URL checking) and provide some evidence trail back to
attack origins.  other is general upgrade of authentication procedures to
public key ... both at boundary points and infrastructure operations (like
DNS).

i believe that public key infrastructure for authentication is good thing.
I believe that basic justification for certificates is to provide
authentication attribute binding for offline operations; raising offline
integrity closer to what online account-based operations have. introducing
certificates into an online account-based operations can result in lowering
the integrity ....

i.e. online account-based operations with public key authentication (and no
certificates) can have extremely high integrity. The incremental increase
in integrity offered by certificates would be nominal and typically more
than offset by the decrease in integrity created by increased complexity
(i.e. complexity all by itself creates an integrity issue).  The addition
of certificate to an AADS PKI .... would represent an integrity issue ....
even if the certificate was totally ignored ... since, at the very least,
the level of complexity is raised. To the extent that the certificate is
not ignored and represents something in the process .... it further
increases complexity (having to check the CA-signing key on the certificate
or checking a CRL represents complexity & integrity issues)..... and to
actually represent a net increase in integrity there would have to some
significant reduction in the account-based operations (like eliminating the
account-related operations totally). A troublesome area for the elimination
of the account-based operations are real-time attributes and/or sensitive
attributes that raise privacy issues.

A pervasive example in the internet world are ISP account based operations
for internet service. There are real-time issues like has the account been
canceled and/or suspended (for say not paying the bill). One might consider
pre-paid accounts (like pre-paid phone cards) ... with a certificate that
was good for the pre-paid period. However, accounts still might be
cancelled ... which would need reference to the account record. As soon as
I have to touch an account record .... then having the public key bound in
the account record is simpler and higher integrity than processing
information both in the account record and in a certificate (along with all
the baggage of validating the certificate & certificate infrastructure).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA10557 for ietf-pkix-bks; Thu, 5 Nov 1998 11:18:09 -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 LAA10553 for <[e-mail]>; Thu, 5 Nov 1998 11:18:06 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV17P6B>; Thu, 5 Nov 1998 14:21:28 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 14:21:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Interesting.  Does this mean that the same CN would have two certs to choose
from during this six-week period?

> -----Original Message-----
> From:	Dwight Arthur [SMTP:[e-mail]]
> Sent:	Thursday, November 05, 1998 1:54 PM
> To:	[e-mail]
> Subject:	RE: Is certificate renewal a good idea?
> 
> At the National Securities Clearing Corporation we are beginning to face
> renewal requirements. 
> 
	[snip]

> The renewed certificate would be issued as much as six weeks before the
> start of its validity period.
> --------------------------------------------------
> p:[phone]                     Dwight Arthur
> f:[phone]        Managing Director: Systems
> b:[phone]      National Securities Clearing
> [e-mail]        55 Water Street
> http://www.nscc.com        New York, NY 10041-0082
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10159 for ietf-pkix-bks; Thu, 5 Nov 1998 10:51:43 -0800 (PST)
Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA10155 for <[e-mail]>; Thu, 5 Nov 1998 10:51:43 -0800 (PST)
Received: from NS95LAP005.nscc.com (user-38ld19t.dialup.mindspring.com [209.86.133.61]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id NAA31809 for <[e-mail]>; Thu, 5 Nov 1998 13:54:32 -0500 (EST)
From: "Dwight Arthur" <[e-mail]>
To: <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 13:53:44 -0500
Message-ID: <000801be08ed$9d1f5420$[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.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

At the National Securities Clearing Corporation we are beginning to face
renewal requirements. In every case we are talking about same CN, same CA,
same DN, and different validity period. I would like to say that in all
cases we will be seeing a new public key, and we would certainly discourage
the idea or re-certifying the same key, but I cannot guarantee that we will
never see renewal with the same public key.

Two requirements that we consider critical, but not easily fulfilled given
the current state of the are, are:
- DN in renewed certificate is exactly identical to DN in original
certificate.
- Start of renewed certificate's validity period is exactly equal to
expiration of the original certificate's validity period no overlap no gap.
The renewed certificate would be issued as much as six weeks before the
start of its validity period.
--------------------------------------------------
p:[phone]                     Dwight Arthur
f:[phone]        Managing Director: Systems
b:[phone]      National Securities Clearing
[e-mail]        55 Water Street
http://www.nscc.com        New York, NY 10041-0082

-----Original Message-----
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
Really?  I always thought it would be validity date.  Of course this would
be about 18 months after PKI rollout.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA10129 for ietf-pkix-bks; Thu, 5 Nov 1998 10:49:47 -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 KAA10124 for <[e-mail]>; Thu, 5 Nov 1998 10:49:45 -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 NAA26277; Thu, 5 Nov 1998 13:50:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 05 Nov 1998 13:47:45 -0500
To: [e-mail], [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jun and Lynn,

As indicated by Jun, a public-key certificate is meant to cryptographically
bound a public key to a user for authentication and identification
purposes, and should last as long as the strength of the cryptographic
algorithm used to sign this public-key certificate will permit unless it
needs to be revoked for various reasons.

For these volatile attributes, this is why Attribute Certificates have been
defined under X.509 (1997) and ANSI X9.57 (1997). An Attribute Certificate
is meant to cryptographically bound attributes (i.e. privileges) to the
public-key certificate of this user for access control and authorization
purposes, and should last as long as required by these privileges, which
can be extremely short or longer as required.

Francois Rousseau
AEPOS Technologies

Jun Yoshitake wrote:
>
>Lynn,
>
>I may misunderstand you, but
>I am wondering why a real-time attribute
>(which causes the privacy issues, etc.)
>has to be included in a certificate.
>
>I think the following method would be better:
>
>  A certificate shows the static binding
>  between the subject and the public key.
>
>  A real-time attribute is accessed inside the
>  application server after the successful
>  validation of the certificate. ("OK, this
>  transaction has surely come from this
>  entity, then we access the real-time
>  attribute of the entity.")
>
>Jun Yoshitake
>
>Mitsubishi Electric Corp.
>
>
>[e-mail] wrote:
>
>> an issue was binding of real-time attributes ... needing real-time access
>> to the account record .... or in a CA model the real-time invalidation &
>> real-time re-issue of a certificate anytime any of the real-time attributes
>> changed (i.e. like everytime you bank account balance changed ... which
>> possibly opens up the privacy issue of all this attribute information
>> flying around the world).
>>
>> if the attributes have to be accessed to complete the transaction ... then
>> the account record can be used in lieu of certificate to create a binding
>> between a public key and the attributes in question. If the transaction has
>> to touch the account record where the binding between the real-time
>> attributes and public key is located .... then a certificate with (possibly
>> stale) duplicate binding is superfulous to include in such a transaction.
>>
>> fundamentailly there are business requirements for authentication bindings
>> .... (passwords, shared secrets, public key, etc). this has been implemeted
>> and deployed for a very long time in the account-based world. one could
>> characterize certificates as having been created to extend a similar
>> capability into an offline environment. trying to propogate the offline
>> (relatively static/stale) certificate solution back into an online
>> environment where there exists a much richer capability for real-time
>> attribute authentication bindings would be at least superfulous .... and at
>> worst creating unecessary risks & liability.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09983 for ietf-pkix-bks; Thu, 5 Nov 1998 10:41:24 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09978 for <[e-mail]>; Thu, 5 Nov 1998 10:41:23 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id KAA14865 for <[e-mail]>; Thu, 5 Nov 1998 10:44:05 -0800 (PST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: [e-mail]
Subject: Questions about the samples in Part1-11
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Nov 1998 10:44:05 -0800
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Hi all...

Not to detract from the terrific debate over fundamental PKI architectures,
but I have a couple of questions/comments about the annotated sample certs
in the Part1 draft.  These concern the AuthorityKeyIdentifier extension.

In the cert in D.2, the OID for the authKeyId (2.5.29.35) is mislabeled as
subjectAltName.

In the cert in D.3, the OID is properly labeled, but the key identifier 
itself is 16 bytes long.  16 bytes doesn't correspond to either of the key 
identifier possibilities (the 160-bit SHA1 hash or the 64-bit partial-
hash-and-prefix).

I'm guessing that the mislabeled authKeyId in the D.2 cert is correct, and
that the properly labeled one in D.3 has got a bad value.

(The subjectKeyId in D.1 looks OK to me.)

Am I misinterpreting this stuff?

		Marc



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNkHx9FrdFXNdDxPlAQE2kgL/Y8/Hi+nx1l7FwqykHpSS4ThRAys4vwo3
ZzBrxfaxOXixQLftLjpay2In1IC8KYWyCz68PNTXrNZyi3bb3PehA8DsOGMUdTWU
OaxESm6n8jcVK9CO5xuCwbH1V58f1CjE
=A/6n
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09890 for ietf-pkix-bks; Thu, 5 Nov 1998 10:37:32 -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 KAA09883 for <[e-mail]>; Thu, 5 Nov 1998 10:37:31 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV17PJM>; Thu, 5 Nov 1998 13:40:41 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Thu, 5 Nov 1998 13:40:14 -0500 
Importance: low
X-Priority: 5
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

Let's, for a moment, go back to case # 2, viz.:  " 2)  Same CA, same public
key, same subject name, different information in the certificate (e.g.,
alternative names, validity period, CP/CPS)".  I can see how "alternative
names" will work (there are several ways to achieve it), but not how the
relying EE could deal with different validity periods or different CPs or
different CPS.  Each cert has one validity period (if it didn't, how could
the relying EE tell if it was still in play?--use the most distant Not
Before date?  I don't think so!).  Each cert also has it's own CP derived
from the three policy extensions.  And each CA has it's own CPS.  It's hard
enough to write just one CPS (it's a growth legal niche supreme).  Anyway,
all of these last three differences are academic, since they lie way outside
of PKIX compliance.  But you can always try SPKI!!

Bill
  


> -----Original Message-----
> From:	Stefan Santesson [SMTP:[e-mail]]
> Sent:	Wednesday, November 04, 1998 5:19 PM
> To:	Tammy Carter; [e-mail]; [e-mail]
> Subject:	RE: Is certificate renewal a good idea?
> 
> I would suggest that all cases #1, #2 and #3 could be valid and should be
> considered good practice as long as the certified information is correct.
> 
> All certificates are individual statements with individual liabilities. 
> 
> We have also identified several scenarios where the same public key can be
> associated with different subject names as long as they are associated
> with
> the same subject. The only "wrong" case I can see is if the same public
> key
> is certified to separate individuals in different certificates.
> 
> It will be the relying party who in the end will decide if a particular
> certificate is suitable for the present case, taking all factors in
> consideration. In this decision the relying party shall not have to be
> aware of any other related certificate for the same subject or key.
> 
> In cases of name change it would also be OK to re-issue the same
> certificate with the new name as long as the old certificate is revoked
> (if
> the old name is invalid).
> 
> For those interested in liabilities and the legal jungle associated with
> digital signatures, I would highly recommend to take a look at INCITRALs;
> "Planning of future work on electronic commerce: digital signatures,
> certification authorities and related legal issues", found at:
> http://www.un.or.at/uncitral/en-index.htm
> 
> /Stefan
> 
> At 12:28 PM 11/4/98 -0700, Tammy Carter wrote:
> >Bill, 
> >
> >I hope that you are right that your case #3 is the prevalent case.
> However,
> >my question is more along the lines of what a CA should do in cases #1
> and
> #2.
> >And, should client software be built to support case #2?
> >
> >
> >>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
> >See comments below.
> >
> >> -----Original Message-----
> >> From:	Tammy Carter [SMTP:[e-mail]] 
> >> Sent:	Tuesday, November 03, 1998 6:24 PM
> >> To:	[e-mail] 
> >> Subject:	Is certificate renewal a good idea?
> >> 
> >> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> >> others have mentioned 
> >> certificate renewal.  I had found this topic conspicuously absent from
> any
> >> of the PKIX drafts and 
> >> had assumed that renewing certificates was considered bad practice.
> Can
> >> someone enlighten 
> >> me?
> >> 
> >> It seems as though there are two cases to consider:
> >> 1)  Same CA, same public key, different subject name
> >> 2)  Same CA, same public key, same subject name, 
> >>       different information in the certificate (e.g., alternative
> names,
> >> validity period, CP/CPS)
> >> 
> >	Actually, the most prevalent case is likely to be:
> >	3) Same CA, different public key, same CN
> >
> >	[snip]
> >
> >> Comments?
> >> 
> >	Above.
> >
> >> Tammy Green Carter
> >> [e-mail] 
> >> 
> >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
> >Defense Information Systems Agency      Fax:           [phone] 
> >Information Assurance Office (JED)      DSN:                      761
> 
> >5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
> >Falls Church, VA 22041-2717        Internet:  <[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 KAA09823 for ietf-pkix-bks; Thu, 5 Nov 1998 10:34:10 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09819 for <[e-mail]>; Thu, 5 Nov 1998 10:34:09 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id KAA06727; Thu, 5 Nov 1998 10:38:16 -0800 (PST)
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 10:38:15 -0800
In-Reply-To: [e-mail]'s message of "Thu, 5 Nov 1998 10:11:36 -0800"
Message-ID: <[e-mail]>
Lines: 34
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:

> i stated that  i've never seen a SSL session fail the first time a client
> sees a server certificate that was manufactored by a CA on the browswer's
> CA list ... and you are claiming that is incorrect?
No, I'm claiming that the following statement is incorrect:
"(the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list)."

> I also believe that as a factor in exploit it is somewhat nullified in
> common practice because majority of SSL sessions are entered with things
> like clicking on a buy button. the URL check catches somebody claiming to
> being a URL that they aren't (and somehow misrouting traffic).
> If it is possible to mis-represent a URL ... prevented by the SSL check ...
> then it is also possible to mis-represent the page that (in common
> practice) gets you to the SSL session ...
> in which case the exploit just has a server certificate that corresponds to
> the URL that you are sent to.
Naturally. However, it's hard to see how to fix this problem
automatically without employing security all the time (which would
protect the references as well), since the issue is typically the
correspondence between the user's expectation of whom he is buying
from (which the program really doesn't have any way of knowing) and
the actual identity of that entity. I'd be interested in hearing
what mechanical check you think would protect against this attack.

Naturally, the user can check the certificate against his expectations,
but that's not automatic.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09657 for ietf-pkix-bks; Thu, 5 Nov 1998 10:24:52 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09652 for <[e-mail]>; Thu, 5 Nov 1998 10:24:51 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22639; Thu, 5 Nov 1998 13:27:41 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA16994; Thu, 5 Nov 1998 13:26:28 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F242 ; Thu, 5 Nov 1998 13:22:36 -0500
X-Lotus-FromDomain: FDC
To: EKR <[e-mail]>
cc: Stephen Kent <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:11:36 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i stated that  i've never seen a SSL session fail the first time a client
sees a server certificate that was manufactored by a CA on the browswer's
CA list ... and you are claiming that is incorrect?

I didn't claim that the URL check didn't exist ... i claimed that I've
never seen it occur.

I also believe that as a factor in exploit it is somewhat nullified in
common practice because majority of SSL sessions are entered with things
like clicking on a buy button. the URL check catches somebody claiming to
being a URL that they aren't (and somehow misrouting traffic).
If it is possible to mis-represent a URL ... prevented by the SSL check ...
then it is also possible to mis-represent the page that (in common
practice) gets you to the SSL session ...
in which case the exploit just has a server certificate that corresponds to
the URL that you are sent to.






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09615 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:47 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09611 for <[e-mail]>; Thu, 5 Nov 1998 10:23:46 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22331; Thu, 5 Nov 1998 13:26:36 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA17006; Thu, 5 Nov 1998 13:26:35 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F47E ; Thu, 5 Nov 1998 13:22:41 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:13:09 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i agree that the SSL specification works as you described ... including the
URL check.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09609 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:45 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09605 for <[e-mail]>; Thu, 5 Nov 1998 10:23:44 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22324; Thu, 5 Nov 1998 13:26:35 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA17001; Thu, 5 Nov 1998 13:26:33 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F4B5 ; Thu, 5 Nov 1998 13:22:42 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Alan Lloyd <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:22:06 -0800
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

i've stated that if an account record has to be accessed in order to
complete the operation/transaction ..... then the certificate portion is
superfulous.

As mentioned elsewhere, certificates have been characterized as originating
to provide similar attribute/authentication binding in the offline world as
has been available in the online, account-based world (the certificates
don't do the authentication ... the certificates provide the binding
between attributes and public-key so that the authentication can be done
... i.e. enabling authentication capability similar to what is provided by
accounts in the online world).

Trying to then retrofit such an offline binding capability to the online
world ... where the binding capability has already existing ... is
superfolous, tends to unncessarily increase risk and complexity while
reducing availability.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09603 for ietf-pkix-bks; Thu, 5 Nov 1998 10:23:42 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09598 for <[e-mail]>; Thu, 5 Nov 1998 10:23:41 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id NAA22320; Thu, 5 Nov 1998 13:26:31 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA16997; Thu, 5 Nov 1998 13:26:29 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0064F1DD ; Thu, 5 Nov 1998 13:22:35 -0500
X-Lotus-FromDomain: FDC
To: Jun Yoshitake <[e-mail]>
cc: Stephen Kent <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Alan Lloyd <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 09:55:00 -0800
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

in order to  complete a transaction/operation ... if a account record has
to be accessed at all (because of real-time, privacy or other reasons),
then seperating attributes into those in a certificate and those in the
account record can, at best, represent superfulous effort and significant
increase in complexity .... and at worst increase various kinds of risk and
significantly lower availability of the infrastructure.

there is nothing implicit about partitioning the attributes needed to
complete a transaction/operation into several places ... however, each such
partitioning typically significantly increases complexity and risk while
lowering availability. Reasons for partitioning can include requirements
for account-based operations because of things like real-time attributes
and/or sensitivity/privacy issues associated with attributes.

the simplest example is an existing online, account-based, electronic
authorization environment (say like an ISP RADIUS environment that uses
passwords for authentication).  Contrast in terms of risk, failure modes,
complexity two implementation modes:

1) registering a public key in a RADIUS account record in lieu of a
password, modifying the RADIUS serrver to do digital signature
authentication with the registered public key, and modifying the RADIUS
client to accept a digital signature (in lieu of a password).

2) create a CA, create a CA database, create a CA customer call center
and/or tieing an existing customer call center into the CA database,
getting a signed CA certificate, registering public keys at the CA, issuing
certificates, modifying RADIUS client to accept certificate and digital
signature, modifying RADIUS server to verify certificate and authenticate
CA digital signature on the certificate, checking for a CRL entry for the
certificate, retrieving the CA's digital certificate, verifying the CA's
digital certificate and the digital signature on the CA's digital
signature, checking for a CRL entry for the CA's digital signature (etc ...
possibly on up to the root-CA tree) and finally accessing the RADIUS
account record.

First off, the transaction in neither mode will complete if the RADIUS
server and RADIUS account record is unavailable. However, in addition, the
second mode won't complete if none of the remaining PKI infrastructure is
unavailable (and/or if it chooses to continue in spite of it being
unavailble opens up fraud and risk potential completing the operation w/o
completing the authentication process).

At NISS conference last month a financial institution talked about
migration to relying party certificates because of privacy and liability
issues .... i.e. a certificate containing only the account number and
public key. In this scenerio, the certificate is stored in the account
record when the public key is registered and a copy returned to the owner.
This about reduces privacy, liability, complexity, risk, availability and
fraud exposures to a minimum (associated with using both a certificate and
an account record). At this point, the question becomes why does the owner
have to send a digital signature and the certificate to the institution on
every operation .... if the institution already has the original of the
certificate. The downside risk is that the certificate signing key at least
becomes a point of attack ... unless the institution totally ignores the
sent certificate and alwas relies on the original in the account  for
verifying the account owners digital signature ... in which case sending
the certificate even becomes more superfulous.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07624 for ietf-pkix-bks; Thu, 5 Nov 1998 06:40:58 -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 GAA07619 for <[e-mail]>; Thu, 5 Nov 1998 06:40:56 -0800 (PST)
From: [e-mail]
Received: (from uucp@localhost) by btec-fw.certco.com (8.8.8/8.8.8) id JAA23644; Thu, 5 Nov 1998 09:43:29 -0500 (EST)
Received: from nycertco-srv1.ny.certco.com(192.168.69.12) by btec-fw.certco.com via smap (V2.1) id xma023627; Thu, 5 Nov 98 09:43:16 -0500
Received: by nycertco-srv1.ny.certco.com with Internet Mail Service (5.5.2232.9) id <W1RH1PDB>; Thu, 5 Nov 1998 09:43:16 -0500
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:43:10 -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

E-mail addresses in Certificates sounds good, but please do not put them
into the Certificate's subject.

A Certificate's subject is a singular Name. A Name is a CHOICE of one type:
RDNSequence.

S/MIME embeds two names into subject: a distinguished name and an e-mail
address. Embedding multiple names into subject works OK for S/MIME, but does
not scale. Just imagine 20 or 30 names.

Should a Certificate contain multiple names? Why not!

One solution is to add a CHOICE to Name each time a new application naming
system is defined. This system is pretty efficient and works in a closed
system. In an open system, this solution does not scale very well and
requires everyone to update their systems.

Another solution is to leave Name alone (RDNSequence remains the common
"handle") and let application's define Extension(s) for their naming
systems. For example, Alice might choose to integrate all her names (and
identifiers) into one monolithic Certificate (e.g., social security number,
credit card account number, checking account number, email address, etc.),
while Bob might choose to use separate certificates.

Frank Balluffi
CertCo


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, November 04, 1998 5:18 PM
To: Phillip M Hallam-Baker
Cc: [e-mail]
Subject: Re: Scale (and the SRV record)


Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07464 for ietf-pkix-bks; Thu, 5 Nov 1998 06:15:51 -0800 (PST)
Received: from tarius.tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07457 for <[e-mail]>; Thu, 5 Nov 1998 06:15:47 -0800 (PST)
Received: from boa.tycho.ncsc.mil (boa.tycho.ncsc.mil [144.51.3.28]) by tarius.tycho.ncsc.mil (8.9.1/8.9.1) with SMTP id JAA03127; Thu, 5 Nov 1998 09:14:20 -0500 (EST)
Received: by boa.tycho.ncsc.mil with Microsoft Mail id <[e-mail]>; Thu, 5 Nov 1998 09:03:33 -0500
Message-ID: <[e-mail]>
From: James M Hayes <[e-mail]>
To: "'EKR'" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:03:31 -0500
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 GAA07459
Sender: [e-mail]
Precedence: bulk

> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847

-----Original Message-----
From:	EKR [SMTP:[e-mail]]
Sent:	Thursday, November 05, 1998 7:58 AM
To:	[e-mail]
Cc:	Stephen Kent; [e-mail]
Subject:	Re: Scale (and the SRV record)

[e-mail] writes:
> you must live on another part of the internet than i do.
> 
> I've seen clients fail SSL connection because the supplied server
> certificate wasn't manufactored by a CA in the included browswer list.
Of course. 

> I've yet to see a client fail an SSL connection because it was the first
> time it had ever encountered a particular server certificate ... had
> absolutely no record of the particular server certificate or prior
> knowledge of the particular server (the only characteristic for succesful
> SSL seems to be that the server's certificate was manufactored by CA known
> in the browser list).
Lynn, this simply isn't correct.

There are two major checks for a server certificate:
1. That it's descended from a trust point.
2. That it contain a name that corresponds to the URL that the
client thinks it's dereferencing. 

In terms of browsers, I would add the following to keep things in perspective:

1. Trust - Trust management is still an issue within the browser environment.  The user doesn't really know which authority is actually authorized to certify a certificate for a given server (certificate masquerade). For example, if Bob connected to a web site outside of his company and ended up with a server certificate signed by his company CA (in his browser), he may actually think that this is okay.   His company is suppose to provide the security to entities outside of his company.  Chances are that Bob will just look for the "secure" icon and not ever see that his CA signed the certificate.
2. Education - Users do not actually know how to go about verifying the authenticity of the CAs in their browsers or where to go to get the actual information.   
3. PKIX Nemesis - Real-time revocation status is still an issue.  

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


> JAMES M. HAYES, Capt, USAF
> Information Operations Research Manager
> The Office of INFOSEC Research and Technology
> National Security Agency
> 301-688-0847



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07436 for ietf-pkix-bks; Thu, 5 Nov 1998 06:13:43 -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 GAA07432 for <[e-mail]>; Thu, 5 Nov 1998 06:13:40 -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 DAA07696; Fri, 6 Nov 1998 03:16:15 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91027537526614>; Fri, 6 Nov 1998 03:16:15 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Scale (and the SRV record)
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 6 Nov 1998 03:16:15 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alan Lloyd <[e-mail]> writes:
 
>Perhaps the answer to most of this is to ask how PKI suppliers are 
>integrating their non directory solutions into organisations - without 
>causing yet more islands of services, information and higher operational costs.
>
>Or why they built X.509 without X.500. Thats a bit like using a data 
>structure from a database - without using the features of a database.
 
It's interesting that you mention the word "database" here in relation to 
X.509.  About six months ago I did an informal poll of users of my crypto 
toolkit to see what they were doing for certificate storage.  The toolkit
supports everything from primitive flat files and smart cards through all 
manner of RDBMS's and LDAP.  The almost universal solution to certificate 
storage needs was MS Access.  Everything else may as well not have existed.
 
Some comments on this:
 
This is for the unwashed masses who have to work with crypto (developers and 
implementors), not cryptographers.  All they wanted was a way to map an email 
address/server name to a key.  Heirarchical storage and free-form attributes 
and fuzzy dice and chrome tailfins were nothing but a nuisance to work around 
(so far I've identified one single user of an LDAP directory, and AFAIK he was 
only playing with it on a Unix box).  Dunno how many users there are in total, 
but at one point it was averaging 200 downloads a week.  Most of the users in 
the informal poll used Win32 and VB (spit), followed by Delphi/C/C++.
 
Although I don't know whether I want to laugh or cry at the use of Access, it 
does make sense: It's either pre-installed on the most widely-used platform on 
the planet or can be trivially added via the MS Jet engine[0], and there are a 
huge number of third-party tools available to use with it.
                                                          
[Purely in order to forestall the inevitable comments about "it won't scale 
 and there's no replication and it's not distributed and you can't get it with 
 fuzzy dice and ...", I'll reiterate what I said above: The users don't care.  
 Given the choice, they've gone for the easy-to-use, widely-available solution 
 which does the job.  I'll continue to support whatever's around and let the
 users make their own choice, but when it comes to key storage mechanisms they 
 sure aren't choosing X.500 or anything derived from it]
 
Peter.
 
[0] So-called because it both sucks and blows.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA07201 for ietf-pkix-bks; Thu, 5 Nov 1998 05:39:12 -0800 (PST)
Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA07197 for <[e-mail]>; Thu, 5 Nov 1998 05:39:11 -0800 (PST)
Received: from doogie by smtp0-alterdial.uu.net with SMTP  (peer crosschecked as: 1Cust119.tnt3.tco2.da.uu.net [153.34.247.119]) id QQfoeo04801; Thu, 5 Nov 1998 13:41:37 GMT
Reply-To: <[e-mail]>
From: "Steve Russell" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Alan Lloyd" <[e-mail]>
Cc: "'Al Arsenault '" <[e-mail]>, <[e-mail]>
Subject: RE: A different architecture?  (was Re: certificate path services
Date: Thu, 5 Nov 1998 08:33:02 -0500
Message-ID: <004701be08c0$d004c870$[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
In-Reply-To: <v04011719b266a5d4610c@[128.89.31.126]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

General comments on this particular thread:

Can a PKI operate and survive without a directory?  Yes.

Could PKI, as envisioned by most companies, be deployed without a directory?
No.

One of the most fundamental issues that we are dealing with is certificate
and CRL retrieval because it deals with the deployability of PKI rather than
its mathematical validity.  To mandate the implementation of a certain style
or type of directory would be wrong.  However, to not formalize the
standards so that the process of retrieving CRLs and certs from a directory
would be interoperable would be just as wrong.

There are some major headaches that we inherit when we start looking at
directories such as does the directory need to be trusted, what is the
access protocol, how is the personal data in the directory protected, how
are multiple non-related directories referenced by a PKI client.  I won't
attempt to address all of these in this mail, but...

Having worked a lot with X.500 directories, I would rather have a limb
removed than mandate X.500 as a foundation for PKI, but some customers will
choose to do that.  Looking at a set of the sample PKI applications I do
think that accessibility via LDAP is necessary.  Having said that, DNS is a
much better model for the quick retrieval of specific data because of it
simplicity and very loose referral relationships.  The structure of a DNS
address is also much easier to process within an application than the
umpteen levels that are commonly implemented in X.500 and LDAP DITs.  The
question is do we place the certificate in DNS and maybe slap (pun intended)
a LDAP server on the database or do we design a separate structure which has
a similar format and build up the relations over time...

May I suggest a compromise?  Make one change to DNS to add a new record type
which is a directory server, however, the certificate repository would
remain separate from the DNS database.  When a user references 'foo.com' to
attempt to find a certificate or a CRL the appropriate DNS would refer them
to appropriate directory server much like MX records work today.  This also
allows users the flexibility to transparently maintain internal directories
separately from publicly available directories based on which DNS their
users reference.  It has the advantage of potentially providing a much
richer set of data storage and access controls (through LDAP or X.500) than
would ever be feasible to build into DNS.  Lastly, it resolves a potential
paging problem that would exist with DNS when requesting a large number of
certificates or CRLs.

Comments?

Steve
_______________________________________________________
Steve Russell
Chief Technologist
Public Key Strategies, Inc.
_______________________________________________________



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06943 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59: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 EAA06939 for <[e-mail]>; Thu, 5 Nov 1998 04:59:45 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03858; Thu, 5 Nov 1998 08:02:19 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011704b2674fc12933@[128.33.238.37]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Nov 1998 07:53:45 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>you must live on another part of the internet than i do.

Well, working for the company that pioneered Internet technology, I may
live in a better neighborhood :-).

>I've seen clients fail SSL connection because the supplied server
>certificate wasn't manufactored by a CA in the included browswer list.

Of course that's true, but that does not disagree with my observation;
first one authenticates the server cert, then one matches it against the
server URL.  You're just seeing a failure of the first part of a two stage
mechanism.

>I've yet to see a client fail an SSL connection because it was the first
>time it had ever encountered a particular server certificate ... had
>absolutely no record of the particular server certificate or prior
>knowledge of the particular server (the only characteristic for succesful
>SSL seems to be that the server's certificate was manufactored by CA known
>in the browser list).

First time has nothing to do with this, Lynn.  Review the description for
how SSL processing of server certs works.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06936 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06923 for <[e-mail]>; Thu, 5 Nov 1998 04:59:42 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03837; Thu, 5 Nov 1998 08:02:13 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011702b2674ddab6a1@[128.33.238.37]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4EE@DSG1>
Date: Thu, 5 Nov 1998 07:47:42 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Cc: [e-mail], Phillip M Hallam-Baker <[e-mail]>, Al Arsenault 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>Steve I think the response missed the issue. The issue Lynn describes is
>one of optimising information management and keeping all things
>pertinent to a User in one place (inc its certs) and that over a
>distributed business, different users will be stored in different
>places. Its not a question of "real time" because directories can be
>real time, thats sizing. Its not a question of caching, because the data
>has to come from somewhere in the first place.
> The common approach to User and user authentication is a single record
>- in a distributed "data store" - a directory system  and that a CA
>directory is part of the directory cloud and that User entries have User
>certs in for authentication.
> IMHO Its the information management and administration optimisation
>that drive the directory requirements for the larger organisations.
>

Not surprizingly, we again disagree.  The issue of realtime IS relevant
here because in such applications (vs. e-mail, for example) the
communicating peers can exchange cert and CRL data directly.  In contrast,
applications such as e-mail require one party to retrieve cert and CRL data
prior to communication.  That's the point I was making.  Also, it IS a
matter of caching because caching provides performamce improvements, an
issue in realtime apps, not so much so in stanged deliver apps.

The common approach you cite for user auth is valid, but the CA is NOT
intrinsically part of the directory.  It is just a subscriber to the
directory, just like the users.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06937 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06926 for <[e-mail]>; Thu, 5 Nov 1998 04:59:43 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03871; Thu, 5 Nov 1998 08:02:22 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011705b267506e51ae@[128.33.238.37]>
In-Reply-To: <[e-mail]>
Date: Thu, 5 Nov 1998 07:56:49 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

 <duplicate text deleted> ...
>
>URL is better than nothing ... but it just says that the URL and the
>certificate is the same. Most instances of https invokation is a button on
>a web-page. It is possible to make sure that the button does in fact invoke
>a URL that matches the certificate ... and it still be an exploit.

The URL against which the match is made is the one associated with the
current SSL session. Since the match is on the DNS name portion, page
differences within the same server are not an issue.  In fact, some
browsers adopt a star-name matching rule and thus allow a match for any of
a series of servers with the same name suffix, e.g., *server.foo.bar.com.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06938 for ietf-pkix-bks; Thu, 5 Nov 1998 04:59:45 -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 EAA06925 for <[e-mail]>; Thu, 5 Nov 1998 04:59:42 -0800 (PST)
Received: from [128.33.238.37] (TC127.BBN.COM [128.33.238.127]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id IAA03845; Thu, 5 Nov 1998 08:02:16 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011703b2674efdfb23@[128.33.238.37]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4EF@DSG1>
Date: Thu, 5 Nov 1998 07:50:26 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: Alan Lloyd 	 <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>But where to these local caches and hard copy books come from. How do
>they get into order. What is the registration or allocation process.

The issue is not the ultimate source of the data, but how people access it
in real time.

>AND
>
>If there was an online directory service would they use that instead.

If it were free, yes. Here in the US the online form is called directory
assistance and it costs money, especially when the data is not local (a
caching issue).

>If directory technology has been designed to be distributed and scale
>and solves lots of people keeping lots of outdated copies - why not use
>it?

If all of this were true of the directory systems, I would agree.  But what
we have now is not characterized by these adjectives ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06843 for ietf-pkix-bks; Thu, 5 Nov 1998 04:54:20 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06838 for <[e-mail]>; Thu, 5 Nov 1998 04:54:19 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id EAA03445; Thu, 5 Nov 1998 04:58:25 -0800 (PST)
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 05 Nov 1998 04:58:24 -0800
In-Reply-To: [e-mail]'s message of "Wed, 4 Nov 1998 21:42:55 -0800"
Message-ID: <[e-mail]>
Lines: 24
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] writes:
> you must live on another part of the internet than i do.
> 
> I've seen clients fail SSL connection because the supplied server
> certificate wasn't manufactored by a CA in the included browswer list.
Of course. 

> I've yet to see a client fail an SSL connection because it was the first
> time it had ever encountered a particular server certificate ... had
> absolutely no record of the particular server certificate or prior
> knowledge of the particular server (the only characteristic for succesful
> SSL seems to be that the server's certificate was manufactored by CA known
> in the browser list).
Lynn, this simply isn't correct.

There are two major checks for a server certificate:
1. That it's descended from a trust point.
2. That it contain a name that corresponds to the URL that the
client thinks it's dereferencing. 

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06706 for ietf-pkix-bks; Thu, 5 Nov 1998 04:23:42 -0800 (PST)
Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06702 for <[e-mail]>; Thu, 5 Nov 1998 04:23:40 -0800 (PST)
Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id VAA29918; Thu, 5 Nov 1998 21:13:39 +0900 (JST)
Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA24175; Thu, 5 Nov 98 21:18:48 JST
Received: from elgw.isl.melco.co.jp ([133.141.13.130]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with ESMTP id VAA02559; Thu, 5 Nov 1998 21:32:59 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id VAA26523; Thu, 5 Nov 1998 21:25:27 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.5+2.7Wbeta5/3.6W) id VAA28623; Thu, 5 Nov 1998 21:31:37 +0900 (JST)
Received: from zaku by iss.isl.melco.co.jp (1.38.193.4/3.6W) id AA02354; Thu, 5 Nov 1998 21:24:55 +0900
Message-Id: <[e-mail]>
Date: Thu, 05 Nov 1998 21:23:48 +0900
From: Jun Yoshitake <[e-mail]>
X-Mailer: Mozilla 4.05 [ja] (Win95; I)
Mime-Version: 1.0
To: [e-mail]
Cc: Stephen Kent <[e-mail]>, Phillip M Hallam-Baker <[e-mail]>, Alan Lloyd <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Subject: Re: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Lynn,

I may misunderstand you, but
I am wondering why a real-time attribute
(which causes the privacy issues, etc.)
has to be included in a certificate.

I think the following method would be better:

  A certificate shows the static binding
  between the subject and the public key.

  A real-time attribute is accessed inside the
  application server after the successful
  validation of the certificate. ("OK, this
  transaction has surely come from this
  entity, then we access the real-time
  attribute of the entity.")

Jun Yoshitake

Mitsubishi Electric Corp.


[e-mail] wrote:

> an issue was binding of real-time attributes ... needing real-time access
> to the account record .... or in a CA model the real-time invalidation &
> real-time re-issue of a certificate anytime any of the real-time attributes
> changed (i.e. like everytime you bank account balance changed ... which
> possibly opens up the privacy issue of all this attribute information
> flying around the world).
>
> if the attributes have to be accessed to complete the transaction ... then
> the account record can be used in lieu of certificate to create a binding
> between a public key and the attributes in question. If the transaction has
> to touch the account record where the binding between the real-time
> attributes and public key is located .... then a certificate with (possibly
> stale) duplicate binding is superfulous to include in such a transaction.
>
> fundamentailly there are business requirements for authentication bindings
> .... (passwords, shared secrets, public key, etc). this has been implemeted
> and deployed for a very long time in the account-based world. one could
> characterize certificates as having been created to extend a similar
> capability into an offline environment. trying to propogate the offline
> (relatively static/stale) certificate solution back into an online
> environment where there exists a much richer capability for real-time
> attribute authentication bindings would be at least superfulous .... and at
> worst creating unecessary risks & liability.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06617 for ietf-pkix-bks; Thu, 5 Nov 1998 04:05:52 -0800 (PST)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06613 for <[e-mail]>; Thu, 5 Nov 1998 04:05:50 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 4188"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-27 #29038) with ESMTP id <[e-mail]> for [e-mail]; Thu, 5 Nov 1998 07:08:12 EDT
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <V93G9XRX>; Thu, 05 Nov 1998 07:05:17 -0500
Content-return: allowed
Date: Thu, 05 Nov 1998 07:07:24 -0500
From: "Larowe, Rick" <[e-mail]>
Subject: RE: Scale (and the SRV record)
To: "Kent, Steve-GTEI" <[e-mail]>, Alan Lloyd <[e-mail]>
Cc: "'Paul Koning'" <[e-mail]>, Alan Lloyd <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Anyway, didn't thin clients become less of a goal with the 
> demise of netPCs
> :-)?  All of the software on my desktop and laptop machines is getting
> bigger each year, not smaller.

But let's not forget about PDAs, smart phones, pagers, and even 
watches.  They'll be the next targets. 

-rick
-----------------------------------------------------------------
Rick LaRowe
GTE Internetworking  -  CyberTrust Solutions, Inc.            
77 "A" Street,  Needham, MA   02194-2892  
781-455-5970 (voice)  781-455-3105 (fax)
[e-mail]
 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02948 for ietf-pkix-bks; Wed, 4 Nov 1998 22:34:25 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02944 for <[e-mail]>; Wed, 4 Nov 1998 22:34:24 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA09770; Thu, 5 Nov 1998 01:37:12 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27919; Thu, 5 Nov 1998 01:37:10 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.0029A237 ; Thu, 5 Nov 1998 01:33:12 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:36:00 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

for the most part routers now use PPP on point-to-point links (i.e. point
to point protocol)  .... typically having modems ... these modem links can
vary from the 14.4 modem banks at a ISP ... to a T3 WAN connection into the
backbone (if you configure you companies router connection into an ISP ...
you could be asked to specify various sorts of PPP parameters for the WAN
connection).

I first used radius on the livingston portmaster with a bank of 14.4 modems
... and it was typically deployed with radius server code running on a unix
login machine .... where the unix machine was configured with
userids/passwords for everything that was allowed to access the portmaster.
The radius server code originally did a unix password operation for the
indicated userid ... to verify a valid portmaster connection.

If you want to see more on radius .... see:

               http://www.garlic.com/~lynn/rfcietf.html

(or pick up the pointer from the RFC editor's page), then click on frames
version, then click on "Term". The Term abbreviations will include Radius
which you can click on ... which will give you list of all the RFC
concerning Radius

from 2058 ....

Managing dispersed serial line and modem pools for large numbers of
   users can create the need for significant administrative support.
   Since modem pools are by definition a link to the outside world, they
   require careful attention to security, authorization and accounting.
   This can be best achieved by managing a single "database" of users,
   which allows for authentication (verifying user name and password) as
   well as configuration information detailing the type of service to
   deliver to the user (for example, SLIP, PPP, telnet, rlogin).

   Key features of RADIUS are:


Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers..




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02838 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:08 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02828 for <[e-mail]>; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08862; Thu, 5 Nov 1998 01:17:50 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27779; Thu, 5 Nov 1998 01:17:48 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BB8 ; Thu, 5 Nov 1998 01:13:46 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 21:38:00 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

if the public key is already bound to attributes in an account record then
the certificate represents duplicate function from what is in the account
record (i.e. since the attributes and the public key would already be in
the account record .... then having to send in the certificate at all is
superfulous ... as well as validating if the certificate is still good,
validating the CA-signing key on the certificate, validating the CA
certificate, validating if the CA certificate is still good, validating the
CA-CA-signing key on the CA-certificate, ... on up to the root
certificate).

For authentication, there needs to be owners digital signature on at least
the account-number and time-stamp or sequence number  (i.e. the owner has
to sign something to show that it possesses the corresponding private key
and that it isn't a replay). Also sending the certificate is superfulous if
the account record has to be accessed (also containing the public key).

Including the certificate can have additional downside (in addition to
being superfolous):
    1) unecessary increased bandwidth
    2) increased systemic risk because of uncessary dependency on
CA-infrastructure
    3) possible attacks based on attributes duplicated in the certificate
that have real-time characteristics and become stale. .... and trying to
precipitate authorization decisions based on the stale data.

Furthermore attributes/information in the




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02837 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:07 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02830 for <[e-mail]>; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08850; Thu, 5 Nov 1998 01:17:46 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27770; Thu, 5 Nov 1998 01:17:44 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BCF ; Thu, 5 Nov 1998 01:13:47 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:02:24 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

I've seen clients fail SSL connection because the supplied server
certificate wasn't manufactored by a CA in the included browswer list.

I've yet to see a client fail an SSL connection because it was the first
time it had ever encountered a particular server certificate ... had
absolutely no record of the particular server certificate or prior
knowledge of the particular server (the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list).

URL is better than nothing ... but it just says that the URL and the
certificate is the same. Most instances of https invokation is a button on
a web-page. It is possible to make sure that the button does in fact invoke
a URL that matches the certificate ... and it still be an exploit.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02829 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:06 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02821 for <[e-mail]>; Wed, 4 Nov 1998 22:15:04 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08867; Thu, 5 Nov 1998 01:17:52 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27783; Thu, 5 Nov 1998 01:17:51 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BF0 ; Thu, 5 Nov 1998 01:13:53 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "Al Arsenault" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 22:16:33 -0800
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

an issue was binding of real-time attributes ... needing real-time access
to the account record .... or in a CA model the real-time invalidation &
real-time re-issue of a certificate anytime any of the real-time attributes
changed (i.e. like everytime you bank account balance changed ... which
possibly opens up the privacy issue of all this attribute information
flying around the world).

if the attributes have to be accessed to complete the transaction ... then
the account record can be used in lieu of certificate to create a binding
between a public key and the attributes in question. If the transaction has
to touch the account record where the binding between the real-time
attributes and public key is located .... then a certificate with (possibly
stale) duplicate binding is superfulous to include in such a transaction.

fundamentailly there are business requirements for authentication bindings
.... (passwords, shared secrets, public key, etc). this has been implemeted
and deployed for a very long time in the account-based world. one could
characterize certificates as having been created to extend a similar
capability into an offline environment. trying to propogate the offline
(relatively static/stale) certificate solution back into an online
environment where there exists a much richer capability for real-time
attribute authentication bindings would be at least superfulous .... and at
worst creating unecessary risks & liability.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02822 for ietf-pkix-bks; Wed, 4 Nov 1998 22:15:05 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02816 for <[e-mail]>; Wed, 4 Nov 1998 22:15:04 -0800 (PST)
From: [e-mail]
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA08858; Thu, 5 Nov 1998 01:17:48 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA27776; Thu, 5 Nov 1998 01:17:47 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1  (569.2 2-6-1998))  id 852566B3.00299BC6 ; Thu, 5 Nov 1998 01:13:47 -0500
X-Lotus-FromDomain: FDC
To: Stephen Kent <[e-mail]>
cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 21:42:55 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

you must live on another part of the internet than i do.

I've seen clients fail SSL connection because the supplied server
certificate wasn't manufactored by a CA in the included browswer list.

I've yet to see a client fail an SSL connection because it was the first
time it had ever encountered a particular server certificate ... had
absolutely no record of the particular server certificate or prior
knowledge of the particular server (the only characteristic for succesful
SSL seems to be that the server's certificate was manufactored by CA known
in the browser list).





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02622 for ietf-pkix-bks; Wed, 4 Nov 1998 21:40:45 -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 VAA02617 for <[e-mail]>; Wed, 4 Nov 1998 21:40:41 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSLX>; Thu, 5 Nov 1998 16:38:08 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4F0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'Paul Koning'" <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 16:38:07 +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

Thanks Steve Comments in line.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 9:29
> To:	Alan Lloyd
> Cc:	'Paul Koning'; Alan Lloyd; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
> Alan,
> 
> >The real issue is that some protocols (not simple or lightweight
> ones)
> >provide system selection features (chaining/replication selection
> >control) and the use of these assist with system operation and
> >information integrity ie. improve reliability and trust.
> >regards alan
> 
> Neither trust nor robustness is necessarily improved by introducing
> more
> players into the cert validaton process.  Replicated copies of CRLs in
> a
> variety of repositories are more robust than a single copy in one
> database,
> all else being equal. 
	[Alan Lloyd]  The issue raised is of inconsistency in
master/replica CRLs and not being able to select the master with LDAP.
ie. the master may have a new CRL, the replica has not seen any of this
yet.

>   However, relying on a network of directories to
> perform operations on which the security of a communication  depends,
> may
> easily be less robust and less secure.  I am especially concerned
> about the
> notion of a thin client relying on servers to validate certs.
	[Alan Lloyd]  Concern is good. But some customers want them. At
the opposite end is the worst evil. 10 or so complex validation path
processes all tied to different CA or service vendors.

> Anyway, didn't thin clients become less of a goal with the demise of
> netPCs
> :-)?  All of the software on my desktop and laptop machines is getting
> bigger each year, not smaller.
	[Alan Lloyd]  Yes - but its the dependency issue. We dont want
CA company X to change a few validation path conditions or add a cros
cert and all the clients to be updated - do we?
	regards alan
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02598 for ietf-pkix-bks; Wed, 4 Nov 1998 21:35:21 -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 VAA02594 for <[e-mail]>; Wed, 4 Nov 1998 21:35:18 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSLV>; Thu, 5 Nov 1998 16:32:48 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4EF@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Alan Lloyd <[e-mail]>
Cc: "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 16:32:46 +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

But where to these local caches and hard copy books come from. How do
they get into order. What is the registration or allocation process.

AND

If there was an online directory service would they use that instead.

If directory technology has been designed to be distributed and scale
and solves lots of people keeping lots of outdated copies - why not use
it?

People work with the tools to hand. New tools should solve todays
problems. And when we use them people will work differently.

regards alan


> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 9:24
> To:	Alan Lloyd
> Cc:	'Phillip M Hallam-Baker'; Russ Housley; [e-mail]
> Subject:	RE: Scale (and the SRV record)
> 
> Alan,
> 
> >I think of CAs as functions and certs that are applied to real life
> >entities which are represented as attributes of objects in a business
> >level directory system.
> >
> >Bashing DNS records into certs and CA operations and validation paths
> >just complicates life with a higher operational costs and does not
> use
> >the utility of distributed information infrastructures. Its like
> >configuring every phone with every one elses phone number. When in
> fact
> >we use the distributed telephone network and its directory system to
> >avoid that.
> >
> 
> In the US few people I know regularly use directory assistance; they
> most
> often use local caches (address books) and hard copy phone
> directories.
> So, this analogy seems a bit questionable.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02558 for ietf-pkix-bks; Wed, 4 Nov 1998 21:29:29 -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 VAA02550 for <[e-mail]>; Wed, 4 Nov 1998 21:29:22 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSL4>; Thu, 5 Nov 1998 16:26:52 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4EE@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: Phillip M Hallam-Baker <[e-mail]>, Al Arsenault <[e-mail]>, [e-mail]
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 5 Nov 1998 16:26: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

Steve I think the response missed the issue. The issue Lynn describes is
one of optimising information management and keeping all things
pertinent to a User in one place (inc its certs) and that over a
distributed business, different users will be stored in different
places. Its not a question of "real time" because directories can be
real time, thats sizing. Its not a question of caching, because the data
has to come from somewhere in the first place. 
 The common approach to User and user authentication is a single record
- in a distributed "data store" - a directory system  and that a CA
directory is part of the directory cloud and that User entries have User
certs in for authentication.
 IMHO Its the information management and administration optimisation
that drive the directory requirements for the larger organisations.

regards alan

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Thursday, 5 November 1998 10:21
> To:	[e-mail]
> Cc:	Phillip M Hallam-Baker; Alan Lloyd; Al Arsenault;
> [e-mail]
> Subject:	RE: A different architecture? (was Re: certificate path
> services 	[ was RE: NEW Data type for certificate selection ? ])
> 
> Lynn,
> 
> >there are business operations with account-based systems with
> >100million
> >entries and raw
> >data in tens of terabytes. for business process that have to access
> the
> >account record to complete the transaction, splitting responsibility
> for
> >the transaction between an account infrastructure and a PKI
> infrastructure
> >... doesn't improve availability ... it actually lowers it since now
> there
> >has to be two things that are operational for transaction completion
> i.e.
> >availability to complete is the product of the availability of the
> two
> >infrastructures; for availability to improve, transaction would have
> to be
> >able to complete even if the whole PKI infrastructure or the whole
> account
> >infrastructure was not operational (and since the original premise
> was that
> >at least the account infrastructure has to be operational for the
> >transaction to complete; adding a PKI infrastructure can't improve
> the
> >availibitliy)
> 
> I agree with the overall observation, but note that for many of these
> sorts
> of applications, realtime exchange of certs and CRLs, and/or caching,
> may
> obviate the need for realtime directory access and thus remove the
> availability concern you cite here.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02409 for ietf-pkix-bks; Wed, 4 Nov 1998 21:10:48 -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 VAA02405 for <[e-mail]>; Wed, 4 Nov 1998 21:10:47 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00785; Thu, 5 Nov 1998 00:13:17 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170bb26681ed9aba@[128.89.31.126]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Nov 1998 17:15:06 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Russ Housley'" <[e-mail]>, "Alan Lloyd" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rich,

>>Denial of service is allways an issue; it is a concern in
>>all of the possible repository alternatives.
>
>At the risk of stating the obvious, a denial of service that
>prevents you from getting revocation information (such as a
>CRL) can be Very Bad, given the implementation quality of most
>network services that I've seen...

True, but note that in many applications one can exchange CRLs; it is not
always necessary to retrieve them from ANY repository.  In that case, the
worst that happens is that one's peers sends a CRL that should be currently
valid, but for which an unscheduled successor has been issued.  In many
applications, and with frequent CRL (e.g., daily) issuance, this is a
reasonable risk to accept.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02400 for ietf-pkix-bks; Wed, 4 Nov 1998 21:10:38 -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 VAA02396 for <[e-mail]>; Wed, 4 Nov 1998 21:10:36 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00794; Thu, 5 Nov 1998 00:13:20 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011721b266b0faff4f@[128.89.31.126]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Nov 1998 20:40:48 -0500
To: "Simonetti David" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: keyIdentifiers
Cc: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Sorry I didn't jump in earlier, but I've been out of town and out of touch
for a while.

Key identifiers were motivated as a hueristic to solve the problem of which
of several certs (presumably with different keys) belonging to a CA should
be used to validate a cert that was signed by that CA.  This means that the
IDs need only be unique relative to the CA in question, since the scope of
the "search" was just the set of certs associated with that CA. Note that
CA name and serial number also are an acceptable alternative for this
purpose.

Some have suggested using these IDs are a "key" for database searches for
cert chain construction, etc., but this is not within the scope of the
extension, and thus I would advise against design decisions based on
presumed global uniqueness, even though the odds are in your favor for many
values of "global" ;-).  S/MIME does rely on the likely global uniqueness
of this value, if I recall correctly, using it as a tag for per-recipient
tokens.  This is a carryover from the MSP design, where we had a key
material ID that was guaranteed to be unique and which could be used for
this purpose.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02386 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09:44 -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 VAA02381 for <[e-mail]>; Wed, 4 Nov 1998 21:09:43 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00717; Thu, 5 Nov 1998 00:12:02 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011727b266d062c373@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 22:55:00 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: Al Arsenault <[e-mail]>, Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>while the current common certificate infrastructure model is SSL ... which
>baiscally checks if the certificate has been manufactored by somebody in
>the list of known certificate manufactors/issuers (aka CAs) .... the common
>authentication model on the internet is logging on to the service provider.

Well, that depends.  For most corporate Internet users, this model is not
at all common.  For redidential subscribers, it is.

>This one is basically somebody signs up for an account and establishes a
>password. When they want to use the internet ... they contact the router,
>give their account name and proof of password. The router is likely running
>something like radius ... in which case it forwards the account name and
>password to an account authenticator.

You contact something like a PPP server, not a router per se.  The RADIUS
server is likely running elsewhere; after all, it's a server.

>For PKIX to address the most fundamental of internet authentication
>requirements ... could involve the ISP issuing a relying party certificate
>with just the account name (sidestepping liability and privacy issues). The
>choice now would be would the ISP router accept the certificate
>authentication at face-value ... or would it use a PKI flavor of radius to
>contact an account authenticator .... for instance to have more timely
>information on whether the account is in good standing.

Because not all subscribers necessarily have the same privileges, mere
verification of the cert provides authentication, but not authorization. So
it would be quite reasonable for the ISP to check a database to see such
things as where the user is allowed to connect, what QoS features he may
elect, etc.  That check against an access control database is a fine time
to check for revocation, precisely because the ISP is both the CA and the
consumer of the cert.

>This is possibly the most fundamental current internet requirement ... and
>it illustrates again the extremely short step from relying party
>certificates to the AADS model ... where if the account has to be touched
>as part of the authentication/authoritization ... then it is easily shown
>that shipping the certificate with the transaction is superfulous (if
>somebody gives you a copy of something .... how many million times do you
>have to send the same copy back to them ... before they realize that they
>don't have to see the copy if they are already looking at the original
>stored in the account record).

Note that my example still differentiates between authentication and
authorization.  Sending in the user's cert is just a convenient way to
package the public key and the ID it represents.  Nothing wrong with that.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02377 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09: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 VAA02373 for <[e-mail]>; Wed, 4 Nov 1998 21:09:34 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00735; Thu, 5 Nov 1998 00:12:18 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011709b2667633b778@[128.89.31.126]>
In-Reply-To: <000401be0291$3c8dec00$[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
Date: Wed, 4 Nov 1998 17:17:52 -0500
To: "Phillip M Hallam-Baker" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Phill,

Although I'm very late getting into this particular debate due to being
away on travel (mostly not Internet connected) for almost 2 weeks, I concur
with several of the themes of your observations, although I might prefer
storing certs and CRLs in the DNS per se, rather than using DNS records as
pointers to othyer repositories.

The DNS is the only robust, distributed directory system the Internet has.
That makes it attractive for two things: storing data, such as certs and
CRLs, and for its naming tree.  Note that anytime we use a name in a cert
that is not exactly the same as the name we use in an application, we are
required to perform a mapping between two name spaces, and that introduces
another database which imposes significant additional management overhead
and another place to make errors with adverse security implications.  So,
for example, for IPsec, i really want certs with DNS names and IP
addresses, since these are the native name forms that the applications
employ and upon which access control decisions are made.  For SSL, browsers
check a DNS name in a certificate against the corresponding portion of the
URL, and ignore the rest of the DN in the subject field.  For e-mail the
case may not be so strong, since people may mentally map identifies
irrespective of e-mail addresses, but even there I worry that cognitive
overload can eaisly set in and cause people to make perception mistakes.
(If one has an S/MIME system that automatically checks for the
correspondence between the "from" address and the sender's DN from his
cert, instead of presenting the subject DN from the certificate, then the
above arguments apply.) So, here too, I really prefer certs with e-mail
addresses, which is a change from a stance I adopted years ago when I wrote
RFC 1422.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02365 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09:24 -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 VAA02361 for <[e-mail]>; Wed, 4 Nov 1998 21:09:23 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00712; Thu, 5 Nov 1998 00:11:57 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011712b26691a19938@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:21:11 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture? (was Re: certificate path services  [ was RE: NEW Data type for certificate selection ? ])
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, "Al Arsenault" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>there are business operations with account-based systems with >100million
>entries and raw
>data in tens of terabytes. for business process that have to access the
>account record to complete the transaction, splitting responsibility for
>the transaction between an account infrastructure and a PKI infrastructure
>... doesn't improve availability ... it actually lowers it since now there
>has to be two things that are operational for transaction completion  i.e.
>availability to complete is the product of the availability of the two
>infrastructures; for availability to improve, transaction would have to be
>able to complete even if the whole PKI infrastructure or the whole account
>infrastructure was not operational (and since the original premise was that
>at least the account infrastructure has to be operational for the
>transaction to complete; adding a PKI infrastructure can't improve the
>availibitliy)

I agree with the overall observation, but note that for many of these sorts
of applications, realtime exchange of certs and CRLs, and/or caching, may
obviate the need for realtime directory access and thus remove the
availability concern you cite here.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02359 for ietf-pkix-bks; Wed, 4 Nov 1998 21:09: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 VAA02355 for <[e-mail]>; Wed, 4 Nov 1998 21:09:16 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00705; Thu, 5 Nov 1998 00:11:49 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170ab26681276c13@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 17:12:31 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Scale (and the SRV record)
Cc: "Phillip M Hallam-Baker" <[e-mail]>, "Alan Lloyd" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Lynn,

>spent a lot of time on the SSL portion of the web ... 94/95 working out how
>to do/deploy electronic commerce operations. Current SSL infrastructure
>uses server certificate for key exchange ... not for authentication. To the
>extent that there is authentication done ... it consists of checking the
>certificate issuer against a list that has typically pre-installed in the
>browser (not checking on the certificate owner). It is one of the reasons
>that I coined the term certificate manufactoring .... to highlight
>manufactoring and distributing certificates is typically only a small part
>of what has become to be considered part of a PKI infrastructure.

I disagree wuth this last observation.  As I mentioned in a recent posting,
browsers do check for a match between the server URL and it's cert, which
is precisely an authentication function.

>I got possibly the first mutual authentication SSL deployed ... before it
>was called SSL3. Again authentication was limited to verifying the
>certificate issuer. The server certificate was essentially a comfort device
>for all the clients ... the client certificates started out essentially
>being "relying party" certificates .... but to do more than simple
>certificate issuer authenitcation ... i had to check the certificate owner
>information against an account database. At that point it became evident
>that even relying party certificates were superfulous in the transaction
>since I needed to reference the account record (which already had copy of
>the public key, lots of attribute binding ... as well as up-to-date
>real-time status).

If you chosen the IDs in the client certs to match the account record keys,
the authentication capability of client certs would have been useful.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02350 for ietf-pkix-bks; Wed, 4 Nov 1998 21:08:12 -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 VAA02346 for <[e-mail]>; Wed, 4 Nov 1998 21:08:11 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00579; Thu, 5 Nov 1998 00:10:40 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011711b26691297cfe@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:19:34 -0500
To: Elliott Ginsburg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fwd: Re: A different architecture
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Elliott,

>I'm adding to my own message. Someone also stated on the list that we do
>not want to have a directory between our apps and our PKI services. But,
>again, how often today do we have DNS between our apps and our network
>communication services?

We already need the DNS to make the existing Internet protocols work. In
many apps, we don't need a directory to support certs/CRLs, so the
introduction of an additional directory system for that purpose introduces
new failure modes.

steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02325 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02319 for <[e-mail]>; Wed, 4 Nov 1998 21:07:52 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00567; Thu, 5 Nov 1998 00:10:36 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011710b26691047432@[128.89.31.126]>
In-Reply-To: <[e-mail]>
Date: Wed, 4 Nov 1998 18:17:39 -0500
To: Elliott Ginsburg <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Elliott,

>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?

DNS is very simple compared to an X.500 or LDAP directory system, and thus
people do question whether thye Internet will succeed in building a
parallel directory structure of this latter sort.  That doesn't mean it
won't happen, but it is by no means certain.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02329 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02324 for <[e-mail]>; Wed, 4 Nov 1998 21:07:53 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00539; Thu, 5 Nov 1998 00:10:10 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011719b266a5d4610c@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC083114@DSG1>
Date: Wed, 4 Nov 1998 23:02:52 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: A different architecture?  (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'Al Arsenault '" <[e-mail]>, "''[e-mail] ' '" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alan,

>snip
>One of the biggest features of a well designed PKI is that it embodies a
>distributed security model that scales through simple replication of
>static
>data, a problem we know how to solve.
>
>
>Alan: However a major weakness in any system occurs when one replicates
>data - particularly when that data forms a linkages to a point of trust
>- and in the path there are other objects that may or may not exist (eg
>CRLs) that could be placed in these paths in non uniform ways...
>EG LDAP -  one of the major deficiencies cannot ask for master data from
>a CA directory ie. If a CRL has been placed in the master but not yet
>propagated to replicas, then a client could consider the cert being
>validated - valid if it (without its knowlege - accesses the replica).

I'm not an LDAP fan and I keep observing that one does not always require
directory systems to support a PKI.

>(ie. why talk of trust and how one achieves trust in a distributed and
>replicated information system and then use a protocol that has so many
>untrusted deficiencies???? eg. LDAP.

See comments re LDAP above.
>
> It also has the property that to
>spoof the identity of an end entity, one ought to have to subvert the CA
>that issued the cert to that entity, although sloppy cross certification
>and bad choices for PKI structure can make this situation worse.
>
>Alan: Bad PKI designs come from weaknesses and complexities in the CA
>and the related client information model and service interaction
>software - as one adds complexity the components that work with an ill
>defined and variable information model, then all things get into a mess.
>EG LDAP - no system service model, add and extension here there and
>everywhere. Outcome - LDAP is not universal anymore - an operational
>mess.

Aw, come on now.  Stop using LDAP as a strawman to make more complex
directory systems seem like the only (preferred?) answer. Complex cert
models are bad, I agree, but they are bad whether one has to deal with them
in fat clients or in fat, fancy validation servers.

>Limited scale systems, complex clients and weak/variable CA information
>models is what we have. Its better to have consistency in service and
>place trust in the implementation of that service. There is no point in
>discussing trust in theoretical Objects and certificates and the
>processes that might happen in someones CA or "cert server".

We have poor examples of PKIs now, but I reject the view that we cannot
make them better, or that we have to fundamentally change the model
underlying X.509 to address these problems.

>
>The notion of cert validation servers is thus very disturbing.
>
>Alan:
>If a client goes to a CAs directory to get a cert in the path and the
>directory provides the wrong one and therefore user to user transaction
>is invalidated - then denial of service happens.
>Something - somewhere in the system has to be trusted. And in my book
>its the implementation that is trusted not theoretical models.

If a directory provides the wrong cert in response to a READ, this is
immediately apparent to the client and thus the bug/attack can be detected.
Implementations must be correct to make things work, but good
implementations of an insecure model are not necessarily better than
mediocre implementations of a secure model.

>eg. I can build a highy trusted directory system that does cert
>matching, has bullet proof access controls, has trusted processes that
>generate valid flags from processing CRLs...for the client.

Maybe, but I am not convinced.  We may have good client implementatins and
bad ones.  Even bad ones may have to be attacked individually to subvert
the security for a lot of users, whereas a successful attack against a good
server that many users rely upon would be much more devastating, and that
makes it more worthwhile to attack it.

>OR I could  write sloppy, bug ridden, fragile process that serves no
>purpose in terms of trust.

You could write it, but I may not choose to buy it. :-)  Be careful here;
if you push too far one might ask whether it's worthwhile having a high
quality cert validation process at all (distributed or centralized) if all
of the clients are running a vulnerable OS anyway!

>OR I could promote a protocol to a server without any distributed,
>directory relevant CA information model and say that solves the problem.
>
What protocol?  OCSP?  We're still working on the scope of the model, but
if the OCSP responder is the CA for the cert in question, we have a fine,
simple, model.

>In the above the following observations MUST be made.
>Using good directory technology, with sound information services to
>support CA functions provide scaleability and measureable trust models.

"measurable trust models?"  What metrics do we use?

>Using bad anything .. provides no trust
>
>Having a protocol to a server without any notion of the CA function and
>the directory support that CAs need or any notion of scaling or how it
>deals with multiple CA domains or the complexity of the client,  only
>generates problems.
>
>IE.
>IMHO Talking of trust in the CA/X.509/directory environment without any
>reference to implemtation and system design qualitative characteristics
>becomes an endless debate - without resolution.

Well, we can terminate this debate now, to avoid falling into that trap.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02317 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02313 for <[e-mail]>; Wed, 4 Nov 1998 21:07:26 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00505; Thu, 5 Nov 1998 00:09:56 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170db26684b00897@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BE@DSG1>
Date: Wed, 4 Nov 1998 17:29:21 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Paul Koning'" <[e-mail]>, Alan Lloyd 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>The real issue is that some protocols (not simple or lightweight ones)
>provide system selection features (chaining/replication selection
>control) and the use of these assist with system operation and
>information integrity ie. improve reliability and trust.
>regards alan

Neither trust nor robustness is necessarily improved by introducing more
players into the cert validaton process.  Replicated copies of CRLs in a
variety of repositories are more robust than a single copy in one database,
all else being equal.  However, relying on a network of directories to
perform operations on which the security of a communication  depends, may
easily be less robust and less secure.  I am especially concerned about the
notion of a thin client relying on servers to validate certs.

Anyway, didn't thin clients become less of a goal with the demise of netPCs
:-)?  All of the software on my desktop and laptop machines is getting
bigger each year, not smaller.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02311 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07: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 VAA02307 for <[e-mail]>; Wed, 4 Nov 1998 21:07:18 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00490; Thu, 5 Nov 1998 00:09:49 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170cb26682c7cdfa@[128.89.31.126]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
Date: Wed, 4 Nov 1998 17:24:08 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Scale (and the SRV record)
Cc: "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley 	 <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Alan,

>I think of CAs as functions and certs that are applied to real life
>entities which are represented as attributes of objects in a business
>level directory system.
>
>Bashing DNS records into certs and CA operations and validation paths
>just complicates life with a higher operational costs and does not use
>the utility of distributed information infrastructures. Its like
>configuring every phone with every one elses phone number. When in fact
>we use the distributed telephone network and its directory system to
>avoid that.
>

In the US few people I know regularly use directory assistance; they most
often use local caches (address books) and hard copy phone directories.
So, this analogy seems a bit questionable.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02305 for ietf-pkix-bks; Wed, 4 Nov 1998 21:07:09 -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 VAA02301 for <[e-mail]>; Wed, 4 Nov 1998 21:07:08 -0800 (PST)
Received: from [128.33.238.37] (TC037.BBN.COM [128.33.238.37]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id AAA00474; Thu, 5 Nov 1998 00:09:34 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v0401170eb2668eb0e84e@[128.89.31.126]>
In-Reply-To: <[e-mail]>
References: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Date: Wed, 4 Nov 1998 18:14:08 -0500
To: Al Arsenault <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk

Al,

>This is one of the areas where the SPKI folk make sense.  There is not, and
>will not ever be, a single, unified, global directory where everything has
>a name that fits into the schema.  There are instead "directories" of
>information that apply to a specific "domain".  In PKIX's case, it's the
>information that applies to the Internet.  The namespace covers those
>things that are important in the Internet context, and nothing else.  To
>me, that's (right now), IP addresses, domain names, port numbers, service
>names, user names/mailbox names, and maybe one or two other things. If the
>Internet expands to cover toll plazas, then a naming space will have to be
>developed for them, and after it's defined and standardized we can figure
>out how to put the proper names in certificates.

The notion of no single, unique, name that is appropriate for every context
is not unqiue to SPKI;  I've been preaching this notion for at least 3
years and gave talks on this at a DIMACS workshop in 1996 and at the RSA
conference in 1997, before publishing a paper on the topic in MILCOM 97.
The SDSI model says that the names in certs are not useful except very
locally, and hence emphasizes the idea of the key as an ID.  What we are
talkin g about does not share that notion.  DNS names, 822 addresses, IP
addresses, URLs, etc. have widespread semantics, even though they are not
universal.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13576 for ietf-pkix-bks; Wed, 4 Nov 1998 12:18:27 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13571 for <[e-mail]>; Wed, 4 Nov 1998 12:18:25 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA16B4; Wed, 4 Nov 1998 15:21:01 -0500
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 15:21:18 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]> <[e-mail]> <[e-mail]>
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 MAA13572
Sender: [e-mail]
Precedence: bulk

X.509 states, for Subject Key Identifier, "A key identifier shall be
unique with respect to all key identifiers for the subject with which it
is used."  

For Authority Key Identifier, it states, "A key identifier shall be
unique with respect to all key identifiers for the issuing authority for
the certificate or CRL containing the extension."

This sounds to me like the key identifier need only be unique to the
subject or issuer, respectively.  Seems like 60 bits would be
sufficiently effective.

Dave S.

Ambarish Malpani wrote:
> 
> I don't think the key identifier was meant to be universally unique
> (although I would like it to be so).
> 
> The use of key idenfiers, AFAIK, is as follows:
> 
> A CA includes a subject key identifier in its cert. It includes that
> subject key identifier as authority key identifier in all certs that
> it issues. This allows an application to find the CA cert - useful
> where an application may have more than one CA cert with the same
> name - for example, when the CA is going through key rollover.
> 
> Hope this helps (and is correct),
> 
> Ambarish

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14450 for ietf-pkix-bks; Wed, 4 Nov 1998 14:20:34 -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 OAA14446 for <[e-mail]>; Wed, 4 Nov 1998 14:20:32 -0800 (PST)
Received: from stefans (t3o68p90.telia.com [62.20.139.90]) by maila.telia.com (8.8.8/8.8.8) with SMTP id XAA25164; Wed, 4 Nov 1998 23:22:54 +0100 (CET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 04 Nov 1998 23:19:04 +0100
To: "Tammy Carter" <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 OAA14447
Sender: [e-mail]
Precedence: bulk

I would suggest that all cases #1, #2 and #3 could be valid and should be
considered good practice as long as the certified information is correct.

All certificates are individual statements with individual liabilities. 

We have also identified several scenarios where the same public key can be
associated with different subject names as long as they are associated with
the same subject. The only "wrong" case I can see is if the same public key
is certified to separate individuals in different certificates.

It will be the relying party who in the end will decide if a particular
certificate is suitable for the present case, taking all factors in
consideration. In this decision the relying party shall not have to be
aware of any other related certificate for the same subject or key.

In cases of name change it would also be OK to re-issue the same
certificate with the new name as long as the old certificate is revoked (if
the old name is invalid).

For those interested in liabilities and the legal jungle associated with
digital signatures, I would highly recommend to take a look at INCITRALs;
"Planning of future work on electronic commerce: digital signatures,
certification authorities and related legal issues", found at:
http://www.un.or.at/uncitral/en-index.htm

/Stefan

At 12:28 PM 11/4/98 -0700, Tammy Carter wrote:
>Bill, 
>
>I hope that you are right that your case #3 is the prevalent case.  However,
>my question is more along the lines of what a CA should do in cases #1 and
#2.
>And, should client software be built to support case #2?
>
>
>>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
>See comments below.
>
>> -----Original Message-----
>> From:	Tammy Carter [SMTP:[e-mail]] 
>> Sent:	Tuesday, November 03, 1998 6:24 PM
>> To:	[e-mail] 
>> Subject:	Is certificate renewal a good idea?
>> 
>> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
>> others have mentioned 
>> certificate renewal.  I had found this topic conspicuously absent from any
>> of the PKIX drafts and 
>> had assumed that renewing certificates was considered bad practice.  Can
>> someone enlighten 
>> me?
>> 
>> It seems as though there are two cases to consider:
>> 1)  Same CA, same public key, different subject name
>> 2)  Same CA, same public key, same subject name, 
>>       different information in the certificate (e.g., alternative names,
>> validity period, CP/CPS)
>> 
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
>	[snip]
>
>> Comments?
>> 
>	Above.
>
>> Tammy Green Carter
>> [e-mail] 
>> 
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
>Defense Information Systems Agency      Fax:           [phone] 
>Information Assurance Office (JED)      DSN:                      761      
>5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
>Falls Church, VA 22041-2717        Internet:  <[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 PAA00456 for ietf-pkix-bks; Wed, 4 Nov 1998 15:21:43 -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 PAA00452 for <[e-mail]>; Wed, 4 Nov 1998 15:21:39 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSJR>; Thu, 5 Nov 1998 10:19:06 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4E0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'David Boyce'" <[e-mail]>, Al Arsenault <[e-mail]>
Cc: Alan Lloyd <[e-mail]>, "'Bill Burr'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, Russ Housley <[e-mail]>, [e-mail]
Subject: RE: A PKI for the Internet (was RE: Scale (and the SRV record))
Date: Thu, 5 Nov 1998 10:19:05 +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

Thanks David - Access Controls without Authentication are not  much use
are they. Perhaps when one looks at PKI and realises that X.509 is used
for "Authentication" of Users - one then may take the next step to say
that this is coupled with ACI for getting at the business data (in the
directories), etc. Then the PKI starts to have some utility.
If the PKI is just used for signing messages, then its limited. But if
its also used for directory access/authentication - then its doing what
X.500 designed it for.

Also - Make that two implementations :-)

regards alan
> -----Original Message-----
> From:	David Boyce [SMTP:[e-mail]]
> Sent:	Saturday, 31 October 1998 2:22
> To:	Al Arsenault
> Cc:	Alan Lloyd; 'Bill Burr'; 'Phillip M Hallam-Baker'; Russ Housley;
> [e-mail]
> Subject:	Re: A PKI for the Internet (was RE: Scale (and the SRV
> record))
> 
> Al Arsenault writes:
> >>
> >>	Isnt it odd that X.509 is used for PKI and X.500 is discounted? 
> >>
> >
> >AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI 
> business.
> >X.509 is not used for its original, X.500-based purpose, which was 
> actually
> >to control access to the directory for the purpose of limiting who 
> could
> >modify entries.
> 
> I'm sorry, Al, but it is factually incorrect to say that X.509 is not
> used for its original, X.500-based purpose.  There is at least one
> commercial implementation of X.500 which supports strong
> authentication
> using X.509 certificates, and makes use of the fact for Access Control
> purposes.
> 
> I'll grant that X.509 is being used beyond its original purpose, but
> that's just a measure of its utility.
> 
> David.
> -- 
> David Boyce
> 
> Tel:	[phone]		Richmond, Surrey, ENGLAND
> Email:	[e-mail]	Isode's WWW:
> http://www.isode.com/
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00239 for ietf-pkix-bks; Wed, 4 Nov 1998 14:47:44 -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 OAA00244 for <[e-mail]>; Wed, 4 Nov 1998 14:34:05 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <WHW7GSJK>; Thu, 5 Nov 1998 09:31:17 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4DB@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Scale (and the SRV record)
Date: Thu, 5 Nov 1998 09:31:16 +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 OAA00248
Sender: [e-mail]
Precedence: bulk

Comments inline.

Perhaps the answer to most of this is to ask how PKI suppliers are
integrating their non directory solutions into organisations - without
causing yet more islands of services, information and higher operational
costs.

Or why they built X.509 without X.500. Thats a bit like using a data
structure from a database - without using the features of a database.

> -----Original Message-----
> From:	Graham Bland [SMTP:[e-mail]]
> Sent:	Friday, 30 October 1998 20:33
> To:	'Alan Lloyd'; '[e-mail]'
> Subject:	RE: Scale (and the SRV record)
> 
> 
> 
> Large portions of original message deleted for readability, relevant
> sections only maintained with comments in line. 
> Graham Bland 
> > -----Original Message----- 
> > From: Alan Lloyd [ mailto:[e-mail] ] 
> > Sent: 29 October 1998 21:37 
> > To: 'Bill Burr'; Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> 
> > [e-mail] 
> > Subject: RE: Scale (and the SRV record) 
> ...deleted 
> > > I have been saying for some time that don't know of anybody who
> has 
> > > built 
> > > an X.500 directory of a size that convinces me that it is a viable
> 
> > > technology to base a US national PKI, or even a US Federal 
> > > government-wide 
> > > PKI on. I keep asking the question, where are the really big 
> > > distributed 
> > > X.500 directories? Particularly multivendor directories.  
> > But I don't 
> > > seem 
> > > to get any answers.  What I hear are horror stories about the 
> > > difficulties 
> > > of getting any two X.500 products to work together. 
> >       [Alan Lloyd]  
> >       No horror stories from us. 20 million entries, 1000s of
> searches 
> > a second, distributed, multi master, etc We have very scaleable, 
> > distributed technology - that also integrates LDAP servers, etc We
> are 
> > very busy deploying X.500 into major corporate infrastructures who
> are 
> > following the themes I described. Including those in the US. 
> > Please read 
> > our WEB site. "Uses of Directory Services" 
> > 
> Can I access these directories or are they private islands.  If they
> are private islands then they might as well not exist.
	[Alan Lloyd]  
	Thats a narrow view. All systems today are islands in one shape
or another. Thats no reason to say that X.500 or directory systems dont
work. They are - in our books - being applied to many organisations to
consolidate their information systems, provide a direction to having a
single logon and a singlr mail box. And on this we appli PKI
functionality.

	Are you saying the above direction is not happening or you dont
agree with it.


> > >   If the X.500 directory industry builds products that
> interoperate 
> > > and scale 
> > > well, it has done a really bad job of getting the word out.  
> >       [Alan Lloyd]  
> >       My view here is that the LDAP hype has done a really good job
> of 
> > damaging X.500. However, now the LDAP hype has dissipated and
> reality 
> > has set in we are left with a protocol that can only ACCESS a 
> > directory 
> > service ? is twice as big as DAP and has half the functionality. In 
> > addition, getting LDAP only solutions is proving to many that X.500
> is 
> > the way to go because of LDAPs NO distribution and a model 
> > that demands 
> > Replicate everything to everywhere. LDAP has high operational 
> > costs and 
> > gets to a point where it is unworkable. 
> >       So LDAP accessed X.500 in my book is the way to go and is
> being 
> > deployed globally. 
> I think you meant to say DAP accessed X.500 from the flow of the text 
> > 
> > >  Until now, I have also been saying, does anybody have a
> believable 
> > > alternative to the mythological, pervasive X.500 directory
> service? 
> > > It 
> > > seemed almost a rhetorical question.  But I think perhaps Phill
> has 
> > > outlined an alternative, that looks like it probably ought to
> work, 
> > > and is 
> > > based on something, DNS, that we know works well, scales well, and
> 
> > > exists 
> > > now. Moreover, we should be able to create the service we need 
> > > incrementally, by just by adding servers as we need them, one at 
> a 
> > > time. 
> > > And, If I understand the proposal, all we have to do is 
> > agree on some 
> > > simple naming conventions. 
> >       [Alan Lloyd]  I am not against alternative proposals - its all
> a 
> > question of how much effort and implementation goes behind it.
> Phills 
> > solution has to be backed by all the DNS and PKI suppliers on this 
> > planet and DNS then has to become secure - with signed operations, 
> > mutual authentication, access controls, real life naming, and scale
> a 
> > lot better and of course be easy to manage and follow Object
> Oriented 
> > design. (does this mean turning DNS into X.500?) I would vote 
> > for that - 
> > thats more X.500! 
> Why would DNS need to be more secure with signed operations mutual
> authentication etc. Certificates and CRLs are signed objects and their
> security is inherent.   Ignoring denial of service I cannot see any
> attacks from an insecure distribution method.  The whole point of the
> distribution method is that I have no trust relationship with it and
> have no need of a trust relationship be it email, X.500 or anything
> else.
	[Alan Lloyd]  
	I did not raise DNS as being a directory service as it has about
5% of the functionality of X.500. Its just that if DNS wants to become a
directory service - then its fuctionality will end up as X.500 no doubt.

> How is it relevant if DNS follows OO design, why should it.  While I
> agree that OO design and methods have many advantages the relevant
> questions are does it work and how much will it cost, not what its
> internal structure is.
> What is the problem with the scalability of DNS (How many users does
> it support now ?) 
> X.500 is easy to manage? later you say "But LDAP did prove that
> directorys are difficult 
>  and complex and X.500 got most things right."  
	[Alan Lloyd]  Any distributed information system that supports a
major organisation for business is difficult to manage - thats obvious -
it has nothing to do with the technology in most part. Its to do with
operational dynamics, wear and tear and scaling up with usually less
resources.


	In addition we are using our X.500 to back end DNS/DHCP and
RADIUS servers  for large ISPs - now theres a trend eh.

	regards alan

> Graham Bland 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13219 for ietf-pkix-bks; Wed, 4 Nov 1998 11:45:17 -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 LAA13215 for <[e-mail]>; Wed, 4 Nov 1998 11:45:16 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA22435; Wed, 4 Nov 1998 11:45:13 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA04668; Wed, 4 Nov 1998 11:47:26 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Robert Moskowitz" <[e-mail]>, "Paul Koning" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: keyIdentifiers
Date: Wed, 4 Nov 1998 14:47:58 -0500
Message-ID: <004701be082c$066024e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> If they need truncation, at least have the
> >length be 96 or so (by the arguments applied to HMAC).
>
> This is an interesting point.  Of course, I THINK the HMAC work post-dates
> the selection of 60 bits by the ECC crowd.  They will have to speak up to
> see if this is a good approach.

The HMAC work is not relevant here. With HMAC the collision problem
is much less severe because there is no requirement for HMACs to be
unique. The requirement is simply to make the discovery of the HMAC
key by brute force to be computationally infeasible.

This means that the HMAC strength is not reduced through the
birthday attack. So the effective cipher strength of 96 bits of
HMAC output is 2^96 - which is in the same ballpark as requiring
generation of 2^80 messages before collision is likely.

2^48 is getting there but in a world with a population of 5,000
billion robots (only 1000 each) the ability to only colonize 50
more solar systems might be constraining.

As Tom Knight once said.. "32 bits is not enough, thats not even
large enough for a phone number" - guess what the venue was??

	Phill


PS, Please, don't feel obliged to remind me there are silicon
lifeforms as well as 9 list members have done this morning. I
did not want to distract from the political point that we should
look beyond the parochial needs of the 1 billion citizens of
the rich countries when designing technology.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13114 for ietf-pkix-bks; Wed, 4 Nov 1998 11:39:47 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13110 for <[e-mail]>; Wed, 4 Nov 1998 11:39:46 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA72AC; Wed, 4 Nov 1998 14:42:22 -0500
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 14:42:38 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Phillip M Hallam-Baker <[e-mail]>
CC: Kevin Kingdon <[e-mail]>, [e-mail]
Subject: Re: keyIdentifiers
References: <003501be080a$78830460$[e-mail]>
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 LAA13111
Sender: [e-mail]
Precedence: bulk

I don't disagree.  The original proposal for a unique key identifier was
for 60 bits of the hash.  PKIX has since added a proposal for use of the
full 160 bits of the SHA-1 hash.

My point is...the key identifier is intended to be unique, using
whatever method you desire to generate it.

Dave S.

Phillip M Hallam-Baker wrote:
> 
> > Kevin,
> >
> > I believe the key identifier is intended to be universally unique.  The
> > profile does not state this.  However, I recall a presentation where
> > someone was proving mathematically that taking 60 bits out of a SHA-1
> > hash of the public key would provide sufficient uniqueness.  What is
> > sufficient?  It was a very, very, very small fraction for a very, very
> > large number of certificates.  Sorry for the generalities, but I'm not a
> > mathematician.
> 
> They would be expecting to issue far fewer than 2^30 (1 billion)
> certificates.
> 
> I'm not sure that is a very good assumption. In fact its a lousy one on
> a planet with 5 billion people.
> 
> We are not so short of bits that we need to skimp on them to create unique
> key IDs.
> 
>                 Phill

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12989 for ietf-pkix-bks; Wed, 4 Nov 1998 11:26:46 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA12985 for <[e-mail]>; Wed, 4 Nov 1998 11:26:45 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Nov 1998 12:28:58 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 04 Nov 1998 12:28:39 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
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 LAA12986
Sender: [e-mail]
Precedence: bulk

Bill, 

I hope that you are right that your case #3 is the prevalent case.  However,
my question is more along the lines of what a CA should do in cases #1 and #2.
And, should client software be built to support case #2?


>>> "Flanigan, Bill" <[e-mail]> 11-4-98 6:31:04 AM >>>
See comments below.

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]] 
> Sent:	Tuesday, November 03, 1998 6:24 PM
> To:	[e-mail] 
> Subject:	Is certificate renewal a good idea?
> 
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned 
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and 
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten 
> me?
> 
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name, 
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
> 
	Actually, the most prevalent case is likely to be:
	3) Same CA, different public key, same CN

	[snip]

> Comments?
> 
	Above.

> Tammy Green Carter
> [e-mail] 
> 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12341 for ietf-pkix-bks; Wed, 4 Nov 1998 10:15:18 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12337 for <[e-mail]>; Wed, 4 Nov 1998 10:15:17 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA243; Wed, 4 Nov 1998 13:17:59 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 13:17:21 -0500
To: Paul Koning <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <003501be080a$78830460$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 01:02 PM 11/4/98 -0500, Paul Koning wrote:
>>>>>> "Robert" == Robert Moskowitz <[e-mail]> writes:
>
> >> We are not so short of bits that we need to skimp on them to
> >> create unique key IDs.
> >> 
> Robert> Some people are bandwidth conservative.  Some devices are
> Robert> indeed bandwidth limited.
>
>I think lots of mistakes in protocol design have been made in the name
>of a misguided goal of saving a few bytes.  I was just looking at one
>yesterday -- a certain well known protocol throwing off all alignment
>for the sake of saving ONE lousy byte.

I agree with your assessment.  I fought a derived IV for IPsec like PPTP
uses (and I think L2TP) to save 4 bytes per packet for 'slow links' and
potentially have IVs with low haming distance or require prior packet
delivery.  Some byte squeezing costs more than is gained.

>Anyway, if you're dealing with certs, you already have big blobs of
>bytes.  And if a few bytes is really that big a deal, isn't the right
>answer to make key IDs optional?  But if supplied they should be good, 
>and I agree with Phillip that there is no sensible reason to truncate
>them to such tiny lengths.  If they need truncation, at least have the 
>length be 96 or so (by the arguments applied to HMAC).

This is an interesting point.  Of course, I THINK the HMAC work post-dates
the selection of 60 bits by the ECC crowd.  They will have to speak up to
see if this is a good approach.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12201 for ietf-pkix-bks; Wed, 4 Nov 1998 10:01:16 -0800 (PST)
Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12195 for <[e-mail]>; Wed, 4 Nov 1998 10:01:15 -0800 (PST)
Received: from xedia.com by relay2.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfobo19001; Wed, 4 Nov 1998 13:02:49 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07715; Wed, 4 Nov 98 13:00:59 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA16108; Wed, 4 Nov 1998 13:02:47 -0500
Date: Wed, 4 Nov 1998 13:02:47 -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: keyIdentifiers
References: <[e-mail]> <003501be080a$78830460$[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk

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

 >> We are not so short of bits that we need to skimp on them to
 >> create unique key IDs.
 >> 
 Robert> Some people are bandwidth conservative.  Some devices are
 Robert> indeed bandwidth limited.

I think lots of mistakes in protocol design have been made in the name
of a misguided goal of saving a few bytes.  I was just looking at one
yesterday -- a certain well known protocol throwing off all alignment
for the sake of saving ONE lousy byte.

Anyway, if you're dealing with certs, you already have big blobs of
bytes.  And if a few bytes is really that big a deal, isn't the right
answer to make key IDs optional?  But if supplied they should be good, 
and I agree with Phillip that there is no sensible reason to truncate
them to such tiny lengths.  If they need truncation, at least have the 
length be 96 or so (by the arguments applied to HMAC).

	paul



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12066 for ietf-pkix-bks; Wed, 4 Nov 1998 09:47:07 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.5]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA12062 for <[e-mail]>; Wed, 4 Nov 1998 09:47:06 -0800 (PST)
Received: (qmail 19365 invoked from network); 4 Nov 1998 17:34:28 -0000
Received: from amazon-dmz.valicert.com (HELO atlantic.valicert.com) (209.185.6.1) by external-mail.valicert.com with SMTP; 4 Nov 1998 17:34:28 -0000
Received: (qmail 1716 invoked from network); 4 Nov 1998 17:49:47 -0000
Received: from unknown (HELO valicert.com) (10.0.0.101) by 10.0.0.4 with SMTP; 4 Nov 1998 17:49:47 -0000
Message-ID: <[e-mail]>
Date: Wed, 04 Nov 1998 09:50:16 -0800
From: Ambarish Malpani <[e-mail]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

I don't think the key identifier was meant to be universally unique
(although I would like it to be so).

The use of key idenfiers, AFAIK, is as follows:

A CA includes a subject key identifier in its cert. It includes that
subject key identifier as authority key identifier in all certs that
it issues. This allows an application to find the CA cert - useful
where an application may have more than one CA cert with the same
name - for example, when the CA is going through key rollover.

Hope this helps (and is correct),

Ambarish


Simonetti David wrote:
> 
> Kevin,
> 
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.
> 
> Dave S.
> 
> Kevin Kingdon wrote:
> >
> > One issue that does affect applications is the scope of a key identifier. Is
> > it unique for a given subject, a given CA, or globally unique? In other
> > words, can I build a certificate chain using just key identifiers, or do I
> > have to use some combination of subject + identifier or issuer + (subject)
> > identifier to build the chain? X.509 says the first case (unique only with
> > respect to a given subject). Does PKIX expand the scope of the identifier to
> > one of the other two levels I mentioned?
> >
> > -----Original Message-----
> > From: Marc Branchaud [mailto:[e-mail]]
> > Sent: Tuesday, November 03, 1998 11:59 AM
> > To: [e-mail]
> > Subject: Re: keyIdentifiers
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > Content-Type: text/plain; charset=us-ascii
> >
> > Robert Moskowitz <[e-mail]> scrawled:
> > >
> > > Not according to a presentation Chicani gave to the federal PKI TWG back
> > in
> > > the spring.  He was quite clear that it was an APP issue to use
> > > keyIdentifiers to build a cert chain.
> > >
> >
> > Sure, but the app doesn't have to construct any key identifiers, just use
> > the ones that are already in the certs.
> >
> > > Then last week Mike Myers was pointing out how an app can use keyIdentifer
> > > for simpler processing for renewals.  Mike could better discuss this then
> > > me remember it.
> > >
> >
> > That's a different, and new, usage for key identifiers which I haven't
> > heard of before.
> >
> > My point is that s'far as chain construction goes, apps don't need to know
> > how to create key identifiers.  If key IDs are to be used for other
> > purposes, then some standard method of construction is probably a good
> > idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> > identifiers, not apps.
> >
> >                 Marc
> >
> > +------------------------------------------------------------------------+
> >  Marc Branchaud                                  \/
> >  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
> >  [e-mail]        PKI References page:              www.xcert.com
> >  604-640-6227          www.xcert.com/~marcnarc/PKI/
> > +------------------------------------------------------------------------+
> >   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> >
> > iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> > YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> > F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> > =Itvv
> > -----END PGP SIGNATURE-----
> 
> --
> David Simonetti, Booz·Allen & Hamilton Inc.

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11329 for ietf-pkix-bks; Wed, 4 Nov 1998 08:20:18 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11325 for <[e-mail]>; Wed, 4 Nov 1998 08:20:16 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA95; Wed, 4 Nov 1998 11:22:52 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 11:23:11 -0500
To: "Phillip M Hallam-Baker" <[e-mail]>, "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: <[e-mail]>
In-Reply-To: <003501be080a$78830460$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:47 AM 11/4/98 -0500, Phillip M Hallam-Baker wrote:
>
>They would be expecting to issue far fewer than 2^30 (1 billion)
>certificates.
>
>I'm not sure that is a very good assumption. In fact its a lousy one on
>a planet with 5 billion people.

But you are counting carbon based life forms.  There will be many factors
more of silicon based life forms that will need certificates.  Mike O'dell,
in his comments on bandwidth consumption has already named all of these
various systems (PCSs, pagers, heart monitors, toasters, refigs) as silicon
cockroaches.

>We are not so short of bits that we need to skimp on them to create unique
>key IDs.
>
Some people are bandwidth conservative.  Some devices are indeed bandwidth
limited.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11003 for ietf-pkix-bks; Wed, 4 Nov 1998 07:45:09 -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 HAA10999 for <[e-mail]>; Wed, 4 Nov 1998 07:45:08 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA15850; Wed, 4 Nov 1998 07:44:59 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA15266; Wed, 4 Nov 1998 07:47:15 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: keyIdentifiers
Date: Wed, 4 Nov 1998 10:47:47 -0500
Message-ID: <003501be080a$78830460$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Kevin,
>
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.

They would be expecting to issue far fewer than 2^30 (1 billion)
certificates.

I'm not sure that is a very good assumption. In fact its a lousy one on
a planet with 5 billion people.

We are not so short of bits that we need to skimp on them to create unique
key IDs.

		Phill



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10796 for ietf-pkix-bks; Wed, 4 Nov 1998 07:13:20 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10792 for <[e-mail]>; Wed, 4 Nov 1998 07:13:19 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA309; Wed, 4 Nov 1998 10:16:03 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 04 Nov 1998 10:11:20 -0500
To: "Flanigan, Bill" <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: RE: Is certificate renewal a good idea?
In-Reply-To: <[e-mail] a.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 08:31 AM 11/4/98 -0500, Flanigan, Bill wrote:
>> 
>> It seems as though there are two cases to consider:
>> 1)  Same CA, same public key, different subject name
>> 2)  Same CA, same public key, same subject name, 
>>       different information in the certificate (e.g., alternative names,
>> validity period, CP/CPS)
>> 
>	Actually, the most prevalent case is likely to be:
>	3) Same CA, different public key, same CN
>
Really?  I always thought it would be validity date.  Of course this would
be about 18 months after PKI rollout.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA10058 for ietf-pkix-bks; Wed, 4 Nov 1998 05:28:27 -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 FAA10054 for <[e-mail]>; Wed, 4 Nov 1998 05:28:26 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV169PQ>; Wed, 4 Nov 1998 08:31:19 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: Is certificate renewal a good idea?
Date: Wed, 4 Nov 1998 08:31:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

See comments below.

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Tuesday, November 03, 1998 6:24 PM
> To:	[e-mail]
> Subject:	Is certificate renewal a good idea?
> 
> In the recent thread about keyIdentifiers, Robert Moskowitz and a few
> others have mentioned 
> certificate renewal.  I had found this topic conspicuously absent from any
> of the PKIX drafts and 
> had assumed that renewing certificates was considered bad practice.  Can
> someone enlighten 
> me?
> 
> It seems as though there are two cases to consider:
> 1)  Same CA, same public key, different subject name
> 2)  Same CA, same public key, same subject name, 
>       different information in the certificate (e.g., alternative names,
> validity period, CP/CPS)
> 
	Actually, the most prevalent case is likely to be:
	3) Same CA, different public key, same CN

	[snip]

> Comments?
> 
	Above.

> Tammy Green Carter
> [e-mail] 
> 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA03745 for ietf-pkix-bks; Tue, 3 Nov 1998 17:25:40 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA03741 for <[e-mail]>; Tue, 3 Nov 1998 17:25:39 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA65; Tue, 3 Nov 1998 20:28:21 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 20:20:15 -0500
To: Kevin Kingdon <[e-mail]>, "'Simonetti David'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 04:19 PM 11/3/98 -0800, Kevin Kingdon wrote:
>In a population of 2^30 certificates, there is a probability of ~50% that
>some two of them will have the same 60-bit identifier. This works out to ~1
>billion on my slide rule -- a large, but not unimaginable, population of
>"Internet" certificates.
>
This is why I prefer the full 160bit hash and damn the 25 byte hit on cert
size.

Speaking of cert size, what are people actually seeing in cert sizes?


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03431 for ietf-pkix-bks; Tue, 3 Nov 1998 16:38:19 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA03427 for <[e-mail]>; Tue, 3 Nov 1998 16:38:18 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Nov 1998 17:40:29 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 03 Nov 1998 16:23:41 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Subject: Is certificate renewal a good idea?
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 QAA03428
Sender: [e-mail]
Precedence: bulk

In the recent thread about keyIdentifiers, Robert Moskowitz and a few others have mentioned 
certificate renewal.  I had found this topic conspicuously absent from any of the PKIX drafts and 
had assumed that renewing certificates was considered bad practice.  Can someone enlighten 
me?

It seems as though there are two cases to consider:
1)  Same CA, same public key, different subject name
2)  Same CA, same public key, same subject name, 
      different information in the certificate (e.g., alternative names, validity period, CP/CPS)

It would seem to me that case #1 should be prohibited by a PKIX-compliant CA.  It would also
seem, on the surface, that case #2 should be discouraged as "bad practice."  Of course, case 
#2 cannot be prohibited by a CA since that would mean that a CA would have to store all of the 
certificates it ever generated and look through them each time it generated a new certificate.

Case #2 is troubling to me, however.  What would stop a subordinate (non-root) CA from doing 
the following:
A)  Get a certificate from a root CA with a CPS indicating that the subordinate CA assumed  
       a large amount of liability for certificates that it issued
B)  Collect lots of money issuing certificates to end entities
C)  Renew it's certificate using the same root CA with a different CPS indicating that the 
       subordinate CA assumed no liability for any certificates it issues, and set the validity 
       period in the certificate to be the same as in the previous certificate
In such a case, it would seem that the users who paid lots of money for their "high quality 
certificates" have just been swindled!  

Comments?


Tammy Green Carter
[e-mail] 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03320 for ietf-pkix-bks; Tue, 3 Nov 1998 16:16:44 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03316 for <[e-mail]>; Tue, 3 Nov 1998 16:16:42 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA335; Tue, 3 Nov 1998 19:19:23 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 19:18:10 -0500
To: "Simonetti David" <[e-mail]>, Kevin Kingdon <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 06:21 PM 11/3/98 -0500, Simonetti David wrote:
>
>I believe the key identifier is intended to be universally unique.  The
>profile does not state this.  However, I recall a presentation where
>someone was proving mathematically that taking 60 bits out of a SHA-1
>hash of the public key would provide sufficient uniqueness.  What is
>sufficient?  It was a very, very, very small fraction for a very, very
>large number of certificates.  Sorry for the generalities, but I'm not a
>mathematician.
>
Dave,

I heard that was for a smaller, Elliptic Curve, key pair.  Not an RSA 1024
(let alone an RSA 2048) key pair.  In fact Tim mentioned the development of
SHA2 for a larger hash...

So the choice of hashing scheme, by the CA, is related to the key
algorithm, selected for global uniqueness.  Full 160 bits for RSA 1024 and
60 bits for little EC.

I guess.

Therefor I am, I guess.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03283 for ietf-pkix-bks; Tue, 3 Nov 1998 16:14:14 -0800 (PST)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA03279 for <[e-mail]>; Tue, 3 Nov 1998 16:14:12 -0800 (PST)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 4 Nov 1998 00:30:52 UT
Received: by lobester.rsa.com with Internet Mail Service (5.5.2232.9) id <VQHAWM6L>; Tue, 3 Nov 1998 16:20:00 -0800
Message-ID: <[e-mail]>
From: Kevin Kingdon <[e-mail]>
To: "'Simonetti David'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers
Date: Tue, 3 Nov 1998 16:19: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

In a population of 2^30 certificates, there is a probability of ~50% that
some two of them will have the same 60-bit identifier. This works out to ~1
billion on my slide rule -- a large, but not unimaginable, population of
"Internet" certificates.

-----Original Message-----
From: Simonetti David [mailto:[e-mail]]
Sent: Tuesday, November 03, 1998 3:21 PM
To: Kevin Kingdon
Cc: '[e-mail]'
Subject: Re: keyIdentifiers


Kevin,

I believe the key identifier is intended to be universally unique.  The
profile does not state this.  However, I recall a presentation where
someone was proving mathematically that taking 60 bits out of a SHA-1
hash of the public key would provide sufficient uniqueness.  What is
sufficient?  It was a very, very, very small fraction for a very, very
large number of certificates.  Sorry for the generalities, but I'm not a
mathematician.

Dave S.

[Snip]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03198 for ietf-pkix-bks; Tue, 3 Nov 1998 16:01:03 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03191 for <[e-mail]>; Tue, 3 Nov 1998 16:01:02 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-113-61.s61.tnt5.ann.erols.com [207.172.113.61]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id TAA22102; Tue, 3 Nov 1998 19:03:28 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "Kevin Kingdon" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Robert Moskowitz" <[e-mail]>
Subject: Re: keyIdentifiers 
Date: Tue, 3 Nov 1998 19:01:17 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

If you're referring to ANSI X9.45, it relies on uniqueness
of (issuer + serial #), rather than key identifier.

Regards,
Rich

----------
> From: Robert Moskowitz <[e-mail]>
> To: Kevin Kingdon <[e-mail]>; '[e-mail]'
> Subject: RE: keyIdentifiers 
> Date: Tuesday, November 03, 1998 4:29 PM
> 
> At 12:45 PM 11/3/98 -0800, Kevin Kingdon wrote:
> >One issue that does affect applications is the scope of a key
identifier. Is
> >it unique for a given subject, a given CA, or globally unique? In other
> >words, can I build a certificate chain using just key identifiers, or do
I
> >have to use some combination of subject + identifier or issuer +
(subject)
> >identifier to build the chain? X.509 says the first case (unique only
with
> >respect to a given subject). Does PKIX expand the scope of the
identifier to
> >one of the other two levels I mentioned?
> >
> I have been in discussions where there is an ASSUMPTION that the scope is
> fairly broad, provided that the users use a different key pair for all of
> their certs.  In fact, if I remember right about one aspect of the X.9
> attribute cert doc, it puts a lot of reliance on uniqueness of
> keyIdentifer.  Now I could be remembering wrong; I can't pull the doc
right
> now, and it was not necessarily the final markup version.
> 
> 
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03199 for ietf-pkix-bks; Tue, 3 Nov 1998 16:01:03 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03189 for <[e-mail]>; Tue, 3 Nov 1998 16:01:02 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-113-61.s61.tnt5.ann.erols.com [207.172.113.61]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id TAA22143; Tue, 3 Nov 1998 19:03:35 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "Simonetti David" <[e-mail]>, "Kevin Kingdon" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: keyIdentifiers
Date: Tue, 3 Nov 1998 19:04:34 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk

I'm concerned that this is changing what's in X.509; people (not
CertCo:-) may have implemented to that.  It would be better to
define a separate extension for a unique key ID...

Regards,
Rich

----------
> From: Simonetti David <[e-mail]>
> To: Kevin Kingdon <[e-mail]>
> Cc: '[e-mail]'
> Subject: Re: keyIdentifiers
> Date: Tuesday, November 03, 1998 6:21 PM
> 
> Kevin,
> 
> I believe the key identifier is intended to be universally unique.  The
> profile does not state this.  However, I recall a presentation where
> someone was proving mathematically that taking 60 bits out of a SHA-1
> hash of the public key would provide sufficient uniqueness.  What is
> sufficient?  It was a very, very, very small fraction for a very, very
> large number of certificates.  Sorry for the generalities, but I'm not a
> mathematician.
> 
> Dave S.
> 
> Kevin Kingdon wrote:
> > 
> > One issue that does affect applications is the scope of a key
identifier. Is
> > it unique for a given subject, a given CA, or globally unique? In other
> > words, can I build a certificate chain using just key identifiers, or
do I
> > have to use some combination of subject + identifier or issuer +
(subject)
> > identifier to build the chain? X.509 says the first case (unique only
with
> > respect to a given subject). Does PKIX expand the scope of the
identifier to
> > one of the other two levels I mentioned?
> > 
> > -----Original Message-----
> > From: Marc Branchaud [mailto:[e-mail]]
> > Sent: Tuesday, November 03, 1998 11:59 AM
> > To: [e-mail]
> > Subject: Re: keyIdentifiers
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 
> > Content-Type: text/plain; charset=us-ascii
> > 
> > Robert Moskowitz <[e-mail]> scrawled:
> > >
> > > Not according to a presentation Chicani gave to the federal PKI TWG
back
> > in
> > > the spring.  He was quite clear that it was an APP issue to use
> > > keyIdentifiers to build a cert chain.
> > >
> > 
> > Sure, but the app doesn't have to construct any key identifiers, just
use
> > the ones that are already in the certs.
> > 
> > > Then last week Mike Myers was pointing out how an app can use
keyIdentifer
> > > for simpler processing for renewals.  Mike could better discuss this
then
> > > me remember it.
> > >
> > 
> > That's a different, and new, usage for key identifiers which I haven't
> > heard of before.
> > 
> > My point is that s'far as chain construction goes, apps don't need to
know
> > how to create key identifiers.  If key IDs are to be used for other
> > purposes, then some standard method of construction is probably a good
> > idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> > identifiers, not apps.
> > 
> >                 Marc
> > 
> >
+------------------------------------------------------------------------+
> >  Marc Branchaud                                  \/
> >  Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
> >  [e-mail]        PKI References page:             
www.xcert.com
> >  604-640-6227          www.xcert.com/~marcnarc/PKI/
> >
+------------------------------------------------------------------------+
> >   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A
E1
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> > 
> > iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> > YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> > F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> > =Itvv
> > -----END PGP SIGNATURE-----
> 
> -- 
> David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02927 for ietf-pkix-bks; Tue, 3 Nov 1998 15:18:41 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02923 for <[e-mail]>; Tue, 3 Nov 1998 15:18:40 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA66BA; Tue, 3 Nov 1998 18:21:13 -0500
Message-ID: <[e-mail]>
Date: Tue, 03 Nov 1998 18:21:27 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Kevin Kingdon <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: keyIdentifiers
References: <[e-mail]>
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 PAA02924
Sender: [e-mail]
Precedence: bulk

Kevin,

I believe the key identifier is intended to be universally unique.  The
profile does not state this.  However, I recall a presentation where
someone was proving mathematically that taking 60 bits out of a SHA-1
hash of the public key would provide sufficient uniqueness.  What is
sufficient?  It was a very, very, very small fraction for a very, very
large number of certificates.  Sorry for the generalities, but I'm not a
mathematician.

Dave S.

Kevin Kingdon wrote:
> 
> One issue that does affect applications is the scope of a key identifier. Is
> it unique for a given subject, a given CA, or globally unique? In other
> words, can I build a certificate chain using just key identifiers, or do I
> have to use some combination of subject + identifier or issuer + (subject)
> identifier to build the chain? X.509 says the first case (unique only with
> respect to a given subject). Does PKIX expand the scope of the identifier to
> one of the other two levels I mentioned?
> 
> -----Original Message-----
> From: Marc Branchaud [mailto:[e-mail]]
> Sent: Tuesday, November 03, 1998 11:59 AM
> To: [e-mail]
> Subject: Re: keyIdentifiers
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Content-Type: text/plain; charset=us-ascii
> 
> Robert Moskowitz <[e-mail]> scrawled:
> >
> > Not according to a presentation Chicani gave to the federal PKI TWG back
> in
> > the spring.  He was quite clear that it was an APP issue to use
> > keyIdentifiers to build a cert chain.
> >
> 
> Sure, but the app doesn't have to construct any key identifiers, just use
> the ones that are already in the certs.
> 
> > Then last week Mike Myers was pointing out how an app can use keyIdentifer
> > for simpler processing for renewals.  Mike could better discuss this then
> > me remember it.
> >
> 
> That's a different, and new, usage for key identifiers which I haven't
> heard of before.
> 
> My point is that s'far as chain construction goes, apps don't need to know
> how to create key identifiers.  If key IDs are to be used for other
> purposes, then some standard method of construction is probably a good
> idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
> identifiers, not apps.
> 
>                 Marc
> 
> +------------------------------------------------------------------------+
>  Marc Branchaud                                  \/
>  Chief PKI Architect                             /\CERT INTERNATIONAL INC.
>  [e-mail]        PKI References page:              www.xcert.com
>  604-640-6227          www.xcert.com/~marcnarc/PKI/
> +------------------------------------------------------------------------+
>   PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
> 
> iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
> YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
> F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
> =Itvv
> -----END PGP SIGNATURE-----

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02762 for ietf-pkix-bks; Tue, 3 Nov 1998 15:00:58 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA02758 for <[e-mail]>; Tue, 3 Nov 1998 15:00:56 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Tue, 03 Nov 1998 16:02:53 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Tue, 03 Nov 1998 16:02:36 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: A different architecture
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 PAA02759
Sender: [e-mail]
Precedence: bulk

Bill,

Just a clarifying note:  Novell's directory (called NDS) __is__ 
an X.500 directory.

Tammy Green Carter
[e-mail] 


>>> Bill Burr <[e-mail]> 11-2-98 8:30:55 AM >>>
Elliot,

But DNS is a rather specialized sort of directory.  I don't know that it
follows that, because we can build a very specialized global DNS service,
that proves it is practical to build a very general global X.500 directory
service.  Nor does the success of DNS establish that the specific X.500
standard itself is workable on a global scale, or even a local scale.  It
doesn't make a business case for creating a global X.500 PKI directory,even
if we have X.500 directory products that could do the job. It may be that
we should take the contrary lesson: that to be successful, a global service
must be lean and mean and focused, rather than grand and all encompassing.

I don't have any certain answers here.  What bothers me as much as anything
is that PKI seems now to bear the main burden of the X.500 directory.  An
X.509 PKI would be relatively straightforward if there were an in-being
pervasive X.500 directory service, but is PKI a sufficient application to
drive the creation of a global X.500 directory service?  If the main reason
we are building a global X.500 directory service is PKI, maybe there are
simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
be one.

Another somewhat distressing thing is that, while directories seem to be
becoming central to distributed applications, and network operating
systems, they don't seem to be X.500 directories.  Netscape, Microsoft
(with NT 5.0) and Novell all seem to be relying on directories to glue
things together effectively, and hold configuration information.  But I
don't believe that any of them are X.500 directories.  So, in the real
world, most of us are going to have a directory of some sort, but it isn't
necessarily going to be an X.500 directory.  And it isn't obvious how we're
going to chain them all together, or even that we want to.

What does seem to be constant I think, even for "proper X.500" directories,
is some flavor (but which flavor?) of LDAP access.  

It isn't obvious that you want to let outsiders into the Active X
directory, or NDS directory that is near the core of your own system.
Maybe we need separate "border directories" and maybe those could be X.500
directories, all chained together.  But do we then have to maintain two
kinds of directory products, one internal and one external?  And how do we
manage the shadowing of the internal directory by the external directory?
Maybe we can manage this for DoD, or most of the Federal government, but
will the rest of the world go this way?

Another point: the apparatus for X.500 distinguished name assignment and
management, does apparently exist, but it seems to be expensive and few
folks actually seem to know how to get a DN, or to have done it.  Managing
a consistent global DIT for the Federal Gov. seems possible if not trivial,
but can we expand that to the country or the world?  It may be primitive,
in some ways, but the DNS management does exist (although I guess it's
changing a bit), it's cheap to get a domain name, practically any ISP will
do it for you, and even I know how to get one this afternoon, if I want to.

Perhaps the best thing about Phill's proposal, as I understand it, is that
it doesn't really seem to demand or ask anything of the DNS that it isn't
already doing, and it seems like that extra load on the DNS would be very
small.

Maybe the worst thing is accepting Internet domain names as the foundation
of PKI naming.  But perhaps that's also a good thing, in that it is bowing
to reality: on the Internet it is domain names that matter.

Regards,

Bill Burr




At 08:00 AM 11/3/98 -0500, you wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01887 for ietf-pkix-bks; Tue, 3 Nov 1998 13:27:01 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01883 for <[e-mail]>; Tue, 3 Nov 1998 13:27:00 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA312; Tue, 3 Nov 1998 16:29:39 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 16:29:42 -0500
To: Kevin Kingdon <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: keyIdentifiers 
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 12:45 PM 11/3/98 -0800, Kevin Kingdon wrote:
>One issue that does affect applications is the scope of a key identifier. Is
>it unique for a given subject, a given CA, or globally unique? In other
>words, can I build a certificate chain using just key identifiers, or do I
>have to use some combination of subject + identifier or issuer + (subject)
>identifier to build the chain? X.509 says the first case (unique only with
>respect to a given subject). Does PKIX expand the scope of the identifier to
>one of the other two levels I mentioned?
>
I have been in discussions where there is an ASSUMPTION that the scope is
fairly broad, provided that the users use a different key pair for all of
their certs.  In fact, if I remember right about one aspect of the X.9
attribute cert doc, it puts a lot of reliance on uniqueness of
keyIdentifer.  Now I could be remembering wrong; I can't pull the doc right
now, and it was not necessarily the final markup version.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01577 for ietf-pkix-bks; Tue, 3 Nov 1998 12:46:04 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01573 for <[e-mail]>; Tue, 3 Nov 1998 12:46:03 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA334; Tue, 3 Nov 1998 15:48:42 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 15:48:47 -0500
To: Marc Branchaud <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers 
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Nov 1998 14:34:25 EST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 07:58 PM 11/3/98 +0000, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Robert Moskowitz <[e-mail]> scrawled:
>> 
>> Not according to a presentation Chicani gave to the federal PKI TWG back in
>> the spring.  He was quite clear that it was an APP issue to use
>> keyIdentifiers to build a cert chain.
>> 
>
>Sure, but the app doesn't have to construct any key identifiers, just use 
>the ones that are already in the certs.

My understanding also.  Your earlier message came through poorly formatted
and I did not read it carefully.  the CA creates the hash, and the app just
uses it.

I think another usage of the hash (if I remember right) is the index for
attribute certs.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01508 for ietf-pkix-bks; Tue, 3 Nov 1998 12:39:52 -0800 (PST)
Received: from eagle.rsa.com (eagle.rsa.com [192.80.211.35]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA01503 for <[e-mail]>; Tue, 3 Nov 1998 12:39:51 -0800 (PST)
Received: from [10.81.217.217] by eagle.rsa.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 3 Nov 1998 20:56:30 UT
Received: by lobester.rsa.com with Internet Mail Service (5.5.2232.9) id <VQHAWMK4>; Tue, 3 Nov 1998 12:45:38 -0800
Message-ID: <[e-mail]>
From: Kevin Kingdon <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: keyIdentifiers 
Date: Tue, 3 Nov 1998 12:45:27 -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

One issue that does affect applications is the scope of a key identifier. Is
it unique for a given subject, a given CA, or globally unique? In other
words, can I build a certificate chain using just key identifiers, or do I
have to use some combination of subject + identifier or issuer + (subject)
identifier to build the chain? X.509 says the first case (unique only with
respect to a given subject). Does PKIX expand the scope of the identifier to
one of the other two levels I mentioned?

-----Original Message-----
From: Marc Branchaud [mailto:[e-mail]]
Sent: Tuesday, November 03, 1998 11:59 AM
To: [e-mail]
Subject: Re: keyIdentifiers 


-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Robert Moskowitz <[e-mail]> scrawled:
> 
> Not according to a presentation Chicani gave to the federal PKI TWG back
in
> the spring.  He was quite clear that it was an APP issue to use
> keyIdentifiers to build a cert chain.
> 

Sure, but the app doesn't have to construct any key identifiers, just use 
the ones that are already in the certs.

> Then last week Mike Myers was pointing out how an app can use keyIdentifer
> for simpler processing for renewals.  Mike could better discuss this then
> me remember it.
> 

That's a different, and new, usage for key identifiers which I haven't 
heard of before.

My point is that s'far as chain construction goes, apps don't need to know
how to create key identifiers.  If key IDs are to be used for other
purposes, then some standard method of construction is probably a good
idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
identifiers, not apps.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
=Itvv
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01201 for ietf-pkix-bks; Tue, 3 Nov 1998 11:56:51 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01197 for <[e-mail]>; Tue, 3 Nov 1998 11:56:50 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id TAA10074 for <[e-mail]>; Tue, 3 Nov 1998 19:58:39 GMT
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: [e-mail]
Subject: Re: keyIdentifiers 
In-Reply-To: Your message of "Tue, 03 Nov 1998 14:34:25 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 19:58:39 +0000
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


Robert Moskowitz <[e-mail]> scrawled:
> 
> Not according to a presentation Chicani gave to the federal PKI TWG back in
> the spring.  He was quite clear that it was an APP issue to use
> keyIdentifiers to build a cert chain.
> 

Sure, but the app doesn't have to construct any key identifiers, just use 
the ones that are already in the certs.

> Then last week Mike Myers was pointing out how an app can use keyIdentifer
> for simpler processing for renewals.  Mike could better discuss this then
> me remember it.
> 

That's a different, and new, usage for key identifiers which I haven't 
heard of before.

My point is that s'far as chain construction goes, apps don't need to know
how to create key identifiers.  If key IDs are to be used for other
purposes, then some standard method of construction is probably a good
idea.  PKIX part1 (perhaps not very clearly) expects CAs to build key
identifiers, not apps.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj9gblrdFXNdDxPlAQFCSwL+KeJshlbX05hbLWXcE2CXB1YZt2rg4t6w
YBwyyKI9XI2VyXxabhO34iFtYBccLHkBB9w8Dhed81T23GojWEv8kloDoPW6RszK
F9EY7+6W2tp9cMoKzSmkVtOKuclc9p+g
=Itvv
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA01077 for ietf-pkix-bks; Tue, 3 Nov 1998 11:31:31 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01073 for <[e-mail]>; Tue, 3 Nov 1998 11:31:30 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA329; Tue, 3 Nov 1998 14:34:06 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 14:34:25 -0500
To: Marc Branchaud <[e-mail]>, "Simonetti David" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers 
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Nov 1998 09:39:25 EST."             <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 05:29 PM 11/3/98 +0000, Marc Branchaud wrote:

Not according to a presentation Chicani gave to the federal PKI TWG back in
the spring.  He was quite clear that it was an APP issue to use
keyIdentifiers to build a cert chain.

Then last week Mike Myers was pointing out how an app can use keyIdentifer
for simpler processing for renewals.  Mike could better discuss this then
me remember it.

>
>Further to this, doesn't end-entity software treat a key identifier as a =
>
>black blob?  In other words, it's up to the CA to include these things in=
> =
>
>its certs, and if they're there then the end-entity app just grabs the =
>
>value and looks for a match in other certs.  That app has no business =
>
>conjuring up a key ID from the public key in a cert and trying to match i=
>t =
>
>to other conjured-up key IDs -- it would be better off just matching up =
>
>the keys directly anyway.
>
>If the CA wants its PKI to use key IDs, it'll put them in its certs and
>that'll be that.  The PKIX recommendations for key ID derivation are for =
>
>CAs to follow, as in they choose one method and stick to it.  End-entity =
>
>apps need not concern themselves with such arcane matters.
>
>		Marc
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNj89flrdFXNdDxPlAQGbhAL9Gk0lN063hZodHTvdGi3A8l1ijyANrJp/
>POHaCLC8qfB41awFY4lPx8bwlSecnMbgu6HRc3RLIRlkNQ2sjPsNLL39x8kE2+lz
>oQ+60LGoKxuBjyeCHxi1SSB7tbNXot6K
>=yK7A
>-----END PGP SIGNATURE-----

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29888 for ietf-pkix-bks; Tue, 3 Nov 1998 09:29:03 -0800 (PST)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29884 for <[e-mail]>; Tue, 3 Nov 1998 09:29:02 -0800 (PST)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id RAA03060; Tue, 3 Nov 1998 17:29:34 GMT
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "Simonetti David" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: keyIdentifiers 
In-Reply-To: Your message of "Tue, 03 Nov 1998 09:39:25 EST." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 17:29:34 +0000
From: Marc Branchaud <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


"Simonetti David" <[e-mail]> scrawled:
> =

> Peter,
> =

> The text you pasted from the profile is one of two recommended methods
> for generating a key identifier.  However, neither is required.  I thin=
k
> the current text mostly accomodates your suggestions.
> =


Further to this, doesn't end-entity software treat a key identifier as a =

black blob?  In other words, it's up to the CA to include these things in=
 =

its certs, and if they're there then the end-entity app just grabs the =

value and looks for a match in other certs.  That app has no business =

conjuring up a key ID from the public key in a cert and trying to match i=
t =

to other conjured-up key IDs -- it would be better off just matching up =

the keys directly anyway.

If the CA wants its PKI to use key IDs, it'll put them in its certs and
that'll be that.  The PKIX recommendations for key ID derivation are for =

CAs to follow, as in they choose one method and stick to it.  End-entity =

apps need not concern themselves with such arcane matters.

		Marc



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNj89flrdFXNdDxPlAQGbhAL9Gk0lN063hZodHTvdGi3A8l1ijyANrJp/
POHaCLC8qfB41awFY4lPx8bwlSecnMbgu6HRc3RLIRlkNQ2sjPsNLL39x8kE2+lz
oQ+60LGoKxuBjyeCHxi1SSB7tbNXot6K
=yK7A
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29763 for ietf-pkix-bks; Tue, 3 Nov 1998 09:14:11 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29759 for <[e-mail]>; Tue, 3 Nov 1998 09:14:09 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id MAA03718; Tue, 3 Nov 1998 12:16:49 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA11845; Tue, 3 Nov 1998 12:16:48 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 12:19:04 -0500
To: Bill Burr <[e-mail]>
From: Elliott Ginsburg <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I did not advocate an X.500 directory, only that we are capable of creating
and administering a global directory space. I myself am looking at various
technologies. DNS is a great model for what can be done and for the value
of a global directory, but it may or not be overloading DNS to expect it to
take on another directory task. 

As far as DNs for naming, its too big a subject for me to tackle at this
time. Suffice it to say that I personally want my personal identity, based
upon which all kinds of conclusions will be drawn, to be as meaningful a
representation as possible, and not bound to domain naming constraints and
mnemonic email addresses.

Elliott

At 10:30 AM 11/2/98 , Bill Burr wrote:
>Elliot,
>
>But DNS is a rather specialized sort of directory.  I don't know that it
>follows that, because we can build a very specialized global DNS service,
>that proves it is practical to build a very general global X.500 directory
>service.  Nor does the success of DNS establish that the specific X.500
>standard itself is workable on a global scale, or even a local scale.  It
>doesn't make a business case for creating a global X.500 PKI directory,even
>if we have X.500 directory products that could do the job. It may be that
>we should take the contrary lesson: that to be successful, a global service
>must be lean and mean and focused, rather than grand and all encompassing.
>
>I don't have any certain answers here.  What bothers me as much as anything
>is that PKI seems now to bear the main burden of the X.500 directory.  An
>X.509 PKI would be relatively straightforward if there were an in-being
>pervasive X.500 directory service, but is PKI a sufficient application to
>drive the creation of a global X.500 directory service?  If the main reason
>we are building a global X.500 directory service is PKI, maybe there are
>simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
>be one.
>
>Another somewhat distressing thing is that, while directories seem to be
>becoming central to distributed applications, and network operating
>systems, they don't seem to be X.500 directories.  Netscape, Microsoft
>(with NT 5.0) and Novell all seem to be relying on directories to glue
>things together effectively, and hold configuration information.  But I
>don't believe that any of them are X.500 directories.  So, in the real
>world, most of us are going to have a directory of some sort, but it isn't
>necessarily going to be an X.500 directory.  And it isn't obvious how we're
>going to chain them all together, or even that we want to.
>
>What does seem to be constant I think, even for "proper X.500" directories,
>is some flavor (but which flavor?) of LDAP access.  
>
>It isn't obvious that you want to let outsiders into the Active X
>directory, or NDS directory that is near the core of your own system.
>Maybe we need separate "border directories" and maybe those could be X.500
>directories, all chained together.  But do we then have to maintain two
>kinds of directory products, one internal and one external?  And how do we
>manage the shadowing of the internal directory by the external directory?
>Maybe we can manage this for DoD, or most of the Federal government, but
>will the rest of the world go this way?
>
>Another point: the apparatus for X.500 distinguished name assignment and
>management, does apparently exist, but it seems to be expensive and few
>folks actually seem to know how to get a DN, or to have done it.  Managing
>a consistent global DIT for the Federal Gov. seems possible if not trivial,
>but can we expand that to the country or the world?  It may be primitive,
>in some ways, but the DNS management does exist (although I guess it's
>changing a bit), it's cheap to get a domain name, practically any ISP will
>do it for you, and even I know how to get one this afternoon, if I want to.
>
>Perhaps the best thing about Phill's proposal, as I understand it, is that
>it doesn't really seem to demand or ask anything of the DNS that it isn't
>already doing, and it seems like that extra load on the DNS would be very
>small.
>
>Maybe the worst thing is accepting Internet domain names as the foundation
>of PKI naming.  But perhaps that's also a good thing, in that it is bowing
>to reality: on the Internet it is domain names that matter.
>
>Regards,
>
>Bill Burr
>
>
>
>
>At 08:00 AM 11/3/98 -0500, you wrote:
>>I think it was on this thread that someone stated that 'we would never have
>>a global distributed directory'. But we already have one (DNS), so why is
>>it inconceivable that we would have another? I don't advocate stretching
>>DNS for this prupose, but it does suggest that we can create global
>>directories. Am I missing something here?
>>
>>Elliott Ginsburg
>>
>>
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29579 for ietf-pkix-bks; Tue, 3 Nov 1998 08:56:02 -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 IAA29575 for <[e-mail]>; Tue, 3 Nov 1998 08:56:00 -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 FAA32715; Wed, 4 Nov 1998 05:58:26 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91011230600046>; Wed, 4 Nov 1998 05:58:26 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: email oid
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 4 Nov 1998 05:58:26 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

David Wilson <[e-mail]> writes:
 
>>There are currently at least three different locations for specifying the
>>email address:
>>
>>  altName.rfc822Name (the correct one which noone actually uses)
>>  emailAddress (officially deprecated, but everyone uses it anyway)
>>  rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial
>>        fricative to anyone who can explain the origin of the rfc822Mailbox
>>        OID without referring the question to one of the RFC's authors.
>>        Answers on the back of a postcard to ...  I'll post the explanation in
>>        a week or so if anyone cares)
 
>I do not know of any standard X.500 schema that defines an attribute called
>altName.rfc822Name. Is there a schema which defines an X.500 attribute which
>uses the GeneralName ASN.1 syntax?
 
I meant the rfc822Name component of the subject/issuerAltName GeneralName.
PKIX requires that the email address be stored there instead of the various
places in which legacy implementations put it (that's PKIX part 1's words, not
mine :-).
 
>Since the much of the early work of this was done University College, London,
>the OIDs allocated to this were under the UCL arc. This is allocated according
>to a scheme based on IPSS X.25 addresses. The 2342 is the DNIC for the U.K.,
>and 234219200300 is the IPSS address for UCL.
 
Congratulations, you win the PKIX trivia quiz.  Would you like your fricative
emailed or via FTP?
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28299 for ietf-pkix-bks; Tue, 3 Nov 1998 07:29:13 -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 HAA28295 for <[e-mail]>; Tue, 3 Nov 1998 07:29:03 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA08852; Tue, 3 Nov 1998 10:29:47 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 02 Nov 1998 10:30:55 -0500
To: Elliott Ginsburg <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: A different architecture
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Elliot,

But DNS is a rather specialized sort of directory.  I don't know that it
follows that, because we can build a very specialized global DNS service,
that proves it is practical to build a very general global X.500 directory
service.  Nor does the success of DNS establish that the specific X.500
standard itself is workable on a global scale, or even a local scale.  It
doesn't make a business case for creating a global X.500 PKI directory,even
if we have X.500 directory products that could do the job. It may be that
we should take the contrary lesson: that to be successful, a global service
must be lean and mean and focused, rather than grand and all encompassing.

I don't have any certain answers here.  What bothers me as much as anything
is that PKI seems now to bear the main burden of the X.500 directory.  An
X.509 PKI would be relatively straightforward if there were an in-being
pervasive X.500 directory service, but is PKI a sufficient application to
drive the creation of a global X.500 directory service?  If the main reason
we are building a global X.500 directory service is PKI, maybe there are
simpler solutions.  Perhaps piggybacking on DNS, as Phill suggests, would
be one.

Another somewhat distressing thing is that, while directories seem to be
becoming central to distributed applications, and network operating
systems, they don't seem to be X.500 directories.  Netscape, Microsoft
(with NT 5.0) and Novell all seem to be relying on directories to glue
things together effectively, and hold configuration information.  But I
don't believe that any of them are X.500 directories.  So, in the real
world, most of us are going to have a directory of some sort, but it isn't
necessarily going to be an X.500 directory.  And it isn't obvious how we're
going to chain them all together, or even that we want to.

What does seem to be constant I think, even for "proper X.500" directories,
is some flavor (but which flavor?) of LDAP access.  

It isn't obvious that you want to let outsiders into the Active X
directory, or NDS directory that is near the core of your own system.
Maybe we need separate "border directories" and maybe those could be X.500
directories, all chained together.  But do we then have to maintain two
kinds of directory products, one internal and one external?  And how do we
manage the shadowing of the internal directory by the external directory?
Maybe we can manage this for DoD, or most of the Federal government, but
will the rest of the world go this way?

Another point: the apparatus for X.500 distinguished name assignment and
management, does apparently exist, but it seems to be expensive and few
folks actually seem to know how to get a DN, or to have done it.  Managing
a consistent global DIT for the Federal Gov. seems possible if not trivial,
but can we expand that to the country or the world?  It may be primitive,
in some ways, but the DNS management does exist (although I guess it's
changing a bit), it's cheap to get a domain name, practically any ISP will
do it for you, and even I know how to get one this afternoon, if I want to.

Perhaps the best thing about Phill's proposal, as I understand it, is that
it doesn't really seem to demand or ask anything of the DNS that it isn't
already doing, and it seems like that extra load on the DNS would be very
small.

Maybe the worst thing is accepting Internet domain names as the foundation
of PKI naming.  But perhaps that's also a good thing, in that it is bowing
to reality: on the Internet it is domain names that matter.

Regards,

Bill Burr




At 08:00 AM 11/3/98 -0500, you wrote:
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27641 for ietf-pkix-bks; Tue, 3 Nov 1998 06:36:48 -0800 (PST)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27637 for <[e-mail]>; Tue, 3 Nov 1998 06:36:47 -0800 (PST)
Received: from bah.com ([156.80.128.195]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.6)  with ESMTP id AAA2FD; Tue, 3 Nov 1998 09:39:11 -0500
Message-ID: <[e-mail]>
Date: Tue, 03 Nov 1998 09:39:25 -0500
From: "Simonetti David" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: keyIdentifiers
References: <[e-mail]>
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 GAA27638
Sender: [e-mail]
Precedence: bulk

Peter,

The text you pasted from the profile is one of two recommended methods
for generating a key identifier.  However, neither is required.  I think
the current text mostly accomodates your suggestions.

Dave S.

Peter Gutmann wrote:
> 
> Someone has just pointed out to me that the newer PKIX drafts have changed the
> keyIdentifier derivation to:
> 
> >      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
> >      value of the BIT STRING subjectPublicKey (excluding the tag,
> >      length, and number of unused bits).
> 
> Since this excludes the algorithm type and parameters, it can lead to
> identifier clashes in cases where the subjectPublicKey consists of just a
> single integer (which is the case for a number of algorithm types).  This
> means that someone could construct a key for a different algorithm which would
> appear identical using the current PKIX interpretation of the keyIdentifier,
> but distinct with other interpretations.  There are various denial-of-service
> attacks possible with this (chaining works with a non-PKIX implementation but
> not a PKIX-compliant one, assuming you're chaining off the keyIdentifier which
> noone actually seems to do at the moment).
> 
> Trawling through my collection of profiles I've found that:
> 
>   X.509v3 allows you to use both types of identifier, but other standards and
>   profiles recommend against this.  Various profiles have at various times
>   required the use of the SHA-1 hash of the public key (whatever that
>   constitutes), the SHA-1 hash of the subjectPublicKeyInfo data (for some
>   reason this has to be done *without* the tag and length at the start), the
>   SHA-1 hash of the subjectPublicKey (again without the tag, length, and
>   unused bits portion of the BIT STRING, which leaves just the raw public key
>   data but omits the algorithm identifier and parameters so that two keys for
>   different algorithms with different parameters which happen to share the
>   same public key field end up with the same hash), a 60-bit hash of the
>   subjectPublicKeyInfo (presumably with the tag and length), a 64-bit hash of
>   the subjectPublicKey (again with tag and length) with the first four bits
>   set to 0100 to indicate the use of SHA-1, and some sort of unique value such
>   as a monotonically increasing sequence.  Several newer profiles have pretty
>   much given up on this and simply specify "a unique value".
> 
> Given the wide selection of choices, it might be better to just include some
> general guidelines on how to generate the keyIdentifier, including a note that
> the input to the hash should include all the parameters for the key (including
> algorithm type and whatnot), and to warn implementors not to expect any
> particular format for the keyIdentifier.
> 
> In addition, moving from a MUST to a MAY also seems to be a good idea, since
> (a) there's no consensus on what to put in there so you'll see all sorts of
> odd stuff, and (b) most implementations either ignore this value entirely or
> function just as well without it.  I don't really see why this has to be a
> MUST anyway, a MAY makes much more sense since it may be required for
> disambiguation in some cases but certainly isn't needed (or used) by virtually
> everything which is currently out there - it's just more useless baggage to
> cart around in a cert.
> 
> Peter.
> 

-- 
David Simonetti, Booz·Allen & Hamilton Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27123 for ietf-pkix-bks; Tue, 3 Nov 1998 05:13:57 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27118 for <[e-mail]>; Tue, 3 Nov 1998 05:13:56 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id IAA03808 for <[e-mail]>; Tue, 3 Nov 1998 08:16:35 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA20537; Tue, 3 Nov 1998 08:16:32 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 08:18:48 -0500
To: [e-mail]
From: Elliott Ginsburg <[e-mail]>
Subject: Fwd: Re: A different architecture
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I'm adding to my own message. Someone also stated on the list that we do
not want to have a directory between our apps and our PKI services. But,
again, how often today do we have DNS between our apps and our network
communication services?

Elliott Ginsburg


>X-Sender: [e-mail]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Tue, 03 Nov 1998 08:00:45 -0500
>To: [e-mail]
>From: Elliott Ginsburg <[e-mail]>
>Subject: Re: A different architecture
>Sender: [e-mail]
>
>I think it was on this thread that someone stated that 'we would never have
>a global distributed directory'. But we already have one (DNS), so why is
>it inconceivable that we would have another? I don't advocate stretching
>DNS for this prupose, but it does suggest that we can create global
>directories. Am I missing something here?
>
>Elliott Ginsburg
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27098 for ietf-pkix-bks; Tue, 3 Nov 1998 05:08:18 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27094 for <[e-mail]>; Tue, 3 Nov 1998 05:08:16 -0800 (PST)
Received: from isode.com (actually sirius.isode.com)  by woozle.isode.com (local) with ESMTP; Tue, 3 Nov 1998 13:10:16 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: email oid 
In-reply-to: Your message of "Tue, 03 Nov 1998 16:20:52." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Nov 1998 13:10:10 +0000
Message-ID: <[e-mail]>
From: David Wilson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I have been forward this by a colleague, so I'm not exactly sure of the 
context...

> >The other day in trying to accommodate a legacy pki, I ran into a problem 
> >with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1 specifies 
> >that the oid used for an email address in the distinguished name is 
> >1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and 
> >others have been using 0.9.2342.19200300.100.1.3 which is for internet mail 
> >as specified in RFC1274.
>  
> There are currently at least three different locations for specifying the 
> email address:
>  
>   altName.rfc822Name (the correct one which noone actually uses)
>   emailAddress (officially deprecated, but everyone uses it anyway)
>   rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial 
>         fricative to anyone who can explain the origin of the rfc822Mailbox 
>         OID without referring the question to one of the RFC's authors.  
>         Answers on the back of a postcard to ...  I'll post the explanation in 
>         a week or so if anyone cares)
>  
> Peter.
>  
> 

I do not know of any standard X.500 schema that defines an attribute called 
altName.rfc822Name. Is there a schema which defines an X.500 attribute which 
uses the GeneralName ASN.1 syntax?

emailAddress and rfc822Mailbox are X.500 (and therefore LDAP) attributes. 

rfc822Mailbox is the common attribute type used for Internet email addresses 
in X.500/LDAP entries (going under a variety of names for LDAP). It is not 
normally used for naming, so the value is not normally in an RDN. The 
intention of the attribute is that its use is within a 'white pages' entry 
for an individual. It would be used by an Email client, for instance, when 
the client enables (L)DAP lookup, and gives the Email address to use.

It has been around for many years, certainly predating LDAP. It is an X.500 
Pilot attribute. Since the much of the early work of this was done University 
College, London, the OIDs allocated to this were under the UCL arc. This is 
allocated according to a scheme based on IPSS X.25 addresses. The 2342 is the 
DNIC for the U.K., and 234219200300 is the IPSS address for UCL.

(O.K. one of the authors is my boss, but I knew this anyway). 

David Wilson                                        [e-mail]
Isode Ltd.                                       Tel: [phone]
http://www.isode.com                             Fax: [phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA27040 for ietf-pkix-bks; Tue, 3 Nov 1998 04:55:55 -0800 (PST)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA27036 for <[e-mail]>; Tue, 3 Nov 1998 04:55:54 -0800 (PST)
Received: from mail92.mitre.org (mail92.mitre.org [129.83.20.76]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with SMTP id HAA29071 for <[e-mail]>; Tue, 3 Nov 1998 07:58:33 -0500 (EST)
Received: from m23132-pc.mitre.org by mail92.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA18569; Tue, 3 Nov 1998 07:58:29 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Tue, 03 Nov 1998 08:00:45 -0500
To: [e-mail]
From: Elliott Ginsburg <[e-mail]>
Subject: Re: A different architecture
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I think it was on this thread that someone stated that 'we would never have
a global distributed directory'. But we already have one (DNS), so why is
it inconceivable that we would have another? I don't advocate stretching
DNS for this prupose, but it does suggest that we can create global
directories. Am I missing something here?

Elliott Ginsburg



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA26928 for ietf-pkix-bks; Tue, 3 Nov 1998 04:29:13 -0800 (PST)
Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA26924 for <[e-mail]>; Tue, 3 Nov 1998 04:29:11 -0800 (PST)
Received: from rgm ([208.235.169.131]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAA312; Tue, 3 Nov 1998 07:31:39 -0500
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Tue, 03 Nov 1998 07:31:41 -0500
To: [e-mail], [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: keyIdentifiers
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <19981103123139725.AAA312@rgm>
Sender: [e-mail]
Precedence: bulk

At 09:27 PM 11/3/98 +0000, Peter Gutmann wrote:
> 
>Given the wide selection of choices, it might be better to just include some 
>general guidelines on how to generate the keyIdentifier, including a note
that 
>the input to the hash should include all the parameters for the key
(including 
>algorithm type and whatnot), and to warn implementors not to expect any 
>particular format for the keyIdentifier.  

I am not able to comment on this part of your observations, but...
 
>In addition, moving from a MUST to a MAY also seems to be a good idea, since 
>(a) there's no consensus on what to put in there so you'll see all sorts of 
>odd stuff, and (b) most implementations either ignore this value entirely or 
>function just as well without it.  I don't really see why this has to be a 
>MUST anyway, a MAY makes much more sense since it may be required for 
>disambiguation in some cases but certainly isn't needed (or used) by
virtually 
>everything which is currently out there - it's just more useless baggage to 
>cart around in a cert.
> 
I have seen two reasons for keyIdentifiers.

The first is by Chichani as a powerful way to build a cert chain.  Now this
is definitely a MAY and not a MUST, it would seem.

The second was brought to my attention by Myers as a clean way to handle
key renewal.  Since little of your field usage has dealt with renewals, we
have not seen this one yet.  But with the emergence of silicon based life
forms (eg IPsec devices), this will become more real in a year.

We need informational RFCs on the use of keyIdentifier for the PKIX
consuming market, ie S/MIME, TLS, and IPsec for starters.  This came out
load and clear last week at the IPsec workshop, where we were nailing down
which cert objects were important to implementors.

I fully intend to include keyIndentifiers (both subject and issuer) in the
ANX PKI and recommend other PKI builders to also push for clearification on
these objects.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20287 for ietf-pkix-bks; Tue, 3 Nov 1998 00:24:46 -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 AAA20280 for <[e-mail]>; Tue, 3 Nov 1998 00:24:44 -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 VAA27224 for <[e-mail]>; Tue, 3 Nov 1998 21:27:19 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91008163927679>; Tue, 3 Nov 1998 21:27:19 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: keyIdentifiers
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 3 Nov 1998 21:27:19 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Someone has just pointed out to me that the newer PKIX drafts have changed the 
keyIdentifier derivation to:
 
>      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
>      value of the BIT STRING subjectPublicKey (excluding the tag,
>      length, and number of unused bits).
 
Since this excludes the algorithm type and parameters, it can lead to 
identifier clashes in cases where the subjectPublicKey consists of just a 
single integer (which is the case for a number of algorithm types).  This 
means that someone could construct a key for a different algorithm which would 
appear identical using the current PKIX interpretation of the keyIdentifier, 
but distinct with other interpretations.  There are various denial-of-service 
attacks possible with this (chaining works with a non-PKIX implementation but 
not a PKIX-compliant one, assuming you're chaining off the keyIdentifier which 
noone actually seems to do at the moment).
 
Trawling through my collection of profiles I've found that:
 
  X.509v3 allows you to use both types of identifier, but other standards and 
  profiles recommend against this.  Various profiles have at various times 
  required the use of the SHA-1 hash of the public key (whatever that 
  constitutes), the SHA-1 hash of the subjectPublicKeyInfo data (for some 
  reason this has to be done *without* the tag and length at the start), the 
  SHA-1 hash of the subjectPublicKey (again without the tag, length, and 
  unused bits portion of the BIT STRING, which leaves just the raw public key 
  data but omits the algorithm identifier and parameters so that two keys for 
  different algorithms with different parameters which happen to share the 
  same public key field end up with the same hash), a 60-bit hash of the 
  subjectPublicKeyInfo (presumably with the tag and length), a 64-bit hash of 
  the subjectPublicKey (again with tag and length) with the first four bits 
  set to 0100 to indicate the use of SHA-1, and some sort of unique value such 
  as a monotonically increasing sequence.  Several newer profiles have pretty 
  much given up on this and simply specify "a unique value".
 
Given the wide selection of choices, it might be better to just include some 
general guidelines on how to generate the keyIdentifier, including a note that 
the input to the hash should include all the parameters for the key (including 
algorithm type and whatnot), and to warn implementors not to expect any 
particular format for the keyIdentifier.  
 
In addition, moving from a MUST to a MAY also seems to be a good idea, since 
(a) there's no consensus on what to put in there so you'll see all sorts of 
odd stuff, and (b) most implementations either ignore this value entirely or 
function just as well without it.  I don't really see why this has to be a 
MUST anyway, a MAY makes much more sense since it may be required for 
disambiguation in some cases but certainly isn't needed (or used) by virtually 
everything which is currently out there - it's just more useless baggage to 
cart around in a cert.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00243 for ietf-pkix-bks; Mon, 2 Nov 1998 19:20:46 -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 TAA00292 for <[e-mail]>; Mon, 2 Nov 1998 19:18:29 -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 QAA20102; Tue, 3 Nov 1998 16:20:52 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91006325228585>; Tue, 3 Nov 1998 16:20:52 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: email oid
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 3 Nov 1998 16:20:52 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>The other day in trying to accommodate a legacy pki, I ran into a problem 
>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1 specifies 
>that the oid used for an email address in the distinguished name is 
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and 
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail 
>as specified in RFC1274.
 
There are currently at least three different locations for specifying the 
email address:
 
  altName.rfc822Name (the correct one which noone actually uses)
  emailAddress (officially deprecated, but everyone uses it anyway)
  rfc822Mailbox (oddball location which virtually noone uses.  A free bilabial 
        fricative to anyone who can explain the origin of the rfc822Mailbox 
        OID without referring the question to one of the RFC's authors.  
        Answers on the back of a postcard to ...  I'll post the explanation in 
        a week or so if anyone cares)
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05714 for ietf-pkix-bks; Mon, 2 Nov 1998 08:14:20 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05710 for <[e-mail]>; Mon, 2 Nov 1998 08:14:18 -0800 (PST)
Received: from klerer.basit.com (shiva119 [128.209.144.119]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id LAA22965; Mon, 2 Nov 1998 11:15:24 -0500 (EST)
Message-ID: <005001be067c$107b9b00$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: "Miklos, Sue A." <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>, <[e-mail]>
Subject: Re: email oid
Date: Mon, 2 Nov 1998 11:15:49 -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.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk

Sandi,  If we want to do a complete job we need to widen the survey a
little.  We have three sets of names to deal with:  LDAP attribute name,
x.500 OID and RDN tag.  The places where an email address has been put (that
I have found in my wonderings around PKI) for secure email (which is
converging on SMIME) are as follows:

OID's:
1.2.840.113549.1.9.1
0.9.2342.19200300.100.1.3

LDAP attribute names:
mail
email
InternetAddress
RFC822mailbox
LabeledURI  (occasionally misspelled as LabelledURI)

RDN tags:
EA
EM

The syntax for LabeledURI is different than the others and may hold
information other than email address.  We can go through "who does what",
but I'm not sure that helpful since the mappings between the name sets are
all controllable.

Since I live in the x.500 world, I would prefer a single OID and can
tolerate as many LDAP (textual) synonyms as others require.  I would suspect
those running LDAP repositories may have a different opinion.  The variance
in RDN tag is a little disconcerting from a PKI point of view since the
x.500 name, to which a certificate binds a key, may change depending on how
the certificate viewer maps RDN OIDs to RDN tags.

Robert
-----Original Message-----
From: Miklos, Sue A. <[e-mail]>
To: 'Russ Housley' <[e-mail]>; 'Robert Klerer' <[e-mail]>
Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
<[e-mail]>
Date: Monday, November 02, 1998 10:31 AM
Subject: RE: email oid


>Robert, in a brief look at the Internet Person draft from netscape, it
>appears they are using the 'rfc822mailbox' oid ('mail' for short).  I
>was told that a quick search with netscape navigator and outlook express
>(LDAP interfaces) appear to search for the 'mail' attribute - mapped to
>rfc822mailbox?
>
>Could either the outlook or netscape folks tell us what they are
>searching on?  "mail" or "emailAddress"?  Is Entrust using the pkcs 9
>oid?
>
>I would like to ensure the specs we are generating capture the
>concensus.
>
>Thanks,
>Sandi
>
>>----------
>>From: Robert Klerer[SMTP:[e-mail]]
>>Sent: Friday, October 30, 1998 4:47 PM
>>To: Miklos, Sue A.; 'Russ Housley'
>>Cc: 'ietf-pkix'; [e-mail]
>>Subject: Re: email oid
>>
>>Sue,
>>
>>Adding the additional OID would not be the optimum solution.  Since if I
>>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>>problem.  pkix should NOT perpetuate the problem by again calling the same
>>thing two different names.
>>
>>Robert
>>
>>-----Original Message-----
>>From: Miklos, Sue A. <[e-mail]>
>>To: 'Russ Housley' <[e-mail]>
>>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]'
<[e-mail]>;
>>'[e-mail]' <[e-mail]>
>>Date: Friday, October 30, 1998 2:34 PM
>>Subject: RE: email oid
>>
>>
>>>Russ, and others, may I then request that it be included or is that not
>>>possible?
>>>
>>>Sandi
>>>
>>>>----------
>>>>From: Russ Housley[SMTP:[e-mail]]
>>>>Sent: Friday, October 30, 1998 1:35 PM
>>>>To: Miklos, Sue A.
>>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>>Subject: Re: email oid
>>>>
>>>>Sandi:
>>>>
>>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>>
>>>>Russ
>>>>
>>>>
>>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>>All,
>>>>>In the specifications for the schema for an international defense
>>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>>registered
>>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>>I would like to request that this remain in whatever documentation you
>>>>>develop.
>>>>>
>>>>>Thanks,
>>>>>Sandi Miklos
>>>>>>
>>>>>>
>>>>>>----------
>>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>>Subject: RE: email oid
>>>>>>
>>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>>if there is a demand for it.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>>To: [e-mail]
>>>>>>Subject: email oid
>>>>>>
>>>>>>
>>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>>problem
>>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>>specifies
>>>>>>that the oid used for an email address in the distinguished name is
>>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I
and
>>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>>mail
>>>>>>as specified in RFC1274.
>>>>>>
>>>>>>Since I believe that the intention is for both of these oids are meant
>>to
>>>>>>represent attributes that hold the same information, this discrepancy
>>may
>>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>>change part1 to refer to the more commonly used OID.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05599 for ietf-pkix-bks; Mon, 2 Nov 1998 07:57:03 -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 HAA05595 for <[e-mail]>; Mon, 2 Nov 1998 07:57:02 -0800 (PST)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA07408 for <[e-mail]>; Mon, 2 Nov 1998 10:59:24 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Mon, 02 Nov 1998 10:58:59 -0500
To: [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Scale (and the SRV record)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>[e-mail] wrote:
>> 
>> >If someone spoofed DNS the worst that would happen is that I would
>> >recieve a certificate I didn't trust (and would ignore) or no >certificate
>> at all.
>> 
>> Well, if you're only fetching certificates, probably.
>> 
>> But if you're fetching CRL's, then no.  Suppose a cert is compromised,
>> and CRLn is issued before the "next update" time purely because of
>> that compromise.  The adversary could spoof DNS and just send out
>> the valid, but outdated CRL(n-1) and potentially have quite a
>> window of opportunity.

>From what I've been reading here and elsewhere, it appears that many people
wish to require that relying parties always use the most up-to-date CRL when
performing a validation. I think this is a bad idea.

In general, a CRL provides the revocation status of a large number of
certificates
and is designed to be cached. If a relying party must check with a repository
for the freshest available revocation information each time it performs a
validation,
then a scheme, such as OCSP, which only provides the revocation status of
the certificate to be validated makes more sense.

If CRLs are to be used, then the CA must allow for validations to be performed
based on "old" revocation information. If the CA wishes to insure that
validations
are never performed using revocation information that is more than 4 hours old
then it should issue CRLs AT LEAST once every 4 hours with each CRL having
a nextUpdate field set to 4 hours after the time of issuance. The CA must then
accept that some relying parties will base validations on CRLs that may
have been
replaced by fresher CRLs, even when the new CRLs were issued as a result of
a compromise.

At 03:53 PM 11/2/98 +0100, Andreas Berger wrote:
>That is if you assume that a CA is allowed to have several CRLs valid at
>a given point in time.
>
>Andreas

I most definitely want to allow a CA to have several CRLs valid at the same
time, but not for security reasons. I have been doing some work recently on
modeling the distribution of revocation information. The goal of the work
is to
determine, for any given situation, the best way to distribute revocation
information in order to minimize the peak load on the repository.

Suppose that a CA wishes to insure that relying parties always validate based
on revocation information that is at most 4 hours old. One option would be to
issue one CRL every 4 hours. However, if instead the CA issues one CRL every
hour, but still makes each CRL valid for 4 hours, the peak request rate to
the repository from relying parties will be lower. In general, the more
often new
CRLs are issued the lower the peak request rate. But, this reduction only
happens
if relying parties cache and continue to use the CRLs they download until the
time specified in nextUpdate is reached, not if they download a new CRL each
time a new one is issued.

David Cooper



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05385 for ietf-pkix-bks; Mon, 2 Nov 1998 07:28:23 -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 HAA05381 for <[e-mail]>; Mon, 2 Nov 1998 07:28:22 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA05956 for <[e-mail]>; Mon, 2 Nov 1998 10:30:57 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA05943 for <[e-mail]>; Mon, 2 Nov 1998 10:30:56 -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 KAA00456 for <[e-mail]>; Mon, 2 Nov 1998 10:30:00 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 02 Nov 1998 10:30:44 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <[e-mail]>; Mon, 2 Nov 1998 10:30:45 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=[e-mail]>
From: "Miklos, Sue A." <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "'Robert Klerer'" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: email oid
Date: Mon, 2 Nov 1998 10:30:44 -0500
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Robert, in a brief look at the Internet Person draft from netscape, it
appears they are using the 'rfc822mailbox' oid ('mail' for short).  I
was told that a quick search with netscape navigator and outlook express
(LDAP interfaces) appear to search for the 'mail' attribute - mapped to
rfc822mailbox? 

Could either the outlook or netscape folks tell us what they are
searching on?  "mail" or "emailAddress"?  Is Entrust using the pkcs 9
oid?

I would like to ensure the specs we are generating capture the
concensus.

Thanks,
Sandi

>----------
>From: 	Robert Klerer[SMTP:[e-mail]]
>Sent: 	Friday, October 30, 1998 4:47 PM
>To: 	Miklos, Sue A.; 'Russ Housley'
>Cc: 	'ietf-pkix'; [e-mail]
>Subject: 	Re: email oid
>
>Sue,
>
>Adding the additional OID would not be the optimum solution.  Since if I
>have an RDN of EA=[e-mail], am I referring to the RFC822mailbox or
>the pkcs-9 address?  Whichever choice will be wrong sometimes -- hence the
>problem.  pkix should NOT perpetuate the problem by again calling the same
>thing two different names.
>
>Robert
>
>-----Original Message-----
>From: Miklos, Sue A. <[e-mail]>
>To: 'Russ Housley' <[e-mail]>
>Cc: 'ietf-pkix' <[e-mail]>; '[e-mail]' <[e-mail]>;
>'[e-mail]' <[e-mail]>
>Date: Friday, October 30, 1998 2:34 PM
>Subject: RE: email oid
>
>
>>Russ, and others, may I then request that it be included or is that not
>>possible?
>>
>>Sandi
>>
>>>----------
>>>From: Russ Housley[SMTP:[e-mail]]
>>>Sent: Friday, October 30, 1998 1:35 PM
>>>To: Miklos, Sue A.
>>>Cc: 'ietf-pkix'; '[e-mail]'; '[e-mail]'
>>>Subject: Re: email oid
>>>
>>>Sandi:
>>>
>>>"Remain" is the issue.  It is not in PKIX part 1!
>>>
>>>Russ
>>>
>>>
>>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>>All,
>>>>In the specifications for the schema for an international defense
>>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>>registered
>>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>>I would like to request that this remain in whatever documentation you
>>>>develop.
>>>>
>>>>Thanks,
>>>>Sandi Miklos
>>>>>
>>>>>
>>>>>----------
>>>>>From: Wang, John[SMTP:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>>To: 'Robert Klerer'; [e-mail]
>>>>>Subject: RE: email oid
>>>>>
>>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>>if there is a demand for it.
>>>>>
>>>>>-----Original Message-----
>>>>>From: Robert Klerer [mailto:[e-mail]]
>>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>>To: [e-mail]
>>>>>Subject: email oid
>>>>>
>>>>>
>>>>>The other day in trying to accommodate a legacy pki, I ran into a
>problem
>>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1
>>>>>specifies
>>>>>that the oid used for an email address in the distinguished name is
>>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
>mail
>>>>>as specified in RFC1274.
>>>>>
>>>>>Since I believe that the intention is for both of these oids are meant
>to
>>>>>represent attributes that hold the same information, this discrepancy
>may
>>>>>cause confusion and failures in the future.  My suggestion would be to
>>>>>change part1 to refer to the more commonly used OID.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05291 for ietf-pkix-bks; Mon, 2 Nov 1998 07:18:41 -0800 (PST)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05287 for <[e-mail]>; Mon, 2 Nov 1998 07:18:40 -0800 (PST)
From: [e-mail]
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24762 for <[e-mail]>; Mon, 2 Nov 1998 10:21:02 -0500
Received: from rampal.raleigh.ibm.com (rampal.raleigh.ibm.com [9.37.178.98]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA24920 for <[e-mail]>; Mon, 2 Nov 1998 10:21:03 -0500
Received: by rampal.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15972; Mon, 2 Nov 1998 10:20:57 -0500
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.5 12/11/95
To: [e-mail]
Subject: PKI-LDAP interaction questions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Nov 98 10:20:57 -0500
Sender: [e-mail]
Precedence: bulk

All,
 
I have some basic questions on storing pki certificates on 
LDAP servers (am new to this stuff so apologise if I am 
missing something straightforward). 


1. Seems like several possible objectclasses can be used to store
certificates on an LDAP directory. draft-ietf-pkix-LDAPv2-schema-02.txt
mentions that the classes pkiUser and pkiCA MAY be used as part of other
objects to store certificates. The netscape directory server has objects like
strongAuthenticationUser and inetOrgPerson which contain attributes for 
certificates. It would appear that there is no standard objectClass 
which a PKI entity can use to search for on a directory. So, PKI entities
should know the exact DN of the entry (which is known out of band) to 
contain the certificate they are looking for (and not search for a 
particular object class), correct ? 

2. Are PKI entities supposed to know the format under which a certificate
is stored in a directory entry ? or is it always mandated to be DER ? 
(note: the netscape directory server has two kinds of attributes 
userCertificate and userCertificate;binary ...). 

3. The DN which a PKI entity uses to request a certificate from a CA need 
not be related in any way to the DN of the entry in which it is stored in the 
LDAP directory (though it might be convenient for them to be the same)
correct ?

4. The process by which a certificate published by a CA is installed on an 
LDAP directory is essentially expected to be out of band correct ? 
(though some CAs may provide the facility to include an LDAP client and 
directly load the certificate onto a specified directory server (if provided
the LDAP bind and DN information etc...).


Thanks,

Sanjeev.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05148 for ietf-pkix-bks; Mon, 2 Nov 1998 06:51:12 -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 GAA05144 for <[e-mail]>; Mon, 2 Nov 1998 06:51:06 -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 PAA25739; Mon, 2 Nov 1998 15:52:44 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 02 Nov 1998 15:53:37 +0100
From: Andreas Berger <[e-mail]>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i686)
MIME-Version: 1.0
To: [e-mail]
CC: "'Phillip M Hallam-Baker'" <[e-mail]>, [e-mail]
Subject: Re: Scale (and the SRV record)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

[e-mail] wrote:
> 
> >If someone spoofed DNS the worst that would happen is that I would
> >recieve a certificate I didn't trust (and would ignore) or no >certificate
> at all.
> 
> Well, if you're only fetching certificates, probably.
> 
> But if you're fetching CRL's, then no.  Suppose a cert is compromised,
> and CRLn is issued before the "next update" time purely because of
> that compromise.  The adversary could spoof DNS and just send out
> the valid, but outdated CRL(n-1) and potentially have quite a
> window of opportunity.
That is if you assume that a CA is allowed to have several CRLs valid at
a given point in time.

Andreas
--
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications